Every payment is a set of ledger entries, and every entry must balance: total debits equal total credits at every step. Pick a scenario, then step through the entries one at a time. Each step shows the T-account debits and credits and the running balances. "Balanced" means debits equal credits at each step; it does not prove the entries are on the right bank's books, so every scenario states whose books it shows.
Ledger map: which account is which
Ledger / account
What it is
Balance-sheet treatment
Customer ledger (core banking)
The bank's accounts for its customers: debtor and creditor accounts.
Liability to the customer.
General ledger (GL)
The bank's own books: double entry, trial balance proven daily, formal period close separate.
Debits must equal credits.
Nostro account
The bank's account with a correspondent bank: money the bank owns abroad.
Asset ('due from banks'). A credit reduces it.
Vostro account
The mirror image on the correspondent's books: the same balance owed to the other bank.
Liability ('due to banks').
Settlement account
The bank's account at the central bank (RTGS) or clearing house. Always state whose account at which system.
Asset (central-bank money).
Clearing account (transit)
An internal transit account that holds funds briefly between two postings.
Must clear to zero by the end of the day.
Suspense account
Holds unexplained items pending investigation, with a named owner and daily ageing.
Must be aged and cleared; never a routine transit account.
Every account in every step below is labelled with its ledger, so a customer account, a nostro account and a settlement account are never confused with each other. "Settlement account" is never used without stating whose settlement account at which system.
A customer in London (Acme Manufacturing Ltd) pays USD 25,000 to Tanaka Trading Pte Ltd in Singapore. EndToEndId INV-8841, instruction INSTR-20261105-001, UETR a3e1f2b4-5c6d-4a7e-9b1c-2d3e4f5a6b7c, value date 2026-11-06, charge bearer SHAR. This scenario shows ONLY the originating (London) bank's books. The correspondents' and the beneficiary bank's books are shown separately, for explanation, in the panel below the steps, and are never posted here.
Step 1: Debit the customer (value date 2026-11-06)
The bank accepts the instruction and debits the customer account for the full USD 25,000. The money waits in the internal payment clearing account (a transit account) until the payment is sent onward. Every entry carries EndToEndId INV-8841 and the UETR above.
Account
Debit (USD)
Credit (USD)
Customer account (liability to the customer, core banking)
Step 2: Instruct the first correspondent (value date 2026-11-06)
The bank instructs its first correspondent bank in New York to pay onward. The nostro account is an asset of this bank ('due from banks'), so crediting it REDUCES it: the full USD 25,000 leaves the nostro when the correspondent acts. The nostro is credited in full, not net of downstream fees: the deductions happen downstream and do not reduce the originator's nostro debit. Instruction, nostro debit and confirmation are three different moments.
Nostro account, correspondent 1, New York (asset: due from banks)
-
25,000.00
Total
25,000.00
25,000.00
Reconciliation check. Reconciliation: the nostro statement (camt.053) for this account shows one debit of USD 25,000, value date 2026-11-06, EndToEndId INV-8841. It matches this step's credit of USD 25,000 on amount, value date and EndToEndId. The payment clearing account is back to zero, which is what reconciliation must prove at the end of the day.
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Nostro account, correspondent 1, New York (asset: due from banks)
Cr 25,000.00
Step 1 of 2
What happens on other banks' books, and other notes
What happens downstream (other banks' books, shown for explanation, NOT posted on the originator's books). Correspondent 1 keeps USD 20 as its own income and forwards USD 24,980. Correspondent 2 keeps USD 22 as its own income and forwards USD 24,958. The beneficiary bank credits Tanaka Trading Pte Ltd with USD 24,958. The USD 42 (20 + 22) is the correspondents' income, never the originator's: the originator does not credit 'charges deducted in transit' as its own income, and it has no beneficiary account on its books. Charge bearer SHAR was instructed, so intermediaries may deduct from the principal. In many SWIFT gpi payments the amount is sent in full instead; whether deduction from principal is permitted depends on the charge bearer and the scheme, so always state it. The pacs.008 for this payment carries both charges (USD 20 + USD 22 = USD 42) and the beneficiary receives USD 24,958, so the XML explorer, this scenario and the state machine all tell one story.
What this scenario proves
On the originator's books, and only on the originator's books: the customer account shows a debit of USD 25,000 and the nostro account with correspondent 1 shows a credit of USD 25,000 in full. The payment clearing account ends at zero. The beneficiary receives USD 24,958 because the two correspondents deducted USD 20 and USD 22 on their own books. 'Balanced' means debits equal credits at each step; it does not prove the entries are on the right bank's books.
A customer buys goods online for EUR 120 with a card. This scenario shows the ACQUIRER bank's books only, and states that up front. Illustrative example: an EU consumer credit card, so interchange is at the 0.3% cap (EUR 0.36); for a consumer debit card the cap is 0.2% (EUR 0.24). The scheme fee (EUR 0.07) and acquirer markup (EUR 0.48) are illustrative commercial figures for this merchant's contract, not capped rates, and they vary by scheme, card and merchant contract. The merchant account is held at the acquirer. The issuer's side is shown for explanation in the final panel, not posted here.
Step 1: Authorisation hold (memo only, no ledger entry)
The customer card is authorised for EUR 120. No money moves yet. An authorisation hold is a memo / available-balance hold: the available balance falls by EUR 120, but the ledger balance is unchanged until clearing posts. There is deliberately no debit and credit in this step, because a hold is not a double-entry GL posting.
Memo only, not a GL posting. Memo only, not a GL posting. Ledger balance unchanged: EUR 0.00. Available balance: EUR 120.00 lower. If the purchase never clears, the hold simply expires and the available balance is restored, with no ledger entry at all.
Running balances after this step.
Account
Net balance
Step 2: Clearing splits the EUR 120
The purchase clears. The EUR 120 due from the scheme is split: EUR 119.09 to merchant settlement, EUR 0.36 owed as interchange to the issuing bank, EUR 0.07 owed as a scheme fee, and EUR 0.48 acquirer markup income. 0.36 plus 0.07 plus 0.48 plus 119.09 equals 120.00. Interchange compensates the issuer for the transaction service and guarantee; on a debit card there is no lending at all, so it is not a fee 'for lending the customer the money'.
Account
Debit (EUR)
Credit (EUR)
Scheme clearing receivable (asset: due from the card scheme)
120.00
-
Merchant settlement account (liability to the merchant)
-
119.09
Interchange payable (liability to the issuer, via the scheme)
-
0.36
Scheme fee payable (liability to the card scheme)
-
0.07
Acquirer markup income
-
0.48
Total
120.00
120.00
Running balances after this step.
Account
Net balance
Scheme clearing receivable (asset: due from the card scheme)
Dr 120.00
Merchant settlement account (liability to the merchant)
Cr 119.09
Interchange payable (liability to the issuer, via the scheme)
Cr 0.36
Scheme fee payable (liability to the card scheme)
Cr 0.07
Acquirer markup income
Cr 0.48
Step 3: Receive settlement from the scheme
The scheme settles the EUR 120 to the acquirer. The clearing receivable is cleared and the acquirer's scheme settlement account is debited (an asset: cash held at the scheme).
Account
Debit (EUR)
Credit (EUR)
Scheme settlement account (asset: cash at the scheme)
120.00
-
Scheme clearing receivable (asset: due from the card scheme)
-
120.00
Total
120.00
120.00
Running balances after this step.
Account
Net balance
Scheme clearing receivable (asset: due from the card scheme)
0.00
Merchant settlement account (liability to the merchant)
Cr 119.09
Interchange payable (liability to the issuer, via the scheme)
Cr 0.36
Scheme fee payable (liability to the card scheme)
Cr 0.07
Acquirer markup income
Cr 0.48
Scheme settlement account (asset: cash at the scheme)
Dr 120.00
Step 4: Pay the merchant EUR 119.09
The merchant settlement account is cleared and the merchant account (held at the acquirer) is credited with EUR 119.09, not EUR 120, because the fees were taken at clearing.
Account
Debit (EUR)
Credit (EUR)
Merchant settlement account (liability to the merchant)
119.09
-
Merchant account (liability to the merchant, core banking)
-
119.09
Total
119.09
119.09
Running balances after this step.
Account
Net balance
Scheme clearing receivable (asset: due from the card scheme)
0.00
Merchant settlement account (liability to the merchant)
0.00
Interchange payable (liability to the issuer, via the scheme)
Cr 0.36
Scheme fee payable (liability to the card scheme)
Cr 0.07
Acquirer markup income
Cr 0.48
Scheme settlement account (asset: cash at the scheme)
Dr 120.00
Merchant account (liability to the merchant, core banking)
Cr 119.09
Step 5: Pay interchange and the scheme fee through the scheme
The acquirer settles both fees in one net payment through the scheme settlement account: EUR 0.36 interchange and EUR 0.07 scheme fee, EUR 0.43 in total. The acquirer does not pay the issuer directly; the scheme nets the interchange to the issuer.
Account
Debit (EUR)
Credit (EUR)
Interchange payable (liability to the issuer, via the scheme)
0.36
-
Scheme fee payable (liability to the card scheme)
0.07
-
Scheme settlement account (asset: cash at the scheme)
-
0.43
Total
0.43
0.43
Running balances after this step.
Account
Net balance
Scheme clearing receivable (asset: due from the card scheme)
0.00
Merchant settlement account (liability to the merchant)
0.00
Interchange payable (liability to the issuer, via the scheme)
0.00
Scheme fee payable (liability to the card scheme)
0.00
Acquirer markup income
Cr 0.48
Scheme settlement account (asset: cash at the scheme)
Dr 119.57
Merchant account (liability to the merchant, core banking)
Cr 119.09
Step 1 of 5
What happens on other banks' books, and other notes
Card break, for completeness: an authorisation that never clears. The hold expires, the available balance is restored, and no GL entry is ever posted. A clearing amount that differs from the authorisation (partial capture) is a reconciliation break: match on the authorisation reference, investigate the clearing file, and post only the amount actually cleared.
What this scenario proves
On the acquirer's books: the scheme settlement account shows a debit of EUR 119.57 (cash held at the scheme), the merchant account shows a credit of EUR 119.09, and acquirer markup income shows EUR 0.48. The EUR 0.48 difference is the acquirer's profit, held as cash. Every clearing and payable account is back to zero. On the ISSUER's books (shown for explanation, not posted here): the issuer debits the cardholder EUR 120 for real when the purchase clears, which releases the memo hold, and records interchange receivable of EUR 0.36, settled via the scheme. The cardholder is debited exactly once, by the issuer, never by the acquirer.
A creditor collects EUR 89.99 from a debtor by SEPA direct debit, mandate reference MND-2026-00417, and the debtor then asks for a refund. This is SDD CORE, stated explicitly: for an authorised Core collection the debtor may claim a refund within eight weeks of the debit, with no reason needed, and the creditor cannot refuse it. SDD B2B has no such refund right for authorised collections. Reason code MD06 (refund requested by the debtor, Core only). An unauthorised collection can be claimed for 13 months. This scenario shows the DEBTOR bank's books only. The creditor bank's debit of the creditor's account happens on the creditor bank's own books, and is shown for explanation, not posted here.
Step 1: Collect the direct debit
The creditor bank presents the direct debit. The debtor bank debits the debtor account EUR 89.99 and the funds wait in the interbank settlement account, owed to the creditor bank through the clearing system.
Account
Debit (EUR)
Credit (EUR)
Debtor account (liability to the debtor, core banking)
89.99
-
Interbank settlement, SDD clearing (liability to the creditor bank)
-
89.99
Total
89.99
89.99
Running balances after this step.
Account
Net balance
Debtor account (liability to the debtor, core banking)
Dr 89.99
Interbank settlement, SDD clearing (liability to the creditor bank)
Cr 89.99
Step 2: Settle with the creditor bank
The debtor bank settles EUR 89.99 to the creditor bank through the settlement account at the central bank or clearing house. The creditor bank credits the creditor account EUR 89.99 on its own books. The debtor's bank cannot debit the creditor's account at another bank.
Account
Debit (EUR)
Credit (EUR)
Interbank settlement, SDD clearing (liability to the creditor bank)
89.99
-
Settlement account at the central bank / clearing house (asset, reduced by the payment)
-
89.99
Total
89.99
89.99
Running balances after this step.
Account
Net balance
Debtor account (liability to the debtor, core banking)
Dr 89.99
Interbank settlement, SDD clearing (liability to the creditor bank)
0.00
Settlement account at the central bank / clearing house (asset, reduced by the payment)
Cr 89.99
Step 3: Debtor requests a refund (MD06, SDD Core)
The debtor asks for a refund of the EUR 89.99 collection within the eight-week Core window, no reason needed. The debtor bank credits the debtor at once and records a refund receivable from the creditor bank, to be recovered through the interbank return (pacs.004). This is a refund (the debtor's claim after the debit), not a return (the creditor bank returning a collection before settlement) and not a reversal.
Account
Debit (EUR)
Credit (EUR)
Interbank refund receivable (asset: due from the creditor bank)
89.99
-
Debtor account (liability to the debtor, core banking)
-
89.99
Total
89.99
89.99
Running balances after this step.
Account
Net balance
Debtor account (liability to the debtor, core banking)
0.00
Interbank settlement, SDD clearing (liability to the creditor bank)
0.00
Settlement account at the central bank / clearing house (asset, reduced by the payment)
Cr 89.99
Interbank refund receivable (asset: due from the creditor bank)
Dr 89.99
Step 4: Recover the refund from the creditor bank
The creditor bank returns EUR 89.99 through the interbank return (pacs.004) and debits the creditor account on its own books. The debtor bank's settlement account is debited and the refund receivable is cleared.
Account
Debit (EUR)
Credit (EUR)
Settlement account at the central bank / clearing house (asset, reduced by the payment)
89.99
-
Interbank refund receivable (asset: due from the creditor bank)
-
89.99
Total
89.99
89.99
Running balances after this step.
Account
Net balance
Debtor account (liability to the debtor, core banking)
0.00
Interbank settlement, SDD clearing (liability to the creditor bank)
0.00
Settlement account at the central bank / clearing house (asset, reduced by the payment)
0.00
Interbank refund receivable (asset: due from the creditor bank)
0.00
Step 1 of 4
What this scenario proves
On the debtor bank's books every account ends at zero: the debtor was debited EUR 89.99 and then refunded EUR 89.99, so the net effect on the debtor is zero, and the interbank legs net to zero as well. A refund is not a failed payment. It is a second, fully recorded payment in the opposite direction, with its own interbank leg (pacs.004) and reason code (MD06).
Reconciliation break. Payment INV-8841, USD 25,000, EndToEndId INV-8841, UETR a3e1f2b4-5c6d-4a7e-9b1c-2d3e4f5a6b7c, value date 2026-11-06. The nostro statement (camt.053) shows TWO debits of USD 25,000 for the same EndToEndId; the internal ledger shows ONE. The payment itself is already settled, so its status does not change while this break is open. This scenario shows the originator bank's books only.
Step 1: The original posting (correct)
The original payment was posted once: the customer was debited USD 25,000 and the nostro account with correspondent 1 was credited USD 25,000 in full.
Account
Debit (USD)
Credit (USD)
Customer account (liability to the customer, core banking)
25,000.00
-
Nostro account, correspondent 1 (asset: due from banks)
-
25,000.00
Total
25,000.00
25,000.00
Reconciliation check. What does not match: the nostro statement shows a second debit of USD 25,000 with the same EndToEndId INV-8841 and the same value date, but there is no second instruction, no second MsgId and no second UETR. Why it might have happened: a correspondent retry after a timeout, or a duplicate file line. Systems and records to investigate: the nostro statement (camt.053), the hub record and event log, the correspondent's settlement confirmation, and the idempotency key. Evidence needed: the two statement lines, the single instruction, and the correspondent's confirmation of what it received. Payment status while open: settled, unchanged; the customer is NOT re-credited yet, because the funds may still be with the correspondent.
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Dr 25,000.00
Nostro account, correspondent 1 (asset: due from banks)
Cr 25,000.00
Step 2: Record the duplicate as a receivable (does not auto-resolve)
The duplicate is proven from the settlement evidence, so the second statement debit is recorded in the ledger as a receivable from correspondent 1, which brings the ledger into line with the statement. This needs operations approval: a duplicate is never auto-matched or auto-cleared.
Account
Debit (USD)
Credit (USD)
Correspondent receivable, duplicate nostro debit (asset: due from correspondent 1)
25,000.00
-
Nostro account, correspondent 1 (asset: due from banks)
-
25,000.00
Total
25,000.00
25,000.00
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Dr 25,000.00
Nostro account, correspondent 1 (asset: due from banks)
Cr 50,000.00
Correspondent receivable, duplicate nostro debit (asset: due from correspondent 1)
Dr 25,000.00
Step 3: The return arrives and the break closes
Correspondent 1 confirms the duplicate and returns USD 25,000 via pacs.004. Only now, with the return in hand and operations approval recorded, does the break close.
Account
Debit (USD)
Credit (USD)
Nostro account, correspondent 1 (asset: due from banks)
25,000.00
-
Correspondent receivable, duplicate nostro debit (asset: due from correspondent 1)
-
25,000.00
Total
25,000.00
25,000.00
Reconciliation check. Resolution: duplicate nostro debit, recovered in full by pacs.004 return from correspondent 1. Correcting entries are Steps 2 and 3 above. The customer was never debited twice and never re-credited: the duplicate was the correspondent's, not the customer's.
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Dr 25,000.00
Nostro account, correspondent 1 (asset: due from banks)
Cr 25,000.00
Correspondent receivable, duplicate nostro debit (asset: due from correspondent 1)
0.00
Step 1 of 3
What this scenario proves
Final balances: customer account Dr USD 25,000, nostro account Cr USD 25,000, correspondent receivable zero. The break closed only on evidence (the pacs.004 return) plus approval, never automatically.
Reconciliation break. Payment INV-9050, USD 75,000, EndToEndId INV-9050, value date 2026-11-06. The nostro statement shows a debit of USD 75,000; the internal ledger shows USD 75,015. The USD 15 difference is the bank's own fee to its customer, which was charged to the customer but never separated in the ledger. Originator bank's books only.
Step 1: The posting as it was made (fee omitted)
The customer was charged USD 75,015 in total (USD 75,000 payment plus the bank's own USD 15 fee), but the posting credited the whole USD 75,015 to the nostro account and never recorded the fee as income.
Account
Debit (USD)
Credit (USD)
Customer account (liability to the customer, core banking)
75,015.00
-
Nostro account, correspondent 1 (asset: due from banks)
-
75,015.00
Total
75,015.00
75,015.00
Reconciliation check. What does not match: statement debit USD 75,000 against ledger credit USD 75,015, a USD 15 amount break on the same EndToEndId INV-9050 and value date. Why it might have happened: the fee was charged to the customer but the fee leg was never posted. Systems and records to investigate: the nostro statement (camt.053), the customer fee schedule and the original instruction, and the hub charge record. Evidence needed: the statement line, the fee schedule showing the USD 15 fee, and the customer debit of USD 75,015. Payment status while open: settled, unchanged; a reconciliation break alone does not change a payment's status.
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Dr 75,015.00
Nostro account, correspondent 1 (asset: due from banks)
Cr 75,015.00
Step 2: Correcting entry, with finance approval
The USD 15 is posted to fee income with finance approval. The ledger is never edited to fit the statement: a wrong entry is corrected with a new entry, never by changing the original record.
Account
Debit (USD)
Credit (USD)
Nostro account, correspondent 1 (asset: due from banks)
15.00
-
Fee income, bank charges (income)
-
15.00
Total
15.00
15.00
Reconciliation check. Resolution: amount break caused by an unposted USD 15 bank fee. Correcting entry is Step 2. After it, the nostro credit is USD 75,000 and matches the statement exactly, and the fee income of USD 15 is recorded. The matching rule is updated so this fee pattern matches automatically next time, but only on reference plus amount plus value date, never on amount alone.
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Dr 75,015.00
Nostro account, correspondent 1 (asset: due from banks)
Cr 75,000.00
Fee income, bank charges (income)
Cr 15.00
Step 1 of 2
What this scenario proves
Final balances: customer account Dr USD 75,015, nostro account Cr USD 75,000, fee income Cr USD 15. The break closed on a posted correcting entry plus approval, with the reason recorded.
Reconciliation break. Payment INV-9060, USD 40,000, EndToEndId INV-9060. The internal ledger records the payment with value date 2026-11-06, but the nostro statement shows the same USD 40,000 debit booked on 2026-11-06 with a value date of 2026-11-07. Originator bank's books only.
Step 1: The original posting (value date 2026-11-06)
The customer was debited USD 40,000 and the nostro account was credited USD 40,000, both with value date 2026-11-06, the date the customer was told the payment would settle.
Account
Debit (USD)
Credit (USD)
Customer account (liability to the customer, core banking)
40,000.00
-
Nostro account, correspondent 1 (asset: due from banks)
-
40,000.00
Total
40,000.00
40,000.00
Reconciliation check. What does not match: the amounts and the EndToEndId match, but the value dates do not. The statement entry has BookgDt 2026-11-06 and ValDt 2026-11-07. Why it might have happened: the instruction missed the correspondent's cut-off, so settlement value moved to the next business day. Systems and records to investigate: the nostro statement (camt.053, BookgDt versus ValDt), the cut-off calendar, and the hub value-date record. Evidence needed: the statement line showing both dates, and the cut-off time for the currency. Payment status while open: settled, unchanged; the money moved, one day later than promised.
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Dr 40,000.00
Nostro account, correspondent 1 (asset: due from banks)
Cr 40,000.00
Step 2: Timing difference, no ledger entry
This is a timing difference, not a missing amount: the USD 40,000 is not lost, it is one day late. No correcting entry is posted, because there is nothing to correct in the amounts. Operations confirms the cut-off, tells the customer the new value date, and notes any interest consequence. The break closes only when the value date passes and the statement confirms the debit with ValDt 2026-11-07.
Memo only, not a GL posting. No entry: timing only. The ledger amounts are correct; only the value date differs. A break that needs no entry still needs an owner, evidence and a recorded close, it is never closed by doing nothing.
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Dr 40,000.00
Nostro account, correspondent 1 (asset: due from banks)
Cr 40,000.00
Step 1 of 2
What this scenario proves
Final balances: customer account Dr USD 40,000, nostro account Cr USD 40,000. The break was a value-date difference, resolved by evidence and a recorded close, not by an entry and not automatically.
Reconciliation break. Payment INV-9070, USD 18,250, EndToEndId INV-9070, value date 2026-11-06. The hub record shows the payment was sent, and the nostro statement (camt.053) shows the USD 18,250 debit, but there is no posting on the customer account in core banking. Originator bank's books only.
Step 1: Investigation (no ledger entry exists yet)
Reconciliation finds the hub record and the statement line, but no core-banking posting. The payment went out, but the customer was never debited. This is the most dangerous kind of break: the bank has paid money it has not collected from its customer.
Memo only, not a GL posting. No entry yet: the break IS the missing entry. What does not match: hub record plus statement debit USD 18,250 against no customer-account posting. Why it might have happened: the core-banking posting failed after the payment was sent, or a posting batch was dropped. Systems and records to investigate: the hub event log, the core-banking posting queue and error log, and the nostro statement. Evidence needed: the hub record, the statement line, and the posting error. Payment status while open: settled, unchanged; the payment is not re-sent, and the customer is told promptly, because the debit will now appear late.
Running balances after this step.
Account
Net balance
Step 2: Post the missing entry late, with approval
The missing posting is made now, with the original value date 2026-11-06, and with operations and finance approval. A posted entry is never deleted; a missing entry is posted late as a new, approved entry, and the late posting is recorded on the audit trail.
Account
Debit (USD)
Credit (USD)
Customer account (liability to the customer, core banking)
18,250.00
-
Nostro account, correspondent 1 (asset: due from banks)
-
18,250.00
Total
18,250.00
18,250.00
Reconciliation check. Resolution: missing core-banking posting, posted late in Step 2 with the original value date. After it, the customer debit matches the statement debit on amount, value date and EndToEndId, and the break closes.
Running balances after this step.
Account
Net balance
Customer account (liability to the customer, core banking)
Dr 18,250.00
Nostro account, correspondent 1 (asset: due from banks)
Cr 18,250.00
Step 1 of 2
What this scenario proves
Final balances: customer account Dr USD 18,250, nostro account Cr USD 18,250. The break closed only when the missing entry was posted with approval, never by assuming the posting would appear on its own.
Reconciliation break. An unmatched receipt of USD 10,000 arrives on the nostro account (advised by camt.054) with no EndToEndId that matches any instruction. Originator bank's books only. A suspense account holds unexplained items pending investigation; it is never a routine transit account, and every suspense balance has a named owner and is aged daily.
Step 1: Park the receipt in suspense
The funds are received, so they must be recorded, but they cannot be credited to a customer yet because no instruction matches. They are parked in the suspense account with a named owner, not allocated on a guess.
Reconciliation check. What does not match: a camt.054 credit of USD 10,000 with no matching hub record, MsgId or EndToEndId. Systems and records to investigate: the camt.054 notification, the nostro statement, the hub instruction log, and the sender's remittance information. Evidence needed: the notification, the sender's confirmation of what the money is for, and the matching instruction. Payment status while open: there is no payment to change the status of; the receipt stays in suspense, held, until it is matched or returned.
Operations contacts the sender. The sender confirms the USD 10,000 is a payment for invoice INV-9120 from a customer whose EndToEndId was mistyped on the instruction. The match is proven from the sender's confirmation and the invoice, not from the amount alone.
Memo only, not a GL posting. No entry: investigation only. A suspected fraud or sanctions item found here would stay held and go to compliance, never be auto-matched or auto-allocated.
With the match proven and approved, the suspense balance is allocated to the customer account. If no match had been found, the funds would be returned to the sender via pacs.004 after the bank's policy period, never kept as income.
Customer account (liability to the customer, core banking)
Cr 10,000.00
Step 1 of 3
What this scenario proves
Final balances: nostro account Dr USD 10,000, customer account Cr USD 10,000, suspense account zero. The suspense balance was cleared by a proven match plus approval, never automatically.
A customer pays GBP 20,000 for a USD 25,000 payment to Tanaka Trading Pte Ltd, EndToEndId INV-8841, value date 2026-11-06. The customer rate is 1.2500 (GBP 20,000 buys USD 25,000). The bank executes in the market at 1.3000, so USD 25,000 costs it GBP 19,230.77. The GBP 769.23 difference is the bank's FX gain. Amounts below are in GBP, the bank's reporting currency; the nostro movement is USD 25,000, shown at its GBP equivalent at the execution rate. Originator bank's books only.
Step 1: Debit the customer GBP 20,000
The customer is debited GBP 20,000 at the agreed customer rate of 1.2500. The funds wait in the FX funding account until the bank buys the dollars.
Account
Debit (GBP (USD 25,000 at GBP equivalent))
Credit (GBP (USD 25,000 at GBP equivalent))
Customer account, GBP (liability to the customer, core banking)
20,000.00
-
FX funding account, GBP
-
20,000.00
Total
20,000.00
20,000.00
Running balances after this step.
Account
Net balance
Customer account, GBP (liability to the customer, core banking)
Dr 20,000.00
FX funding account, GBP
Cr 20,000.00
Step 2: Buy USD 25,000 in the market at 1.3000
The bank buys USD 25,000 at the market rate of 1.3000, paying GBP 19,230.77 from the FX funding account, and the dollars arrive in the nostro account. The nostro movement is USD 25,000; GBP 19,230.77 is its equivalent at the execution rate.
Account
Debit (GBP (USD 25,000 at GBP equivalent))
Credit (GBP (USD 25,000 at GBP equivalent))
Nostro account, USD 25,000 (asset, GBP 19,230.77 equivalent at 1.3000)
19,230.77
-
FX funding account, GBP
19,230.77
-
FX funding account, GBP
-
19,230.77
GBP settlement account (asset, reduced by the GBP paid to the market)
-
19,230.77
Total
38,461.54
38,461.54
Reconciliation check. Check the arithmetic: GBP 20,000.00 at 1.2500 is USD 25,000.00, and USD 25,000.00 at 1.3000 is GBP 19,230.77. The GBP settlement account shows a credit here because this scenario starts from a zero opening balance; in the real ledger it is a reduction of the bank's GBP cash, not a liability.
Running balances after this step.
Account
Net balance
Customer account, GBP (liability to the customer, core banking)
Dr 20,000.00
FX funding account, GBP
Cr 20,000.00
Nostro account, USD 25,000 (asset, GBP 19,230.77 equivalent at 1.3000)
Dr 19,230.77
GBP settlement account (asset, reduced by the GBP paid to the market)
Cr 19,230.77
Step 3: Recognise the FX gain GBP 769.23
The customer paid GBP 20,000.00 and the dollars cost GBP 19,230.77. The GBP 769.23 difference is the bank's FX gain on the trade, recognised as income. The dollars sit in the nostro account, ready to be sent onward on the value date.
Account
Debit (GBP (USD 25,000 at GBP equivalent))
Credit (GBP (USD 25,000 at GBP equivalent))
FX funding account, GBP
769.23
-
FX gain income, GBP
-
769.23
Total
769.23
769.23
Running balances after this step.
Account
Net balance
Customer account, GBP (liability to the customer, core banking)
Dr 20,000.00
FX funding account, GBP
Cr 19,230.77
Nostro account, USD 25,000 (asset, GBP 19,230.77 equivalent at 1.3000)
Dr 19,230.77
GBP settlement account (asset, reduced by the GBP paid to the market)
Cr 19,230.77
FX gain income, GBP
Cr 769.23
Step 1 of 3
What this scenario proves
Final balances: customer account Dr GBP 20,000.00, nostro account Dr GBP 19,230.77 (USD 25,000), FX funding account Cr GBP 19,230.77 (the dollars still to be delivered onward), GBP settlement account Cr GBP 19,230.77 (cash paid to the market), FX gain income Cr GBP 769.23. The customer rate, the execution rate and the gain are all stated, so the learner can see where the GBP 769.23 came from.
Message sent, payment accepted, payment settled, customer account credited: five different moments
Status ladder (pacs.002, in order). ACTC: technical validation passed. ACCP: customer-profile checks passed, accepted for processing. ACSP: settlement in process. ACSC: settlement completed on the debtor account. ACCC: settlement completed on the creditor account. RJCT: rejected (before settlement). PDNG: pending. No business outcome is a status code: "rejected", "returned" and "recalled" describe what happened, the code describes the status.
Message sent. The bank has transmitted the payment message, for example a pacs.008, to the next bank. Nothing has moved yet except data. A sent message can still be rejected, returned, or lost in transit.
Payment accepted (ACCP). The receiving bank or clearing system has checked the message and accepted it for processing. Acceptance means the payment is well formed and will be processed. It does not mean the money has moved. In SEPA SCT a pacs.002 is normally sent only for rejections (no news means accepted); in SCT Inst it is a positive and negative confirmation; under CBPR+ only the negative (RJCT) notification is mandatory and positive statuses are by bilateral agreement.
Payment settling (ACSP) and settled (ACSC). ACSP means settlement is in process; ACSC means settlement is completed on the debtor account. Settlement differs by model. RTGS (CHAPS/T2/Fedwire): final and irrevocable on the central-bank posting. Nostro (correspondent banking): final on the nostro debit under the correspondent agreement, in commercial-bank money, not through a central-bank account. Deferred net settlement: the net position settles at the scheduled time. Instant payments (SCT Inst / TIPS / Faster Payments): the beneficiary is credited within the scheme maximum (10 seconds for SCT Inst), effectively simultaneous with interbank settlement; if the payee cannot be credited in time, the instant payment is rejected and the payer restored. On-us payments have no interbank settlement at all: they are an internal posting only.
Customer account credited (ACCC). The beneficiary bank has posted the funds to the beneficiary customer account, so the customer can see the money. This is the only one of the moments the beneficiary customer experiences directly. It can happen after settlement, or never: if the account is closed, the payment is returned instead, via pacs.004, which is a new payment after settlement. A rejection (pacs.002 RJCT) is different: it happens before settlement, when nothing has moved.