The BAI2 file format is a comma-delimited bank statement standard that US banks use to report balances and transactions to corporate clients, built from numbered records such as 01, 03, 16, and 99. It sits alongside two other formats treasury teams meet constantly: SWIFT MT940, the tagged text statement common in cross-border and European banking, and camt.053, the ISO 20022 XML statement that is replacing it. According to the history of the BAI format, the Bank Administration Institute released BAI2 in 1987, and copyright moved to ASC X9 in 2008.
​

Most published guides cover one of these formats in isolation, usually as a bank's developer PDF. This article puts all three side by side: how each file is built, which banks and regions send which, and what the differences mean for a reconciliation team trying to match cash to invoices.
​

A bank statement file format is a machine-readable layout that a bank uses to send account balances and transaction lines to a company's ERP, treasury system, or reconciliation tool. It replaces the PDF statement with structured data, so software can post cash and match payments automatically instead of relying on staff to rekey figures.
​

Three formats cover most corporate statement traffic. BAI2 dominates US domestic reporting. MT940 is the SWIFT message for end-of-day customer statements, often paired with MT942 for intraday activity. camt.053 is the ISO 20022 equivalent of MT940, with camt.052 covering intraday reports and camt.054 covering individual debit and credit notifications, as J.P. Morgan's ISO 20022 FAQ describes when it maps MT9xx reporting to its camt equivalents.
​

Every format carries the same core facts: which account, which period, an opening balance, a list of entries, and a closing balance. Where they differ is in how much context each entry can hold, how strictly the fields are defined, and how easily a parser can tell one bank's output from another's. Those differences drive most of the effort in a treasury or accounts receivable software implementation.
​

A BAI2 file is a plain text file where each line is a record identified by a two-digit code. Records nest in a strict hierarchy: a file holds groups, a group holds accounts, and an account holds transactions. Each level has a header and a trailer, and trailers carry control totals so the receiver can confirm nothing was lost.
​

The Huntington BAI2 format guide sets out the record types most banks follow. Fields are separated by commas and each record ends with a slash.
​

The meaning of each balance and transaction sits in three-digit type codes. On the 03 record, Huntington lists 010 for opening ledger, 015 for closing ledger, 040 and 045 for opening and closing available, 100 for total credits, and 400 for total debits. Detail codes on the 16 record run from 101 to 728 in the same guide and identify transaction types such as ACH, wires, checks, and fees.
​

Amounts carry no decimal point. The currency code implies the decimal places, so a USD amount of 125000 means 1,250.00, per the Huntington specification. Parsers that ignore this rule produce balances off by a factor of 100, one of the most common first-week bugs in a BAI2 integration.
​

BAI stopped actively maintaining the format, and ASC X9 took over the copyright in 2008, according to the BAI format history. The successor standard is called BTRS, the Balance and Transaction Reporting Standard. Huntington describes its files as following BAI2 aligned with X9 BTRS reference standards, and the same guide notes previous-day files are available by 7:00 a.m. ET, with current-day files on a configurable schedule.
​

MT940 is a SWIFT customer statement message built from tagged fields, each starting with a colon and a field number. A statement opens with a reference and account, states an opening balance, lists entries as pairs of statement lines and narrative, and ends with a closing balance. It is text-based and compact, with tight character limits.
​

The core tags, as laid out in Paiementor's MT940 field analysis, are these:
​

The :61: line packs a lot into one string. It holds a six-digit value date, an optional four-digit entry date, a D or C debit and credit mark, an amount of up to 15 digits, a three-character transaction type code, and two references of up to 16 characters separated by a double slash, according to Paiementor.
​

The :86: field carries the narrative that reconciliation teams actually need, such as the payer name and invoice reference. Its format is 6*65x, meaning at most six lines of 65 characters, per the same field analysis. Deutsche Bank's corporate team puts the practical ceiling on MT940 remittance information at 390 characters.
​

An MT940 message is capped at 2,000 characters, according to Paiementor. Long statements are split across several messages numbered in :28C:. The first message opens with :60F: and closes with an intermediate :62M:, and later messages use :60M: until the final one closes with :62F:, as the Gravam MT940 tag walkthrough explains. A parser that only reads :60F: and :62F: will miss balances in the middle messages.
​

Content inside :86: is not standardized across banks. Some banks structure it with subfield codes, while others use free text. Deutsche Bank notes that MT940 relies on country-specific code systems such as German BTC and US BAI2, which is why the same payment can look different on statements from two banks.
​

camt.053 is the ISO 20022 bank-to-customer statement, delivered as XML with named, nested elements instead of positional fields. Each file holds a group header, one or more statements per account and period, and entries that can carry full transaction details, structured remittance data, and standardized bank transaction codes that read the same across banks.
​

The ValidateFin camt.053 field guide breaks the file into three levels. GrpHdr carries the message ID and creation timestamp. Stmt represents one account for one reporting period, including the IBAN and balances. Ntry holds each debit or credit, and inside it NtryDtls and TxDtls can hold one or many underlying transactions.
​

Those definitions come from the ValidateFin guide. Deutsche Bank adds that camt.053 supports theoretically unlimited remittance details, sender and recipient data that MT940 lacks, and fields for credit line amounts and interest rates.
​

camt.053 is not one fixed schema. Versions run from .02 through .11, with .02, .06, and .08 the most common at European banks, per ValidateFin. Deutsche Bank counts roughly 1,300 tags in v02 and more than 5,000 in v08. A company receiving statements from many banks may get several versions at once and needs a parser that handles each.
​

BAI2, MT940, and camt.053 all deliver balances and transactions, but they differ in syntax, geography, data depth, and future direction. BAI2 is a US domestic comma-delimited format, MT940 is a SWIFT tagged text message used internationally, and camt.053 is the XML standard that banks and Swift are moving statement traffic toward.
​

Region and banking relationship decide the format more than company preference. US banks deliver BAI2 as the standard domestic statement file. International banks and SWIFT-connected corporates have relied on MT940 for years. Banks in the SEPA zone increasingly send camt.053 by default, and global banks are adding camt reporting ahead of the ISO 20022 deadline for statements.
​

In the US, BAI2 remains the working format for most corporate balance reporting, and bank developer portals such as Huntington's publish their own BAI2 implementation guides. Because each bank can add its own detail codes and conventions, a company with five US banks often maintains five slightly different BAI2 mappings.
​

In Europe, camt.053 is the default statement format at most SEPA-zone banks, according to ValidateFin. Large multinationals often run both formats during transition. Deutsche Bank describes Merck moving about 1,200 bank accounts across 140 banking partners using a decoupled approach, where banks send MT940 and camt.053 in parallel while internal systems switch over account by account.
​

The November 2025 Swift milestone applied to cross-border payment messages, not statements. J.P. Morgan's FAQ states that, per current Swift communication, the end-of-coexistence period for statements and reporting messages is November 2028. The same page says J.P. Morgan will keep MT9xx as the default and move clients to camt.052, camt.053, and camt.054 on an opt-in basis starting in late 2026.
​

That gives treasury teams a planning window, not an excuse to wait. Parsers, ERP mappings, and matching rules built around MT940 narrative fields will need rework once the richer camt data arrives. Teams that also receive BAI2 from US banks will likely run all three formats for several years.
​

Format choice changes how much reconciliation a company can automate. BAI2 and MT940 carry limited, bank-specific narrative, so matching rules lean on references and fuzzy text. camt.053 carries structured remittance data, counterparty details, and standard transaction codes, which lets software match more payments to invoices without human review.
​

The weak point in both legacy formats is the narrative. In MT940, the payer name and invoice reference sit in :86:, limited to six lines of 65 characters per Paiementor. When a customer pays ten invoices in one transfer, the references often do not fit, and a cash application analyst has to find the remittance advice separately. camt.053 can carry multiple TxDtls under one entry, each with its own references, as the ValidateFin guide shows.
​

Deutsche Bank reports that initial estimates put the potential automation rate with camt.053 approaching 100%, against the manual workarounds that MT940 clearing often needs. That estimate depends on payers sending structured references in the first place, since the statement can only pass along what the payment carried.
​

BAI2 detail codes and the MT940 :61: type code both classify transactions, but each bank can extend or interpret them. camt.053's BkTxCd uses a shared domain, family, and subfamily structure, so a rule written for one bank's card settlements is more likely to work for another's. This is where cash application automation tools earn back their setup time.
​

Each format has its own integrity check, and a reconciliation pipeline should run it before posting anything:

These checks follow directly from the structures described by Huntington for BAI2 trailers and Gravam for MT940 split statements. Skipping them is how a truncated file quietly posts half a day of cash.
​

Most companies do not pick one format. They accept what each bank sends, normalize it into one internal model, and push banks toward camt.053 where available. The practical questions are which banks support which formats, how many camt versions arrive, and whether the treasury or ERP system can parse all of them.
​

A US-only business with a few domestic banks can run on BAI2 for the foreseeable future, since ASC X9 continues to maintain it as BTRS. A company with European entities should ask each bank for camt.053 now and confirm the version. A company still consuming MT940 from global banks should map the November 2028 date from J.P. Morgan's FAQ into its system roadmap and budget for parallel running.
​

The software layer does most of the work. Treasury management software and bank connectivity platforms usually ship parsers for all three formats and translate them into a common schema, which lets reconciliation rules stay the same when a bank changes format. When evaluating tools, ask for supported camt.053 versions, handling of BAI2 88 continuation records, and support for split MT940 statements.
​

Record codes, tag definitions, element names, version counts, and timeline dates in this article come from bank developer documentation (Huntington, Deutsche Bank, J.P. Morgan), a published BAI format history, and format reference guides, each linked where cited and accessed in September 2026. Bank implementations vary, so confirm details against each bank's own specification before building a parser.
​