Reading a Statement

10.0 What this chapter gives you#

1. You will be able to read a bank statement line by line and say, for each line, which system wrote it, when, on whose authority, and what could still change it.
2. You will be able to explain why Priya’s booked balance was £47.30 too high and her available balance £52.70 too low on the same screen at the same moment, with no bug anywhere.
3. You will be able to separate booking date, value date and the underlying transaction’s own date, and say why a report that chooses between them implicitly books entries into the adjacent day.
4. You will be able to explain why a pending card item is not an entry at all, why it can vanish leaving no reversal line, and why matching it to a posted entry is inference rather than lookup.
5. You will be able to check the two arithmetic proofs on any statement — opening plus movements equals closing, and unbroken statement sequence numbers — before accepting the file.
6. You will be able to choose between camt.052, camt.053, MT940 and BAI2 for a controlled reconciliation and defend the choice.
7. You will be able to read the ISO 20022 balance type codes and say whether a given screen is showing CLBD, CLAV or XPCD.
8. You will be able to explain why a payer-supplied reference is evidence of intent rather than a key, and design allocation that does not break when it is truncated or wrong.
9. You will be able to run a three-way reconciliation between internal ledger, processor report and bank statement, and name the characteristic failure of each pair.
10. You will be able to say why twelve failed safeguarding firms averaged a 65 per cent shortfall in client funds, and what the rules coming into force on 7 May 2026 require instead.

Everything in this volume so far has been an argument about what money is. Money is a record. A balance is a row. Every payment is two facts. A bank is a balance sheet whose liabilities you happen to call your savings. Clearing is not settlement. Netting turns twenty-seven million obligations into a few dozen. And an amount of money is an integer in minor units, never a floating-point number.

All of that is true, and none of it is in your hand.

This chapter is. Open your banking app, or take the PDF the bank sent you at the start of the month, and put it in front of you. Every abstraction in the preceding nine chapters is printed on it somewhere, usually in a column you have never looked at. By the end of this chapter you will be able to read the document line by line and say, for each line, which system wrote it, when, on whose authority, and what could still change it.

Then we will do the harder thing, which is to prove that your record of these events and the bank’s record of these events are the same record. That exercise is called reconciliation, and it is where young payments companies actually die — not in a dramatic outage, but quietly, over eighteen months, because nobody could ever say with certainty how much customer money the firm was holding.

The plain version#

Here is the first thing to understand, and it is not obvious.

Your bank statement is not your money. It is not even a picture of your money. It is a letter from your bank saying what it believes it owes you, written at a particular moment, by a system that was not finished processing.

Think of a school report. The report says what the teacher thinks of your work. It is written on a Thursday, printed on a Friday, and posted on a Monday. If you handed in a brilliant essay on the Friday afternoon, it is not in the report, and the report is not wrong — it was written before the essay arrived. The report is a true description of a moment that has already passed.

A statement is the same. It is written at a moment. The world kept going.

Three dates, not one#

Every line on your statement has at least three dates attached to it, and most statements only show you one or two of them.

Imagine you write an essay on Friday. You hand it in on Monday. The teacher marks it as though it had arrived on Sunday night, because Sunday night was the deadline. Three dates:

The date it happened. Friday, when you wrote it.

The date it was recorded. Monday, when the teacher took it off the pile and wrote your name in the mark book.

The date it counts from. Sunday, because that is the date the rules say applies.

Money works exactly like this. You buy a coffee on Saturday. The shop tells its bank about it on Monday. Your bank writes it into your account on Tuesday. And your bank may decide that, for the purposes of working out interest, the money left you on Saturday.

Three dates for one coffee. Most people have never noticed there is more than one, and then one day they see a purchase they made on the first of the month sitting on a line dated the fifth, and think the bank has made a mistake. It has not. It has shown a different one of the three dates than the one they were thinking of.

Two balances, not one#

The second thing that is not obvious is that you have two balances at the same time, and they are usually different.

One is the balance the bank has written down: the sum of everything it has actually recorded. Call it the written-down balance.

The other is the balance you are allowed to spend: the written-down balance, minus anything the bank has promised somebody else on your behalf but has not yet recorded. Call it the spendable balance.

Here is the classic case. You drive onto a forecourt and use the pay-at-pump. The pump has no idea how much fuel you are about to take. It could be five pounds, it could be ninety. So before it releases a drop, it asks your bank a question: if this person tries to spend one hundred pounds, will you cover it? Your bank says yes, and — this is the important part — it sets one hundred pounds aside. Not spent. Set aside.

You put in forty-seven pounds and thirty pence of fuel and drive away. For the next couple of days, your written-down balance has not moved at all, because nothing has been recorded yet. But your spendable balance is a hundred pounds lower, because a hundred pounds is being held back for a bill that has not arrived. Then the real bill arrives for forty-seven pounds thirty, the bank records it, the written-down balance finally drops, and the hundred-pound reservation is released.

Notice what happened in between. For two or three days, your written-down balance was too high — you had spent forty-seven thirty and it did not show. And your spendable balance was too low — a hundred pounds was reserved when only forty-seven thirty was owed. Both balances were wrong at the same time, in opposite directions, and neither of them was a bug.

A month in one account#

Let us make this concrete. Here is a statement. Priya has a current account. This is March.

Ten lines. Now read them properly.

The coffee on line three was bought on 1 March and written down on 5 March. Four days. Nothing went wrong; that is simply how long it took the coffee shop’s bank to send the bill to Priya’s bank.

The fifty pounds on line four came from Priya’s brother. The word BIRTHDAY is on the statement because her brother typed it into his banking app. No bank wrote it, no bank checked it, and no bank knows what it means. If he had typed nothing, the line would say nothing. If he had typed the wrong thing, the line would say the wrong thing and the money would still have arrived, because the money is addressed by the account number, not by the note.

The Esso line is the forecourt. Purchase 15 March, recorded 18 March. On 16 March, Priya’s app would have shown a written-down balance of £1,793.05 and a spendable balance of £1,693.05, because £100 was reserved. Her real position — everything she had actually spent — was £1,745.75. Her written-down balance was £47.30 too high. Her spendable balance was £52.70 too low. On one screen. At the same time.

The refund on line seven is for something bought on 14 February. It is not the February purchase being undone. It is a completely separate payment, going the other way, made by the shop to Priya. This is why refunds are slow when purchases feel instant: nothing is being erased, a second thing is being done.

And the whole statement has one property that matters more than any single line: the opening balance plus everything in, minus everything out, equals the closing balance. £1,842.60 plus £2,229.41 in, minus £1,246.85 out, is £2,825.16. If that sum does not come out, something is missing from the page.

Reconciliation, without the word#

Now the second half of the chapter, in plain terms.

Suppose you run a market stall. At the end of Saturday you have a notebook: every sale, what it was, how much. Your card machine’s provider also has a record of every sale. And your bank has a record of what landed in your account.

Three records of the same day. Reconciliation is the work of proving all three describe the same Saturday, and explaining — line by line, not in total — every place they differ.

It sounds trivial. It is not. Your notebook says you took £1,240 on Saturday. Your bank account shows £1,213.90 arriving on Tuesday. Those numbers are different and both are correct: the card company kept £26.10 in fees, and it paid you two days later. If your test is “does the bank number equal my number”, you fail a test you should pass. And the reverse also happens: your notebook says £1,240, the bank says £1,240, and you are missing a sale, because two errors cancelled out. The total matched and the record is wrong.

That is the whole discipline in one paragraph. Matching totals proves nothing. Reconciliation means matching individual events, one by one, to individual events, and having a defensible explanation for every single one that does not match. Not most of them. All of them.

Do this every day and a mistake is a small puzzle. Do it every month and a mistake is an investigation. Do it never — and this is the thing that kills companies — and one day somebody asks how much of the money in your bank account belongs to your customers, and the honest answer is that nobody knows.

Where the plain version stops being true#

The report-card picture is a good one, and the three dates and two balances are real. Four things it hides matter enough to correct.

There is no such thing as “the statement”#

The plain version implies one document. In practice, at least three different artefacts are called your statement, they are produced by different systems at different moments, and they routinely disagree.

The screen in the mobile app is usually a merged view: recorded entries from the ledger, plus card authorisations that have not been recorded at all, presented in one list so it looks like a single sequence of events. The PDF or paper statement is normally the ledger alone. The machine-readable file that a business downloads — an ISO 20022 camt.053, a SWIFT MT940, a BAI2 file — is the ledger alone as well, but it is generated at a fixed cut-off and delivered on a schedule, so it can be hours behind the app and days behind reality.

When a customer says “the app shows a payment but the statement does not”, nobody has made an error. Two different systems were asked two different questions. This is also why software consuming bank data must be explicit about which artefact it is reading. Building a customer balance from the app’s merged view and building it from the camt.053 will give different numbers on most days, and only one of them is a balance in any accounting sense.

“Pending” is not a status; it is the absence of an entry#

This is the correction that matters most for anyone building systems.

In the plain version, the pending coffee “becomes” the posted coffee, as though a single record changed state from grey to black. That is not what happens in a card transaction. The pending item is not an entry in the ledger at all. It is a memorandum — an amount held against your available funds, recorded in an authorisation store, with no double entry behind it and no place in the sum that produces your balance. The posted item, days later, is a genuinely new ledger entry created from a completely separate message that arrived through the clearing system.

Three consequences follow, and each of them breaks naive software.

The amounts need not match. The forecourt held £100 and the entry was £47.30. A restaurant may authorise the bill and clear the bill plus a tip. A hotel may authorise nightly and clear once.

The pending item can vanish with no trace whatsoever. If the merchant never submits the transaction for clearing, the hold simply expires. Nothing appears on the statement. There is no reversal line, because there was never a line.

And there is usually no field on your statement that links the two. The authorisation and the clearing record carry identifiers that can be matched by the issuer’s systems, but those identifiers are frequently not surfaced to the customer, and are not present in a camt.053 in any standardised place. Matching a pending item to a posted item from the outside is inference, not lookup.

Value date is not “when I can spend it”#

The plain version compressed three ideas into “the date it counts from”. They come apart.

The value date is an interest and accounting concept: the date from which the amount is treated as being at the account holder’s disposal for the purpose of calculating interest. It is not a promise about availability of funds, and in the United Kingdom the two are regulated separately. The Payment Services Regulations 2017 require, at regulation 89, that “the credit value date for the payee’s payment account must be no later than the business day on which the amount of the payment transaction is credited to the account of the payee’s payment service provider”, and, separately, that the payee’s provider “must ensure that the amount of the payment transaction is at the payee’s disposal immediately after that amount has been credited to that payment service provider’s account”. Two obligations, one about interest, one about access.

Value dates can also point backwards. An entry booked today can carry a value date of last Tuesday, which means interest is recalculated as though the money had been there since last Tuesday. Back-valuation is normal, particularly for corrections, and it means that yesterday’s interest figure was not final when it was printed.

Finally, the money-can-still-go-back problem. A recorded credit is not necessarily a final credit. Cheques paid in under the United Kingdom’s Image Clearing System, live since 2019, are typically available to withdraw by 23:59 on the next weekday, but availability and finality are different questions and a cheque can still be returned. Direct debit collections can be represented or refunded. Payments sent in error can be pursued through indemnity and recall processes. So a balance made entirely of booked entries can still overstate what you will keep.

Reconciliation is not matching, it is explaining#

The market stall gave the right instinct and the wrong scale. Reconciliation in a real payments business is not a comparison of two lists; it is a continuous process of accounting for differences, most of which are expected.

Differences fall into recognisable species. Timing differences, where both records are right and one is early. Netting differences, where one side reports gross and the other net of fees. Granularity differences, where one side records a thousand sales and the other records one settlement. Sign and direction differences, especially around refunds and chargebacks. Currency differences, where the amount instructed and the amount settled are not in the same currency and neither party rounded the same way.

None of those is an error. Each still has to be identified, categorised and proved, because the only way to find the one real break — the missing payment, the double credit, the customer whose money went to the wrong internal account — is to have rules that eliminate every harmless difference and leave the harmful one standing alone.

The technical version#

What the document actually is#

An account is a ledger: an ordered, append-only sequence of postings, each of which is one half of a double entry, as chapters three and four established. A statement is not that ledger. A statement is a report over an interval of that ledger, and it has a fixed logical shape regardless of format:

An identification of the account and the account servicing institution. A statement identifier and a sequence number. A period, with a start and an end. One or more balances, each labelled with a type and a date. Zero or more entries. And, implicitly, an arithmetic proof: opening booked balance, plus the signed sum of the entries in the period, equals the closing booked balance.

That proof is the single most useful property of the document and it is the first thing an integration should check. If it does not hold, the statement is either truncated, mis-parsed, or reporting a balance type you have misidentified.

The sequence number is the second most useful property. In ISO 20022 it is the ElctrncSeqNb element inside Stmt; in SWIFT MT940 it is field :28C:, the statement number and sequence number. Consecutive statements must have consecutive numbers. A gap means a statement was never delivered, and a firm reconciling only the statements it received will reconcile cleanly to a false position. BAI2 provides no equivalent statement sequence number, which is one of several reasons it is a weaker basis for controlled reconciliation than camt.053; it relies instead on control totals in its account, group and file trailer records.

The formats, and which one you are actually reading#

The distinction between camt.052 and camt.053 is the one that causes the most trouble in practice. camt.053 is the official end-of-day statement for the previous business day and its entries are booked. camt.052 is an intraday report and may contain items that are not final. Reconciling a firm’s books against camt.052 will produce a position that changes underneath you; reconciling against camt.053 produces a position that does not.

An MT940 message is a tagged text format. The fields that matter are :20: transaction reference number, :25: account identification, :28C: statement number and sequence number, :60a: opening balance, :61: statement line, :86: information to account owner, :62a: closing balance, :64: closing available balance and :65: forward available balance.

Field :61: carries the format 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] with an optional [34x] supplementary details line. Read left to right, that is: a six-digit value date as YYMMDD; an optional four-digit entry date as MMDD; a debit/credit mark of C, D, RC or RD; an optional funds code; the amount; a transaction type identification code of one letter and three characters, where S denotes a SWIFT transfer and the three characters are the message type, and N denotes a non-SWIFT transfer with a mnemonic such as TRF or CHG; a reference for the account owner; optionally, after a double slash, the account servicing institution’s own reference; and optionally a supplementary details line.

Look at that entry date again. MMDD. Four digits. There is no year. A parser must infer the year from context, and every year in the last week of December and the first week of January, somewhere in the world, a reconciliation engine books an entry twelve months out because it inferred wrongly. This is not a hypothetical class of bug; it is a scheduled one.

BAI2 is a comma-delimited record format used mainly by North American banks and by global banks for cash management reporting. Its records are 01 file header, 02 group header, 03 account identifier, 16 transaction detail, 88 continuation, 49 account trailer, 98 group trailer and 99 file trailer. Balances appear as type codes inside the 03 record: 010 opening ledger balance, 015 closing ledger balance, 040 opening available balance and 045 closing available balance, with 100 and 400 carrying total credits and total debits.

The dates, exactly#

ISO 20022 gives an entry three date elements and they are not interchangeable.

BookgDt is the booking date: the date the entry was posted to the account. This is the date that determines which statement the entry appears on and which day’s closing balance it affects.

ValDt is the value date: the date from which the amount is taken to be at the account holder’s disposal for interest and accounting purposes.

Dt inside the transaction details, and the various dates inside RltdDts, carry the underlying transaction’s own dates — for a card entry, the date of purchase; for a direct debit, the requested collection date.

The relationship between them is institution-specific and rail-specific, and the only safe assumption is that they are three separate facts. For a Bacs direct credit, booking date and value date will typically both fall on entry day. For a card purchase, the transaction date precedes the booking date by anything from hours to a week. For a back-valued correction, the value date precedes the booking date deliberately.

Store all three, plus the timezone in which the booking date was determined. A very large proportion of reconciliation breaks that appear to be missing transactions are, on inspection, entries booked into the adjacent day because two systems disagreed about when the day ended. Business date is not a derived quantity. It is a value the institution declares, and it changes at a cut-off, not at midnight.

Pending, posted, and the balance type code set#

ISO 20022 gives an entry a status element, Sts, from a code set whose members are BOOK (booked, posted to the account), PDNG (pending, not yet posted), INFO (informational, no financial impact) and, in current versions, FUTR (future). Market practice for an end-of-cycle camt.053 requires BOOK; PDNG and INFO entries belong in intraday reporting. If you are receiving PDNG entries in a document you believe to be an end-of-day statement, you are reading a camt.052 or a bank’s proprietary variant.

Balances are where the standard is most useful and most ignored. A Bal element carries a type code, and the code set is precise:

Two of these deserve emphasis. XPCD is the standard’s name for the number a customer thinks of as “my balance” in a mobile app — booked plus pending — and it is explicitly labelled as a projection, not a position. And FWAV is the mechanism by which a bank tells you that money is arriving on a future date under a value-dating arrangement; it is a forward-looking figure and belongs in cash forecasting, not in a ledger.

The available balance itself is not defined by any standard, because it is a commercial construct. In broad terms:

Available balance equals the booked balance, minus authorisation holds not yet cleared, minus credits booked but not yet available under the institution’s funds availability policy, plus any agreed overdraft or credit facility, plus any same-day credits the institution has chosen to release early.

Every term after the first varies by institution, by product and sometimes by customer. This is why two accounts holding identical entries can show different available balances at the same bank, and why “available balance” is never a safe input to an accounting process.

Authorisation holds#

A card authorisation is a message, not an entry. Its economic effect on the cardholder is a reduction in available funds; its accounting effect on the issuer’s ledger is nothing at all until a clearing record arrives.

The scheme rules control how long that gap may be, and the answer depends on how the merchant characterised the authorisation. A final authorisation asserts that the amount is exactly the amount that will be captured. An estimated or pre-authorisation asserts that the amount is a good-faith estimate, which is what a fuel pump, a hotel and a car hire desk necessarily send.

Timeframes published by the acquirer Worldline for the European region, as of writing, illustrate the shape of the rules:

Visa’s own acceptance documentation states the merchant-side obligation in the same terms: an authorisation flagged as final “must be submitted for capture within seven calendar days of its request”, while a pre-authorisation must be submitted for capture within 30 calendar days, and an authorisation that is not captured must be reversed.

Three practical points follow.

First, the hold on the cardholder’s available balance and the scheme’s authorisation validity period are related but not identical. An issuer may release a hold on its own schedule, typically shorter than the scheme maximum, precisely because customers complain. Once released, the funds are spendable again — and the clearing record may still arrive afterwards, producing an entry against a balance that no longer expects it.

Second, an estimated authorisation can be adjusted. Incremental authorisations increase the reserved amount as a hotel stay lengthens; partial reversals reduce it when the final amount is known. Whether an issuer reflects those adjustments promptly in the customer-visible available balance is an implementation matter, not a rule.

Third, the amount that clears may legitimately differ from the amount authorised, within tolerances that vary by merchant category. Software that treats such a mismatch as an anomaly will generate an unmanageable volume of false positives against fuel, hospitality and transport merchants.

Why a balance can be wrong in two directions at once#

Return to Priya’s account on the afternoon of 16 March.

The booked balance overstates her position by £47.30, because she has bought fuel that the ledger does not yet know about. The available balance understates it by £52.70, because £100 is reserved against a £47.30 obligation. There is no number on the screen that is correct, and every number on the screen is produced correctly.

Generalise it. A balance overstates in three situations: authorised but uncleared card spending; credits booked that remain revocable, including cheques within the return window, direct debits within the indemnity window and credit transfers subject to recall; and fees and interest accrued but not yet applied. It understates in three others: holds that exceed the eventual clearing amount; holds that persist after the corresponding clearing record has already posted, producing a temporary double count; and incoming credits received by the institution but not yet released under its availability policy.

Both categories are usually live at once on a busy account. The correct engineering response is not to pick one balance and trust it. It is to hold, separately, a booked position derived from entries, a set of outstanding holds with their own lifecycle, and a set of credits with a finality date. Any single number you present to a user is a summary of those three, and you should know which one you are presenting.

The reference field, and who wrote it#

The most misunderstood column on any statement is the narrative, and the misunderstanding is this: people believe the bank wrote it. Almost none of it is written by the bank.

Different rails give the payer different amounts of room, and the room is small.

For Bacs, using the Standard 18 file layout described in the Bacs Electronic Funds Transfer, File Structures document, the payment instruction record carries a service user's reference in field 10, and it is 18 characters. The originating account name is field 9, the destination account name field 11, and the amount in pence field 8, itself limited to 11 digits. Eighteen characters is the whole channel through which a payroll bureau, a utility or an insurer can tell the receiving party what a payment is for.

For Faster Payments, which uses an ISO 8583 message, the Open Banking Read/Write specification’s field mapping shows field 62 END TO END REFERENCE at 31 characters, field 120 REFERENCE INFORMATION at 18 characters and field 121 REMITTANCE INFORMATION at 140 characters. Note the asymmetry: 140 characters of remittance information exist in the message, but the field most receiving systems key on is the 18-character one, and if the creditor account carries a secondary identification such as a building society roll number, that secondary identification takes field 120 and the payer’s reference does not get it.

For CHAPS, carried as an MT103, the beneficiary reference is field 70, four lines of 35 characters, with structured tags such as /ROC/ for the original customer reference.

In a camt.053, the references that reach the statement live in NtryDtls/TxDtls/Refs and comprise MsgId, PmtInfId, EndToEndId, TxId and, for direct debits, MndtId. Remittance data lives in RmtInf, as Ustrd free text of up to 140 characters per occurrence or as Strd structured remittance. The entry itself carries AcctSvcrRef, the account servicing institution’s own reference, and AddtlNtryInf, free text written by the bank.

So the ownership of each string is as follows:

The consequence for anybody building a payment system is a single hard rule. A payer-supplied reference is evidence of intent, not a key. It can be truncated, uppercased, stripped of punctuation, rewritten by an intermediary, mistyped by the payer or omitted entirely, and the payment will still arrive, because the payment is addressed by account identifier. Systems that allocate incoming funds by exact-matching a reference will misallocate. Systems that allocate by exact match, then fall back to fuzzy match, then fall back to a human queue with the amount, date, payer name and remitting sort code available for judgement, will misallocate far less.

The corresponding rule for outbound payments is to generate the reference yourself, make it structurally checkable — a prefix plus a check character is enough — and keep it within the tightest field length on any rail you use, which in the United Kingdom means 18 characters, not 35 and not 140.

Classification: bank transaction codes#

Each entry may carry a BkTxCd, a hierarchical classification with a domain, a family and a sub-family, drawn from the ISO 20022 external code set, plus an optional proprietary code.

A received SEPA credit transfer, for example, is PMNT / RCDT / ESCT: payments domain, received credit transfer family, SEPA credit transfer sub-family. The family codes within the payments domain distinguish received from issued and credit transfers from direct debits — RCDT, ICDT, RDDT, IDDT — with MCOP and MDOP for miscellaneous credit and debit operations such as fees and interest.

Two warnings. Banks vary enormously in how carefully they populate this structure, and a great deal of real-world classification lives in the proprietary code rather than the standard one. And the American equivalent, the BAI2 numeric type code, has a different and larger vocabulary, so a firm consuming both formats needs a mapping layer and should expect that mapping to be incomplete.

Reconciliation, properly#

Reconciliation is the process of proving that two or more independently maintained records of the same set of events agree, and identifying, categorising and resolving every difference between them.

In a payments business there are rarely two records. There are usually three, and the discipline is described as three-way reconciliation:

The internal ledger: what your own system says each customer is owed and what your own system says you instructed.

The scheme or processor report: what the acquirer, processor or scheme says happened — authorisations, captures, refunds, chargebacks, fees, and the settlement amounts derived from them.

The bank statement: what money actually arrived in or left your bank accounts.

Each pair must tie, and each fails in a characteristic way.

Internal ledger against processor report fails on events the processor knows about and you do not: chargebacks raised, fees levied, and transactions your API call timed out on but which the processor nonetheless completed. That last case produces duplicate charges, and it is why every outbound instruction must carry an idempotency key that survives a retry.

Processor report against bank statement fails on netting. The processor reports gross transactions; the bank receives a net settlement after fees, refunds, chargebacks and reserve movements. If your matching logic looks for a bank credit equal to the sum of the day’s sales, it will never find one. The correct approach is to reconstruct the settlement: sum the gross items in the batch, subtract each reported deduction, and prove the result equals the credit on the statement to the penny. Then, separately, prove every gross item in the batch exists in your ledger.

Internal ledger against bank statement fails on timing and on entries you never created: bank charges, interest, returned direct debits, and credits from parties you were not expecting.

A working process has five properties. It runs daily, not monthly. It matches at item level, never at total level alone. It classifies every break into a named category with an owner. It ages breaks and escalates them, so that a break surviving three days becomes somebody’s problem by policy rather than by luck. And it treats the arithmetic proofs described earlier — opening plus movements equals closing, sequence numbers unbroken, BAI2 control totals consistent — as automated preconditions, not as things a human notices.

Why this is where firms die#

This is not a metaphor and there are figures.

For investment firms holding client money, the FCA’s client assets rules are explicit. CASS 7.15.15R requires an internal client money reconciliation “each business day”, performed on the previous business day’s closing records. CASS 7.15.22R requires an external reconciliation against third-party records “as regularly as is necessary but without allowing more than one month to pass” between reconciliations. And CASS 7.15.29R requires that where an internal reconciliation reveals a shortfall, the firm determines the reason and pays in the difference “by the close of business on the day that the reconciliation is performed”. A firm that cannot reconcile daily cannot fund a shortfall daily, and a firm that cannot fund a shortfall daily is in breach on the day it first fails.

For payments and e-money firms, the rules were weaker for years, and the FCA’s own evidence on what that produced is stark. In its consultation paper CP24/20, published in September 2024, the regulator recorded that between the first quarter of 2018 and the second quarter of 2023, twelve payments firms that safeguarded relevant funds became insolvent, and that for those firms there was an average shortfall of 65 per cent in funds owed to clients. Two thirds of customer money, gone, on average, across twelve failures. The same paper identified the causes in terms that are almost a description of this chapter: “a lack of documented processes for consistently identifying which funds must be safeguarded” and “inadequate reconciliation procedures to ensure that the correct sums are protected on an ongoing basis”. In 2023 alone the FCA opened supervisory cases relating to approximately 15 per cent of firms that safeguard.

The response is Policy Statement PS25/12, published on 7 August 2025, which introduces the interim Supplementary Regime through new Handbook chapters CASS 15, CASS 10A, SUP 3A and SUP 16.14A, together with amendments to the Payment Services and Electronic Money — Our Approach document. The rules come into force on 7 May 2026. Their substance is this chapter’s subject matter turned into obligations: internal and external safeguarding reconciliations at least once each reconciliation day, excluding weekends, public holidays and days when relevant foreign markets are closed; a resolution pack sufficient to return customer funds promptly on insolvency; an annual safeguarding audit by a qualified auditor, with an exemption for firms that have not been required to safeguard more than £100,000 of relevant funds over a period of at least 53 weeks; a monthly safeguarding return to the regulator; and documented due diligence on third parties holding relevant funds.

Read that list next to the failure statistic and the causal story is unambiguous. Firms did not fail because their payments went wrong. Their payments mostly worked. They failed because nobody could prove, on any given day, how much of the money in the bank belonged to customers — and by the time anyone asked the question properly, two thirds of it was not there.

Reconciliation is therefore not back-office hygiene. It is the control that converts a database of intentions into a defensible statement of obligation. It is the difference between a firm that knows what it owes and a firm that believes what it owes.

A short list of things to build#

For anyone implementing against bank statement data, the practical conclusions of this chapter compress into seven rules.

Parse and store all three dates on every entry, plus the timezone, and never let a report choose between them implicitly.

Verify the arithmetic proof on every statement before accepting it, and verify statement sequence continuity, alarming on a gap rather than proceeding.

Key on the account servicing institution’s own reference for idempotency of ingestion, and on your own generated end-to-end identifier for outbound payments. Never key on payer free text.

Model holds as a separate object with their own lifecycle, linked to entries where possible and explicitly unlinked where not.

Distinguish booked, available and projected balances in your data model with different names, and never store one in a field named after another.

Reconcile daily, at item level, three ways, with categorised and aged breaks.

And treat every credit as revocable until the rail-specific finality point has passed — a subject the remaining volumes take apart rail by rail.

Where Volume I leaves you#

Trace the argument backwards from the document in your hand.

The statement is a report over a ledger. The ledger is a sequence of double entries, each recording two facts about one event, because a payment is never one fact. Those entries adjust a balance, and the balance is not a quantity of anything; it is the size of a debt a bank owes you, held as a row in the bank’s records. The bank can owe you that debt because a bank is an institution whose liabilities circulate as money, and its own money — the money it uses to settle with other banks — is a different and superior kind, issued by a central bank. When your payment reaches another bank, the obligation between the two of them is established by clearing and discharged by settlement, which are different events at different times, and those obligations are compressed by netting before any central bank money moves. Every amount involved is an integer count of minor units in a currency identified by an ISO 4217 code, because it has to be exact.

That is Volume I. It is a description of what money is, and every part of it happened inside one institution’s records, or between an institution and the central bank that stands above it.

The rest of this book is about what happens between institutions, and it starts with the most familiar object in the whole system.

There is a piece of plastic in your pocket that weighs about five grams. It carries, in several different physical forms, one piece of information: which account to charge. It talks to a terminal it has never met, through a network owned by neither of them, using a message format designed in the 1980s and cryptography designed in the 1990s, and it does this several hundred billion times a year without anybody thinking about it.

Volume II is about that card, and it begins by taking it apart.

10.98 Common wrong ideas#

Wrong: A statement is a picture of your money. Right: It is a letter from your bank saying what it believes it owes you, written at a particular moment by a system that was not finished processing.

Wrong: There is one document called “the statement”. Right: At least three artefacts carry that name — the app’s merged view, the PDF, and the machine-readable file at a fixed cut-off — produced by different systems at different moments, and they routinely disagree.

Wrong: A pending item becomes the posted item, changing state from grey to black. Right: The pending item is a memorandum in an authorisation store with no double entry behind it; the posted item is a genuinely new ledger entry created from a separate clearing message.

Wrong: A cleared amount that differs from the authorised amount is an anomaly worth alerting on. Right: The forecourt held £100 against a £47.30 entry, and treating such differences as anomalies produces an unmanageable volume of false positives against fuel, hospitality and transport merchants.

Wrong: If a hold disappears there will be a reversal line to reconcile it against. Right: If the merchant never submits the transaction for clearing the hold simply expires, and nothing appears on the statement, because there was never a line.

Wrong: The value date tells you when you can spend the money. Right: It is an interest and accounting concept, regulated separately from availability under regulation 89, and it can point backwards, so yesterday’s interest figure was not final when it was printed.

Wrong: A booked credit is money you will keep. Right: Cheques can be returned, direct debits represented or refunded and credit transfers recalled, so a balance made entirely of booked entries can still overstate what you will keep.

Wrong: The narrative on a statement was written by the bank. Right: Almost none of it was; the end-to-end identifier and the remittance text come from the originating party, and a payment arrives on its account identifier whatever the reference says.

Wrong: Reconciliation means proving the two numbers agree. Right: Matching totals proves nothing, because two errors cancel out; the discipline is matching individual events and having a defensible explanation for every single difference.

Wrong: The bank credit should equal the day’s sales. Right: The processor reports gross and the bank receives a net settlement after fees, refunds, chargebacks and reserve movements, so logic that looks for that credit will never find one.

10.99 Chapter summary in 20 lines#

1. A statement is not your money and not a picture of it; it is a report over an interval of a ledger, written at a moment by a system that was still processing.
2. Every entry carries at least three dates: when the transaction happened, when it was booked, and the date it counts from for interest.
3. ISO 20022 names them BookgDt, ValDt and the transaction’s own dates, they are three separate facts, and all three should be stored with the timezone.
4. Business date is not a derived quantity but a value the institution declares, and it changes at a cut-off rather than at midnight.
5. You have two balances at once: the booked balance the bank has recorded, and the available balance you are allowed to spend.
6. On the afternoon of 16 March Priya’s booked balance overstated her position by £47.30 and her available balance understated it by £52.70, and every number on the screen was produced correctly.
7. The most useful property of any statement is its arithmetic proof: opening booked balance plus the signed entries in the period equals the closing booked balance.
8. The second most useful is the sequence number, because a gap means a statement was never delivered and a firm will otherwise reconcile cleanly to a false position.
9. There is no single statement: the app shows a merged view, the PDF and the machine-readable file show the ledger, and the file is generated at a cut-off and can be days behind reality.
10. camt.053 is the end-of-day booked statement and camt.052 is intraday and not final, so reconciling against the latter gives a position that changes underneath you.
11. MT940’s field :61: carries an entry date as MMDD with no year, which makes the turn of the calendar a scheduled bug rather than a hypothetical one.
12. A pending card item is not a ledger entry but a hold against available funds, and the amounts need not match, the item can vanish silently, and no standardised field links the two.
13. Authorisation validity runs from three days to thirty depending on scheme and on whether the merchant flagged the authorisation final or estimated, and issuers release holds on their own shorter schedules.
14. The ISO 20022 balance type codes are precise, and XPCD — booked plus pending — is the number a mobile app calls “my balance” and the standard explicitly calls a projection.
15. Available balance is defined by no standard because it is a commercial construct, which is why it is never a safe input to an accounting process.
16. A balance can overstate and understate at once, so hold booked entries, outstanding holds and credits with finality dates as three separate things and know which one you are presenting.
17. Almost none of the narrative is written by the bank, and the tightest United Kingdom reference field is eighteen characters, so a payer reference is evidence of intent and never a key.
18. Reconciliation is not matching but explaining: timing, netting, granularity, sign and currency differences are all expected, and rules must eliminate every harmless one so the harmful one stands alone.
19. In a payments business it is three-way — internal ledger, processor report and bank statement — run daily, at item level, with breaks categorised, owned, aged and escalated.
20. Between the first quarter of 2018 and the second quarter of 2023 twelve safeguarding payments firms became insolvent with an average 65 per cent shortfall in client funds, which is why reconciliation is the control that turns a database of intentions into a defensible statement of obligation.

Sources used: The Payment Services Regulations 2017, SI 2017/752, regulation 89 (legislation.gov.uk). FCA Handbook, CASS 7.15.12R, 7.15.13R, 7.15.15R, 7.15.20R, 7.15.22R, 7.15.27R, 7.15.29R and 7.15.31R. Financial Conduct Authority, CP24/20 “Changes to the safeguarding regime for payments and e-money firms” (September 2024) and PS25/12 (7 August 2025), together with the FCA’s safeguarding requirements page for payment and e-money institutions. ISO 20022 external code sets: BalanceType (OPBD, CLBD, OPAV, CLAV, ITBD, ITAV, FWAV, PRCD, XPCD, INFO) and EntryStatus (BOOK, PDNG, INFO, FUTR); camt.052, camt.053 and camt.054 message definitions, including the SWIFT camt.053.001.02 message definition report. SWIFT MT940 and MT942 specifications, field :61: format 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x][34x]. Banking Administration Institute BAI2 cash management balance reporting format, record codes 01, 02, 03, 16, 88, 49, 98 and 99 and account type codes 010, 015, 040 and 045. Open Banking Limited, Read/Write API Standard v3.1.3, “Domestic Payment Message Formats”, covering the Bacs Standard 18 mapping derived from Bacs “Electronic Funds Transfer, File Structures” (PN5011), the Faster Payments ISO 8583 field mapping and the CHAPS MT103 mapping. Visa Acceptance Solutions developer documentation on the final authorisation indicator. Worldline Acquiring documentation, “Authorization validity”, scheme validity periods for the European region. Pay.UK, Image Clearing System.