Skip to content

ISO 20022 · end of day

What is inside a CAMT.053, element by element

A CAMT.053 is the closed statement your bank publishes as XML. Every fact an MT940 pushes into free text has an element with a name here: the payer’s reference, the transaction code, the party the money came from, and both dates. The reading stops being an exercise in guessing what a bank meant and starts being a question of which version of the message it sends.

The account every page here reads

EUR
Published by
ISO 20022
What it carries
One account, one closed period: both balances, every entry, every reference.
Account
ES21 0049 0001 5323 4567 8901

Closing balance · Aug 14, 2026EUR 2,990,901.67

The definition

What a CAMT.053 actually is

The bank-to-customer statement of the ISO 20022 family, and the message a treasury team asks for once :86: has stopped being readable.

A CAMT.053 is the ISO 20022 XML message a bank sends to report one account’s closed statement period. Inside BkToCstmrStmt a GrpHdr carries the file’s own identification and one Stmt carries an account, its balances and its entries. The balances are coded — OPBD opens the period and CLBD closes it — and every entry states its amount, its credit or debit indicator, its booking date, its value date and a bank transaction code that is either a published three-part domain code or the bank’s own with the issuer named beside it.

Who sends it
Your bank, over the channel that already delivers everything else: EBICS, host-to-host, SFTP, an API. Most banks publish it beside MT940 rather than in place of it, so the same account arrives twice on the same morning in two spellings.
When it arrives
Once the statement period closes, one message per account per banking day, with the period stated on the statement rather than assumed by the reader. A bank that splits a busy account across several statements numbers them, and the numbering is what tells you one has not arrived.
What it looks like
XML, nested, and roughly three times the length of the MT940 for the same day. Nothing is positional: an element is found by its name and its path, so the file survives being reformatted, indented or pretty-printed on the way to you.

What its parts are called

  • CAMT.053 BkToCstmrStmt
  • camt.053 vs MT940
  • CAMT.053 BkTxCd
  • CAMT.053 EndToEndId
  • camt.053.001.02

The file

One account’s closed day, as the bank published it

The same account and the same three movements every page in this library uses. Carry the closing balance from here to the MT940 page and it has to agree with itself.

CAMT.053Both balances before the entries, which is the schema’s own order
<Stmt>
  <Id>26081400161</Id>
  <Acct><Id><IBAN>ES2100490001532345678901</IBAN></Id><Ccy>EUR</Ccy></Acct>
  <Bal>
    <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
    <Amt Ccy="EUR">2864112.47</Amt><CdtDbtInd>CRDT</CdtDbtInd>
    <Dt><Dt>2026-08-13</Dt></Dt>
  </Bal>
  <Bal>
    <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>
    <Amt Ccy="EUR">2990901.67</Amt><CdtDbtInd>CRDT</CdtDbtInd>
    <Dt><Dt>2026-08-14</Dt></Dt>
  </Bal>
  <Ntry>
    <Amt Ccy="EUR">182046.55</Amt><CdtDbtInd>CRDT</CdtDbtInd><Sts><Cd>BOOK</Cd></Sts>
    <BookgDt><Dt>2026-08-14</Dt></BookgDt><ValDt><Dt>2026-08-15</Dt></ValDt>
    <AcctSvcrRef>BK26081401</AcctSvcrRef>
    <BkTxCd><Domn><Cd>PMNT</Cd><Fmly><Cd>RCDT</Cd><SubFmlyCd>ESCT</SubFmlyCd></Fmly></Domn></BkTxCd>
    <NtryDtls><TxDtls>
      <Refs><EndToEndId>4471QX</EndToEndId></Refs>
      <RltdPties><Dbtr><Pty><Nm>NORTE TESORERIA SL</Nm></Pty></Dbtr></RltdPties>
      <RmtInf><Ustrd>FRA 4471</Ustrd></RmtInf>
    </TxDtls></NtryDtls>
  </Ntry>
  <Ntry>
    <Amt Ccy="EUR">42318.90</Amt><CdtDbtInd>DBIT</CdtDbtInd><Sts><Cd>BOOK</Cd></Sts>
    <BookgDt><Dt>2026-08-14</Dt></BookgDt><ValDt><Dt>2026-08-14</Dt></ValDt>
    <AcctSvcrRef>BK26081402</AcctSvcrRef>
    <BkTxCd><Domn><Cd>PMNT</Cd><Fmly><Cd>RDDT</Cd><SubFmlyCd>ESDD</SubFmlyCd></Fmly></Domn></BkTxCd>
    <AddtlNtryInf>NORTE SUMINISTROS SL SUMINISTRO JULIO</AddtlNtryInf>
  </Ntry>
  <Ntry>
    <Amt Ccy="EUR">12938.45</Amt><CdtDbtInd>DBIT</CdtDbtInd><Sts><Cd>BOOK</Cd></Sts>
    <BookgDt><Dt>2026-08-14</Dt></BookgDt><ValDt><Dt>2026-08-14</Dt></ValDt>
    <AcctSvcrRef>BK26081403</AcctSvcrRef>
    <BkTxCd><Prtry><Cd>NCHG</Cd><Issr>SWIFT</Issr></Prtry></BkTxCd>
    <AddtlNtryInf>COMISION MANTENIMIENTO 3T</AddtlNtryInf>
  </Ntry>
</Stmt>

Where each fact lives in this file

Which account it is
<Acct><Id><IBAN>
The balance it opened on
<Bal><Tp><CdOrPrtry><Cd>OPBD
One movement, and which way it went
<Ntry><Amt> · <CdtDbtInd>
The day it was booked, and the day the money is yours
<ValDt> · <BookgDt>
What the bank wrote about it
<RmtInf> · <AddtlNtryInf>
The reference that ties it to a payment
<EndToEndId> · <AcctSvcrRef>
The balance it closed on
<Bal><Tp><CdOrPrtry><Cd>CLBD

What comes out

Named elements, and the version your bank actually sends

Everything MT940 leaves to a convention, this message states. What it leaves to you instead is knowing which release of it you are holding.

Out of each entry we take the amount, the indicator, both dates, the account servicer reference and the bank transaction code. Where the entry carries transaction details we also take the end-to-end reference and the named party, which are the two facts a match is usually made on. A domain code and a proprietary code are both legal and we keep whichever arrived, with its issuer, so a code nobody publishes is still evidence rather than a blank.

The catch is version drift. Element depth moved between releases of camt.053: a party sits one level deeper in the later ones, a status went from a bare code to a structure, and a file that validates against one schema fails against another. So a format profile is pinned to the version a bank actually sends rather than to the standard’s name, and a bank that changes release gets a new profile instead of a broken morning. Plenty of banks also fill AddtlNtryInf with the same sentence they used to put in :86:, and that lands on the same per-bank rules the MT940 needs.

Format profiles · CAMT.053
Which account it is<Acct><Id><IBAN>
ES21 0049 0001 5323 4567 8901
The balance it opened on<Bal><Tp><CdOrPrtry><Cd>OPBD
EUR 2,864,112.47
One movement, and which way it went<Ntry><Amt> · <CdtDbtInd>
EUR +182,046.55
The day it was booked, and the day the money is yours<ValDt> · <BookgDt>
Aug 15, 2026
What the bank wrote about it<RmtInf> · <AddtlNtryInf>
NORTE TESORERIA SL · FRA 4471
The reference that ties it to a payment<EndToEndId> · <AcctSvcrRef>
4471QX
The balance it closed on<Bal><Tp><CdOrPrtry><Cd>CLBD
EUR 2,990,901.67
Every value beside the tag it was read from, so the reading can be checked against the record above.

Ask your bank for this one where you can get it. It is the same day either way, and this is the version where the references survive the trip.

Next

The same day, and the same day unfinished

MT940 is this statement in the message most banks still send beside it. CAMT.052 is this account before the close, with an interim balance instead of a closing one. BAI2 is the American file that answers the same question with numbered records.

The same day written in four formats, side by side, is on Format library

Asked about CAMT.053

The questions a practitioner actually types

01What is the difference between CAMT.053 and MT940?
The same statement, with structure instead of free text. An MT940 states the amount, the dates and the direction in fixed positions and leaves the counterparty, the invoice reference and the end-to-end reference inside :86:, which has no standard behind it. A CAMT.053 gives each of those an element with a name, adds a coded transaction type and separates the booking date from the value date as two elements rather than two subfields. It is longer, and the length is the references.
02What do OPBD and CLBD mean in a CAMT.053?
They are balance type codes. OPBD is the opening booked balance for the period and CLBD is the closing booked balance, and a statement carries both. The available pair, OPAV and CLAV, is the same money minus whatever the bank has not released, and a statement may state all four. The type sits in the balance’s own Tp element, so a reader takes the code rather than the position.
03What is BkTxCd in a CAMT.053?
The bank transaction code, and it comes in two legal forms. A domain code is the published three-part set — a domain, a family and a sub-family, such as PMNT, RCDT and ESCT for a received credit transfer. A proprietary code is the bank’s own, with the issuer that defines it named beside it, and banks reach for it whenever they do something routinely that the published set has no code for. Charges are the usual case. Both are valid, and a reader that only handles the first drops entries.
04Which version of camt.053 does my bank send?
Ask, and pin it. The message has several releases, they differ in element depth and in a few structures, and the standard’s name alone does not identify one. Your bank states the release in its file specification and usually in the namespace of the file itself. We hold the version per bank as a format profile, so two banks on two releases are two profiles rather than one parser with branches in it.
05Does a CAMT.053 always carry the end-to-end reference?
Only when the entry carries transaction details, and not every entry does. A bank sends the structured detail for entries that came from a payment and falls back to a free-text line for the ones that did not — its own charges, an adjustment, a manual posting. The element exists whenever the fact exists, which is the difference from MT940, where the fact and the free text share one field.

Send one CAMT.053 and see it read.

One account, one month. You get back every entry with both dates, its transaction code, the party it names and the reference chain, and the balances footed.

Whatever release your bank is on. Tell us nothing about it and we will tell you.