MT940 vs BAI2 vs CAMT.053: Which Bank Statement Format?

Short answer: use CAMT.053 if your bank and ERP both support it, because the ISO 20022 XML format carries the richest, most self-describing data. Use BAI2 for US cash-management and balance reporting where CAMT is not available, and use MT940 when you deal with international or European banks that still deliver the legacy SWIFT format. All three describe the same thing (an end-of-day account statement with balances and transactions) but they encode it differently, so the right choice depends on what your bank offers and what your accounting or treasury system can read.

If you run treasury, accounts payable, or an ERP integration, you eventually have to pick a statement format for automated reconciliation. Banks rarely offer all three, and the one you choose shapes how much transaction detail flows into your system. Here is a practical comparison.

What is the difference between MT940, BAI2, and CAMT.053?

The difference is the encoding and the amount of detail each format carries. MT940 is a text file of tagged, fixed-length fields from the SWIFT MT standard. BAI2 is a comma-delimited format from the Bank Administration Institute built for US cash management. CAMT.053 is ISO 20022 XML with named, nested elements, so every transaction carries structured context such as remittance information, counterparty details, and standardized bank transaction codes. All three deliver an opening balance, a closing balance, and the day's transactions; CAMT.053 simply carries more of the surrounding detail in a machine-readable way.

Which format should you use for treasury?

For treasury, use CAMT.053 when your bank and treasury management system both support it, because it gives you the cleanest automated reconciliation and the richest transaction data. If you operate mainly in the United States and CAMT is not offered, BAI2 is the practical standard for balance and transaction reporting. Keep MT940 for banks (often European or international) that have not moved to ISO 20022 yet. Many corporates run a mix, so it is normal to receive BAI2 from one bank and CAMT.053 from another and normalize both into your system.

One reason CAMT.053 keeps winning is automation. The structured bank transaction code replaces MT940's looser GVC codes, so your system can categorize transactions reliably across banks instead of maintaining a lookup table per institution. Estimates from banks moving corporates off MT940 put the automation potential of the CAMT transition near 100 percent, because far less human intervention is needed to interpret each line.

Is MT940 being replaced by CAMT.053?

Yes. Across the industry, MT940 is being phased out in favor of ISO 20022 CAMT.053, which removes MT940's length and detail limits and carries structured remittance information. The transition is gradual, and many banks still deliver MT940 today, so you cannot assume it has disappeared. The safe plan is to accept both: keep your MT940 mapping in place for banks that still send it while adopting CAMT.053 wherever a bank offers it.

How do you convert these formats to Excel or CSV?

You convert them by parsing the format's structure and flattening the transactions into rows. For CAMT.053, read the XML entries into columns; our CAMT.053 to Excel converter handles the ISO 20022 nesting. For BAI2, map the type codes and continuation records into a table; the BAI to Excel converter and the walkthrough on converting a BAI2 file to CSV or Excel cover it. If your bank only gives you a PDF statement rather than an electronic file, extract the transactions from the PDF instead and export to the format your system wants. For engineering teams building an integration, a statement conversion API and a JSON export let you pull the same fields straight into code.

Once the statement data is in clean rows, the reporting layer gets much easier. A finance team can load a month of normalized transactions and ask plain-English questions of the data to spot balance swings or categorize spend, instead of hand-building pivot tables for every account. The format you receive from the bank matters most at the ingestion step; once the data is structured, every downstream report reads from the same clean source.

Common mistakes when working with these formats

Three problems account for most failed statement imports. The first is assuming two files of the same format are identical: CAMT.053 has many optional elements, and one bank may populate structured remittance data that another leaves blank, so a parser tuned to one bank can silently drop fields from another. The second is mishandling MT940 continuation and multi-line fields, where a single transaction spans several tag lines and a naive line-by-line reader splits one transaction into several. The third is misreading BAI2 type codes, since the same dollar amount means very different things depending on whether the code marks a credit, a debit, or a memo record, and getting the sign wrong quietly throws off every balance.

The fix for all three is the same: get a format specification from the bank and test against a real file before you trust the pipeline. Reconcile the parsed opening balance plus the sum of transactions against the parsed closing balance for every statement. If they do not tie out to the penny, the parser missed or double-counted a line, and you want to catch that on day one rather than after a month of automated postings. This footing check is cheap to run and catches the large majority of format-handling bugs.

Choosing in practice

Start from what your bank offers, then match it to what your system reads. Ask each bank for a format specification document so you know exactly which fields and codes to expect, because two banks sending CAMT.053 can still populate optional elements differently. If you are standardizing a new integration, target CAMT.053 first and fall back to BAI2 for US accounts that do not support it. Treat MT940 as a compatibility path you keep alive rather than a format you would choose fresh in 2026. And whichever formats you accept, build the balance footing check into ingestion so a malformed file is flagged before it reaches your ledger.