The Correspondent Account Statement Is a Treasury Control Artifact

Start with the reporting object, not the word “balance”

In correspondent banking, the two banks can describe the same account relationship differently. The respondent or customer bank may call its account at another bank a Nostro account; the servicing bank sees the corresponding account from the Vostro/Loro perspective.

For account reporting, ISO 20022 separates three important objects:

• camt.052 — Bank-to-Customer Account Report, used for intraday account reporting;
• camt.053 — Bank-to-Customer Statement, the statement object;
• camt.054 — Bank-to-Customer Debit/Credit Notification, an advice or notification object that does not itself carry account balances.

There is also a version-layer distinction worth making once and then getting out of the way. As reviewed on 19 August 2026, the live ISO repository lists version 14 of these message definitions, while the current Swift CBPR+/CGI materials reviewed for this article use version 8. “Current camt version” is therefore incomplete unless the layer or market profile is named.

Legacy MT reporting needs the same caution. MT940/942 and related category-9 messages still matter in defined scopes and coexistence arrangements, even while Swift’s migration direction is toward the camt reporting family. Calling them “obsolete everywhere” would be too strong.

The practical rule is simple: before interpreting any field, identify the reporting object, profile, account servicer and coverage period behind it.

Booked, available, pending-like and unmatched are not four peer statement fields

A treasury review may need all four concepts, but they do not all come from the statement itself.

Booked state can come directly from the reporting source. In the Swift PMPG interbank camt.053 practice, entries are booked (BOOK). Reporting also distinguishes booked balance types such as closing booked, opening booked and interim booked balances. For the reviewer, that means the entry has been posted to the account servicer’s books under the cited practice. It still does not establish legal finality, accounting recognition or unrestricted use.

Explicitly reported available state can also come from the source — but only when the report actually supplies an availability balance code and its context. CGI reporting practice defines available-family balance codes such as closing available, opening available, interim available and forward available. Read those codes with the timestamp and the account-servicer or market-practice definition behind them. Do not quietly turn “available” into “cash you can use now.”

A pending-like or not-yet-booked state needs a different source. The reviewed material does not establish one universal pending field across camt.052, camt.053, camt.054 and all banks. If an intermediate payment state matters, point to the payment, event or service-specific evidence that actually supplies it. A missing statement entry is not enough to manufacture a PENDING status.

Unmatched state sits on the review side, not the statement side. The reviewed reporting standards provide references and transaction data that can support matching, but they do not establish a universal statement field called unmatched. “Matched”, “unmatched” or “ambiguous” is a reviewer-derived reconciliation classification, so keep the match rule, reason and evidence pointers with it.

That separation is the point of the control artifact: source state on one side, review state on the other.

Time is part of the evidence

An account-state review can still be wrong when every amount is right if all the timestamps are collapsed into one “as of” label.

At minimum, the reviewer may need to distinguish:

• message or report creation time;
• reporting-period start and end;
• the timestamp attached to a particular balance;
• booking date or time for an entry;
• value date or time;
• the reviewer’s own evidence-freeze time.

These are not interchangeable.

Each clock answers a different question. Creation time says when the reporting object was created. The reporting period says what window it covers. A balance timestamp says when that balance applies. Booking date records when the entry was posted to the account-servicer books under the cited practice. Value date has its own account-availability timing meaning in the PMPG interbank practice.

So if a reviewer receives a report at 10:05, 10:05 should not automatically become the balance cutoff, booking time, value time and business cutoff. Keep the clocks separate.

Link the account entry back to the payment event

A statement becomes much more useful when the reviewer can trace an entry back to the payment event behind it.

Swift PMPG interbank guidance points to references such as UETR, Instruction ID, End-to-End ID and Account Servicer Reference as useful linkage fields when they are present. Other transaction identifiers, amount, currency, date and party/remittance information may help corroborate a match.

The catch is that there is no universal join key to assume. In particular, Entry Reference should not be treated as a guaranteed cross-message key across camt.052, camt.054 and camt.053.

In practice, the reviewer can trace the evidence in this order:

1. payment or settlement event;
2. debit/credit advice where used;
3. intraday account report;
4. booked statement;
5. reconciliation record linking the exact evidence objects;
6. exception and closure evidence when the link is incomplete or later reversed.

That is a linkage pattern, not an ISO or bank standard.

The statement does not complete reconciliation by itself

A bank statement can give the reviewer booked entries, balances, timestamps, references and transaction codes. It cannot decide whether the organization matched the expected payment correctly or whether an exception is actually resolved.

That decision belongs in a separate reconciliation record.

The derived fields can stay simple: match state, rule or review method, reason, confidence where relevant, exception ID, owner and next evidence required. If the match is ambiguous, leave it ambiguous instead of forcing a link from amount and date alone.

Returns and reversals make the separation even more important. PMPG practice provides return/reversal indicators and original/return references that can help connect a new account movement to the original payment. The reviewer should preserve both events. A return does not mean the original payment “never happened,” and a reversal should not overwrite the original evidence.

Failure cases the evidence file should make visible

This is where the control artifact becomes most useful: when the evidence is incomplete or conflicting.

A stale report should be marked stale from its coverage, creation time or balance time — not carried forward as “current.”

A missing report or sequence/page gap should open an evidence-gap exception. No report does not mean no account activity.

With a delayed posting, keep the payment/event state separate from the booked account state. Do not invent a statement-level pending status while you wait for posting.

Treat a duplicate delivery as a duplicate evidence object, not as a second account movement.

For a value-date mismatch, preserve booking date and value date separately rather than forcing them to agree.

A missing reference should lower match confidence and make the secondary matching attributes visible. Amount and date alone should not become a guaranteed join.

Keep a service or channel delay classified as a freshness problem. By itself, it is not evidence of a liquidity shortage.

Finally, a bank-specific availability definition should stay bank- or service-specific. The same balance code family does not create a universal promise about overdrafts, credit lines, collateral, earmarks or executable funds.

Intraday Liquidity Evidence Map

A public example should stay synthetic. It can still be useful without a real statement, account number, UETR, customer name, remittance narrative or bank credential.

What this does not prove

Reader-facing sources

• ISO 20022 — Message Definitions — current ISO message-definition repository; supports the message-object/version layer, not universal market deployment.
• Swift — ISO 20022: Standards — current Swift standards/migration context and MT/camt coexistence boundaries.
• Swift — ISO 20022: Corporates — corporate reporting scope and continued MT940/942 use in specified SCORE scope.
• CGI / Swift-hosted — Bank-to-Customer Reporting Best-Practices and Use Cases, v1.6 — balance codes, reporting period, sequence/pagination and institution-specific balance practices.
• Swift PMPG — Interbank Statement Creation — Market Practice Paper — Nostro/Vostro statement role, booked entries, booking/value dates, references, returns and reversals.
• Swift — CBPR+ Roadmap beyond Nov 2025 v5 — current migration/coexistence roadmap; roadmap timing is not a guarantee of each institution’s implementation.
• ING Wholesale Banking — ISO20022 SWIFT CBPR+ update — one bank-specific implementation example; not universal practice.
• Deutsche Bank — ISO changes on account information messages — one bank-specific account-reporting implementation example; timing/use should not be generalized.
• European Central Bank glossary: Nostro account and Loro/Vostro account — perspective terminology; not a statement of specific contract or availability terms.
• Basel Committee on Banking Supervision — Monitoring tools for intraday liquidity management — explains why intraday liquidity is broader than a single account balance.
• Deutsche Bundesbank — public camt.052/camt.053 example files — public implementation examples; not evidence of universal field population.