Bank Statement Data Lab

The account this statement covers — one camt.053 message covers exactly one account.

Why it matters: If you hold accounts at the same bank in several currencies, each gets its own statement message, even if the bank shows them together in its portal.

The currency the balances and entries below are expressed in.

Why it matters: For a multi-currency account structure, don't assume — always read this field rather than the account nickname.

Balance at the start of this statement's period — OPBD = opening booked.

Why it matters: This should equal the previous statement's closing balance. If it doesn't, you're either missing a statement or a correction was posted out of sequence — check before trusting the cash position built from this file.

Balance at the end of this statement's period — CLBD = closing booked.

Why it matters: This is the number most cash position tools pick up as "today's balance" — but it's booked, not necessarily available (see closing available balance).

What you can actually use right now — closing booked balance adjusted for holds, float, or uncleared items.

Why it matters: This is usually lower than the closing booked balance, and it's the number that actually matters for a same-day funding decision. Conflating the two is a common cause of "why did the payment bounce, the balance showed enough."

The amount of this one statement line — always positive; direction comes from the credit/debit indicator, not the sign.

Why it matters: A parser that reads this as negative for debits by convention, without checking the indicator field, will silently get every debit backwards.

Whether this entry increases (CRDT) or decreases (DBIT) the account balance.

Why it matters: This is the field that actually determines direction — always read it alongside the amount, never infer direction from context or memo text.

BOOK = booked/final. The alternative, PDNG (pending), means the entry can still be reversed or amended.

Why it matters: Reconciliation logic that treats PDNG entries as final can produce a cash position that changes underneath you the next day — worth filtering on this field explicitly.

The date the bank posted this entry to the account.

Why it matters: Not always the same as the value date below — the gap between them is exactly what "same-day" cash positioning has to account for.

The date interest calculations treat the funds as having moved — can lag or lead the booking date.

Why it matters: For FX or cross-border entries especially, a value date after the booking date means the funds aren't earning (or costing) interest yet, even though they're already on the statement.

The same reference your original pain.001 payment carried, if the bank preserved it — the field automated reconciliation is built to match on.

Why it matters: If this comes back blank or truncated on a real statement, it's usually the bank (or an intermediary bank in a cross-border chain) that dropped it, not a bug in your own matching logic — worth confirming with the bank before assuming your rules are wrong.

Free text passed through with the payment — often the actual invoice reference, sometimes reformatted or truncated by an intermediary bank.

Why it matters: When EndToEndId is missing, this field is the fallback for matching — but because it's free text, matching against it needs fuzzier rules than an exact reference comparison.

A standardized ISO 20022 code classifying what kind of movement this is — here, a received credit transfer.

Why it matters: This is what lets automation distinguish "a customer paid an invoice" from "a bank fee" or "an FX settlement" without parsing free text — worth using this field directly instead of guessing from the description.