Guide
camt.053 vs MT940: differences and field-by-field mapping
Both are the end-of-day bank statement: the same balances and the same entries. MT940 packs them into short text fields; camt.053 spells them out in XML, with room for the references, parties and codes that MT940 squeezes into one free-text field. Here is what differs, and where every MT940 field goes in a camt.053.
What differs
| Aspect | MT940 | camt.053 |
|---|---|---|
| Format | Tagged text fields (:20:, :61: …), optionally in a SWIFT FIN envelope | XML, validated against a published schema |
| Characters | The SWIFT character set: no accents or umlauts on the SWIFT network | UTF-8: names and text as written |
| Amounts | Comma decimal, no sign; a D/C mark gives the direction | Point decimal, never negative; CdtDbtInd (CRDT, DBIT) gives the direction |
| Entry type | A three-letter code after N, S or F (NTRF, NCHG), chosen per bank | An ISO bank transaction code in three levels (PMNT/RCDT/ESCT), plus an optional proprietary one |
| References | 16 characters for the customer’s and the bank’s reference | 35 characters; separate end-to-end id, instruction id, mandate id and UETR |
| Counterparty | Inside :86:, in a bank-specific layout | Structured: name, account, bank and address in their own elements |
| Remittance | Inside :86:, 6 lines of 65 characters in all | Unstructured text or a structured creditor reference (RF) in RmtInf |
| Batches | One :61: per booking; the detail of a batch is not there | A batch entry can list every transaction in TxDtls (or a camt.054 does) |
| Returns | A returned-item code (NRTI) and text in :86: | A return reason code in RtrInf and the original references |
| Balances | :60F: opening, :62F: closing, :64: available, :65: forward | Bal with a type code each: OPBD, CLBD, CLAV, FWAV … |
| Long statements | Split into pages (:28C: page number, :62M: / :60M:) | Pagination elements, rarely needed |
What a camt.053 gains is mostly structure: an accounting system can match an incoming payment on its end-to-end id and its bank transaction code, and route a return by its reason code, instead of parsing a bank’s :86: layout.
Field-by-field mapping
The mapping the MT940 Viewer and the convert endpoint use to turn an MT940 into camt.053.001.08 (urn:iso:std:iso:20022:tech:xsd:camt.053.001.08): one Stmt per statement, one Ntry with one TxDtls per :61:.
| MT940 | camt.053.001.08 | Note |
|---|---|---|
| :20: Transaction Reference | Stmt/Id | |
| :21: Related Reference | — | Not carried over (camt.053 has no place for the MT920 request reference). |
| :25: Account | Stmt/Acct/Id/IBAN, else Acct/Id/Othr/Id | An IBAN that passes mod-97 goes in IBAN; anything else in Othr/Id (34 characters at most). |
| :25P: identifier code | Stmt/Acct/Ownr/Id/OrgId/AnyBIC | The account owner’s BIC (field 25a identifies the account and, optionally, its owner). An identifier code that is not a BIC is left out. |
| :25: BIC/account, or the SWIFT header | Stmt/Acct/Svcr/FinInstnId/BICFI | The bank that services the account: a BIC written before the account in :25:, else the bank that sent the statement (the sender in block 2 of a SWIFT output message, or in block 1 of an input one). |
| :28C: Statement number / page | Stmt/ElctrncSeqNb, Stmt/StmtPgntn/PgNb | LastPgInd is true for :62F:, false for :62M:. |
| :60F: / :60M: | Bal Tp OPBD | :60M: and :62M: carry the sub-type code INTM (Bal/Tp/SubTp/Cd, an intermediate balance carried to the next page) so the page break stays visible. |
| :62F: / :62M: | Bal Tp CLBD | |
| :64: | Bal Tp CLAV | |
| :65: | Bal Tp FWAV (one per :65:) | |
| :61: value date / entry date | Ntry/ValDt/Dt, Ntry/BookgDt/Dt | Without an entry date the booking date is the value date. The entry date’s year is the one closest to the value date. |
| :61: D/C mark | Ntry/CdtDbtInd, Ntry/RvslInd | C → CRDT, D → DBIT, RD → CRDT + RvslInd, RC → DBIT + RvslInd (the indicator gives the booking’s actual direction). EC/ED (MT942 expected entries) are refused. |
| :61: amount | Ntry/Amt (+ TxDtls/Amt) | Comma decimal to point, written with the currency’s decimals. |
| :61: transaction type (NTRF, S103 …) | Ntry/BkTxCd/Prtry/Cd, Issr SWIFT | Not mapped to ISO domain/family/sub-family codes: the MT codes are too coarse for that to be reliable. |
| :61: reference for the account owner | TxDtls/Refs/AcctOwnrTxId | NONREF is dropped; 35 characters at most. |
| :61: //bank reference | Ntry/AcctSvcrRef | 35 characters at most. |
| :61: supplementary details | TxDtls/AddtlTxInf | |
| :86: (after a :61:) | Ntry/AddtlNtryInf and TxDtls/RmtInf/Ustrd | The full text is kept (500 characters at most in AddtlNtryInf; Ustrd in 140-character parts). Structured :86: lines join as written (they are wrapped mid-word), free-text lines with a space. |
| :86: ?20–?29 / /REMI/ remittance | TxDtls/RmtInf/Ustrd | From structured :86: the remittance lines (or SVWZ+) are used instead of the whole text. |
| :86: ?32/?33, /NAME/, /CNTP/ | TxDtls/RltdPties/Dbtr (credits) or Cdtr (debits)/Pty/Nm | |
| :86: ?31, /IBAN/ | TxDtls/RltdPties/DbtrAcct or CdtrAcct | |
| :86: ?30, /BIC/ | TxDtls/RltdAgts/DbtrAgt or CdtrAgt (BICFI, else clearing member id) | |
| :86: EREF+ / /EREF/ | TxDtls/Refs/EndToEndId | |
| :86: MREF+ / /MARF/ | TxDtls/Refs/MndtId | |
| :86: at the end of the statement | Stmt/AddtlStmtInf | |
| (none) | GrpHdr/CreDtTm, Stmt/CreDtTm | MT940 carries no creation time: both are the time of the conversion. |
| (computed) | Stmt/TxsSummry | Counted and summed from the :61: lines. |
What a conversion cannot add
A converted file carries what the MT940 says and nothing more, so the camt.053 your bank produces for the same account usually holds more:
- Transaction types stay proprietary codes (
BkTxCd/Prtry, issuer SWIFT): NTRF does not say whether a transfer was SEPA, domestic or cross-border, so an ISO code would be a guess. - Unstructured :86: text stays text; only subfields the converter recognizes become parties, accounts, references and remittance.
- Batch detail, return reason codes and UETRs that the bank never put in the MT940 cannot appear in the camt.053.
- Creation times are the time of the conversion: MT940 has none.
A conversion is a bridge for a system that only reads camt.053 while a bank still sends MT940. For the long run, ask the bank for camt.053 itself; the migration guide has a checklist.