# Bank Statement Formats: MT940 vs camt.053 vs BAI2

Source: https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: MT940, camt.053 and BAI2 are the main bank statement formats treasury imports: legacy SWIFT, modern ISO 20022, a US format. How they differ and which to use.

**MT940, camt.053 and BAI2 are the main formats a bank statement arrives in, and a treasury system has to import whatever its banks send.** MT940 is the legacy SWIFT flat-file standard — compact and everywhere, but limited in structure. camt.053 is the modern ISO 20022 XML statement — richer and more structured, the direction the industry is moving. BAI2 is a flat-file format used mainly in the US. The format matters because it determines how much a system can _automatically_ reconcile versus how much a human has to touch.

## What these formats are

All three are **end-of-day bank statements** — the file a bank sends reporting the prior day's opening and closing balances and every transaction. Your treasury system imports it to build the cash position and reconcile. (There are intraday cousins too — more below.) Remember the distinction from the [connectivity channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics): the format is _what the file says_; the channel is _how it travels_.

## MT940

MT940 is the SWIFT **Customer Statement Message** — a flat file of tagged fields (account, opening/closing balances, and a line per transaction; [tag by tag here](https://gravam.com/blog/mt940-format-tags-explained)). Its payment-side cousins are [a separate comparison](https://gravam.com/blog/mt101-vs-mt103-vs-mt202). It's compact, mature and extremely widely supported, which is why it's still the workhorse in many landscapes. Its weakness is **structure**: transaction detail is often packed into free-text fields, so richer information (remittance data, structured references) can be lost or hard to parse, which limits automatic matching. Its intraday sibling is **MT942** (interim transaction report).

## camt.053

camt.053 is the ISO 20022 **Bank-to-Customer Statement** — an **XML** end-of-day statement with a defined, structured schema. Because the data is structured rather than free-text, it can carry richer, cleaner information — better structured references and remittance detail — which supports **higher automatic reconciliation rates**. It's the direction of travel as [the industry migrates to ISO 20022](https://gravam.com/blog/iso-20022-migration-mt-to-mx). Its relatives: **camt.052** (intraday report) and **[camt.054](https://gravam.com/blog/camt-054-notification-explained)** (debit/credit notification). For what's actually inside the file — balances, entries, the Bank Transaction Code — see the [camt.053 field-level walkthrough](https://gravam.com/blog/camt-053-structure-and-fields).

> "We use camt.053" is not the whole story. Banks implement the ISO 20022 schema with variations — different usage of optional fields, different ways of populating references. So camt.053 from Bank A and Bank B may not be identical, and each still needs mapping and testing. The standard reduces variation; it doesn't eliminate it.

## BAI2

BAI2 is a statement format from the **Bank Administration Institute**, used mainly in the **United States**. Like MT940 it's a structured flat file, reporting balances and transactions with numeric **type codes** that classify each entry ([record by record here](https://gravam.com/blog/bai2-file-format-explained)). If your banks are US-based, BAI2 is common; outside the US, MT940 or camt.053 dominate.

## Comparison

|  | MT940 | camt.053 | BAI2 |
| --- | --- | --- | --- |
| **Type** | SWIFT flat file | ISO 20022 XML | Flat file (US) |
| **Structure** | Limited; free-text detail | Rich, structured schema | Structured, type-coded |
| **Auto-reconciliation** | Moderate | Higher (structured data) | Moderate |
| **Geography** | Global, legacy | Global, growing | Mainly US |
| **Intraday sibling** | [MT942](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) | [camt.052](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) | (intraday BAI variants) |
| **Direction of travel** | Being superseded | The target standard | US-specific |

## Why the format matters

It's not a technicality — it decides how much of reconciliation is automatic. Structured data (camt.053) lets the system match statement lines to expected items and open receivables with less human intervention; free-text-heavy formats (MT940) leave more to manual matching or fragile parsing rules. When teams complain that "reconciliation is manual," the statement format and how it's mapped is often part of the cause.

## Which to use, and migration

You largely take what your banks offer, but the strategic direction is **camt.053 / ISO 20022** for its richer data. Treat any move as a **per-bank migration**: confirm each bank's camt variant, map and test it against real statements, and expect to run MT940 and camt.053 in parallel through the transition. Don't assume one bank's camt file behaves like another's.

## What usually goes wrong

- **Assuming camt is uniform.** Bank-specific variations mean each camt.053 still needs mapping and testing.
- **Losing data in MT940.** Relying on free-text fields for references that then can't be parsed reliably.
- **Format vs channel confusion.** Agreeing a channel (SWIFT, host-to-host) without settling the statement format per bank.
- **No reconciliation testing.** Going live without testing statements against real reconciliation scenarios, then discovering the auto-match rate is poor.

Get the format and its mapping right per bank, favour structured formats where you can, and reconciliation quietly gets easier.

***

_See also [bank connectivity channels](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), [ISO 20022 payments](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), and what the statement is actually used for once it arrives: [the bank-reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation)._

## Primary sources

- Nordea — Account Statement Service MT940 file description — accessed 2026-07-29 — https://www.nordea.com/en/doc/2010-05-31accountstatementservicemt940en.pdf
- Nordea — Balance and Transaction Reporting (MT940/MT941/MT942) — accessed 2026-07-29 — https://www.nordea.dk/Images/38-49260/Balance_and_Transaction_Reporting.pdf
- Nordea — Corporate Access MIG camt.053.001.02 (BankToCustomerStatement) — accessed 2026-07-29 — https://www.nordea.com/en/doc/caar-camt-053-001-02-account-statement-standard.pdf
- DZ BANK — camt.053 / camt.052 bank account statement and reporting — accessed 2026-07-29 — https://corporates.dzbank.com/content/firmenkunden/en/homepage/products/transaction-banking/national-international_payments/iso-20022/camt-053-52.html
- Modern Treasury — BAI2 Files — accessed 2026-07-29 — https://www.moderntreasury.com/learn/bai2

## Questions this article answers

**Q: What is the difference between MT940 and camt.053?**

MT940 is the legacy SWIFT flat-file end-of-day statement format — widely used, compact, but with limited structure. camt.053 is the modern ISO 20022 XML end-of-day statement — richer, more structured data that supports better automatic reconciliation. camt.053 is the industry's direction of travel as part of the ISO 20022 migration, but MT940 is still very common, so many treasuries handle both.

**Q: What is BAI2 format?**

BAI2 is a bank statement file format defined by the Bank Administration Institute, used mainly in the United States. Like MT940 it is a structured flat file that reports balances and transactions with type codes. Where your banks are US-based, you'll often receive BAI2; elsewhere MT940 or camt.053 are more common.

**Q: Should we move from MT940 to camt.053?**

Generally the direction of travel is toward camt.053 (ISO 20022), because its richer, structured data improves automatic reconciliation and carries information MT940 can lose. But it's driven by what your banks support and your systems can consume, and there are bank-specific variations in camt files. Plan it as a migration per bank, test thoroughly, and expect to run both formats during the transition.