camt.052, camt.053 and camt.054: The Account Reporting Operator Reference

An operator asking "which account-reporting message should I expect, when, and what do I reconcile from it?" needs to separate three ISO 20022 messages that all describe the same underlying account but serve different jobs: camt.052 for same-day visibility, camt.053 for the closed-period statement you reconcile against, and camt.054 for per-entry debit/credit notices. Confusing them is the most common source of false reconciliation breaks in this layer — not because the messages are unclear, but because they are frequently read as interchangeable when the ISO 20022 message definitions explicitly scope them differently.

This reference stays at the message-format layer: what each message is, what it structurally contains, and what an operator does with it. It does not restate the three-way match, break taxonomy, or PSP settlement-file mechanics — those are owned by the PSP reconciliation failure runbook and the Stripe vs Adyen settlement file reference, which cover the processor side of reconciliation. This article is the bank side: what your bank sends you about your own account, in ISO 20022 form.

What each message is

camt.052 — BankToCustomerAccountReport. Per the ISO 20022 message definition, camt.052 is sent by the account servicer to inform the account owner "of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time." Critically, it can be used to "report pending and booked items" — camt.052 is not restricted to settled entries. Banks send it on request or push it at configured intervals through the business day, which is why it is the message treasury teams poll for same-day cash position and liquidity sweeping decisions.

camt.053 — BankToCustomerStatement. The ISO definition states camt.053 is used "to inform the account owner ... of the entries booked to the account, and to provide the owner with balance information ... at a given point in time," and explicitly: "It contains information on booked entries only." This is the closed-period statement — the one document in this family that behaves like a traditional bank statement, generated for an agreed period (commonly prior-day, sometimes intraday depending on the bank agreement) and carrying only settled entries. This is the message operators reconcile the ledger against.

camt.054 — BankToCustomerDebitCreditNotification. Per the ISO definition, camt.054 notifies "one or more debit and/or credit entries reported to the account," can report pending and booked items, and — the detail most often missed — "does not contain balance information." camt.054 is a notification about specific entries, not a balance report. It is the message accounts payable/receivable teams use to match an individual incoming or outgoing payment to an invoice the moment it posts, without waiting for the end-of-day statement.

Comparison table

The MT-to-camt entries in the right column are stated at the purpose level only — as "replaces" or "supersedes" relationships documented by bank and SWIFT-affiliated implementation guides — not as field-by-field equivalence. No source reviewed for this reference asserted an exact field mapping between MT940 and camt.053, or between MT900/910 and camt.054; that level of detail sits in gated CBPR+ Usage Guidelines, consistent with the pattern noted in the MT103 to pacs.008 field mapping reference.

Structure that matters operationally

All three messages share the same building-block shape: a GroupHeader carrying message-level metadata (message ID, creation timestamp), followed by the substantive block — Report for camt.052, Statement for camt.053, Notification for camt.054 — which in turn carries the account, balances (where applicable), and entries.

Entry (Ntry) is not the same as a transaction. This is the single most consequential structural fact for anyone writing a parser against these messages. One Entry line can represent a single payment, or it can represent a batch — a payroll run, a merchant acquirer's daily settlement, a direct debit collection file. The ISO 20022 definition for EntryDetails (NtryDtls), the block nested inside each Entry, states it "identifies the underlying transaction(s) and/or batched entries." Inside EntryDetails, a Batch (Btch) sub-block carries the transaction count and total amount for the batch, and TransactionDetails (TxDtls) — nested further in — "provides information on the underlying transaction(s)": the individual payments, their references, and their counterparties.

The practical failure mode: a naive integration that reads only Ntry-level amount and reference will see "one credit, $48,000, payroll" and stop there. It will not see the twenty-two individual salary payments unless it descends into NtryDtls and iterates TxDtls. Any ERP or TMS ingestion process that needs to match individual underlying payments to invoices or employee records must parse to the TxDtls level, not the Ntry level — and must handle the case where TxDtls is absent (a single unbatched entry, where the entry-level data is the complete picture).

camt.054 is the entry-notification counterpart to this same structure: rather than aggregating entries into a periodic report or statement, it sends the notification for one or more specific entries as they occur, using the same underlying Entry/EntryDetails/TransactionDetails shape. The structural difference from camt.052/053 is at the message-purpose level (a notification vs. a report/statement), not in how an individual entry is internally represented.

Balances: why opening, closing, interim, and available differ

Balance information sits in a Balance (Bal) block, coded by BalanceType, using values published in a separate ISO 20022 external code list (the Message Definition Report references this as ExternalBalanceType1Code and points to the downloadable code set rather than embedding it). Bank implementation guides that reproduce this code set document the following balance types and their definitions:

• OPBD (Opening Booked) — the book balance at the start of the reporting period; must equal the prior period's closing booked balance.
• CLBD (Closing Booked) — the sum of the opening booked balance and all entries booked to the account during the reporting period. This is the balance you reconcile the period's activity against.
• ITBD (Interim Booked) — a balance calculated during the account servicer's business day, at a specified time, and explicitly subject to further change during that day. This is an intraday snapshot, not a final figure.
• CLAV (Closing Available) — funds at the account owner's disposal on the date specified, at close.
• OPAV (Opening Available) and ITAV (Interim Available) — the available-funds counterparts to OPBD and ITBD.
• FWAV (Forward Available) — forward-looking available balance.
• PRCD (Previously Closed Booked) — the balance of the account at the previously closed reporting period; the new period's OPBD must equal this value, which is the mechanism operators can use to detect a missing or skipped statement.
• XPCD (Expected) — booked entries plus pending items known at calculation time, projecting the end-of-day balance if nothing else posts.
• INFO (Information) — for informational purposes.

Booked vs. available is the distinction operators most often collapse. A booked balance reflects entries that have posted to the account; an available balance reflects what the account owner can actually draw on, which may be lower (holds, uncleared items) or presented differently depending on the bank's liquidity rules. Reconciling against an available balance when the ledger expects a booked balance — or vice versa — produces a mismatch that looks like a missing entry but is actually a balance-type mismatch.

Booking date vs. value date compounds this at the entry level. Each Entry carries a booking date (when the entry posted to the account) and a value date (used for interest calculation and, in many corridors, for determining which period the entry effectively belongs to for cash purposes). The two commonly diverge — an entry booked on a Friday may carry a Monday value date. At period-end, an entry booked in one statement period but value-dated into the next (or vice versa) is a frequent, expected mismatch, not evidence of a processing error — provided the entry appears on the correct booking-date statement.

Which balance types a given bank actually sends varies. The full code set above is what the ISO 20022 standard makes available; it is not what every bank populates. A Nordic bank implementation guide reviewed for this reference documents only OPBD, CLBD, FWAV, and CLAV as used codes on its camt.053. A Swiss market implementation guideline documents OPBD+CLBD as the mandatory pairing on camt.053, with CLAV, FWAV, and INFO optional, and a different mandatory/optional split (OPBD+ITBD, with ITBD sendable up to twice for opening and closing interim balance) on camt.052. Confirm the actual populated set with each bank rather than assuming your ERP mapping built for one bank's camt.053 will read cleanly from another's.

Reconciliation use cases

Reconcile cash to camt.053, not camt.052 or camt.054. camt.053 is the only message of the three that is explicitly scoped to booked entries only, for a closed period, with an opening and closing balance that should tie out arithmetically (CLBD = OPBD + net of booked entries). camt.052 can carry pending items that have not yet settled and may not reflect the final position; camt.054 carries no balance at all, so there is no closing figure to tie the period to. Using camt.052 as the reconciliation source risks reconciling against entries that later reverse or fail to settle; using camt.054 alone means never confirming the account's closing position.

camt.054 is not a substitute for camt.053 — it is a faster, narrower signal. Because camt.054 notifies individual entries as they post, it is the fastest way to match a specific incoming payment to an open invoice — useful for AR teams that want same-day cash application rather than waiting for the next day's statement. But because it carries no balance, it cannot confirm that the account's overall position is correct, and because it is entry-level, a missed or dropped camt.054 notification is not necessarily visible until the camt.053 statement is checked against it. Treat camt.054 as an acceleration layer on top of camt.053 reconciliation, not a replacement for it.

The same entry legitimately appears twice — in an intraday report and again in the end-of-day statement. An entry that posts mid-morning will appear in that day's camt.052 (if pulled or pushed after posting) and will also appear in that evening's camt.053 once the period closes. This is expected duplication across message types, not a processing duplicate, and matching logic that treats every appearance of a reference across camt.052 and camt.053 as a separate event will systematically double-count. Match by entry-level reference and reconcile within the message type the entry is being sourced from, not across camt.052 and camt.053 simultaneously.

Duplicate delivery within the same message type is a different, real risk — covered by the CopyDuplicateIndicator field in the message's Group Header, which flags a message as CODU (copy and duplicate), COPY (a copy sent to a party other than the account owner, for information), or DUPL (a duplicate of a message previously sent, for information/confirmation purposes). An ingestion process that does not check this indicator, or that receives the same statement resent for legitimate reasons (a bank reissuing a corrected file, a portal resend after a delivery failure), risks double-posting the same booked entries into the ledger. This is separate from the "same entry in camt.052 and camt.053" case above — CopyDuplicateIndicator governs re-delivery of the same message, not the expected overlap between different message types.

Ingestion realities for ERP/TMS

File vs. API delivery. Banks deliver camt.052/053/054 over multiple channels — SWIFT FileAct, EBICS, host-to-host, direct API, or a corporate portal — and the same bank may offer different channels for different message types. The message content and structure are the same regardless of channel, but delivery reliability, retry behaviour, and duplicate risk differ by channel and are worth confirming per bank rather than assumed to be uniform.

Missing-statement detection. The ElectronicSequenceNumber and LegalSequenceNumber fields in the Group Header (or Report/Statement block, depending on message) are defined as sequential numbers "increased incrementally for each report sent" — a gap in the sequence is a structurally detectable signal that a statement did not arrive, independent of whether the balance chain (PRCD-to-OPBD continuity, described above) also flags it. An ERP or TMS that tracks the last-received sequence number per account can alert on a gap before the balance-continuity check would catch the same problem a day later.

Statement pagination. Large statements can be split across multiple physical messages by size constraints — implementation-specific limits exist (one bank-published implementation guide documents an 80,000-character size threshold that triggers a new paginated camt.053 file) — and the pagination indicator in the message tells the receiver whether more pages follow. Ingestion logic must reassemble paginated statements before running balance-continuity checks; checking OPBD/CLBD on a single page of a multi-page statement will produce a false imbalance.

Reconciling across multiple banks with different implementation choices. The balance-type subset comparison above (Nordic bank vs. Swiss market guideline vs. the full ISO code list) is one concrete illustration of a broader pattern documented consistently across the bank implementation guides reviewed for this reference: the ISO 20022 standard defines the full structure and the full external code list, but each bank's actual implementation — which balance types it populates, which channels it offers, what size triggers pagination, whether it supports intraday camt.053 by agreement — is configured per bank, often per contract. A parsing layer built against one bank's camt.053 output will not necessarily read cleanly from a second bank's camt.053 without adjustment, even though both are nominally the same message type and version. This is a documented characteristic of multi-bank camt implementation, not an operator error to correct in isolation.

Failure scenarios

Missing end-of-day statement. No camt.053 arrives for an account by the expected time. First check: has the delivery channel failed, or has the bank simply not generated the statement yet (confirm the agreed generation/delivery schedule before escalating)? Second check: use the ElectronicSequenceNumber/LegalSequenceNumber gap check above to confirm whether a statement was skipped entirely versus merely delayed.

Entry present intraday, absent at end-of-day. An entry visible in a camt.052 during the day does not appear in that day's camt.053. Because camt.052 can carry pending items, this is the expected outcome for an entry that did not ultimately settle — an authorization that was reversed, a pending item that failed final booking. Do not treat every camt.052 entry as a commitment that it will appear in the corresponding camt.053; only booked entries carry through.

Batched entry that cannot be split to invoices. A single Ntry represents a batch (a payment aggregator's daily payout, a payroll run) but the underlying EntryDetails/TxDtls either was not populated by the sending bank or does not carry the reference data needed to match each underlying payment to an invoice. This is a data-quality gap at the bank or originator side, not a parsing bug — confirm with the bank whether TxDtls population is contractually available for that payment type, since not every batch source populates it to the same depth.

Value-date vs. booking-date mismatch at period end. An entry booked on the last day of a period carries a value date in the next period (or the reverse). If the ledger's period-close logic uses value date rather than booking date to assign an entry to a period, it will not match the camt.053 statement, which groups entries by booking date. Confirm which date your reconciliation logic keys on and align it to the statement's grouping basis.

Duplicate ingestion. A statement or notification is re-delivered — whether flagged via CopyDuplicateIndicator or not — and the ingestion process posts the same booked entries a second time. Guard against this by keying ingestion on the message's unique MessageIdentification plus the entry-level reference, not solely on file arrival, and by checking the CopyDuplicateIndicator value before processing a re-received file as new.

Operator controls and bank verification checklist

Before building or trusting an ingestion pipeline against a bank's camt.052/053/054 output, confirm the following per bank:

• Which balance types (OPBD, CLBD, ITBD, CLAV, FWAV, and so on) the bank actually populates on camt.053 and camt.052 — do not assume the full external code list is sent.
• Whether camt.053 is generated prior-day only, or intraday by agreement, and the exact generation/delivery schedule to set missing-statement alert thresholds against.
• Whether the bank populates NtryDtls/TxDtls for batched entries (payroll, acquirer settlement, direct debit collections) to the depth needed for invoice-level matching, or only aggregate Batch totals.
• Which delivery channel(s) are offered for each message type (SWIFT FileAct, EBICS, API, portal) and the retry/resend behaviour of each.
• Whether the bank sets CopyDuplicateIndicator on resends, and whether the ERP/TMS ingestion logic checks it before posting.
• The size/pagination threshold that triggers a multi-file camt.053, and confirmation that pagination reassembly happens before balance-continuity checks run.
• Whether booking date or value date governs period-close entry assignment on the bank's side, so the ledger's period-close logic can be aligned to match.

Related references

• MT103 to pacs.008 field mapping reference — the payment-initiation side of ISO 20022 messaging; this article covers what happens to the money in flight, not what the account statement reports afterward.
• ISO 20022 investigation messages: a camt operator reference — the camt.056/camt.029/camt.110/camt.111 cancellation and investigation pair, a different camt sub-family from the account reporting messages covered here.
• PSP reconciliation failure runbook — the three-way match, break taxonomy, and escalation checklists for processor settlement reconciliation; this article does not restate that material.
• Reading PSP settlement files: Stripe vs Adyen — why a PSP settlement file is not a bank statement, and the processor-side field model; camt.052/053/054 are the bank-side counterpart this article covers instead.

For term definitions — ISO 20022, CBPR+ — see the Payments Glossary.

Scope note

Three layers, kept distinct throughout this reference:

1. ISO 20022 message definition (what camt.052, camt.053, and camt.054 are scoped to do, and their Entry/EntryDetails/TransactionDetails/Balance structure) — sourced directly from the ISO 20022 Registration Authority's Bank-to-Customer Cash Management Message Definition Report, retrieved and parsed for this reference. This is the authoritative primary source for scope, structure, and field definitions.
2. Balance type code set — maintained by ISO 20022 as a separate external code list, not embedded in the Message Definition Report itself. The ten codes described here (OPBD, CLBD, ITBD, CLAV, OPAV, ITAV, FWAV, PRCD, XPCD, INFO) are sourced from a bank implementation guide that reproduces the code set with definitions. Codes that could not be independently confirmed against a primary or bank-published source were omitted rather than listed from memory — no balance-type code in this article is unsourced.
3. Bank/market implementation variation (which balance types a given bank populates, size/pagination thresholds, mandatory-vs-optional splits by market) — explicitly attributed per source throughout (Luxembourg, Nordic, and Swiss examples), and stated as illustrative of variation, not as universal or CBPR+-mandated practice. CBPR+ field-level usage guidelines for account reporting are gated on SWIFT MyStandards and were not used as a source in this article.
4. MT-to-camt relationships (camt.052/MT942, camt.053/MT940 and MT950, camt.054/MT900/MT910) are stated at the purpose level only — as "replaces" or "supersedes" language drawn directly from a Deutsche Bank implementation overview and a SWIFT-affiliated Clearstream user guide — not as field-identical mappings. No field-by-field MT-to-camt account reporting mapping is asserted anywhere in this article.

This article does not restate the PSP settlement-file field model or the three-way reconciliation match and break taxonomy — those are owned by the Stripe vs Adyen settlement file reference and the PSP reconciliation failure runbook respectively (both linked above); this article covers the bank-side ISO 20022 account reporting messages those processes ultimately reconcile against.