Core Banking Integration Patterns

Prerequisite: The External World

Your ACH origination file submitted at 4:47 PM ET returns a cryptic error: INVALID FIELD 37 BATCH CONTROL. The core banking platform — a Fiserv Premier instance running on an IBM zSeries mainframe — rejected the file because the batch entry count in the control record was a 6-digit number and the field width is 6 characters, but the COBOL program that parses it expects right-justified, zero-padded numeric strings. Your batch of 100,042 entries formatted the count as 100042, which is correct. But a downstream COBOL subroutine truncated it to 00042 because it read a PIC 9(5) instead of PIC 9(6). The fix is on the bank’s side. The timeline for the fix is “next quarterly release.” Your customers’ payroll runs tomorrow.

This is core banking integration. Three vendors — FIS, Fiserv, and Jack Henry — run the platforms behind roughly 80% of US depository institutions. Your fintech product does not move money without going through one of them, and the integration layer between modern APIs and 40-year-old mainframes is where most production incidents originate.

The Three Vendors

The US core banking market is an oligopoly. Each vendor serves a different segment, runs different technology, and exposes different integration surfaces.

Vendor	Platform(s)	Typical customer	Technology base	Market share (US banks)
FIS	IBS, Horizon, Modern Banking Platform	Large banks, top-20 institutions	IBM mainframe (IBS), cloud-native (MBP)	~35%
Fiserv	Premier, Signature, DNA	Mid-size banks, credit unions	IBM mainframe (Premier), .NET (DNA)	~30%
Jack Henry	SilverLake, CIF 20/20, Symitar	Community banks, credit unions	IBM AS/400 (SilverLake), AIX (Symitar)	~15%

The remaining 20% is fragmented across dozens of smaller vendors, plus the rare institution that built its own core. For integration purposes, if your partner bank has not told you which core they run, ask. The file formats, batch windows, error codes, and API surfaces differ across platforms, and testing against the wrong one wastes months.

File Formats: The Integration Lingua Franca

Core banking systems communicate primarily through files. Not APIs, not message queues — flat files with fixed-width fields, submitted and retrieved on batch schedules.

NACHA (ACH)

The NACHA file format is the standard for ACH origination and receipt. A file contains a file header, one or more batches (each with a batch header, entry detail records, optional addenda, and a batch control), and a file control record. Every field has a fixed position, fixed width, and specific alignment.

1   File Header       (94 chars)
5   Batch Header      (94 chars)
6   Entry Detail      (94 chars)  ← one per transaction
7   Addenda           (94 chars)  ← optional, for remittance data
8   Batch Control     (94 chars)
9   File Control      (94 chars)

Each record type is identified by the first character. Field 4 of the entry detail record — the transaction code — determines whether the entry is a credit or debit, checking or savings. The receiving DFI routing number occupies positions 4-11. The amount occupies positions 30-39 as a right-justified, zero-padded integer in cents.

NACHA files have no schema validation, no checksums beyond hash totals, and no structured error responses. A malformed file is rejected as a unit. You find out what went wrong by reading a human-written rejection notice, sometimes by phone.

BAI2 (Bank Administration Institute)

BAI2 is the standard for cash management reporting — your bank sends you a BAI2 file telling you what happened in your accounts. It carries opening balances, closing balances, individual transactions, and summary totals. The format is comma-delimited with a hierarchical structure: file header → group header → account header → transaction detail → account trailer → group trailer → file trailer.

01,ORIGINATOR,DESTINATION,210615,0800,1,80,1,2/
02,DESTINATION,ORIGINATOR,1,210615,0800,USD/
03,ACCTNUM,USD,010,50000000,,/
16,195,100000,0,210615,,REF123,Customer payment/
49,50100000,1/
98,50100000,1,1/
99,50100000,1,1/

Transaction type codes in BAI2 are three-digit numbers. Code 195 is a check paid. Code 399 is a miscellaneous credit. There are over 200 codes, and banks use them inconsistently. Your parser must handle the standard codes, bank-specific extensions, and the inevitable transaction with type code 000 that means “the core system didn’t know what to put here.”

OFX and ISO 20022

OFX (Open Financial Exchange) is XML-based and used primarily for consumer-facing data — account aggregation, bill payment, investment reporting. ISO 20022 (MX messages) is the modern standard for interbank communication. Both are structured, schema-validated, and self-describing. Both are also irrelevant for most core banking integration work, because the core systems predate them by decades and expose neither natively. You will encounter OFX and ISO 20022 at the edges — aggregation APIs, SWIFT messaging — but the core integration remains NACHA and BAI2.

Batch Windows

Core banking systems process work in batch cycles, not real-time streams. The batch schedule dictates when your files are processed and when you receive responses.

Window	Typical timing	What happens
Morning open	6:00–7:00 AM ET	Previous day’s batch results available, BAI2 files posted
ACH cutoff 1	10:00 AM ET	Same-day ACH window 1 origination deadline
ACH cutoff 2	2:45 PM ET	Same-day ACH window 2 origination deadline
Wire cutoff	4:30–5:00 PM ET	Last Fedwire submission for the day
End-of-day	6:00–8:00 PM ET	Batch processing begins — no file submissions accepted
Overnight batch	8:00 PM–6:00 AM ET	GL posting, interest accrual, statement generation, regulatory reporting

During the overnight batch window — typically 10-12 hours — the core system is processing the day’s work. File submissions are queued or rejected. Balance inquiries return the previous day’s closing balance, not the current position. If your product promises real-time balances to customers, understand that “real-time” means “as of the last time the core system told us,” and during the batch window, that timestamp is hours old.

See The External World. Batch windows are the fundamental constraint. Your API can respond in 50ms, but the core banking system behind it updates once a day.

Real-Time API Overlays

The vendors have built API layers on top of their batch cores. These overlays provide REST or SOAP interfaces for balance inquiries, transaction posting, and account management — but they are wrappers around batch operations, not replacements for them.

Fiserv DNA is the exception. DNA is a .NET-based core built in the 2000s with event-driven architecture. It supports real-time posting and balance updates without batch dependencies. DNA powers a small percentage of Fiserv’s install base — most institutions still run Premier on the mainframe.

Jack Henry Banno is a digital banking platform layered on top of SilverLake or Symitar. It provides modern APIs for mobile and web banking, but balance and transaction data flow through the core’s batch schedule. A memo-post (provisional credit) can appear in real-time on the Banno API while the actual ledger entry processes in the overnight batch.

FIS Modern Banking Platform is a cloud-native core built on AWS, designed to replace IBS over time. It offers real-time APIs, event-driven processing, and no batch windows. Adoption is early. Most FIS clients still run IBS on the mainframe.

Platform	Real-time balance	Real-time posting	Batch dependency
FIS IBS	Via memo-post	No — overnight batch	Full
FIS MBP	Yes	Yes	None
Fiserv Premier	Via memo-post	No — overnight batch	Full
Fiserv DNA	Yes	Yes	Minimal
Jack Henry SilverLake	Via memo-post	No — overnight batch	Full
Jack Henry Symitar	Via memo-post	Limited	Partial

The memo-post pattern deserves attention. When a core system cannot post a transaction in real-time, it records a memo — a provisional entry that updates the displayed balance but does not post to the general ledger until the next batch cycle. Memo-posts can be reversed during batch processing if validation fails. Your system must distinguish between memo-posted (provisional) and hard-posted (final) balances, because a memo-posted credit that reverses in batch creates a balance discrepancy that your customers will notice.

Error Handling Against Legacy Systems

Mainframe-based cores return errors in formats that predate structured error handling. You will encounter:

COBOL copybook error codes. The error is a numeric code defined in a COBOL copybook (a shared data structure definition). Code 0412 means “invalid routing number.” Code 0413 means “account not found.” Code 0414 might mean anything — the copybook definition was last updated in 2003, and new error conditions were added without updating the documentation.

Free-text rejection notices. The batch file was rejected and the response is a human-readable string: BATCH REJECTED - INVALID EFFECTIVE DATE. No error code, no field pointer, no structured data. Your parser must pattern-match against known rejection strings, and unknown strings go to a manual review queue.

Silent failures. The file was accepted, the acknowledgment was clean, but three of 10,000 entries did not post. The core system logged the failures internally but did not include them in the response file. You discover the problem during reconciliation the next morning — or the customer calls first.

The defensive pattern is reconciliation-first integration. Never trust the acknowledgment alone. For every file submitted, reconcile the expected entries against the core’s BAI2 output the following morning. Every entry you sent should appear in the BAI2 transaction detail. Entries that are missing are failures the core did not report.

Expected entries:     10,000
BAI2 reported:         9,997
Unmatched:                 3  ← investigate immediately

The COBOL Reality

Roughly 95% of ATM swipes and 80% of in-person banking transactions in the US touch COBOL code. The mainframes running FIS IBS and Fiserv Premier execute COBOL programs written between the 1970s and 1990s, maintained by engineers whose median age is over 55.

The engineering implications are concrete:

Character encoding. Mainframes use EBCDIC, not ASCII. File transfers between your system and the core require codepage conversion. A dollar sign in ASCII (0x24) is not a dollar sign in EBCDIC (0x5B). Get the conversion wrong and numeric fields become garbage.

Packed decimal. COBOL stores numbers in packed BCD (binary-coded decimal) format. The amount field 000012345C represents +$123.45 — each digit occupies a nibble, and the trailing nibble is the sign (C for positive, D for negative). Your parser must handle packed decimal correctly, and your test data must include negative amounts to verify the sign nibble.

Fixed-width fields. Every field in a COBOL record has a fixed width defined by a PIC clause. PIC 9(7)V99 means 7 integer digits and 2 decimal digits, no decimal point stored. PIC X(30) means 30 alphanumeric characters, left-justified, space-padded. Overflow is truncated silently — a 12-digit account number in a PIC X(10) field loses the last 2 digits without error.

Date formats. COBOL date fields use YYMMDD or YYYYMMDD depending on when the program was written and whether it was updated for Y2K. Some programs use Julian dates (YYDDD). Some use business-day counters relative to an epoch that only the original developer knew. Your integration must handle all of them.

Testing and Certification

Each core banking vendor requires certification before a fintech can submit production files. The certification process involves:

Format validation. Submit test files against a sandbox environment. The sandbox may or may not reflect the production system’s behavior — it is often a simplified version that accepts files the production system would reject.
Functional testing. End-to-end tests covering origination, return processing, and exception handling. The vendor provides test cases; your system must produce correct output for each one.
Production pilot. Limited-volume production files monitored by the vendor’s integration team. Typically 2-4 weeks.

Certification timelines vary from 4 weeks (Jack Henry, streamlined process) to 16 weeks (FIS, full certification for new originators). Plan for the long end. Your go-live date is not controlled by your engineering timeline — it is controlled by the vendor’s certification queue.

Vendor	Sandbox available	Certification timeline	Annual recertification
FIS	Yes (limited fidelity)	8–16 weeks	Yes
Fiserv	Yes	6–12 weeks	Varies by product
Jack Henry	Yes	4–8 weeks	No

The sandbox fidelity problem is worth emphasizing. A test file that passes the sandbox with zero errors may fail in production because the production system runs additional validations — field-level edits, cross-reference checks against the bank’s account master, or business rules specific to that institution’s configuration. The only reliable test environment is production, which is why the pilot phase exists and why you should not skip it.