camt: Cash management
camt.053 Bank to Customer Statement
Written and maintained by ZagTrader. Last reviewed . How this page is sourced and checked
camt.053 is the ISO 20022 account statement: the account servicing bank reports the booked entries and balances of an account for a period, usually one business day, to the account owner or to a party the owner authorised. It is the successor of the MT940 customer statement and the MT950 bank-to-bank statement, and in CBPR+ the version is camt.053.001.08.
- Message
- BankToCustomerStatement
- Root element
- BkToCstmrStmt
- Common version
- camt.053.001.08
When camt.053 is used
A camt.053 is sent after the statement period closes, typically once per business day. One message holds a group header and one or more statements (Stmt), each for one account, with balances (Bal), optional totals (TxsSummry) and one entry (Ntry) per booking. CBPR+ allows one statement per message and asks the parties to agree how many entries a message carries.
An entry can carry the full story of the payment behind it in its entry details (NtryDtls/TxDtls): the end-to-end and instruction identifications, the UETR, the debtor and creditor with their agents and accounts, purpose and remittance information. That is the main difference from the MT940, where the same data has to fit into field 61 and six lines of field 86.
The same message is used between banks and towards customers. The CBPR+ guideline states that camt.053 covers both the bank-to-bank leg, where the MT950 is used for nostro reconciliation today, and the bank-to-customer leg. Corporates also receive camt.053 files outside Swift, through host-to-host links, EBICS or online banking, using the version and rules their bank publishes.
Statements were not part of the 22 November 2025 deadline for payment instructions. Swift continues to support reporting messages, MT9xx statements included, beyond that date, so banks and their clients agree when to move from MT940 or MT950 to camt.053. For intraday reporting see camt.052; for single debit and credit advices see camt.054.
Versions in common use
| Version | Where it is used |
|---|---|
| camt.053.001.08 | CBPR+ (cross-border payments and reporting on Swift), with the Business Application Header head.001.001.02 mandatory. Also the version in Payments Canada’s Lynx reporting guidelines, and offered by many banks to corporates. |
| camt.053.001.09 and later | ISO 20022 has published newer versions. Each market practice chooses its own, so confirm with your bank which version it sends and read the namespace of every file. |
camt.053 key elements
Paths are relative to Document/BkToCstmrStmt. Occurrence is from the base message (camt.053.001.08); market practice such as CBPR+ or a CSD’s rules can make an optional element mandatory or forbid it.
| Element | Occurs | Meaning |
|---|---|---|
| GrpHdrGroup Header | [1..1] | Information about the message as a whole. |
| MsgIdMessage Identification | [1..1] | The sender’s reference for this message. In CBPR+ the Business Application Header repeats it in BizMsgIdr. |
| CreDtTmCreation Date Time | [1..1] | When the message was created, with time zone offset. |
| MsgPgntnMessage Pagination | [0..1] | Page number of the message. Use either message pagination or statement pagination, not both. |
| StmtStatement | [1..n] | One statement for one account. CBPR+ restricts it to one per message. |
| IdIdentification | [1..1] | The bank’s unique identification of this statement. |
| StmtPgntnStatement Pagination | [0..1] | Page number and last-page flag when one statement is split over several messages. Mandatory in CBPR+. |
| PgNbPage Number | [1..1] | The page of this message within the statement, starting at 1. Same role as the sequence number in MT940 field 28C. |
| LastPgIndLast Page Indicator | [1..1] | true on the last page. Tells the receiver the statement is complete. |
| ElctrncSeqNbElectronic Sequence Number | [0..1] | Running number of electronic statements for the account, the equivalent of the MT940 statement number. CBPR+ requires this or the legal sequence number. |
| LglSeqNbLegal Sequence Number | [0..1] | Statement number where a legal (for example paper) statement sequence is kept separately from the electronic one. |
| CreDtTmCreation Date Time | [0..1] | When this statement was created. |
| FrToDtFrom To Date | [0..1] | The period the statement covers, as start and end date-times. |
| AcctAccount | [1..1] | The account reported on. |
| IBANIBAN | [0..1] | The account as an IBAN. A choice with Othr/Id for accounts without an IBAN. |
| CcyCurrency | [0..1] | Currency of the account. |
| OwnrOwner | [0..1] | The account owner, for example by name or AnyBIC. Corresponds to the BIC in MT940 field 25P. |
| SvcrServicer | [0..1] | The account servicing institution, usually by BICFI. |
| BalBalance | [1..n] | One balance per occurrence: type, amount, credit or debit and date. |
| CdBalance Type Code | [0..1] | OPBD opening booked, CLBD closing booked, CLAV closing available, FWAV forward available, ITBD interim booked, ITAV interim available, OPAV opening available, PRCD previously closed booked, XPCD expected, INFO information only. |
| CdBalance Sub Type Code | [0..1] | Refines the type. CBPR+ uses INTM on OPBD and CLBD for the intermediate balances of a split statement, the equivalent of 60M and 62M. |
| AmtAmount | [1..1] | The balance amount, never negative, with the currency in the Ccy attribute and a dot as decimal mark. |
| CdtDbtIndCredit Debit Indicator | [1..1] | CRDT for a credit balance, DBIT for a debit (overdrawn) balance. |
| DtDate | [0..1] | Date of the balance. A choice with DtTm when a time is needed. |
| TxsSummryTransactions Summary | [0..1] | Number and sum of entries, in total, for credits (TtlCdtNtries), for debits (TtlDbtNtries) and per bank transaction code. |
| NtryEntry | [0..n] | One booking on the account, the equivalent of an MT940 field 61 with its field 86. |
| NtryRefEntry Reference | [0..1] | Unique reference of the entry. |
| AmtAmount | [1..1] | Amount of the entry, never negative, with the currency attribute. |
| CdtDbtIndCredit Debit Indicator | [1..1] | CRDT or DBIT: the direction of this entry on the account. |
| RvslIndReversal Indicator | [0..1] | Present and true only when the entry results from a reversal. CRDT with true means the original was a debit (MT940 RD); DBIT with true means the original was a credit (MT940 RC). |
| CdStatus Code | [0..1] | BOOK booked, PDNG pending, INFO information only, FUTR future value. In a CBPR+ statement only BOOK is allowed. |
| DtBooking Date | [0..1] | Date the entry was posted. Equivalent of the entry date in field 61. |
| DtValue Date | [0..1] | Date the funds become available (credit) or stop being available (debit). Mandatory in CBPR+. |
| AcctSvcrRefAccount Servicer Reference | [0..1] | The bank’s own reference for the entry, as in subfield 8 of MT940 field 61. |
| BkTxCdBank Transaction Code | [1..1] | The type of transaction, as a structured ISO code (Domn) and/or a proprietary code (Prtry). CBPR+ prefers the structured code. |
| CdDomain Code | [1..1] | Top level of the ISO bank transaction code, for example PMNT payments, SECU securities, FORX foreign exchange, ACMT account management. |
| CdFamily Code | [1..1] | Second level, for example RCDT received credit transfers, ICDT issued credit transfers, MDOP miscellaneous debit operations, CORP corporate action. |
| SubFmlyCdSub Family Code | [1..1] | Third level, for example XBCT cross-border credit transfer, DMCT domestic credit transfer, FICT financial institution credit transfer, BOOK internal book transfer, CHRG charges, DVCA cash dividend. |
| CdProprietary Code | [1..1] | The bank’s own transaction code, with its issuer in Prtry/Issr. |
| TxDtlsTransaction Details | [0..n] | Details of the underlying transaction. Several per entry for batch bookings in the base message; CBPR+ requires exactly one per entry details block. |
| InstrIdInstruction Identification | [0..1] | Point-to-point reference of the instruction, often the account owner’s own reference for a debit. |
| EndToEndIdEnd To End Identification | [0..1] | The originator’s reference, passed unchanged through the whole payment chain. The best key for matching receivables. |
| UETRUETR | [0..1] | The unique end-to-end transaction reference of the underlying Swift payment, a UUID version 4. See how to read a UETR. |
| DbtrDebtor | [0..1] | Who paid, as a party or an agent. With Cdtr, DbtrAcct and CdtrAcct it replaces /ORDP/ and /BENM/ in field 86. |
| DbtrAgtDebtor Agent | [0..1] | The payer’s bank. |
| UstrdUnstructured Remittance Information | [0..n] | Free remittance text, for example the invoice number. Structured references go in RmtInf/Strd. |
| CdReturn Reason Code | [0..1] | ISO reason code when the entry is a returned payment, for example AC04 (closed account). |
| AddtlNtryInfAdditional Entry Information | [0..1] | Free text about the entry. The usual home for what a bank used to put in field 86 without codes. |
| AddtlStmtInfAdditional Statement Information | [0..1] | Free text about the statement as a whole, like the final field 86 of an MT940. |
Rules worth knowing
- Balances reconcile by direction: OPBD plus the sum of CRDT entries minus the sum of DBIT entries equals CLBD. Amounts are never negative; the direction is in CdtDbtInd.
- CBPR+: either ElctrncSeqNb or LglSeqNb must be present, and both are allowed.
- CBPR+: on page 1 there must be exactly one OPBD balance and it must not carry sub type INTM; on later pages exactly one OPBD with sub type INTM.
- CBPR+: when LastPgInd is
truethere must be exactly one CLBD without sub type INTM; on earlier pages exactly one CLBD with sub type INTM. At most one CLAV balance per statement. - CBPR+: entry status is BOOK only, ValDt is mandatory, and each NtryDtls holds exactly one TxDtls with mandatory Refs, Amt and CdtDbtInd.
- CBPR+: the Business Application Header (head.001.001.02) is mandatory. In the SR2025 guideline its BizSvc is
swift.cbprplus.03and BizMsgIdr repeats GrpHdr/MsgId. - CBPR+ character set: text fields are limited to the FIN X character set, except names, addresses and remittance information, which allow a wider set of characters.
- Base message rule: MsgPgntn in the group header and StmtPgntn in the statement must not both be used.
- Bank transaction codes have three mandatory levels when the structured form is used: domain, family and sub-family. If no specific code fits, generic codes such as NTAV (not available) or OTHR (other) are used.
camt.053 XML example
The same day as the MT940 example: ZagTrader Test Bank, Dubai (ZAGTAEADXXX) reports the USD account of a broker (BRKRAEADXXX) for 20 October 2026. Opening booked USD 1,250,000.00, four credits totalling USD 314,500.00 (one of them the reversal of a debit), two debits totalling USD 480,125.00, closing booked USD 1,084,375.00, closing available USD 1,069,375.00 because one credit has value date 21 October. Document only; on Swift under CBPR+ it travels with a Business Application Header.
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.08">
<BkToCstmrStmt>
<GrpHdr>
<MsgId>STMT261020USD01</MsgId>
<CreDtTm>2026-10-20T22:15:00+04:00</CreDtTm>
</GrpHdr>
<Stmt>
<Id>207-20261020-USD</Id>
<StmtPgntn>
<PgNb>1</PgNb>
<LastPgInd>true</LastPgInd>
</StmtPgntn>
<ElctrncSeqNb>207</ElctrncSeqNb>
<CreDtTm>2026-10-20T22:15:00+04:00</CreDtTm>
<Acct>
<Id>
<IBAN>AE070331234567890123456</IBAN>
</Id>
<Ccy>USD</Ccy>
<Ownr>
<Id>
<OrgId>
<AnyBIC>BRKRAEADXXX</AnyBIC>
</OrgId>
</Id>
</Ownr>
<Svcr>
<FinInstnId>
<BICFI>ZAGTAEADXXX</BICFI>
</FinInstnId>
</Svcr>
</Acct>
<Bal>
<Tp>
<CdOrPrtry>
<Cd>OPBD</Cd>
</CdOrPrtry>
</Tp>
<Amt Ccy="USD">1250000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Dt>
<Dt>2026-10-19</Dt>
</Dt>
</Bal>
<Bal>
<Tp>
<CdOrPrtry>
<Cd>CLBD</Cd>
</CdOrPrtry>
</Tp>
<Amt Ccy="USD">1084375.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Dt>
<Dt>2026-10-20</Dt>
</Dt>
</Bal>
<Bal>
<Tp>
<CdOrPrtry>
<Cd>CLAV</Cd>
</CdOrPrtry>
</Tp>
<Amt Ccy="USD">1069375.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Dt>
<Dt>2026-10-20</Dt>
</Dt>
</Bal>
<Bal>
<Tp>
<CdOrPrtry>
<Cd>FWAV</Cd>
</CdOrPrtry>
</Tp>
<Amt Ccy="USD">1084375.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Dt>
<Dt>2026-10-21</Dt>
</Dt>
</Bal>
<TxsSummry>
<TtlCdtNtries>
<NbOfNtries>4</NbOfNtries>
<Sum>314500.00</Sum>
</TtlCdtNtries>
<TtlDbtNtries>
<NbOfNtries>2</NbOfNtries>
<Sum>480125.00</Sum>
</TtlDbtNtries>
</TxsSummry>
<Ntry>
<Amt Ccy="USD">480000.00</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-10-20</Dt>
</BookgDt>
<ValDt>
<Dt>2026-10-20</Dt>
</ValDt>
<AcctSvcrRef>ZAG26293000101</AcctSvcrRef>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>ICDT</Cd>
<SubFmlyCd>FICT</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<NtryDtls>
<TxDtls>
<Refs>
<InstrId>BRK2610200017</InstrId>
<EndToEndId>BRK2610200017</EndToEndId>
<UETR>fbf98c4f-3a79-49d0-a030-5d6bb29aaca9</UETR>
</Refs>
<Amt Ccy="USD">480000.00</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<RltdPties>
<Cdtr>
<Agt>
<FinInstnId>
<BICFI>BRKRGB2LXXX</BICFI>
</FinInstnId>
</Agt>
</Cdtr>
</RltdPties>
<RmtInf>
<Ustrd>MARGIN CALL SETTLEMENT 20OCT26</Ustrd>
</RmtInf>
</TxDtls>
</NtryDtls>
</Ntry>
<Ntry>
<Amt Ccy="USD">250000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-10-20</Dt>
</BookgDt>
<ValDt>
<Dt>2026-10-20</Dt>
</ValDt>
<AcctSvcrRef>ZAG26293000102</AcctSvcrRef>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>RCDT</Cd>
<SubFmlyCd>XBCT</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<NtryDtls>
<TxDtls>
<Refs>
<InstrId>PAY2610200388</InstrId>
<EndToEndId>DEP-88213-1020</EndToEndId>
<UETR>ad60d86d-1d33-4493-977b-a90383e679fd</UETR>
</Refs>
<Amt Ccy="USD">250000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<RltdPties>
<Dbtr>
<Pty>
<Nm>AL NOOR INVESTMENTS LLC</Nm>
</Pty>
</Dbtr>
<DbtrAcct>
<Id>
<IBAN>GB42BANK40051587654321</IBAN>
</Id>
</DbtrAcct>
</RltdPties>
<RltdAgts>
<DbtrAgt>
<FinInstnId>
<BICFI>BANKGB2LXXX</BICFI>
</FinInstnId>
</DbtrAgt>
</RltdAgts>
<RmtInf>
<Ustrd>CLIENT DEPOSIT ACCOUNT 88213</Ustrd>
</RmtInf>
</TxDtls>
</NtryDtls>
</Ntry>
<Ntry>
<Amt Ccy="USD">37500.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-10-20</Dt>
</BookgDt>
<ValDt>
<Dt>2026-10-20</Dt>
</ValDt>
<AcctSvcrRef>ZAG26293000103</AcctSvcrRef>
<BkTxCd>
<Domn>
<Cd>SECU</Cd>
<Fmly>
<Cd>CORP</Cd>
<SubFmlyCd>DVCA</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<NtryDtls>
<TxDtls>
<Refs>
<AcctSvcrRef>ZAG26293000103</AcctSvcrRef>
</Refs>
<Amt Ccy="USD">37500.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<AddtlTxInf>CASH DIVIDEND ISIN AEZAGT000016 EX DATE 15OCT26</AddtlTxInf>
</TxDtls>
</NtryDtls>
</Ntry>
<Ntry>
<Amt Ccy="USD">15000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-10-20</Dt>
</BookgDt>
<ValDt>
<Dt>2026-10-21</Dt>
</ValDt>
<AcctSvcrRef>ZAG26293000104</AcctSvcrRef>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>RCDT</Cd>
<SubFmlyCd>BOOK</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<NtryDtls>
<TxDtls>
<Refs>
<EndToEndId>TRF2610200045</EndToEndId>
</Refs>
<Amt Ccy="USD">15000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<RltdPties>
<Dbtr>
<Pty>
<Nm>GULF TRADING LLC</Nm>
</Pty>
</Dbtr>
</RltdPties>
<RmtInf>
<Ustrd>INTERNAL TRANSFER VALUE 21OCT26</Ustrd>
</RmtInf>
</TxDtls>
</NtryDtls>
</Ntry>
<Ntry>
<Amt Ccy="USD">12000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<RvslInd>true</RvslInd>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-10-20</Dt>
</BookgDt>
<ValDt>
<Dt>2026-10-20</Dt>
</ValDt>
<AcctSvcrRef>ZAG26293000105</AcctSvcrRef>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>ICDT</Cd>
<SubFmlyCd>XBCT</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<NtryDtls>
<TxDtls>
<Refs>
<InstrId>BRK2610190031</InstrId>
</Refs>
<Amt Ccy="USD">12000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
</TxDtls>
</NtryDtls>
<AddtlNtryInf>REVERSAL OF DUPLICATE DEBIT BOOKED 19OCT26</AddtlNtryInf>
</Ntry>
<Ntry>
<Amt Ccy="USD">125.00</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-10-20</Dt>
</BookgDt>
<ValDt>
<Dt>2026-10-20</Dt>
</ValDt>
<AcctSvcrRef>ZAG26293000106</AcctSvcrRef>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>MDOP</Cd>
<SubFmlyCd>CHRG</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<NtryDtls>
<TxDtls>
<Refs>
<InstrId>BRK2610200017</InstrId>
</Refs>
<Amt Ccy="USD">125.00</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
</TxDtls>
</NtryDtls>
<AddtlNtryInf>CHARGES OUTGOING TRANSFER BRK2610200017</AddtlNtryInf>
</Ntry>
<AddtlStmtInf>CREDIT INTEREST RATE 3.25 PCT FROM 01NOV26</AddtlStmtInf>
</Stmt>
</BkToCstmrStmt>
</Document>Decode this example in the parserAmounts use a dot as decimal mark and carry no sign; CdtDbtInd gives the direction.
The reversal entry is CRDT with RvslInd true, the equivalent of RD in MT940 field 61.
BICs, names, references, IBANs, the ISIN and the UETRs are made up; the IBANs and the ISIN carry valid check digits.
camt.053 and its MT equivalent
camt.053 is the ISO 20022 equivalent of the MT940 (customer statement) and the MT950 (bank-to-bank statement). Balances and entries map closely; the difference is the transaction detail, which camt.053 carries in structured elements instead of field 86 text.
Going from camt.053 to MT940 loses data: end-to-end references longer than 16 characters, UETRs, structured addresses and long remittance information do not fit into field 61 and six lines of field 86. See camt.053 vs MT940 and truncation in MT translation.
| ISO 20022 element | MT field | Note |
|---|---|---|
GrpHdr/MsgId | 20 | Message reference. Stmt/Id identifies the statement itself. |
GrpHdr/OrgnlBizQry/MsgId | 21 | Only when the statement answers a request. |
Stmt/Acct/Id (IBAN or Othr/Id), Stmt/Acct/Ownr | 25 / 25P | The BIC of option P becomes the owner identification. |
Stmt/ElctrncSeqNb, Stmt/StmtPgntn/PgNb | 28C | Statement number and page number. |
Stmt/Bal, Tp/CdOrPrtry/Cd = OPBD | 60F / 60M | 60M: OPBD with SubTp/Cd INTM in CBPR+. |
Stmt/Bal, Tp/CdOrPrtry/Cd = CLBD | 62F / 62M | 62M: CLBD with SubTp/Cd INTM in CBPR+. |
Stmt/Bal, Tp/CdOrPrtry/Cd = CLAV | 64 | |
Stmt/Bal, Tp/CdOrPrtry/Cd = FWAV | 65 | |
Stmt/Ntry/ValDt | 61 subfield 1 (value date) | |
Stmt/Ntry/BookgDt | 61 subfield 2 (entry date) | |
Stmt/Ntry/CdtDbtInd, Stmt/Ntry/RvslInd | 61 subfield 3 (C, D, RC, RD) | RD = CRDT with RvslInd true; RC = DBIT with RvslInd true. |
Stmt/Ntry/Amt | 61 subfield 5 (amount) | |
Stmt/Ntry/BkTxCd | 61 subfield 6 (S103, NTRF, FCHG ...) | Structured domain/family/sub-family code, or the bank’s proprietary code. |
Stmt/Ntry/NtryDtls/TxDtls/Refs | 61 subfield 7 (reference for the account owner) | InstrId, EndToEndId or another reference element, depending on the transaction. |
Stmt/Ntry/AcctSvcrRef | 61 subfield 8 (//bank reference) | |
TxDtls/RltdPties, TxDtls/RltdAgts, TxDtls/RmtInf, TxDtls/AddtlTxInf, Ntry/AddtlNtryInf | 61 subfield 9 and field 86 | /ORDP/ and /BENM/ become structured parties; /REMI/ becomes RmtInf. |
Stmt/AddtlStmtInf | Final field 86 |
Common errors and rejects
Closing balance does not reconcile
OPBD plus CRDT entries minus DBIT entries must equal CLBD. If it does not, look for a missing page (check PgNb and LastPgInd), an intermediate balance with sub type INTM read as final, or a file loaded twice.
How to fix itReversals counted with the wrong sign
In camt.053 CdtDbtInd already gives the direction of the reversal entry. Flipping the sign again because RvslInd is
How to fix ittruebooks it the wrong way. Use RvslInd only to link the entry to the one it reverses.Batch entry counted twice
Outside CBPR+ one entry can hold a batch with many TxDtls whose amounts add up to Ntry/Amt. Posting both the entry and its transactions doubles the movement. Post Ntry/Amt and use TxDtls for matching only.
Parser fails because of the version
The namespace, for example
urn:iso:std:iso:20022:tech:xsd:camt.053.001.08, fixes the version. A parser built for an older version may not read the element names and multiplicities of a newer one. Agree the version with each bank and read the namespace first.Transaction type cannot be mapped
Some banks send only a proprietary BkTxCd. Mapping tables built on the ISO domain, family and sub-family codes then miss. Ask the bank for the structured code, which CBPR+ recommends, or keep a per-bank table of proprietary codes.
Remittance details missing after conversion to MT940
A bank or system that converts camt.053 to MT940 has to cut references and remittance text to fit fields 61 and 86. Receive the camt.053 directly to keep the full data.
How to fix it
camt.053 questions
- What is a camt.053 file?
- An ISO 20022 XML bank statement. It reports the booked entries and balances of one or more accounts for a period, usually a business day, and can carry detailed data about each underlying payment.
- What is the difference between camt.053 and MT940?
- Both are end-of-day statements with the same balances and entries. camt.053 is structured XML: references, parties, agents and remittance information each have their own element, where the MT940 squeezes them into field 61 and up to six lines of field 86. See camt.053 vs MT940.
- What do OPBD, CLBD, CLAV and FWAV mean?
- They are balance type codes: OPBD opening booked balance (MT940 60F), CLBD closing booked balance (62F), CLAV closing available balance (64) and FWAV forward available balance (65). On split statements CBPR+ marks the intermediate opening and closing balances with sub type INTM.
- Which camt.053 version is used on Swift?
- CBPR+ uses camt.053.001.08 with a mandatory Business Application Header. Corporate channels and national practices may use other versions, so check the namespace of the file and your bank’s guide.
- Do I have to move from MT940 to camt.053?
- Statements were not part of the November 2025 deadline for cross-border payment instructions, and Swift continues to support MT statements beyond it. The move is agreed with each bank, but camt.053 is the way to receive the full ISO 20022 payment data on your statement.
All ISO 20022 messages · MT messages · MT to ISO 20022 migration