If your treasury or ERP system pulls statements straight from the bank, you're on one of two formats: the decades-old MT940 or the ISO 20022 XML statement camt.053. The short answer is ask for camt.053 if your systems can take it, because MT940 is deprecated and on a retirement path — but the timeline is widely misreported, so it's worth knowing exactly what is and isn't required of you.
Where the migration actually stands
The headline event people remember is November 2025, when SWIFT ended the coexistence period for cross-border payment messages — MT103 and MT202 were retired outright. Statements were not part of that. MT9xx reporting messages, including MT940, are still in service today. They are deprecated and no longer being developed, but they have not been withdrawn.
What's on the calendar for statements:
- November 2027 — institutions are expected to be able to receive ISO 20022 reporting messages. Critically, SWIFT has said it will not translate MT9xx into camt for you, so the capability has to exist on your side.
- 2028 standards release — the planned end of coexistence for statement and reporting messages, when MT940, MT942, MT950 and the MT900/910 advices give way to camt.052, camt.053 and camt.054.
In the meantime individual banks are moving at their own pace, and several already offer camt.053 on request as a like-for-like replacement. Which means the practically useful question isn't "when does SWIFT switch it off" — it's "what does my bank offer today, and can my system read it?"
What each format is
MT940 — the compact one
A plain-text SWIFT Customer Statement Message built from colon-delimited tags. Once you know the tags it's genuinely readable by eye:
| Tag | Meaning |
|---|---|
:20: | Transaction reference for the statement |
:25: | Account identification |
:28C: | Statement and sequence number |
:60F: | Opening balance |
:61: | One transaction line (date, D/C mark, amount, type, references) |
:86: | Free-text detail for the preceding transaction |
:62F: | Closing balance |
Its weaknesses are structural: tight field lengths, debit/credit direction encoded as a one- or two-letter mark, amounts using a comma as decimal separator, and the :86: detail being largely unstructured text whose conventions vary bank to bank. That last one is the reason so many treasury teams maintain per-bank parsing rules — a familiar problem if you've ever tried to normalise statement data across several banks.
camt.053 — the structured one
ISO 20022 XML: BankToCustomerStatement. Far more verbose — expect a file several times larger for the same statement — but the verbosity buys you real structure. Parties, agents, references, bank transaction codes and remittance information all get their own defined elements rather than sharing a free-text field, and values aren't squeezed into legacy length limits. For automated reconciliation, that's the whole point: less guessing at what a description meant.
How the fields map
| MT940 | camt.053 |
|---|---|
:25: account | Stmt/Acct/Id |
:28C: statement number | Stmt/LglSeqNb / ElctrncSeqNb |
:60F: opening balance | Bal with code OPBD |
:62F: closing balance | Bal with code CLBD |
:61: transaction line | Ntry (amount, CdtDbtInd, booking and value dates) |
:86: free text | NtryDtls/TxDtls — structured refs, parties, remittance info |
Two things to note when mapping. Direction moves from an embedded mark in :61: to an explicit CdtDbtInd element of CRDT or DBIT — cleaner, but it means sign handling has to be rewritten rather than reused. And :86: doesn't map to one element at all; it explodes into several. Going MT940 → camt.053 you can only structure what the free text actually contained, so a conversion is never richer than its source.
Which to ask for
Ask for camt.053 if your ERP or treasury platform supports it. It's where everything is heading, it carries more structured data, and adopting it early turns a deadline into a non-event. Most modern systems have supported it for years.
Stay on MT940 only while a system genuinely requires it — and treat that as a migration project with a date on it, not a permanent state. The thing to internalise is that no one will convert for you at the network level; if November 2027 arrives and your side can only read MT940, that's your problem to have solved.
A sensible interim: ask your bank whether they can deliver both for a period. Several do. You keep production on MT940 while testing camt.053 ingestion against the same real statements — which is by far the least stressful way to migrate.
If your bank only gives you PDFs
Worth saying plainly, because it's the most common situation for smaller businesses: MT940 and camt.053 are machine-to-machine formats delivered through corporate banking or SWIFT channels. Many small-business accounts simply don't offer them — you get a PDF in online banking and that's it.
If that's you, this migration isn't your problem, and chasing MT940 access is the wrong errand. What you need is the transaction data out of those PDFs in something your accounting software accepts: Excel or CSV for review, or QBO/OFX for a direct import. Statement Mill converts PDF statements — including scans and photos — into those formats, reconciled against the statement's own opening and closing balances so you know nothing was dropped in the process.
And if you're building the pipeline yourself, our API returns the same structured JSON with verification included, which is the closest thing to a camt-shaped payload you can get from a document that was only ever printed.
The short version
MT940 still works today and will for a while yet, but it's deprecated and the coexistence period for statements is planned to end with the 2028 standards release, with the ability to receive ISO 20022 reporting expected by November 2027. camt.053 carries genuinely better-structured data. If your systems can read it, ask your bank to switch you now; if they can't, put a date on fixing that. And if your bank only ever hands you a PDF, none of this applies — you need a converter, not a message format.