camt.052 intraday report: watching the position when the settlement leg never closes

A camt.052 intraday report tells a treasury team what an account looks like right now. Not what it looked like at yesterday's close, and not what one named payment did. It reports the position during the business day, while there is still time to act on it. When part of a cross border flow settles in stablecoins on a public blockchain, that message matters more, because the day it describes no longer has a clean beginning or end. This article sets out what the report carries, how often to produce it against an on chain leg, and what a treasury team should do when one arrives.

What is a camt.052 intraday report?

camt.052 is the ISO 20022 bank to customer account report. Its job is to describe an account during the business day, before that day has closed. The message definition sits in the cash management family, alongside camt.053 and camt.054.

The shape follows the rest of that family. A group header identifies the report. One or more report blocks each name an account. Each block carries balances, and under them the entries that have moved the account since the last report.

Two things make the message distinct. It carries balances, which a credit notification does not. And it is provisional, which a statement is not. Nothing in a camt.052 is final, because the period it describes has not finished.

That provisional status is the point. Treasury does not need a final number during the day. It needs a current one, early enough to fund a position or hold back a release.

Supervisors expect that visibility. The Basel Committee on Banking Supervision set out monitoring tools for intraday liquidity management in BCBS 248, published in April 2013, which expects a bank to track the intraday liquidity available to it and the size of its largest payments. A report that arrives the next morning cannot support that work.

How does an intraday report differ from camt.053 and camt.054?

The three messages answer three different questions. Confusing them creates real operational cost.

camt.054 answers whether one named payment arrived. camt.052 answers what the account looks like at this moment. camt.053 answers what the account did across a period that has closed.

Only the statement is authoritative. An intraday report is provisional by design, and the next one may supersede it. The credit notification is narrower than both, because it describes a movement rather than an account.

The consumers differ accordingly. Operations acts on the notification, because it releases the next leg. Treasury funds from the intraday report, because it needs a position now. Finance reconciles on the statement, because only the statement closes.

One rule ties the set together. Every entry that appears in a camt.052 during the day must appear in the camt.053 that covers the same period. If it does not, the difference is a break, and it belongs in an exception queue the same day.

Why does an intraday report matter more when settlement runs on a public blockchain?

A correspondent leg imposes a rhythm. Cut off times, business days and currency holidays decide when value can move, and a treasury team plans around them.

A stablecoin settlement leg removes that rhythm. Value can arrive at three in the morning, on a Sunday, in a corridor whose local clearing system is shut. The account changes when the chain says so, not when a market opens.

This cuts both ways. A treasury that sees its position only at the start of the business day is blind for most of the hours in which value actually moves. It will hold larger buffers than it needs, because it cannot see what it already has.

The intraday report closes that gap. It turns a ledger that never sleeps into a position a person can reason about and act on.

It also carries something a traditional report could not. Each on chain entry has a transaction hash, so the balance in the report can be checked against the chain rather than trusted on the word of whoever sent it.

An intraday report on a traditional rail is a snapshot of somebody else's record. One that carries transaction hashes is a snapshot the reader can verify independently. A treasury team should hold out for the second kind.

What must a camt.052 intraday report carry to be usable?

A report is usable when a treasury system can derive a position from it and match every entry to something it already knows, without a person reading the file.

Start with balances. Carry an opening available balance, a current interim booked balance and a current available balance, each with its own balance type code and its own timestamp. Booked and available are not the same number. A system that treats them as one will either over fund or release money it does not have.

Then the entries. Each entry needs an amount, a credit or debit indicator, a booking date, a value date, and a status that says whether it is booked or still pending.

Then the identifiers that join the entry to the payment behind it. Carry the end to end identification, and the UETR that the Swift CBPR+ usage guidelines require on cross border payment instructions. The UETR is what lets an entry in the report be matched to the pacs.008 that instructed the payment and the pacs.002 that reported its status.

Then classification. Every entry carries a bank transaction code with a domain, a family and a sub family, drawn from the ISO 20022 external code sets. A received credit transfer sits in the PMNT domain and the RCDT family. A code can be routed by software. A free text narrative cannot.

Finally the settlement detail for an on chain leg. Name the chain, the token, the sending address, the receiving address, the transaction hash and the confirmation count behind the entry. Schemes differ on where that detail belongs, so many institutions carry it in structured remittance information or in supplementary data. Wherever it sits, it has to be in the message and it has to be in the same place every time.

How often should the intraday report be produced against an on chain leg?

There is no single correct cadence. There is a wrong one. Producing a report once, at the start of the business day, wastes the rail underneath it.

Three patterns are in common use. A fixed schedule produces a report at set intervals through the day. An event driven pattern produces one whenever an entry is booked. A hybrid produces scheduled reports and an extra report after any entry above a threshold the institution sets.

The hybrid suits stablecoin settlement best. Small movements can wait for the next scheduled report. A large arrival should not, because the whole reason to settle on chain is that the money is usable within minutes.

Two rules keep any of these patterns honest. The report must state the exact time it was produced, because a position without a timestamp cannot be compared with anything. And a pending entry must never be counted in an available balance, because confirmation depth on a public chain is a risk decision rather than an accounting one.

Write that confirmation depth down for each chain you settle on. It differs by chain, and it belongs in policy rather than in code somebody wrote once.

How should a treasury team act on an intraday report?

The report is worth producing only if something happens when it arrives. A predictable sequence keeps that work small and keeps it honest.

• Ingest the report idempotently, keyed on its report identification, and discard an exact repeat rather than counting it twice.
• Rebuild the position from the balances the report carries, not by adding entries to yesterday's closing number.
• Match every entry on the UETR or the end to end identification, never on the amount alone, because two payments of the same size on the same day are ordinary.
• Verify each on chain entry against the chain using its transaction hash, and raise anything the chain does not support.
• Exclude pending entries from available liquidity, and re-evaluate them at the next report rather than releasing against them.
• Compare the position against the funding thresholds you have published, and act on a breach in the same hour it appears.
• Reconcile the day's reports against the camt.053 once the period closes, and open a break for anything present in one and absent from the other.

None of these steps is difficult on its own. What makes them work is that they happen every time, in the same order, whether or not anyone is watching the screen.

The failure mode to design against is a quiet one. A treasury team that trusts an intraday report it has never reconciled will eventually fund against a number that was wrong for hours before anyone noticed.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. It settles in regulated stablecoins on public blockchains, and it is ISO 20022 native, so a settled leg carries the identifiers a treasury system already matches on: the UETR, the end to end identification and the pacs.008 or pacs.009 behind the movement. Every movement leaves a transaction hash and a tamper evident audit trail, which is what turns an intraday position from something reported into something the reader can verify. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.