R27 — Payment processing: the checks, the accounts, the transactions and the platform

R0 to R16, plus R25 and R26, are the distributed-systems machinery. This section is the payments domain those mechanisms are built for: what a payment platform must check before it moves money, what accounts it moves money between, what the three transaction types actually do, and how the whole thing assembles into an architecture.

Read it before R28. Every design walkthrough there assumes this vocabulary.

The vocabulary, first

Payments has a large jargon surface, and most of it is shorthand for something simple. This is the reference for the whole pack — R28 uses it freely.

Parties and roles

• Payer / debtor — whose account is debited. Payee / creditor / beneficiary — whose account is credited. ISO 20022 uses debtor and creditor; schemes and product people say payer and payee.
• Remitter bank / debtor agent — the payer's bank. Beneficiary bank / creditor agent — the payee's bank.
• Correspondent bank — a bank that holds an account for another bank and moves money on its behalf, typically in a currency or country the first bank has no presence in.
• Intermediary bank — a hop in the middle of a cross-border chain, neither end's bank.
• PSP (payment service provider) — anyone providing payment services; in UPI it is the app you pay from, in cards it is often the acquirer's technology provider.
• Acquirer — the merchant's bank in a card transaction. Issuer — the cardholder's bank.
• Scheme / rail operator — the body that runs the network and writes the rules: NPCI, Nacha, EBA Clearing, SWIFT, Visa.
• Sponsor bank — a licensed bank that lets a fintech access a rail under its licence and its accounts.

Shapes of payment

• Credit transfer (push) — the payer instructs their bank to send money. Most of what this pack covers.
• Direct debit (pull) — the payee instructs their bank to collect, under a mandate the payer signed. Reversible for far longer, which is why mandates matter.
• Book payment / on-us / internal transfer — both parties bank with the same institution, so nothing leaves it.
• Inbound / outbound — from your institution's point of view: money arriving from a rail, or leaving to one.
• FI-to-FI — bank-to-bank movement for the banks' own account, rather than on behalf of a customer. Everything in R27 and R28 is customer-initiated.
• Cover payment — the customer-facing message travels one way while the funds move separately between correspondents. The serial method sends both together through the chain.

Money movement and timing

• Clearing — exchanging the instructions and working out who owes whom.
• Settlement — actually moving the money between the institutions. Frequently much later than the customer's experience of the payment.
• RTGS (gross, real time) versus DNS (deferred net settlement) — settle each payment individually and immediately, or net everything and move the difference at set times. High-value rails are usually gross; retail rails are usually net.
• Netting — offsetting what two parties owe each other so only the difference moves.
• Value date — when the customer's money is meant to move. Settlement date — when it actually did. Business date — the accounting day the rail is working on, which is not midnight and not your server's date.
• Cut-off — the moment a rail stops accepting work for the current window.
• Warehousing — holding a future-dated instruction until its value date (R26).
• Return — the receiving side sends the money back after accepting it. Reject — the message is refused up front, before any money moves. The distinction matters, because a reject is cheap and a return has already touched the ledger.
• Recall — asking for an irrevocable payment back as a favour, with no guarantee. Reversal — a correcting entry in your own books. Refund — a new payment in the opposite direction. Chargeback — the card-scheme mechanism where the issuer forcibly takes the money back.
• Repair — fixing a payment that could not be processed as received, usually a human correcting details.
• STP (straight-through processing) — a payment that completed with no human touching it. STP rate is the headline efficiency metric of any payments operation.

Accounts

• DDA (demand deposit account) — an ordinary current account: money available on demand. The real account in the core banking system.
• Nostro — our account held at another bank. Vostro — their account held with us. Same relationship, opposite sides. Loro — a third party's account at another bank, rarely used outside older literature.
• Clearing / settlement account — what we owe or are owed with a scheme between settlement cycles.
• Suspense — money we hold but cannot yet attribute. Must age out; the oldest item is a reported number.
• Escrow — money held for a purpose and released on a condition.
• Omnibus / pool account — one real account holding many parties' money, with the split existing only in our ledger.
• Virtual account — an identifier that routes to a real account, so incoming payments self-attribute. No money sits in it.
• Wash / internal transfer account — deliberately transient, and expected to end the day at zero.
• GL (general ledger) account — the accounting system's own account, into which the sub-ledger totals feed.
• Pot — informal engineering shorthand for an internal account that exists for mechanical reasons rather than because a person owns it: the suspense pot, the fee pot, the clearing pot. It is not a term of art, so in a document write internal account or GL account. Two things to know: in UK consumer fintech, "Pots" (Monzo), "Spaces" (Starling) and "Vaults" (Revolut) are a customer-facing feature — a sub-balance the customer created inside one real account. And in both senses, a pot is not a real bank account: the bank sees one balance, and the split exists only in your ledger.

Balances

• Current / book balance — the sum of everything posted.
• Available balance — current, minus holds, plus any agreed overdraft. This is the number a payment is checked against, and the number the customer sees.
• Cleared balance — the portion that has fully settled and cannot be clawed back.
• Hold / earmark / block — money present but not spendable, because something has reserved it (R5's semantic lock).

Ledger terms

• Posting — one accounting event, made of two or more entries. Journal — the sequential record of postings.
• Debit and credit — the two directions. What they do depends on the account's normal side: a debit increases an asset and decreases a liability.
• Sub-ledger versus general ledger — the payments ledger holds every entry in detail; the GL receives summarised totals for the bank's accounts.
• Minor units — whole numbers of the smallest denomination: paise, cents. Never decimals or floats.
• Trial balance — the check that all debits equal all credits. Continuous in a payments ledger, rather than a month-end ritual.
• Accrual — recognising income or cost before the cash moves, such as a fee earned today and collected monthly.

Identifiers and messages

• ISO 20022 — the XML message standard. pain = customer-to-bank initiation, pacs = bank-to-bank clearing and settlement, camt = cash management and statements.
• MT103 — the legacy SWIFT single customer credit transfer, replaced by pacs.008.
• UETR — the unique reference carried end to end through a cross-border chain. RRN — the equivalent reference in UPI and card rails.
• End-to-end ID versus instruction ID versus transaction ID — the reference the customer supplies and that survives the whole journey, the reference for one hop, and your own internal identifier.
• IBAN, IFSC, sort code, routing number — account addressing, by region. BIC / SWIFT code — addressing an institution.
• Purpose code — why the money is moving; mandatory on many cross-border and domestic regulatory flows.
• Remittance information — the reference the payee needs to know what the payment is for. Structured means machine-readable fields; unstructured means free text that somebody has to read.

Controls and compliance

• KYC / CDD / EDD — know your customer, customer due diligence, and the enhanced version for higher-risk cases.
• Sanctions screening — checking parties against restricted lists. A hit parks a payment; most hits are false positives.
• PEP — politically exposed person. Adverse media — negative news screening.
• AML / CTF — anti-money laundering and counter-terrorist financing.
• TFR / Travel Rule — the requirement that payer and payee information travels with the payment.
• Transaction monitoring — looking for laundering patterns after the fact. SAR / STR — the report filed when something looks wrong. Tipping off — telling the customer they are under investigation, which is prohibited.
• Structuring — splitting payments to stay under reporting thresholds. Mule account — an account used to move someone else's criminal proceeds.
• Four-eyes — a second person must approve. SCA — strong customer authentication, the two-factor requirement on many European payments.

Operations

• Break — a discrepancy found in reconciliation. Aging — how long a break or a suspense item has been open.
• Exception / investigation queue — the human work list for anything that could not be processed automatically.
• Intraday liquidity — having enough money in the right account at the right time of day to meet obligations as they fall due.
• Funding — moving money into a nostro or a scheme account so payments can settle.
• Technical decline — a payment rejected for a system reason rather than a business one. Regulators and schemes measure this, so it is your number as much as theirs.

1. The checks a payment system must perform

A payment is not a database write with extra steps. Before money moves, a regulated institution must satisfy itself on several distinct questions, and confusing them is a common interview stumble — they have different owners, different consequences and different timing.

Sanctions screening, in a little more detail

You are checking names and identifiers on the payment against restricted lists — OFAC's SDN list, the UK's OFSI list, the EU consolidated list, UN lists, and local ones. The engineering characteristics are what matter in an interview:

• It is fuzzy matching, not equality. "Mohammed Ali", "Muhammad Ali" and "M. Ali" have to be considered, so the matching is phonetic and edit-distance based. That produces a high false-positive rate — most hits are innocent — which is why the answer to a hit is a review queue rather than a rejection.
• A hit parks the payment; it does not fail it. And you may not tell the customer why, which is the tipping off prohibition. The UI says "under review".
• The lists change constantly and without a schedule — often several times a week. So you version the list, record which version screened each payment, re-screen the back book after each update, and re-screen warehoused payments at release (R26), because a payment submitted on the 25th for value date the 30th may be screened clean and then hit a designation added on the 28th.
• It sits in the latency budget of any irrevocable rail, since there is no recall afterwards (R25).

TFR and the Travel Rule

Often skipped by candidates, and worth knowing because it explains fields in the message rather than logic in your code. The EU's Transfer of Funds Regulation, and FATF Recommendation 16 more broadly, require that a payment carries identifying information about both the payer and the payee through the chain — name, account identifier, and address or an equivalent identifier above thresholds.

Three consequences for the platform: outbound messages must be constructed with those fields populated, inbound messages must be validated for their presence, and a payment arriving without them is rejected or sent back for repair rather than quietly applied. It is the reason an inbound payment can fail for a reason that has nothing to do with money or accounts.

Fraud versus AML — the distinction to state clearly

Fraud protects the customer. Someone is trying to take their money: account takeover, a scam, a stolen card. It is detected in the path, in milliseconds, and the customer is on your side.

AML protects the system. The customer may be a willing participant — laundering, mule activity, structuring. It is detected over days across many payments, and the customer must not be told.

Same data, opposite assumptions, different architectures: one is a synchronous scoring service with a feature store; the other is a batch and streaming analytics estate feeding an alert queue.

2. Accounts: the three meanings, and the types that matter

"Account" means three different things, and an interviewer will notice if you blur them.

• A real account at a bank — a DDA (demand deposit account), the thing with an IBAN or an account number that exists in the core banking system. Money genuinely sits here.
• A ledger account — an entry in your double-entry ledger (R6). Every party, internal account and category has one. This is where postings happen.
• A virtual account — an identifier you hand out that routes to a real account. No money sits in it; it exists so that incoming payments can be attributed automatically.

A corporate might be given 10,000 virtual account numbers, one per customer of theirs, all pointing at one real account. When money arrives quoting a virtual account, attribution is automatic instead of a human matching a payment reference — which is why virtual account management is sold as a reconciliation product rather than a banking one.

The account types you should be able to name

Two rules that come up repeatedly. Suspense must age out — an unattributed balance that sits for weeks is a regulatory problem, so the oldest item in suspense is a reported number, not just an ops queue. And pool accounts make the ledger the only record of ownership — the bank sees one balance, so if your ledger is wrong, nobody else can tell you who owns what.

3. The three transaction types

Every customer-initiated payment is one of three shapes. The orchestrator is a black box for now — what matters is the list of activities it drives, and the postings that result.

Book payment (on-us)

Both parties bank with us, so no money leaves the institution.

Activities: intake and idempotency check → validate → resolve both accounts (virtual to ledger) → limits → screen both parties → fraud score → funds check → post → notify both sides. No message is built, no rail is involved, nothing settles.

Postings:

What to notice: our assets never move. Only the claim on them changes hands — we owed A, now we owe B. This is why on-us payments are instant, free to us, and carry no counterparty risk, and it is also why they are the highest-margin traffic a wallet or a bank has.

Some institutions route it through an internal clearing account — DR A, CR clearing, then DR clearing, CR B — purely so each side is separately auditable. Same money, one more hop.

Inbound payment

Someone else's customer is paying ours. Inbound is reactive: we did not initiate it and cannot refuse it, and the money arrives before we know who it belongs to.

Activities: receive message → parse and validate → duplicate check on the sender's reference → post to suspense → screen the payer → validate TFR fields → resolve the beneficiary → apply to the customer → notify → reconcile against the settlement file.

Postings:

Why two postings rather than one: "we received money" and "we know whose it is" are different facts, sometimes minutes apart and sometimes days. Posting straight to a customer would mean trusting a message you have not yet validated.

When resolution fails — closed account, name mismatch, missing TFR data — the money stays in suspense and becomes a repair item: an ops queue, an investigation, possibly a request to the sending bank. If it cannot be repaired inside the return window, it is returned: DR suspense, CR nostro. Nothing was ever posted to a customer, which is exactly what the suspense account exists for.

Outbound payment

Our customer pays someone at another bank. The longest path, because every control must complete before the money leaves.

Activities: intake and idempotency → validate beneficiary details → limits → screen beneficiary, purpose and country → fraud score → check and reserve funds → check the rail cut-off → post → build the ISO 20022 message → submit → acknowledgement → settlement → notify.

Postings:

Three things to say about this one. Funds are reserved, not merely checked, because between the check and the posting another payment could spend the same money (R5). The message is derived from the ledger, never the reverse — the posting is the fact, and pacs.008 is a description of it. And an acknowledgement is not settlement: the rail accepting the message says nothing about the beneficiary being paid, and treating the two as the same is a classic error.

If the payment is returned days later, it arrives as an inbound: cash into nostro, into suspense, then a reversing credit to the customer. You never edit the original entries (R6).

4. The platform architecture

Put the three flows together and the components fall out of them.

flowchart TB
  subgraph CH["Channels"]
    A1["Mobile / web"]; A2["Corporate API"]; A3["Bulk file"]; A4["Rail inbound"]
  end
  subgraph EDGE["Edge"]
    G["API gateway<br/>authn · rate limits · idempotency keys"]
  end
  subgraph CORE["Payment core"]
    O["Orchestrator<br/>state machine per payment"]
    V["Validation + enrichment"]
    ACC["Account resolution<br/>virtual → ledger"]
    LIM["Limits + entitlements"]
    RSK["Risk<br/>fraud score · feature store"]
    SCR["Screening<br/>sanctions · PEP"]
    LED["Ledger<br/>double-entry, append-only"]
  end
  subgraph RAILS["Rail layer"]
    MSG["Message construction<br/>ISO 20022 · NACHA"]
    AD["Rail adapters"]
    SCH["Scheduler<br/>cut-offs · warehouse · kick-off"]
  end
  subgraph BACK["Back office"]
    REC["Reconciliation"]; INV["Investigations + repair"]; RPT["Reporting + regulatory"]
  end
  CH --> EDGE --> O
  O --> V --> ACC --> LIM --> RSK --> SCR --> LED
  LED --> MSG --> AD --> SCH
  LED --> REC --> INV
  LED --> RPT

The layers, and what each owns:

• Channels differ in shape, not in substance — an app request, a corporate API call, a 100,000-row file and an inbound rail message all become the same internal payment object. Normalising early is what stops every downstream service knowing about file formats.
• The edge owns authentication, rate limiting and the idempotency key (R3). Anything that must be true of every request lives here.
• The orchestrator owns the payment's state machine and nothing else. It calls; it does not compute.
• The ledger is the source of truth. Every other store is derived and rebuildable from it.
• The rail layer is where the outside world's rules live — message formats, cut-offs, acknowledgements, returns. Keeping it at the edge of the system means a new rail is a new adapter rather than a change to the core.
• The back office is not an afterthought. Reconciliation, investigations and reporting are where correctness is proved and where regulators look (R6, R7).

The cross-cutting mechanisms, and where they come from:

And the three design rules that hold the whole thing together:

1. The ledger is the only source of truth. Messages, read models, dashboards and reports are all derived from it, and all rebuildable.
2. Nothing irreversible happens before every control has passed. Sequence the pipeline so screening, limits and funds reservation all complete before the pivot (R5).
3. Every external boundary is at-least-once and therefore idempotent, and whatever slips through is caught by reconciliation rather than assumed away (R0).

What to say in the interview

"I'd separate the controls first, because they behave differently: sanctions screening is in the path and a hit parks rather than declines, fraud is in the path in milliseconds, AML monitoring is asynchronous over days, and TFR is a message-content rule that makes inbound payments fail for non-money reasons. Then the accounts: customer DDAs, nostro for cross-border, clearing for what we owe a scheme between settlement cycles, and suspense for money we hold but cannot yet attribute. Book payments are two ledger entries and nothing else; inbound is always two postings, because received and applied are different facts; outbound is instruction and settlement as separate postings, with funds reserved rather than merely checked. And the ledger is the source of truth throughout — the ISO message is derived from the posting, never the other way round."