camt.053 bank statements: the ISO 20022 format

camt.053 is the ISO 20022 XML message a bank sends to an account holder as an end-of-day statement. It is the structured replacement for the MT940 tagged-text format and it is delivered the same way: through corporate banking portals, host-to-host links and SFTP, to the treasury systems and ERPs of companies large enough to have an electronic reporting agreement with their bank. Most small businesses will never see one, though in Switzerland, the Netherlands, Germany and the Nordics business online banking often offers a camt.053 download alongside CSV and PDF. If someone has sent you an XML file whose first real element is BkToCstmrStmt, this guide explains what is in it, how it relates to MT940, and what to do when your software cannot read it.

The camt family

ISO 20022 is a catalogue of financial messages defined as XML schemas. Each message has a name made of a business area, a number and a version. The cash management area is camt, and three of its messages report on accounts:

The full identifier includes the version. camt.053.001.02 is what most European banks first implemented during the SEPA rollout, and camt.053.001.08 is the version adopted for the SWIFT cross-border migration and by many banks that have refreshed their reporting since. Later versions exist. The overall structure is the same across all of them, but element shapes differ in places: in .02 the entry status is a bare Sts element holding BOOK and a party is Cdtr with Nm directly inside, while .08 nests them as Sts/Cd and Cdtr/Pty/Nm. The sample below uses .08.

What a file looks like

A trimmed statement with one debit entry:

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.08">
  <BkToCstmrStmt>
    <GrpHdr>
      <MsgId>STMT260630001</MsgId>
      <CreDtTm>2026-06-30T23:15:00</CreDtTm>
    </GrpHdr>
    <Stmt>
      <Id>00126</Id>
      <ElctrncSeqNb>126</ElctrncSeqNb>
      <CreDtTm>2026-06-30T23:15:00</CreDtTm>
      <Acct><Id><IBAN>GB29NWBK60161331926819</IBAN></Id><Ccy>GBP</Ccy></Acct>
      <Bal>
        <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
        <Amt Ccy="GBP">14250.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt><Dt>2026-06-29</Dt></Dt>
      </Bal>
      <Bal>
        <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>
        <Amt Ccy="GBP">13050.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt><Dt>2026-06-30</Dt></Dt>
      </Bal>
      <Ntry>
        <Amt Ccy="GBP">1200.00</Amt>
        <CdtDbtInd>DBIT</CdtDbtInd>
        <Sts><Cd>BOOK</Cd></Sts>
        <BookgDt><Dt>2026-06-30</Dt></BookgDt>
        <ValDt><Dt>2026-06-30</Dt></ValDt>
        <AcctSvcrRef>BANKREF001</AcctSvcrRef>
        <BkTxCd><Domn><Cd>PMNT</Cd><Fmly><Cd>ICDT</Cd><SubFmlyCd>ESCT</SubFmlyCd></Fmly></Domn></BkTxCd>
        <NtryDtls>
          <TxDtls>
            <Refs><EndToEndId>INV4471</EndToEndId></Refs>
            <RltdPties><Cdtr><Pty><Nm>Acme Supplies Ltd</Nm></Pty></Cdtr></RltdPties>
            <RmtInf><Ustrd>Invoice 4471</Ustrd></RmtInf>
          </TxDtls>
        </NtryDtls>
      </Ntry>
    </Stmt>
  </BkToCstmrStmt>
</Document>

Element names are abbreviated the same way throughout ISO 20022: vowels dropped, so Statement becomes Stmt, Entry becomes Ntry, Creditor becomes Cdtr and Remittance Information becomes RmtInf. Once you know the pattern you can read most of a file cold.

The structure

GrpHdr: group header

One per file. MsgId is the bank's unique reference for this message and CreDtTm is when it was generated. A copy or duplicate is meant to be flagged with CpyDplctInd on the Stmt (COPY, DUPL or CODU), although some banks simply resend with the same MsgId.

Stmt: the statement

One per account per period. A single file can hold several Stmt blocks for several accounts. Inside sit Id and ElctrncSeqNb (the statement number, which increments each banking day), an optional FrToDt for the period, Acct with the IBAN or other account identifier and its currency, and then the balances and entries.

Bal: balances

Each Bal has a type code, an amount with its currency, a credit or debit indicator and a date. The codes you will see:

CdtDbtInd is CRDT for a positive balance and DBIT for an overdrawn one. The amount itself is never signed.

Ntry: entries

One Ntry per booked movement on the account. Amt and CdtDbtInd give the amount and direction. Sts is BOOK for a booked entry; camt.052 can also carry PDNG for pending, and newer versions add INFO and FUTR, though national guidelines usually keep camt.053 to booked entries only. BookgDt and ValDt are the booking and value dates. AcctSvcrRef is the bank's own reference. An entry can be a single payment or a batch: a payroll run or a direct debit collection arrives as one Ntry for the total.

NtryDtls and TxDtls: the transactions inside an entry

NtryDtls holds the breakdown. For a single payment there is one TxDtls. For a batch there can be hundreds, each with its own references, parties and amount, or the bank may send only a Btch element with the count and total and deliver the detail separately in camt.054. Inside TxDtls, Refs carries the identifiers (EndToEndId set by the payer, InstrId, TxId, and MndtId for a direct debit mandate), RltdPties names the debtor and creditor with their accounts, RltdAgts names their banks, and AmtDtls gives the original amount and exchange rate when a currency conversion happened.

RmtInf: remittance information

What the payer wrote on the payment. Ustrd is unstructured text, up to 140 characters per occurrence. Strd is the structured form with invoice numbers, amounts and creditor references in their own fields, which is what makes automatic invoice matching work when the payer's software fills it in.

BkTxCd: bank transaction codes

Every Ntry carries a BkTxCd with a three-level ISO code and, usually, the bank's proprietary code alongside it under Prtry. The three levels are Domn (domain), Fmly (family) and SubFmlyCd (sub-family):

ISO publishes the full list, several hundred combinations, as an external code set. The point of the scheme is that PMNT/RCDT/ESCT means the same thing from every bank, where how banks populate MT940's :61: type codes and lay out :86: differs from one bank to the next. In practice banks populate the ISO code with varying care, so reconciliation software matches on the proprietary code as a fallback.

camt.053 and MT940

The two carry the same statement. Field for field:

The gain is that camt.053 gives the counterparty, the references and the remittance text their own elements with defined lengths, where MT940 packs all of it into six lines of :86: in a layout each bank chooses. The MT940 guide shows what that looks like from the other side. The cost is size: a camt.053 file is several times the bytes of the equivalent MT940.

Migration status

SWIFT's coexistence period for cross-border interbank payment messages ended in November 2025, and interbank payment instructions over SWIFT are now ISO 20022 only. Bank-to-customer statement reporting was never on that deadline. SWIFT has a later end date for the interbank MT 940, 942 and 950 messages, currently planned for November 2028, but that governs bank-to-bank traffic. For the statements a bank sends its own customers, each bank decides when, and whether, to stop sending MT940.

As of September 2026 the picture is mixed. Most European corporate banks have offered camt.053 for years and some have told customers when their MT940 reporting will end; elsewhere camt.053 is usually available on request while MT940 continues. ERP vendors have kept pace: SAP, Oracle and Microsoft Dynamics 365 import camt.053, and Business Central added camt.053.001.08 in its 2025 release cycle. If your company relies on an MT940 feed, ask your bank for its written timetable and test camt.053 in parallel before you need it.

Who receives camt.053

Corporate treasury teams reconciling many accounts across several banks. Finance departments running SAP, Oracle or Dynamics with bank statement import configured. Payment providers that hold accounts at partner banks and reconcile settlement. In every case the file travels machine to machine, and the finance staff see the result in a reconciliation screen rather than the XML.

If you have a camt.053 file and need the transactions

Use the system the file was meant for, if it exists. If a treasury or ERP system requested the feed, its bank reconciliation module is the right place to import it, and it will handle batch entries and camt.054 detail properly.

Otherwise, go back to the same account through a different door. The bank that generates camt.053 also produces a PDF statement and a CSV export for the same account, with the same opening and closing balances. stmtai does not read camt.053, and it does not read MT940 either. It takes PDF statements, scanned images and CSV, QIF and OFX exports, checks them against the opening and closing balances the statement prints, and writes Excel, CSV, QuickBooks .qbo or Xero CSV. For a bookkeeper who needs the month's transactions in a spreadsheet or an accounting package, the PDF of the account is the better source anyway: it is readable, the balances are in plain sight, and converting it to Excel takes a few minutes.