CAMT.053, MT940 and BAI2: the corporate statement formats

What they have in common

All three are designed for a bank to deliver statements to a corporate treasury or ERP system automatically, usually daily, usually over SWIFT, a host-to-host connection or a corporate banking portal rather than a website download button. None is something you get from consumer online banking, and none is aimed at a person reading it.

They carry more than a consumer format does: value dates alongside booking dates, opening and closing balances with explicit debit or credit marks, bank reference numbers, structured counterparty details, and transaction codes that say what kind of movement each line is.

CAMT.053: the ISO 20022 one

Formally camt.053.001.xx, the Bank to Customer Statement message, where the last two digits are the version: .02 is still the one most banks send, and later versions up to .13 add optional fields rather than removing any. It is XML, deeply nested, and the direction the industry has settled on as SWIFT MT messages are retired.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02">
 <BkToCstmrStmt>
  <GrpHdr><MsgId>STMT-20260315</MsgId><CreDtTm>2026-03-16T06:00:00</CreDtTm></GrpHdr>
  <Stmt>
   <Acct><Id><IBAN>DE89370400440532013000</IBAN></Id><Ccy>EUR</Ccy></Acct>
   <Bal><Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>        opening booked
        <Amt Ccy="EUR">10500.00</Amt><CdtDbtInd>CRDT</CdtDbtInd> ...</Bal>
   <Ntry>                                                  one entry
    <Amt Ccy="EUR">45.20</Amt>                             always positive
    <CdtDbtInd>DBIT</CdtDbtInd>                            direction here
    <Sts>BOOK</Sts>
    <BookgDt><Dt>2026-03-15</Dt></BookgDt>
    <ValDt><Dt>2026-03-15</Dt></ValDt>
    <BkTxCd><Domn><Cd>PMNT</Cd><Fmly><Cd>CCRD</Cd><SubFmlyCd>POSD</SubFmlyCd></Fmly></Domn></BkTxCd>
    <NtryDtls><TxDtls> ... <RmtInf><Ustrd>SHELL OIL 1234</Ustrd></RmtInf></TxDtls></NtryDtls>
   </Ntry>
   <Bal> ... <Cd>CLBD</Cd> ... </Bal>                       closing booked
  </Stmt>
 </BkToCstmrStmt>
</Document>

Two details trip up anyone writing a parser for the first time. Amounts are always positive, and the direction lives in a separate CdtDbtInd element, so a parser that ignores it books every payment as a receipt. And a single Ntry can contain several TxDtls, as when a bank books a batch of payments as one entry, so counting entries is not the same as counting transactions.

It is verbose by design: a single transaction carries booking date, value date, amount with an explicit currency, a three-level bank transaction code, end-to-end references and remittance information which may itself be structured. That richness is why treasury systems want it, and why it is unpleasant to read by hand.

MT940: the SWIFT one it is replacing

MT940, the Customer Statement Message, is a SWIFT format: tag-based, compact, and still very widely used. Rather than XML it uses numbered tags at the start of lines, with dates as YYMMDD and a comma as the decimal separator.

:61:2603150315D45,20NMSCNONREF//8812345
    260315      value date, YYMMDD
    0315        entry date, MMDD (optional)
    D           debit; C credit, RD/RC reversals
    45,20       amount, comma decimal, unsigned
    NMSC        transaction type code
    NONREF      account owner’s reference
    //8812345   bank’s reference
:86:SHELL OIL CARD 1234 LONDON

The :86: field is where interoperability goes to die. It is free text in principle, and every bank has structured it differently in practice, some with numbered sub-fields, some with slash codes such as /REMI/, some not at all, and a few exceed the standard length. A parser that works for one bank frequently fails on another. Reversal marks are the other trap: a parser that only expects D and C will choke on RD and RC.

MT940’s siblings are MT942, an interim intraday report, and MT950, the statement banks send to each other. If figures never reconcile, check which of them you are actually receiving.

Is MT940 being switched off?

Not yet, and not on the date often quoted. The November 2025 deadline in SWIFT’s ISO 20022 migration applied to cross-border payment instructions such as MT103, not to statements. SWIFT extended the coexistence period for reporting messages: under its published roadmap, institutions must be able to receive camt messages from November 2027, and the end of coexistence for MT940 and its siblings is planned for November 2028, with SWIFT itself noting that enforcement depends on how quickly the community adopts it.

Separate from SWIFT’s network rules, many European banks have already moved their own corporate customers to camt.053 or offer both. The practical advice is the same either way: new integrations should be built on camt.053, and an MT940 feed that works today is not an emergency.

BAI2: the US equivalent

BAI2 is the Bank Administration Institute’s Cash Management Balance Reporting format, the one US banks use for corporate cash reporting. Its successor is maintained by the standards body ASC X9 as the Balance and Transaction Reporting Standard, BTRS, which keeps the same record layout and is designed to be backwards compatible. Each line is a record identified by a leading two-digit code, fields are separated by commas, and each record ends with a slash.

03,123456789,USD,010,1050000,,,015,1045480,,/   010 opening, 015 closing ledger
16,475,4520,Z,8812345,CHK1042/                    475 = cheque paid, $45.20
88,SHELL OIL CARD 1234
49,2100000,4/                                      control total of 03, 16, 88 amounts; 4 records

Amounts carry no decimal point; the currency’s decimal places are implied, so 4520 in US dollars is $45.20. Type codes are numeric and standardised: 010 to 099 are balances and summaries, 100 to 399 credits, 400 to 699 debits. That standardisation is genuinely useful for automated posting, and the control totals in the trailers let a reader confirm nothing went missing in transit, which is more than either of the other two formats offers.

CAMT.052, .053 and .054 are three different messages

The ISO 20022 family is often referred to as “CAMT” as though it were one thing. Three messages matter, and receiving the wrong one accounts for a surprising share of confusion.

• camt.052: an intraday account report. What has happened so far today, provisional, and not a statement. The successor to MT942.
• camt.053: the statement proper. Final, for a closed period, and the one that reconciles. The successor to MT940.
• camt.054: a debit or credit notification. Advice that something specific happened, often the detail behind a batch, not a period summary.

Reconciling against a .052 will not work and is not meant to, because the day is not over. If figures never quite agree, checking which message the bank is actually sending is worth doing before anything else.

How the three map onto each other

MT940 and camt.053 carry broadly the same information, which is why migrations between them are possible at all. The mapping is lossy in one direction: camt.053 has structured fields for things MT940 pushes into free text, so converting camt to MT940 discards structure, and going the other way cannot invent it. SWIFT does not convert reporting messages between the two for you.

BAI2 sits apart. Its transaction type codes are standardised across US banks, which makes automated posting rules genuinely portable, something neither of the others quite manages, since MT940’s free-text field and banks’ proprietary codes in camt both vary by institution.

What to do if you have been handed one

• Check whether your accounting system reads it. Zoho Books lists CAMT.053, CAMT.054 and MT940 among its statement formats, TallyPrime’s Bank Statement import accepts MT940 for some banks, and most treasury and ERP systems handle all three. Small-business packages such as QuickBooks, Xero and MYOB generally handle none.
• Ask the bank for CSV or OFX as well. Corporate portals often offer both alongside the feed.
• Where neither is available, the PDF statement is the fallback everyone forgets: it exists for every account, covers every period, and converts to the formats small-business software reads.

We do not export these formats, and nothing here converts into them. This post exists because knowing what they are saves an afternoon of trying to make one work in software that was never going to read it.