Direct answer
MT940 is a SWIFT customer statement: compact tags, narratives that may be unstructured, opening and closing balances. camt.053 is the ISO 20022 XML statement: nested parties, structured remittance, versioned schemas. Banks migrate from the first toward the second, especially in Europe, but MT940 has not vanished on bank-to-corporate channels. F20 FinanceOps converts both to CSV or Excel and checks opening plus net against closing. If your ERP wants the other XML or MT flavour, a specialist converter such as StatementBridge may be the extra hop — F20 emits rows, not the opposite ISO message.
Migration programmes talk as if a date will turn MT940 off like a light. Operations knows better. One legal entity gets camt.053. A sister entity in another country still gets .sta files. The recon calendar does not care about your programme plan.
The practical question is whether you lose information in the hop to a spreadsheet. camt.053 can carry structured creditor/debtor data that an :86: line mashed into 140 characters. If you flatten XML to five Excel columns, you threw some of that away. F20 keeps references it can see; it cannot keep a tree in a grid.
Shape of the file
MT940: human-hostile but greppable. :61: then :86:. Encodings and line wrapping cause real parser bugs.
camt.053: human-hostile in another way. Namespaces, optional elements, bank extensions. A parser that pins camt.053.001.02 will fail a .08 file even when the business content is the same. F20 walks by element name for that reason.
What reconciliation cares about
Both can name an amount, a date, a currency, and some reference. camt.053 is more likely to give you a clean end-to-end ID. MT940 is more likely to hide it in :86:. Matching quality follows the reference, not the brand of XML.
Neither format is a cash book. You still need the second side.
Side-by-side
Migration is not deletion.
| MT940 | camt.053 | |
|---|---|---|
| Family | SWIFT MT | ISO 20022 cash management |
| Container | Tagged text | XML |
| Related messages | MT942 etc. | camt.052, camt.054 |
| Typical push | Legacy / still corporate | Europe and ISO programmes |
| F20 converter | /tools/mt940-to-csv | /tools/camt053-to-csv |
Workflow
Identify the file. Convert on F20. Do not convert camt to MT940 and back 'for consistency' unless an importer forces you — each hop can drop structured parties. If an importer forces you, StatementBridge documents MT940 to camt.053; the reverse is a different tool category.
Pricing and privacy
F20: both free, not stored. Specialists: see best-converter articles.
Limitations
We are not SWIFT. We are not ISO. This is operational comparison for people who received a file, not a standards tutorial. Learn pages carry more format teaching.
A migration week on the ground
Week one: the Dutch entity's bank turns off MT940 in the portal UI but the host-to-host channel still drops .sta files for three accounts. You now have two formats for one legal entity. Convert both. Do not wait for the programme manager's 'complete' email.
Week two: camt.053 arrives with structured remittance that the old MT940 importer used to mash into one narration field. Your ERP match rate may improve if you map those references. Or it may fall if the importer expected the mash. Test on one account before you declare victory.
Week three: someone converts camt to Excel, emails it, and a colleague converts it back to something MT-shaped for a legacy loader. You have now lost parties twice. If a loader still wants MT940, use a dedicated translator and test balances, not a round-trip through a pivot table. Keep a copy of the original XML next to the spreadsheet. When the loader rejects a line, the XML is the document you read, not the Excel filter that already dropped empty reference columns.
Methodology
Engine behaviour from F20 catalog. StatementBridge as an official example of MT940→camt conversion. Canonical three-way: Learn.
Where F20 FinanceOps is a better fit
- You need whichever file arrived turned into rows with a balance check, today, without a project.
- You will reconcile those rows to a cash book on F20 next.
Where another option is a better fit
- You must feed an ERP that only drinks camt.053 and you still have MT940: a dedicated translator, e.g. StatementBridge as they document it.
- You must feed an ERP that only drinks MT940 and you now have camt.053: F20 will not write MT940. Look at a camt-to-MT940 specialist and test it yourself.
- You are designing the bank channel: talk to the bank and the ERP, not a converter comparison.
- You need a three-format textbook rather than a pairwise working paper: use the Learn article, which remains canonical for BAI2 versus MT940 versus camt.053 together.
FAQ
Only if every downstream importer is ready. A converter is a bridge, not a mandate.
No. It converts each to CSV/Excel.
No. 053 is the statement this article is about.
Accuracy is parse quality plus whether references survived. XML is not magically more true.
/samples/mt940 and /samples/camt053.
Yes. Convert each independently, recon each account, and only retire MT940 when every importer that still needs it is gone. A migration slide is not a cutover. If one entity still posts from .sta files, keep the MT940 converter in the close checklist even after the programme dashboard is green.
Sources
- F20 FinanceOps policies — F20 FinanceOps. Verified. Uploaded files are processed in memory and dropped when the response is sent. There is no charge to run a tool. Output is not professional advice.
- MT940 Converter | StatementBridge — StatementBridge. Verified. StatementBridge converts MT940 to camt.053, CSV, Excel, OFX and CODA, aimed at Dutch and European accounting packages.
Convert MT940 — Use the camt.053 tool when the file is XML. Keep the original message beside the spreadsheet until the period is signed.