Convert CAMT.053 to MT940 for Legacy Systems

Why convert CAMT.053 down to MT940

The direction of travel is CAMT.053 replacing MT940: banks across the ISO 20022 migration now issue statements as CAMT.053 XML, and the old SWIFT MT940 is being phased out. But software moves slower than banks. Plenty of ERP, treasury, and accounting systems were built to import MT940 and read nothing else, so when the bank switches to CAMT.053 those systems suddenly have a file they cannot parse. Converting the CAMT.053 back down to MT940 is the pragmatic fix: it keeps the existing import working while you are still on a version that has not learned the XML format.

How the XML maps into MT940 tags

MT940 is a flat, tagged text format, and the conversion places each piece of the CAMT.053 XML into the matching tag. The transaction reference goes to tag 20, the account to tag 25, and the statement number to tag 28C. The opening balance becomes tag 60F and the closing balance tag 62F. Every entry in the XML becomes a tag 61 statement line carrying the date and amount, with the CAMT credit-or-debit indicator turned into the D or C mark that MT940 uses. The transaction's details follow in a tag 86 line beneath it.

What compresses in the downgrade

CAMT.053 carries far more per transaction than MT940 can hold: structured remittance information, a bank transaction code, debtor and creditor details, and purpose codes, each in its own named XML element. MT940's tag 86 is a single free-text field with a length limit, so that structured detail is condensed into it during conversion. The numbers that matter for reconciliation, dates, amounts, balances, and the debit or credit direction, carry over exactly; it is the richest counterparty and remittance context that gets flattened into text. For a system that only ever read MT940, that is the expected trade and does not affect the balancing.

Keeping balances and lines correct

A legacy parser is strict, so the MT940 has to be well-formed or the import rejects it. The opening balance in tag 60F, each tag 61 line, and the closing balance in tag 62F all have to tie out, and the statement number has to increment as the system expects. The conversion carries the balances straight from the CAMT.053 balance records and preserves each line's amount and direction, so the file the old system receives reconciles the same way the XML would, just in the format it can actually read.

Accuracy and privacy

Because a treasury or ERP import balances to the statement, the amounts, directions, and balances have to be exact, and the converted MT940 is reviewable before it goes into the system. The output is a standard MT940 the legacy parser accepts. Since the CAMT.053 holds real account activity, the file is processed to build the MT940 and then deleted automatically, with nothing kept on a server afterward.

Frequently Asked Questions