CAMT.053 Bank-to-Customer Statement: A Complete Guide From Beginner to Advanced

A payment being sent is not the same thing as a payment being confirmed. Every Nostro operations desk learns this lesson the hard way at some point: your correspondent bank may have received your instruction, but until their statement says the entry is booked, your ledger and their ledger are two separate stories. CAMT.053, the ISO 20022 Bank-to-Customer Statement, is where those two stories are supposed to meet.

If you work in SWIFT operations, Nostro reconciliation, or correspondent banking, you already know MT940 well: fixed tags, positional text, and a narrative field that tries to hold too much information. ISO 20022 CAMT.053 replaces that compressed text with a hierarchical XML message that names every business fact explicitly, from the opening balance to the underlying payment reference.

This guide walks through the CAMT.053 XML structure, its key elements, a worked example, how it compares to MT940 and to its sibling messages CAMT.052 and CAMT.054, how to parse and reconcile it, and what a real implementation project looks like. Every fact below comes from the source material this guide was built from. Where the source material does not address something, that is stated explicitly rather than filled in.

1. Beginner Foundations: What a Bank Statement Actually Confirms

The Nostro/Vostro Relationship in Plain Terms

In correspondent banking, your bank holds foreign-currency accounts at other banks. Your bank calls its own account a Nostro account ("our money with you"). The correspondent bank calls the same account a Vostro account ("your money with us") on its own books. Your internal Core Banking System (CBS) or General Ledger (GL) keeps a mirror of that account; the correspondent's system keeps its own record.

A bank statement is the account servicer's authoritative report of what actually happened on that account: debits, credits, and balances for a given period. The account owner is the party the statement is issued to, which in a Nostro context is your bank, not necessarily a retail customer, even though the message is formally named "Bank-to-Customer Statement."

Illustrative example: Your bank sends an outward payment to clear USD 500,000 through a correspondent in New York. When the correspondent posts the debit, its statement reflects that movement. Your Nostro team matches the incoming statement entry against your own outward settlement ledger. That matching exercise is reconciliation.

Why This Distinction Matters

A statement is not a payment instruction. It is strictly an accounting report of transactions already booked. Confusing a camt.053 entry with an authorization to move funds is a foundational mistake. Similarly, unreconciled Nostro items are not a paperwork inconvenience; they expose the bank to foreign exchange risk, liquidity shortfalls, operational losses, and regulatory scrutiny.

2. Business Context: Why ISO 20022 and XML Replace Flat-Text Messaging

The Limits of Legacy MT Text

Legacy SWIFT MT messages, including MT940, use tagged positional text such as:

:61:2504100410D1500,00NTRFNONREF//ACME-12345

Every fact in that line — the value date, entry date, debit/credit indicator, amount, transaction type, and reference — is packed into a single string that a parser must decode using regular expressions and fixed character positions. The narrative field (Tag 86) is worse: it is a free-text block limited to roughly 390 characters (six lines of 65 characters), which forces counterparty names, invoice numbers, and charge details into unstructured prose. If a counterparty name is too long, it gets truncated.

What ISO 20022 XML Changes

ISO 20022 is not simply "MT940 rewritten as XML." It is a broader messaging methodology comprising a modelling approach, a shared data dictionary, and formally defined message structures, of which XML is one derived syntax. Under ISO 20022, data is organized hierarchically with named, self-describing elements:

<Ntry>
    <Amt Ccy="USD">1500.00</Amt>
    <CdtDbtInd>DBIT</CdtDbtInd>
    <BookgDt><Dt>2025-04-10</Dt></BookgDt>
    <ValDt><Dt>2025-04-10</Dt></ValDt>
</Ntry>

There is no character-limit truncation, no positional ambiguity, and no regex guessing. A counterparty name lives in <Dbtr><Nm> as structured text rather than bleeding across narrative lines. Because every element carries its own business meaning, downstream systems can consume the data directly rather than parsing prose.

Common mistake: editing CAMT XML manually in a plain text editor without validating against the XML Schema Definition (XSD), which risks malformed tags or namespace mismatches that crash ingestion engines.

3. CAMT.053 XML Structure: The Four-Tier Hierarchy

CAMT.053 messages are organized under a <Document> root and a <BkToCstmrStmt> container, following a consistent four-level structure:

Document
└── BkToCstmrStmt
    ├── GrpHdr        (Level A - Group Header)
    └── Stmt           (Level B - Statement, one per account)
        ├── Acct        (Account identification)
        ├── Bal          (Opening, closing, interim balances)
        └── Ntry          (Level C - Booked entry)
            └── NtryDtls
                └── TxDtls  (Level D - Transaction details)

Group Header (GrpHdr) — Level A

The message-level envelope. Contains, at minimum, a Message ID (<MsgId>) and a Creation Timestamp (<CreDtTm>); pagination information (<MsgPgntn>) may also appear here. The Message ID is used for duplicate detection, audit trails, and troubleshooting. It identifies the message, not an individual underlying payment, so it should not be treated as a transaction reference.

Statement (Stmt) — Level B

Represents the statement scope for a specific account and reporting period. A single message can contain more than one Stmt block. Key contents include the statement identifier (<Id>), electronic sequence number (<ElctrncSeqNb>), reporting sequence, pagination, account identification, and balances.

Account Identification

Held under Stmt/Acct/Id, using either <IBAN> for IBAN-compliant accounts, or <Othr><Id> for proprietary or BBAN-style account numbers, which is the common case for Nostro accounts settled through non-IBAN clearing systems such as US Fedwire/CHIPS. The servicing bank's BIC sits under Stmt/Acct/Svcr/FinInstnId/BICFI.

Common mistake: building a parser that only expects <IBAN> and fails when a correspondent delivers a proprietary account number in <Othr><Id>.

Balances (Bal)

Balance blocks define the accounting boundaries of the statement. Each contains a balance type code, an amount with currency, a credit/debit indicator, and a date.

OPBD and CLBD are described as the confirmed opening and closing positions used for reconciliation. The fundamental arithmetic check is:

Opening Balance (OPBD) ± sum of Entries = Closing Balance (CLBD)

This equation is one of the strongest completeness controls available when validating an incoming statement.

Booked versus available: a closing booked balance (CLBD) can differ from a closing available balance (CLAV) due to value dating, holds, or float. A difference between the two does not automatically mean the statement is wrong; it means the booked position and the available position are simply not the same thing.

Credit/Debit Indicator (CdtDbtInd)

Direction is never expressed through a signed amount. Amounts in ISO 20022 are always positive decimals. Direction is carried strictly by <CdtDbtInd>: CRDT = the account increased, DBIT = the account decreased.

Common mistake: Subtracting an amount because a legacy internal system expects a negative string, or failing to flip the sign correctly when posting to an internal Nostro mirror GL. Also worth remembering: CRDT describes what happened to the reported account, not an assumption about who sent money. Always confirm whose account the statement is reporting before interpreting direction.

Entry Status (Sts)

Ntry/Sts reports the status of the entry on the account servicer's books. Common values include BOOK (booked), PDNG (pending), and INFO (informational). A standard end-of-day statement will typically show BOOK.

Booking Date vs. Value Date

<BookgDt> — the date the entry was posted to the account servicer's general ledger. <ValDt> — the date funds become effective for interest calculation or availability.

<BookgDt><Dt>2025-09-25</Dt></BookgDt>
<ValDt><Dt>2025-09-24</Dt></ValDt>

A payment processed near a cut-off time can carry a booking date one day later than its value date. Reconciling strictly on booking date, while ignoring value date, causes mismatches in interest calculations and FX positioning. Store and compare both.

Entry (Ntry) vs. Transaction Details (TxDtls)

This is arguably the single most important conceptual shift from MT940. Ntry (Level C) is the ledger-level movement: what hit the account. TxDtls (Level D), nested inside NtryDtls, describes the underlying payment(s) that caused that movement. For an individual wire, there is typically one Ntry and one TxDtls. For a batch or bulk clearing settlement, a single Ntry can contain multiple TxDtls blocks summarizing several underlying payments netted into one posting.

Illustrative example: a correspondent books a single Ntry of USD 1,000,000, but underneath it there are two TxDtls entries of USD 600,000 and USD 400,000 respectively, each representing a separate underlying payment.

Common mistake: assuming one Ntry always equals one payment. Automated reconciliation engines that make this assumption will misfire against batched postings.

References, Parties, Remittance, and Charges (inside TxDtls)

References (Refs): <AcctSvcrRef> — the correspondent's internal posting reference, useful for investigations. <EndToEndId> — a business reference passed unchanged from payer to payee. <UETR> — a 36-character UUID, the Unique End-to-End Transaction Reference used across SWIFT payment tracking. Additional reference fields appearing in the source material's transaction reference structure include MsgId, PmtInfId, InstrId, and TxId.

Related Parties (RltdPties): <Dbtr> / <DbtrAcct> (debtor name and account) and <Cdtr> / <CdtrAcct> (creditor name and account).

Remittance Information (RmtInf): either unstructured (<Ustrd>, free text) or structured (<Strd>), which can carry an ISO 11649 creditor reference under <CdtrRefInf>.

Charges (Chrgs): a breakdown of deductions, including <TtlChrgsAndTaxAmt> and individual charge records (<Rcrd>) with their own amount and direction.

Nostro example: you expect an incoming payment of USD 250,000. The correspondent's charge structure might reflect the full amount with a separate charge entry, a net amount after fee deduction, or some other combination. These are not equivalent accounting events, so the actual <Chrgs> structure must be inspected rather than assumed.

Bank Transaction Code (BkTxCd)

Instead of relying on free-text narration, CAMT.053 can classify an entry using a structured, multi-level taxonomy under <BkTxCd>, typically expressed as Domain / Family / Sub-Family, for example a payment / received credit transfer / cross-border credit transfer classification. The source material shows this hierarchy using both PMNT and PAYM as the domain-level code in different examples, with RCDT (received credit transfer) as the family code and XBCT (cross-border credit transfer) as the sub-family code in most illustrations. Because bank transaction codes depend on the applicable external code set and each correspondent's own implementation practice, do not assume every bank populates them identically.

Reversal Indicator (RvslInd)

<RvslInd>true</RvslInd> flags an entry as a reversal. A credit reversal can mean the original posting was a debit, and vice versa. Reversal entries are often paired with a <RtrInf> block carrying a return reason code, for example AC04 (account closed), plus additional free-text detail. Operationally, a reversal should be linked back to the original transaction rather than treated as an unrelated new item.

4. A Practical CAMT.053 XML Example (Beginner Level)

The following walkthrough is adapted directly from the source material's beginner example and demonstrates a simple end-of-day statement: one account, one opening balance, one credit entry, one closing balance.

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.14">
  <BkToCstmrStmt>
    <GrpHdr>
      <MsgId>NOSTRO-USD-20260922-000781</MsgId>
      <CreDtTm>2026-09-22T18:05:27Z</CreDtTm>
    </GrpHdr>
    <Stmt>
      <Id>USD-NOSTRO-20260922-425</Id>
      <Acct>
        <Id><Othr><Id>USD-NOSTRO-001234567</Id></Othr></Id>
        <Ccy>USD</Ccy>
      </Acct>
      <Bal>
        <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
        <Amt Ccy="USD">1250000.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt><Dt>2026-09-22</Dt></Dt>
      </Bal>
      <Ntry>
        <NtryRef>CORR-ENTRY-001</NtryRef>
        <Amt Ccy="USD">250000.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Sts><Cd>BOOK</Cd></Sts>
        <BookgDt><Dt>2026-09-22</Dt></BookgDt>
        <ValDt><Dt>2026-09-22</Dt></ValDt>
        <AcctSvcrRef>CORR-20260922-001</AcctSvcrRef>
      </Ntry>
      <Bal>
        <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>
        <Amt Ccy="USD">1500000.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt><Dt>2026-09-22</Dt></Dt>
      </Bal>
    </Stmt>
  </BkToCstmrStmt>
</Document>

Reading it like an operator would: Message ID NOSTRO-USD-20260922-000781, statement ID USD-NOSTRO-20260922-425, account USD-NOSTRO-001234567. Opening booked balance: USD 1,250,000, credit. One entry: USD 250,000 credit, booked and value-dated on the same day, correspondent reference CORR-20260922-001. Closing booked balance: USD 1,500,000, credit. Arithmetic check: 1,250,000 + 250,000 = 1,500,000. It balances.

5. CAMT.053 vs. MT940, CAMT.052, and CAMT.054

CAMT.053 vs. MT940: Field Mapping

The most important lesson in this table is that Tag 86 does not have a clean one-to-one destination. In MT940, a single free-text block might carry a counterparty name, an invoice number, and a reference, all mixed together. CAMT.053 gives each of those facts its own element (Dbtr/Nm, RmtInf, EndToEndId), but only if the migration mapping is built with genuine semantic analysis rather than a blind "dump the text into Ustrd" approach. Source material explicitly warns against that shortcut, describing it as a "lazy bank" implementation that reduces automated matching quality even though the file is technically valid XML.

General Comparison

(The exact percentage ranges vary slightly between the source documents; both agree directionally that deterministic XML matching materially outperforms legacy text parsing.)

CAMT.052 vs. CAMT.053 vs. CAMT.054

A simple mental model from the source material: camt.052 answers "what's happening right now," camt.053 answers "what happened, with a confirmed balance," and camt.054 answers "notify me about this specific movement." The source material cautions against treating these timing patterns as universal rules; actual frequency and content depend on the service agreement in place with each correspondent.

Why this distinction matters operationally: reconciling a General Ledger against a camt.052 intraday report can generate false mismatches, because intraday entries may still be reversed or amended before end-of-day close. GL reconciliation should be performed against camt.053. Similarly, camt.054 notifications should never be mistaken for a statement, since they lack the opening/closing balance boundaries that prove ledger completeness.

6. How to Read and Parse CAMT.053 XML

A Structured Reading Method

The source material recommends working through the message top-down rather than searching for individual fields:

• Check the namespace and version.
• Read the Group Header (MsgId, CreDtTm).
• Identify the statement and account (Stmt, Acct).
• Read the opening balance.
• Walk through each entry: amount, CdtDbtInd, status, booking date, value date, references.
• Drill into NtryDtls/TxDtls for underlying payment detail: UETR, EndToEndId, parties, remittance.
• Check for a Chrgs block.
• Verify balance arithmetic (opening plus movements equals closing).
• Read the closing balance.
• Compare the whole statement against the CBS/GL.

Parsing Discipline

• Validate before you trust. At minimum this means checking XML well-formedness, namespace, schema (XSD) compliance, mandatory field presence, permitted code values, and business rules, in that order. A file can be well-formed XML and still be invalid because it uses a code value that is not permitted, for example an unrecognised value in <CdtDbtInd>.
• Use a real XML parser, not regex. Parsing CAMT.053 with string-splitting or regular expressions defeats the purpose of a structured format and is called out repeatedly across the source material as a common implementation error.
• Do not hardcode account-identification assumptions. A parser expecting only <IBAN> will fail against correspondents that use <Othr><Id> for non-IBAN Nostro accounts.
• Do not assume one Ntry equals one payment. Always iterate through NtryDtls/TxDtls.
• Track sequence continuity. Compare the previous statement's closing balance against the current statement's opening balance, and monitor ElctrncSeqNb (and related sequence/pagination fields) to catch a missing or duplicate statement file.
• Guard against duplicate ingestion. The source material recommends hash-checking or otherwise enforcing uniqueness on the combination of MsgId, account identifier, and statement identifier, so that a re-delivered or retried file is not processed twice.
• Enforce UTF-8 and encoding checks at the gateway. Non-ASCII characters in payee names can otherwise cause parsing failures.

7. CAMT.053 Reconciliation for Nostro Operations

The Matching Waterfall

Rather than one blanket matching rule, the source material describes a cascading, priority-ordered approach:

• Deterministic identity keys (strongest): UETR, or EndToEndId/TxId/InstrId, matched together with amount and currency.
• Banking reference keys: AcctSvcrRef, or the outward SWIFT message reference, matched with amount.
• Structured remittance and party matching: structured creditor reference (CdtrRefInf/Ref), value date, and amount.
• Heuristic matching (requires manual review): value date within a tolerance window, amount, and fuzzy counterparty name matching.

Important caveat: UETR is a powerful matching key when present, but it is not guaranteed to be populated on every entry. Matching logic needs a defined fallback path rather than a hard dependency on any single field.

Exception Types and What to Check

Handling Specific Exceptions

Correspondent charge deductions: if an expected USD 100,000 credit posts as USD 99,950 due to an undisclosed fee, an auto-tolerance rule can post the USD 50 difference to a Nostro bank-charges expense account when the Chrgs node is present and the variance falls within an agreed threshold, while the principal amount still matches.

Returned or rejected wires: parse RtrInf/Rsn/Cd. A code such as AC04 (account closed) or BE04 (beneficiary name mismatch) should trigger an automated reversing entry to re-credit the original payer, net of any return charges.

Missing outward settlement: if your CBS shows an outward payment posted but no corresponding debit appears in the statement, check SWIFT GPI/UETR tracking; the payment may be held in sanctions screening or repair at an intermediary bank before it reaches the correspondent's books.

Common mistake: never assume the sum of every TxDtls amount must always equal the parent Ntry amount in every implementation. Some correspondents include charges, adjustments, or batch structures at different levels, so reconciliation rules must follow the specific usage specification of the correspondent involved rather than a single universal formula.

8. CAMT.053 Versioning and Schema Considerations

CAMT.053 is not a single fixed format; it is versioned. The version identifier appears in the XML namespace, for example:

urn:iso:std:iso:20022:tech:xsd:camt.053.001.14

The final digits identify the specific version. The source material references version suffixes spanning camt.053.001.02 through camt.053.001.11 in the context of implementation pitfalls, and separately identifies camt.053.001.14 as the current global message definition, noted as updated 19 March 2026 in the source material describing that version. In practice, different correspondents and different points in time can deliver different version suffixes.

Why this matters operationally:

• A parser built against one version (for example .001.02) can crash when it receives a message built on a later version (for example .001.08), if optional or extended fields are handled rigidly.
• The recommended control is a version-aware or version-agnostic XML abstraction layer that dynamically loads the appropriate schema based on the namespace declared in the incoming file.
• Validation should not stop at "it starts with camt.053." At minimum it should check message family, message definition, variant, version, namespace, schema compliance, business rules, and any applicable community or bilateral usage rules.

Current operational points noted in the source material: under CBPR+ usage guidance referenced for the SR2026 release, unstructured postal addresses are being retired for certain CBPR+ payment messages, while camt.052, camt.053, and camt.054 continue to allow unstructured addresses. The same SR2026 material notes a change mandating the Electronic Sequence Number in camt.052 and camt.053 under CBPR+ usage. This is a useful reminder that the global ISO 20022 message definition and the community-specific usage guideline (CBPR+) are not the same thing; a field can be optional in the base ISO message and still be mandatory under a particular market practice.

The available source material does not specify exact release-by-release version histories beyond the points listed above.

9. Advanced Implementation: Migration, Testing, and SWIFT Context

A Structured Migration Path

Across the source material, migrating a Nostro reconciliation environment from MT940 to CAMT.053 is consistently described as a structured project, not a simple text-to-XML conversion. The stages described include:

• Gap analysis and inventory: audit the CBS, treasury management system, and reconciliation engine for XML ingestion and XSD schema support; collect actual sample statements from each correspondent bank, since MT940 narrative practices vary significantly by institution.
• Semantic mapping design: build a genuine field-by-field mapping, particularly for Tag 86, deciding deliberately which narrative components map to UETR, RmtInf, RltdPties, and other structured fields, rather than dumping the whole narrative into Ustrd.
• Bilateral setup: exchange RMA keys or equivalent bilateral arrangements with correspondent banks for CAMT.053 delivery over the relevant SWIFT service.
• Schema and business-rule validation: validate every incoming file against the correct XSD, then layer business-rule and community/bilateral rule validation on top.
• Positive and negative testing: test scenarios should include a zero-entry day, multi-page/paginated statements, structured versus unstructured remittance fallback, large-file stress tests (the source material references files with 10,000+ entries), invalid namespaces, invalid codes, missing mandatory fields, and duplicate message IDs.
• Parallel run: run MT940 and CAMT.053 feeds side by side for a period, comparing account, opening balance, credits, debits, entries, references, dates, and closing balance, ideally down to transaction-level semantic equivalence rather than simple file-received checks.
• Cutover with fallback: switch the primary reconciliation feed to CAMT.053 while retaining the MT940 parser as backup during the transition.
• Post-go-live monitoring: continue monitoring for schema version drift, sequence gaps, and duplicate ingestion after cutover.

Common Implementation Pitfalls

Clarifying the SWIFT Ecosystem: ISO 20022, CAMT, CBPR+, and FINplus

These five terms are frequently conflated but mean different things:

• ISO 20022 — the overarching, SWIFT-independent international standard: a modelling methodology, data dictionary, and message framework.
• CAMT — the Cash Management business area within ISO 20022, covering account reporting messages including camt.052, camt.053, and camt.054.
• CAMT.053 — one specific ISO 20022 message definition: Bank-to-Customer Statement.
• CBPR+ (Cross-Border Payments and Reporting Plus) — SWIFT's community usage guidelines and market practice rules defining how ISO 20022 messages must be formatted for cross-border business on the SWIFT network. CBPR+ is a usage guideline layered on top of ISO 20022, not a separate standard and not the same thing as CAMT.053 itself.
• FINplus — SWIFT's IP-based transport service used to exchange ISO 20022 (MX) messages, distinct from the legacy FIN service used for MT messages. FINplus is a transport channel, not identical to CBPR+.

The MT940 "Universal Replacement" Myth

This is one of the most operationally important clarifications in the source material: do not state that CAMT.053 universally replaced MT940 overnight.

What actually happened: on 22 November 2025, SWIFT ended the MT/MX coexistence period specifically for cross-border payment instruction messages. Legacy payment instructions (MT103, MT202, MT202 COV) were migrated to pacs.008 and pacs.009, and legacy MT payment instructions in that category are now rejected.

Account statement messages (MT940, MT942, MT950) were not decommissioned on that date. Statement reporting continues to coexist, and the transition from MT940 to camt.053 for statements is governed by bilateral agreements between individual banking partners and by domestic market infrastructure timelines, which can extend well beyond the payment-instruction cutover (the source material cites one correspondent supporting MT940 until at least 2028 as an example). Corporate-to-bank reporting frameworks can likewise continue supporting legacy MT formats independently of the payment-instruction migration.

Practical takeaway: for any given correspondent relationship, always confirm which specific service, channel, and bilateral agreement governs statement delivery, rather than assuming a blanket industry-wide MT940 retirement date.

Conclusion

CAMT.053 is not a cosmetic upgrade to MT940. It replaces compressed, positionally-encoded text with a hierarchical, explicitly-labelled XML message that separates balances, direction, dates, references, parties, remittance information, and charges into their own elements. That structure is what makes higher rates of automated Nostro reconciliation possible, but only if the underlying implementation treats it as a genuine data model rather than a text file with angle brackets.

For SWIFT and Nostro operations specialists, the practical payoff of understanding CAMT.053 properly is fewer manual exceptions, faster investigation when something does not match, and a reconciliation engine that can rely on deterministic keys like UETR and EndToEndId instead of fuzzy text matching. The cost of getting it wrong, whether through a "lazy" implementation that dumps everything into free text, a parser that assumes one entry always equals one payment, or a version-rigid ingestion layer, is the same operational risk MT940 always carried, just wearing an XML wrapper.

Key Takeaways

• A statement confirms bookings; it does not authorize payments. Never treat a camt.053 entry as an instruction.
• Amounts are always positive; direction lives in CdtDbtInd. Never infer direction from a sign.
• Ntry is the ledger movement; TxDtls explains what caused it. One entry can hold multiple transaction details in a batch.
• Booking date and value date are different facts. Store and reconcile both.
• Match on identity first, amount and date second. UETR, EndToEndId, TxId, InstrId, and AcctSvcrRef outrank amount/date/party heuristics, but no single field is guaranteed to be present.
• CAMT.053 is the end-of-day statement of record; CAMT.052 is intraday; CAMT.054 is an event notification without full balances. GL closure belongs against CAMT.053.
• Version matters. The namespace suffix (.001.02 through .001.14 in the source material) identifies the schema version, and parsers must be version-aware.
• MT940 was not universally retired in November 2025. Only cross-border payment instructions (MT103/MT202) were cut over on that date; statement messages continue on a bilateral timeline.

Recap Questions

• Why must Nostro GL reconciliation be performed against camt.053 rather than camt.052?
• What is the structural difference between an Ntry element and a TxDtls element, and why does that difference matter for batch postings?
• Which matching key is considered the strongest for automated reconciliation, and what should a matching engine do when that key is absent?
• Did SWIFT decommission MT940 statement messages on 22 November 2025? What exactly changed on that date?
• Why is mapping MT940 Tag 86 to CAMT.053 considered the hardest part of a migration project?

Sakir Ahmed led Southeast Bank PLC's ISO 20022 CBPR+ migration and works daily with SWIFT operations and cross-border payment infrastructure. He writes about payment systems, SWIFT operations, and Fintech innovation in emerging markets at sakirahmed.com.