Camt.054 is the ISO 20022 BankToCustomerDebitCreditNotification message: the modern debit and credit advice that replaces MT900/MT910. It is optional, requires bilateral agreement between account servicer and account owner, and reports individual booked or pending entries rather than balances. The sections below cover its structure, key fields, MT mapping, and processing rules.
TL;DR:
- Banks are not obligated to send camt.054 messages unless a bilateral agreement is in place, making proactive setup essential for accurate transaction notifications.
- Proper parsing requires handling variability in account identification, date formats, and the mapping of free-text fields like Tag 72, which can complicate migration.
- Matching entries should prioritize EndToEndId and TxId, with duplicate detection relying on message IDs and sequence numbers, especially for reversals and retries.
- Successful implementation depends on explicit coordination with banks regarding pagination, batching, and reporting behavior rather than schema complexity alone.
DemivoltSimplify Cross-Border Payment OperationsDemivolt provides dedicated IBAN accounts, SEPA and SWIFT payments, and business cards through regulated digital-first financial infrastructure.Explore Demivolt
Table of Contents
- When Do Banks Send Camt.054 Messages?
- What Does a Camt.054 Message Look Like Inside?
- How Do MT900 and MT910 Fields Map to Camt.054?
- How Do Banks Configure Camt.054 Delivery?
- Reconciliation and Parsing: What Actually Breaks in Production
- What Do CGI and CBPR+ Recommend for Consistency?
- How Demivolt Supports Camt.054 Implementation
- Where to Find the Official Camt.054 Standards
- An Editorial Take on Camt.054 Adoption
- Get Your Camt.054 Feed Running Without the Bank Back-and-Forth
- Sources
When Do Banks Send Camt.054 Messages?
Camt.054 exists to notify an account owner of specific debit or credit entries, one transaction (or a batch of transactions) at a time, without reporting an account balance at all. That last point trips up a lot of teams migrating from statement-based reconciliation: camt.054 tells you what moved, not where the account stands. For balances, you still need camt.052 for intraday reporting or camt.053 for end-of-day statements.
Think of the three messages as answering different questions. Camt.052 answers “what does my account look like right now?” Camt.053 answers “what did my account look like at close of business?” Camt.054 answers “did this specific payment just settle?” Corporates that need same-day visibility into individual credits, say, a treasury team watching for a large incoming wire, lean on camt.054 because it can be pushed the moment an entry books, rather than waiting for a scheduled statement cycle.
SWIFT’s own guidance confirms camt.054 can carry both pending and booked items, and that it is increasingly used for instant payment notifications and securities reporting, not just traditional SEPA or wire credits. The message structure closely mirrors camt.052 and camt.053, apart from the missing balance block, which makes it easier to build parsers that share logic across all three formats.
Every entry inside a camt.054 notification carries a booking status code that determines how you should treat it in reconciliation:
- BOOK: the entry has posted to the account and is final for that day’s ledger.
- PDNG: the entry is pending. It has been initiated but not yet settled, and it can still be reversed or rejected.
- FUTR: the entry is scheduled to book on a future value date.
- INFO: the entry is informational only and does not represent a ledger movement.
Reconciliation logic needs to branch on this code. Treating a PDNG entry as final can create phantom cash positions; ignoring FUTR entries can blind treasury to upcoming settlement dates that matter for liquidity planning.
The one constraint that overrides all of this: camt.054 is optional. Your bank is under no obligation to send it unless you’ve established the feed through a bilateral agreement, typically formalized through an RMA or business profile arrangement. Some banks default new corporate clients to camt.053 only, and you have to explicitly request camt.054 provisioning during onboarding or through a change request afterward.
What Does a Camt.054 Message Look Like Inside?
A camt.054 document has three structural layers, and knowing what lives in each one determines how fast you can build a reliable parser.
At the top sits the GroupHeader, found at /Document/BkToCstmrDbtCdtNtfctn/GrpHdr. This carries MsgId, a unique identifier for the message itself (not the transaction), and CreDtTm, the creation timestamp. Treat MsgId as your primary tool for duplicate detection at the message level. It is not a transaction reference, so don’t try to match payments against it.
Below the header comes the Notification block, under /Document/BkToCstmrDbtCdtNtfctn/Ntfctn. This is where account identification lives, at Ntfctn/Acct/Id. Most banks populate this with an IBAN under Id/IBAN, but some use Id/Othr/Id for non-IBAN account numbers, particularly in markets outside the SEPA zone. Never hardcode an assumption that the IBAN path will always be populated. Build your parser to check Othr as a fallback, or you’ll drop notifications silently the first time a bank sends a proprietary account number.
The real payload sits inside Ntfctn/Ntry, repeated once per entry, with transaction-level detail nested further inside NtryDtls. This is where reconciliation engineers spend most of their time.
| Element | XML path | What it tells you |
|---|---|---|
| Credit/debit indicator | Ntry/CdtDbtInd |
Whether the entry is a credit or debit to the account |
| Amount | Ntry/Amt (with Ccy attribute) |
Transaction amount and currency |
| Booking date | Ntry/BookgDt/Dt or DtTm |
Date the entry posted to the ledger |
| Value date | Ntry/ValDt/Dt |
Date funds are value-dated, which can differ from booking date |
| Transaction ID | NtryDtls/TxDtls/Refs/TxId |
Bank-assigned transaction reference |
| End-to-end ID | NtryDtls/TxDtls/Refs/EndToEndId |
Originator-assigned reference, often the most reliable matching key |
| Remittance info | NtryDtls/TxDtls/RmtInf/Ustrd |
Free-text payment reference from the payer |
SupplementaryData can appear at multiple levels and typically carries bank-proprietary extensions that fall outside the standard schema. Some banks use it for internal routing codes or additional compliance flags. Don’t build core matching logic against SupplementaryData content since it varies by institution and isn’t governed by the base ISO 20022 message definitions the way TxId and EndToEndId are.
For matching reliability, rank your keys. EndToEndId is the strongest anchor because the originator controls it and it survives most bank processing untouched. TxId is second, since it’s bank-assigned and can change if a payment routes through correspondent banks. RmtInf/Ustrd is a distant third: useful as a fallback, but it’s free text, and formatting varies wildly between payment originators. The ISO 20022 message catalogue publishes the full XSD for camt.054.001.08, which is worth downloading directly rather than relying on a bank’s abbreviated sample file, since sample files often omit optional elements you’ll eventually encounter in production. Lithuanian banks generally follow the Lithuanian Banking Association’s XML usage rules for local account identification conventions, which is a useful reference if you’re parsing entries from a bank operating under that guidance.
How Do MT900 and MT910 Fields Map to Camt.054?
Migrating from MT-based debit and credit advices to camt.054 is mostly mechanical, but a handful of fields need deliberate handling or you lose data your reconciliation engine has depended on for years.
| MT field | Camt.054 element | Migration note |
|---|---|---|
| MT900/910 Tag 20 (Transaction Reference) | Refs/TxId |
Direct mapping in most bank implementations |
| Related Reference | Refs/EndToEndId |
Not always populated identically; confirm with your bank’s formatting guide |
| Account | Ntfctn/Acct/Id/IBAN or Othr/Id |
Account format depends on whether the bank issues IBANs |
| Value Date/Currency/Amount | Ntry/ValDt and Ntry/Amt |
Amount and currency now carry as separate elements with a currency attribute |
| Tag 72 (Sender to Receiver Info) | AddtlNtryInf or structured RmtInf |
Highest migration risk; see below |
Tag 72 is the field that causes the most headaches. In MT messages, Tag 72 was a catch-all free-text field banks stuffed with everything from charge details to compliance codes to informal remittance notes. Camt.054 doesn’t have a single equivalent. J.P. Morgan’s client formatting guide shows that Tag 72 content typically maps into AddtlNtryInf when it’s operational commentary, or into structured RmtInf elements when the content is genuinely a payment reference. Some banks split Tag 72 content across multiple XML elements based on internal parsing rules, and some banks simply drop portions of it if the content doesn’t fit a recognized pattern. Document exactly how your bank handles this before you retire your MT parsing logic.
Currency handling deserves a similar checklist item. A handful of banks perform account-currency conversion on entries before populating Ntry/Amt, particularly for multi-currency accounts where the underlying transaction settled in a different currency than the account’s base currency. If your reconciliation engine expects the original transaction currency and instead receives a converted figure, you’ll see unexplained rounding discrepancies that have nothing to do with actual bank fees.
For migration planning, build this into your checklist:
- Run MT and camt.054 in parallel for at least one full statement cycle before decommissioning MT parsing.
- Confirm which camt.054.001.08 version your bank has deployed, since CBPR+ guidance has evolved the schema across releases.
- Map every Tag 72 pattern you currently parse and confirm its camt.054 destination with your bank’s implementation team.
- Verify currency population rules for any multi-currency account structures.
How Do Banks Configure Camt.054 Delivery?
Before a single camt.054 message reaches your system, your bank has to configure the feed, and several operational decisions shape what you’ll actually receive.
- Bilateral setup comes first. You (or your relationship manager) establish an RMA or business profile entry specifying that camt.054 should be delivered, distinct from any camt.052 or camt.053 feed you already receive. Confirm this during onboarding rather than assuming it’s bundled automatically with a standard account.
- Pagination follows CGI conventions. For high-volume accounts, a single day’s entries may not fit in one message. The CGI best-practices guidance specifies electronic sequence numbers and a last-page indicator so your ingestion logic can detect and request missing pages rather than silently processing an incomplete report.
- Notification granularity varies by bank. Some institutions send one camt.054 per transaction in near real time; others batch multiple entries into a single message on a schedule, say, every 15 minutes or hourly. Batched delivery reduces message volume but delays the moment your system learns about a specific entry, which matters if you’re triggering downstream actions like releasing goods on payment receipt.
- Incremental versus full reporting changes your ingestion model. Most camt.054 feeds are incremental, reporting only new entries since the last message. A smaller subset of implementations resend a fuller snapshot on each cycle. Confirm which model your bank uses before building deduplication logic, since the wrong assumption causes either missed entries or repeated processing of the same transaction.
- Platform-specific timing conventions apply for instant payment rails. Banks connected to settlement platforms like TARGET Instant Payment Settlement handle business date assignment on camt.054 messages according to platform-specific rules that can differ from standard booking date logic, so instant payment entries deserve their own date-handling branch in your parser.
Reconciliation and Parsing: What Actually Breaks in Production
Building a camt.054 ingestion pipeline that survives real-world bank behavior takes more than following the schema. Most failures come from a handful of predictable gaps.
File ingestion and transport. If your bank delivers camt.054 through SWIFT’s MX transport, each message typically arrives wrapped in an Application Header (AppHdr) that carries sender, receiver, and message-type metadata separate from the business content. Parse the AppHdr first to confirm routing before you touch the Document payload, since a misrouted message with a valid-looking XML body will otherwise process cleanly into the wrong account’s reconciliation record.
Date and time normalization. BookgDt can arrive as either a Dt (date only) or DtTm (date and time with timezone offset), depending on the bank. Normalize both into a single internal format immediately on ingestion, and never assume BookgDt and ValDt are the same day. They frequently diverge for cross-border payments and weekend-adjacent settlements, and treasury teams that conflate the two often end up with liquidity forecasts that are off by a day.
Currency normalization. Always read the Ccy attribute on Amt rather than assuming account base currency. This matters most for multi-currency account structures where a single camt.054 feed reports entries in several currencies across a single business day.
Matching priority. Build your matching engine to try identifiers in this order:
EndToEndIdfirst, since it’s originator-controlled and most consistently preserved end to end.TxIdsecond, as a bank-assigned fallback.- Amount plus
RmtInfcombined, when neither ID is populated or usable. - Fuzzy remittance text matching last, reserved for cases where structured references are absent entirely.
J.P. Morgan’s guidance backs this ordering, noting that reliability drops sharply once you fall back to free-text remittance parsing.
Duplicate detection and reversals. Use the combination of MsgId and electronic sequence number to detect exact duplicate deliveries, a common occurrence when a bank retries a failed transmission. For reversals, watch for a second entry referencing the original TxId with an opposite CdtDbtInd. Flag these for manual review rather than auto-netting them, since reversal timing can vary and silent netting can hide a dispute that finance needs to see.
Pro Tip: Compare the TransactionSummary count on the first page of a paginated report against the number of entries you actually processed across all pages. A mismatch is the fastest signal that a page went missing in transit, well before your bank’s support line will confirm it.
Missing IDs deserve their own alert category rather than silent fallback. When both EndToEndId and TxId are blank, that’s unusual enough to warrant flagging for the reconciliation team, not just routing straight to fuzzy matching.
What Do CGI and CBPR+ Recommend for Consistency?
The Common Global Implementation group’s guidance exists precisely because banks, left to their own devices, format camt reports inconsistently enough to make corporate reconciliation painful across a multi-bank relationship. A few rules matter most for camt.054 specifically:
- Transaction summary placement is restricted to the first page. When a report spans multiple pages, the summary totals belong only on page one, not repeated on every page, which prevents double-counting if your ingestion logic naively sums summary figures across pages.
- Electronic sequence numbers must increment continuously. Each page in a paginated report carries a sequence number, and a gap in that sequence is your clearest signal that a page failed to arrive.
- Last-page indicators close out the set. A report isn’t complete until you receive a message flagged as the final page; processing before that point risks treating a partial report as the full picture.
- Interim balances can be omitted from camt.054 by design, since the message format doesn’t carry balance information the way camt.052 and camt.053 do. Don’t interpret a missing balance as an error. It’s expected behavior for this message type.
- Negotiate configuration explicitly with your bank, including pagination thresholds and batching frequency, and test the actual feed in a sandbox or pilot period before relying on it for production reconciliation.
Corporates running multi-bank treasury structures benefit most from pushing every banking partner toward the same CGI conventions, since consistent pagination and sequencing logic means one parser can handle feeds from several institutions without bank-specific branching.
How Demivolt Supports Camt.054 Implementation
Demivolt’s platform architecture is built around the kind of multi-account, multi-currency structures that generate meaningful camt.054 volume in the first place. Businesses running SEPA and SWIFT payment flows through Demivolt manage dedicated IBAN accounts with role-based access controls that let finance teams separate who initiates payments from who reconciles them. This separation matters once automated camt.054 ingestion starts feeding directly into reconciliation systems.
Two workflow patterns come up repeatedly among businesses formalizing a camt.054 feed:
- Onboarding the feed itself: confirming bilateral agreement terms, testing pagination behavior in a pilot period, and validating that account identification fields match what your parser expects before flipping production traffic onto the new format.
- Mapping camt.054 into an existing reconciliation engine: prioritizing
EndToEndIdandTxIdas primary keys, building a fallback path for remittance-text matching, and setting up duplicate detection using message ID and sequence number pairs.
[brand_signal] [internal_data]
Businesses operating cross-border trade or digital services structures tend to see the clearest reconciliation gains from camt.054 once the feed is properly configured, since individual entry-level notifications close the gap between payment initiation and confirmed settlement far faster than waiting on end-of-day statements alone.
[author_bio]
Where to Find the Official Camt.054 Standards
For schema downloads, start with the ISO 20022 message catalogue, which hosts the canonical XSD for camt.054.001.08 and every prior version still in active use. For migration and mapping guidance, particularly around CBPR+ considerations, consult SWIFT’s implementation material alongside a specific bank’s formatting guide, since generic schema documentation won’t tell you how a given institution populates optional fields.
For operational negotiation, meaning pagination behavior, sequence numbering, and batching frequency, the CGI best-practices document is the reference to bring into conversations with your bank’s implementation team. And if you’re working with a bank operating under Lithuanian conventions, the Lithuanian Banking Association’s XML usage rules documents local account identification formats worth checking against your parser’s assumptions.
An Editorial Take on Camt.054 Adoption
The conventional advice treats camt.054 as a straightforward schema upgrade from MT900/910. It isn’t. The optionality clause is the whole story, and most implementation guides bury it under structural detail. If your bank hasn’t bilaterally agreed to send camt.054, no amount of parser sophistication matters.
What’s overrated is exhaustive field mapping before you’ve confirmed delivery mechanics: pagination behavior, batching frequency, incremental versus full reporting. Teams that build a beautiful XML parser against sample files and only then discover their bank batches hourly, rather than sending real-time notifications, waste real engineering time.
Prioritize the operational negotiation first. Confirm what your bank will actually send, at what frequency, before investing in matching logic. Then build reconciliation around EndToEndId as your primary key, not remittance text. That single choice determines whether your matching accuracy holds up at volume or degrades the moment payment originators get creative with free-text references.
— dd
Get Your Camt.054 Feed Running Without the Bank Back-and-Forth
Setting up a camt.054 feed usually means chasing a relationship manager through account configuration requests, RMA paperwork, and formatting confirmations that stretch across weeks. Business accounts are built digital-first, so IBAN provisioning, SEPA and SWIFT payment configuration, and multi-account setup can happen through a platform interface instead of a back-and-forth email chain with a branch contact.
For treasury and IT teams already parsing camt.054 payloads, account identification accuracy matters from the first message. Demivolt’s free IBAN validator checks account numbers against ISO 13616 formatting before they ever enter your reconciliation pipeline, catching mapping errors before they cost you a failed match. If your business needs dedicated IBAN accounts with role-based access and integrated payment reporting built for exactly this kind of technical implementation, consider opening a business account with a digital-first platform to potentially get your first IBAN provisioned in days, not weeks.