camt.053 — the Bank-to-Customer Statement — is the ISO 20022 XML message your bank uses to report an account statement: every booking, every balance, every counterparty, in typed, structured elements instead of MT940's colon-delimited tags. It is the message corporate treasuries, ERPs, and reconciliation engines are migrating to as banks retire the SWIFT MT format — and unlike the payment-side migration driven by the November 2026 coexistence deadline, the statement move is happening bank by bank, which is why you keep receiving both formats right now.
The Document Skeleton
A camt.053 file is a Document root containing a single BkToCstmrStmt element with two children: a GrpHdr (message ID and creation timestamp) and one or more Stmt blocks — one per account statement. The namespace tells you the schema version: urn:iso:std:iso:20022:tech:xsd:camt.053.001.02 is the classic SEPA deployment; .001.08 is the current ISO release most new implementations adopt.
Inside Stmt you find the statement ID, optional sequence number, the reporting period (FrToDt), the Acct block identifying the account (IBAN, currency, owner, servicing agent), a list of Bal balances, and the Ntry list — the transactions.
Balance Types: More Than Opening and Closing
- OPBD — opening booked balance, equivalent of MT940 :60F:.
- CLBD — closing booked balance (:62F:) — the figure reconciliation ties to.
- CLAV — closing available balance (:64:) after holds and pending items.
- FWAV — forward available balances (:65:) for future value dates.
- ITBD — interim booked balance in intraday camt.052 reports.
Each Bal carries the amount with a Ccy attribute, a CdtDbtInd of CRDT/DBIT (a negative amount is never written — the indicator carries the sign), and a Dt. Bank-specific balance types appear as Prtry codes.
The Ntry: Anatomy of a Booking
Every Ntry replaces the MT940 :61:/:86: pair with named elements:
Amt Ccy="EUR"+CdtDbtInd— the amount and direction.RvslInd— replaces MT940's RC/RD reversal marks.Sts— BOOK (booked), PDNG (pending), INFO (informational).BookgDtvsValDt— posting date vs value date, no more guessing entry-date years.AcctSvcrRef— the bank's unique transaction reference, replacing the :61: bank reference.BkTxCd— domain/family/subfamily transaction codes instead of opaque :61: transaction types.
Details that MT940 crammed into free-text :86: live in NtryDtls > TxDtls: RltdPties (Dbtr/Cdtr name plus account), RltdAgts (counterparty BICs), Rfs (EndToEndId — your payment reference, the reconciliation key), and RmtInf — either unstructured Ustrd text or structured Strd with a CdtrRefInf creditor reference (SCOR) for QR-bill and Nordic KID-style payments.
camt.053 vs MT940: The Practical Differences
- Structured remittance: the :86: subfield guessing game (?00, ?20–?29, ?30–?34, SEPA TAG+) becomes typed elements — counterparty name, IBAN, BIC, EndToEndId, creditor reference each in their own field. This is why auto-matching rates jump on camt.
- Decimal point, not comma: amounts use
1234.56— no more locale-sensitive parsing. - Richer identification: account owner and servicing agent exist in the schema — fields MT940 could not express.
- One family, four messages: camt.052 for intraday reports (≈MT942), camt.054 for debit/credit notifications (≈MT900/910), camt.053 for the statement itself — same Ntry structure across all three.
Versions: .001.02 vs .001.08
SEPA deployments standardized on camt.053.001.02 (EBA/CGI guideline) — the version most banks still produce. The .001.08 release reorganizes some structures: remittance details consolidate under NtryDtls, component names shift, and the schema gains richer party and agent identification. For consumers the pragmatic answer is a namespace-agnostic parser that reads element local names — which is exactly how our tools work.
Working With camt Files
Inspect any message visually in our ISO 20022 Message Viewer, flatten a whole file to spreadsheet rows with the camt.053 to CSV converter, and check SEPA rulebook constraints with the SEPA XML Validator. Still receiving MT940? Convert it forward with MT940 → camt.053 — and see the MT940 format guide for the field-by-field mapping.
Frequently Asked Questions
Is camt.053 mandatory?
Not by a single mandate — the November 2026 SWIFT deadline covers payment instructions (pain/pacs), not statement reporting. But European banks are individually migrating statement delivery to camt.053, several already default to it, and some are retiring MT940 feeds entirely. Plan for a dual-format period rather than a single cutoff.
What is the difference between camt.053 and camt.052?
camt.053 is the end-of-day booked statement; camt.052 is the intraday account report — same Ntry structure, but entries carry PDNG status and ITBD balances. camt.054 covers single debit/credit notifications. All three share the camt schema family.
Why is my EndToEndId missing?
EndToEndId is populated by the payment originator, not the bank — it flows through from the pain.001 that created the booking. If the payment was sent without an end-to-end reference (or a bank generated the entry, e.g. fees), the field is absent. For reconciliation keys that always exist, use AcctSvcrRef.
How do I open camt.053 in Excel?
Excel cannot read the nested XML directly — flatten it first. Our camt.053 to CSV converter produces one row per Ntry with booking/value dates, signed amounts, counterparty, and remittance columns, entirely in your browser.
Does camt.053 replace MT940 everywhere?
In Europe, progressively. US and Asia-Pacific banks still ship MT940/BAI2 heavily, and even in SEPA some banks keep dual feeds. A reconciliation layer that reads both is the realistic target for the next few years.
