MT940 to camt.053 for Nostro Reconciliation: The Interbank Reporting Migration

Interbank reporting moves from MT to ISO 20022 in two steps under CBPR+: from November 2027 every bank must be able to receive camt.052, camt.053, and camt.054, and in November 2028 MT9xx coexistence ends. MT940 and MT950 become camt.053, MT942 becomes camt.052, MT900 and MT910 become camt.054. For nostro reconciliation, the work is in the matcher: new reference fields, longer references, structured transaction codes, and a parallel run that proves nothing got worse.

Most of the ISO 20022 attention went to payment instructions, because they had the November 2025 deadline. Reporting is the second wave, and it lands on a different team. Payments teams own pacs.008. Reconciliation teams own MT950, and their matching rules were tuned over twenty years against the exact shape of a :61 line.

This article is in the migration section of The ISO 20022 Reference. Reading a camt.053 covers the message itself: balances, entries, transaction details, bank transaction codes. Here the focus is the interbank migration: the dates, the mapping from the MT you have today, what breaks in the reconciliation engine, and how to test it.

What are the dates, and what has moved?

Current as of October 2026, from SWIFT’s CBPR+ roadmap as restated by ING (1 September 2026) and J.P. Morgan:

Milestone	Scope	Status
November 2025	End of coexistence for payment instructions (MT 103, MT 202, MT 202 COV and related)	Done. Reporting was not in scope
November 2027	All financial institutions (SUPE and NOSU user categories) must be able to receive camt.052, camt.053, and camt.054	Unchanged by the August 2026 SR2026 deferral
November 2028	End of MT9xx reporting coexistence: camt becomes the only format for interbank payment reporting	Unchanged

Three practical details sit under the table.

SWIFT will not convert your MT9xx. The contingency processing for MT senders covers payment instruction types only (MT 103, MT 103 STP, MT 200, MT 202, MT 202 COV, MT 205, MT 205 COV). It has been chargeable since 1 January 2026, and SWIFT has said the charges increase from 1 January 2027. Statements are not on the list, so an account servicer has to produce camt natively.

In-flow translation goes one way, and only to MT940. A receiver not yet ready can have a camt.053 translated into an MT940. SWIFT’s FAQ explains why it is never an MT950: nothing in the camt.053 says which one to produce, and the CBPR+ working group chose MT940 because MT950 is mostly used by market infrastructures. If your nostro matcher reads MT950 and your correspondent switches to camt.053 before you do, you will start receiving MT940 format, with :86 information lines your parser may never have seen.

camt needs relationship management. J.P. Morgan notes that camt.052, camt.053, and camt.054 require RMA (Relationship Management Application) authorisation on FINplus, unlike the MT9 series today, and ING asks clients to update their FINplus RMA before enabling camt. Put it on the plan as a dependency per correspondent, not as a technical footnote.

Outside CBPR+, nothing changes on these dates: MT940 between corporates and banks over SCORE (Swift for Corporates) continues. And statements and notifications were never in scope of the structured address rule, so your reporting parser must keep handling unstructured addresses even after payment messages stop carrying them.

Which message replaces which?

MT	Purpose	ISO 20022	Version in use at major banks (October 2026)
MT940 / MT950	End-of-day statement	camt.053 Bank to Customer Statement	camt.053.001.08
MT941 / MT942	Balance report / interim transaction report	camt.052 Bank to Customer Account Report	camt.052.001.08
MT900 / MT910	Confirmation of debit / credit	camt.054 Bank to Customer Debit Credit Notification	camt.054.001.08

The version column comes from ING’s CBPR+ page. Confirm against the CBPR+ usage guidelines in MyStandards for the release you go live on, since the usage guideline, not the base standard, decides what you receive.

How do MT940 and MT950 fields map to camt.053?

This is the table your reconciliation team needs. It is not one-to-one in either direction.

MT940 / MT950 field	Content	camt.053 element	Note
:20	Transaction reference number	Stmt/Id (and GrpHdr/MsgId)	Message identity, not a matching key
:21	Related reference (MT940 only)	No direct equivalent	Rarely used
:25	Account identification	Stmt/Acct/Id (IBAN or Othr/Id)	Static data mapping per nostro
:28C	Statement number / sequence number	Stmt/ElctrncSeqNb, Stmt/LglSeqNb, plus pagination (PgNb, LastPgInd)	Sequence gap checks must move to these
:60F	Opening balance	Bal with type OPBD
:60M	Intermediate opening balance (multi-page)	Bal with type ITBD, or pagination	Paging works differently in camt
:61 sub 1	Value date	Ntry/ValDt
:61 sub 2	Entry date	Ntry/BookgDt
:61 sub 3	Debit/credit mark (C, D, RC, RD)	Ntry/CdtDbtInd plus Ntry/RvslInd	RC and RD become a flag, not a mark
:61 sub 5	Amount (comma decimal)	Ntry/Amt with Ccy attribute	Decimal point, currency on the element
:61 sub 6	Transaction type (S103, S202, NTRF, NCHG)	Ntry/BkTxCd (domain, family, subfamily, and optional proprietary)	The classification rewrite
:61 sub 7	Reference for the account owner (16x)	TxDtls/Refs/InstrId, EndToEndId, UETR	Up to 35 characters (UETR is 36)
:61 sub 8	Account servicing institution reference (16x)	Ntry/AcctSvcrRef	Up to 35 characters
:61 sub 9	Supplementary details (34x)	Ntry/AddtlNtryInf or TxDtls elements	Structured parties replace free text
:62F	Closing balance	Bal with type CLBD
:62M	Intermediate closing balance	Bal with type ITBD, or pagination
:64	Closing available balance	Bal with type CLAV
:65	Forward available balance	Bal with type FWAV
:86	Information to account owner (MT940 only, 6x65)	TxDtls/RltdPties, RltdAgts, RmtInf, AddtlTxInf	Free text becomes structured

Two rows carry most of the risk.

:61 subfield 7 is your matching key, and it changes meaning. On a nostro statement it normally held the reference you put in field 20 of the MT 103 or MT 202 you sent. In ISO 20022 the analogue for your leg is the instruction identification (InstrId) you set in the pacs.008 or pacs.009. The identifiers article warns that InstrId is point to point and rewritten at every hop, which is exactly why it works here: a nostro statement reports one hop, the one between you and your correspondent. Use the UETR as the cross-check, and the EndToEndId when you need to tie the entry to the customer payment.

:61 subfield 6 becomes a code hierarchy. S103 and S202 told you which MT caused the entry. The camt.053 carries a bank transaction code instead, for example a payments domain, a received or issued credit transfer family, and a cross-border credit transfer subfamily. Your matching rules that branch on “S202 means FI transfer” need a new branch on domain, family, and subfamily. Keep the proprietary code as a fallback, because servicers populate the hierarchy to different depths.

MT942 to camt.052, and MT900/910 to camt.054

camt.052 replaces MT942 and MT941. The intraday report can carry pending as well as booked items, at a frequency you agree with each account servicer. Two MT942 features have no direct equivalent: the :34F floor limit (agree the threshold bilaterally instead) and the :90D/:90C debit and credit totals, which move to the transaction summary block. Liquidity teams that read MT942 for intraday nostro positions need the same rule as before: intraday data informs decisions, the end-of-day camt.053 is what you reconcile.

camt.054 replaces MT900 and MT910. One notification can carry several entries, where the MT900/910 carried one movement each. If your cash management system raised one event per MT910, decide whether it now raises one per notification or one per entry, and specify it. The related reference that :21 carried maps to the transaction details references, and the ordering party (:50a, :52a) becomes structured related parties and agents.

What breaks in the reconciliation engine?

From the reporting migrations I have worked on, these are the defects that show up in parallel runs, roughly in order of frequency.

1. Reference truncation in the matcher. The matcher was keyed on 16 characters, because that is what MT allowed. A 35-character InstrId gets cut, two different payments start sharing a key, and matches go to the wrong item. Check every reference column in the reconciliation database, not just the parser. Data truncation has the wider pattern.
2. Reversals read as new movements. RC and RD used to be a debit/credit mark. In camt.053 they are a reversal indicator alongside a normal credit or debit. A matcher that ignores the indicator treats a reversed debit as an unrelated credit.
3. Charges hidden in the transaction detail. Correspondent charges that used to appear as separate :61 lines with NCHG can arrive as their own entries, or as charge detail inside the transaction. Amount-only matching then fails by exactly the fee.
4. Batched entries. The camt.053 schema lets one entry contain several transaction details. Nostro statements usually keep one per entry, but not all servicers do, and the camt.053 article explains why reading entries only destroys a match rate.
5. Paging and sequence checks. Gap detection built on :28C has to move to the electronic sequence number and pagination. A missing page now looks like a balance mismatch rather than a missing message.
6. Translation artefacts during transition. A camt.053 translated to MT940 for you carries truncated references and remittance squeezed into :86. If one correspondent sends native camt and another sends translated MT940 for the same kind of entry, your rules must handle both shapes until November 2028.
7. Cover and FX legs. Cover payments and FX amounts put instructed and settled amounts in different elements. Pick one for matching, explicitly, and test it with a currency that has zero decimals.

None of these are camt.053 problems. They are assumptions in the reconciliation design, written down in code twenty years ago. That is why the reconciliation design document, the matching rules, the tolerances, and the break categories, is the real deliverable of this migration, more than the parser.

If you need a clean template for that design document and the mapping table above, the BA Deliverables Template Pack has it, and Break Into Banking covers the nostro and correspondent banking background.

What does the test plan look like?

Three layers. Do them in this order.

Layer 1: parser and mapping, per field. For every row of the mapping table, a test file with the field populated at maximum length, at minimum, and absent where optional. Assert that the value lands in the right column of your reconciliation store without truncation. Golden files from your correspondents beat synthetic ones, so ask each correspondent for camt samples as soon as the RMA is in place.

Layer 2: reconciliation logic, per scenario.

#	Scenario	Expected result
1	Outgoing pacs.009 with a 35-character InstrId	Matched on the full reference
2	Two payments whose InstrIds share the first 16 characters	Matched to the right items, no cross-match
3	Reversal (RvslInd true) of a debit	Classified as reversal, linked to the original
4	Return of a payment (pacs.004 credit)	Classified by bank transaction code, linked by UETR, not treated as new incoming funds
5	Charge deducted by the correspondent	Break categorised as charges, amount equals the fee
6	Entry with several transaction details	Each transaction matched individually
7	Multi-page statement	Pages assembled, OPBD plus entries equals CLBD across pages
8	Missing page or missing statement	Detected by sequence number, matching halted for that account
9	camt.052 intraday item that disappears by end of day	No ledger posting from the intraday report
10	Translated MT940 and native camt.053 for the same correspondent type	Both reconcile with the same rules
11	Zero-decimal currency (JPY)	Amounts compared without scaling errors

Layer 3: the parallel run. Pick nostro accounts that cover your main currencies and your noisiest correspondent. For at least one full month, including a month end, reconcile each account twice: once from MT950, once from camt.053. Then compare with a query, not by eye:

SELECT category,
       SUM(CASE WHEN source = 'MT'   AND matched THEN 1 ELSE 0 END) AS mt_matched,
       SUM(CASE WHEN source = 'CAMT' AND matched THEN 1 ELSE 0 END) AS camt_matched,
       SUM(CASE WHEN source = 'MT'   AND NOT matched THEN 1 ELSE 0 END) AS mt_breaks,
       SUM(CASE WHEN source = 'CAMT' AND NOT matched THEN 1 ELSE 0 END) AS camt_breaks
FROM recon_parallel_run
WHERE run_date BETWEEN DATE '2026-11-01' AND DATE '2026-11-30'
GROUP BY category
ORDER BY camt_breaks - mt_breaks DESC;

The categories at the top of that result are your defects. A category where camt matches more than MT is not automatically good news: check that the extra matches are correct, because a looser key matches more and explains less. The exit criterion is not “camt match rate at least equal to MT”. It is “every difference between the two runs explained”. Treat it like any other regression test: the old system is the oracle until proven wrong.

And check the systems downstream of reconciliation. Liquidity reports, nostro ageing, and regulatory returns often read the same statement data, and the downstream impact of a format change is usually larger than the reconciliation team’s own scope.

The takeaway

The interbank reporting migration has firm dates: receive camt.052, camt.053, and camt.054 from November 2027, and MT9xx coexistence ends in November 2028. SWIFT will not convert MT9xx for the sender, and in-flow translation for the receiver produces MT940, never MT950. Map the fields with care, above all the account owner reference in :61, which becomes the 35-character InstrId of your own leg with the UETR beside it. Then prove the change with a parallel run where every difference is explained, because a reconciliation that matches more is not the same as one that is right.

For the message structure itself, read Reading a camt.053, and for the whole MT-to-MX picture, the MT to ISO 20022 mapping. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: ISO 20022, CBPR+, Reconciliation, Nostro, Migration