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.

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.

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.

Bank Statement Formats: MT940 vs camt.053 vs BAI2

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: 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). 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. Its relatives: camt.052 (intraday report) and camt.054 (debit/credit notification).

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. 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	camt.052	(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.

Part of the Treasury Systems Architecture guide. See also bank connectivity channels and ISO 20022 payments. The newsletter sends one finance-systems pattern every two weeks.