Skip to content
LegacyFile
← Learn

CAMT.053 vs MT940: What Changes When Your Bank Switches

By LegacyFile ·

The email from your bank says something like "as part of our ISO 20022 migration, MT940 statement delivery will be discontinued; please switch to camt.053." If your reconciliation process — a treasury system, an ERP import, or a well-worn spreadsheet macro — was built around MT940, that's not a trivial swap. The good news: camt.053 carries everything MT940 did and quite a bit more. Here's how the two formats line up, and what to watch when you make the move.

Why banks are switching

MT940 is a SWIFT message format from the 1980s: line-oriented text, colon-prefixed tags like :61: and :86:, and hard limits on line length. It served for four decades, but SWIFT is retiring the MT category for cash management in favor of ISO 20022 XML, and SEPA schemes already standardized on the camt family. camt.053 — the BankToCustomerStatement — is the designated end-of-day replacement. (For a full tour of the new format, see What is a CAMT.053 file?)

How the fields map

Every MT940 concept has a camt.053 home:

| MT940 | camt.053 | | ----------------------------- | ------------------------------------------- | | :20: transaction reference | Stmt > Id | | :25: account identification | Acct > Id > IBAN (or Othr > Id) | | :28C: statement number | ElctrncSeqNb / LglSeqNb | | :60F: opening balance | Bal with type OPBD | | :61: statement line | Ntry (amount, dates, CdtDbtInd) | | :61: N-code (e.g. NTRF) | BkTxCd domain/family/sub-family | | :86: information to owner | NtryDtls > TxDtls (parties, refs, text) | | :62F: closing balance | Bal with type CLBD |

The shape changes — colon tags become nested XML — but the statement is the same: opening balance, one record per transaction, closing balance.

What camt.053 adds

The :86: line was MT940's junk drawer: counterparty, references, and payment purpose all mashed into a few 65-character lines, formatted differently by every bank. camt.053 gives each of those a structured field:

  • Named counterparties. The debtor or creditor's name and IBAN live in RltdPties — no more parsing them out of free text.
  • End-to-end references. The EndToEndId the payer supplied survives the whole payment chain intact, which makes matching invoices dramatically more reliable.
  • Mandate IDs for SEPA direct debits, straight from Refs > MndtId.
  • Real transaction codes. Instead of bank-flavored N-codes, BkTxCd carries an ISO classification like PMNT.RCDT.ESCT with a published meaning.
  • Untruncated remittance info. Ustrd text isn't clipped to fit a line length.
  • Batch detail. A batch booking is one Ntry whose NtryDtls holds one TxDtls per underlying payment — the individual transactions MT940 could only summarize.

What to watch when you migrate

A few things genuinely change behavior, not just syntax:

  1. Row counts can differ. If your bank sends batch entries with full TxDtls detail, a statement that was 40 MT940 lines might legitimately become 90 camt.053 transactions. That's more data, not an error — but reconciliation totals built on line counts will move.
  2. Pending entries exist. camt.053 entries carry a status; PDNG items may appear that MT940 never showed. Filter on BOOK if you only want booked movements.
  3. Versions vary. camt.053.001.02 and .001.08 structure a few things differently (party names, status codes). Confirm which version your bank sends and that your tooling reads it.
  4. File size grows. XML is verbose; expect files ten times the size of the MT940 they replace. The content compresses well and parses fine — just don't be alarmed.
  5. Signs are explicit. Amounts are always positive in the XML; direction lives in CdtDbtInd. Anything that inferred debit/credit from MT940's D/C marks needs the equivalent logic.

Reading both formats without an ERP

During a migration you'll often hold both files for the same day — the old MT940 and the new camt.053 — and want to eyeball them side by side. Both LegacyFile converters run free in your browser with no upload: the CAMT.053 to CSV converter flattens the XML to one signed row per transaction with counterparties and references, and the MT940 to CSV converter does the same for the SWIFT format. Drop each file in, export CSV or Excel, and the comparison is a spreadsheet diff instead of an archaeology project.