Payments and Core Banking Interviews: The Engineer's and Architect's Guide

What it is

A payments and core banking interview tests whether you can hold two models in your head at once: money as an accounting fact, and money as a distributed system's best guess. The accounting model says every pound sits somewhere, the total never changes when it moves, and any balance can be reconstructed from the entries that produced it. The distributed-systems model says you sent a message to another institution, you did not get a reply, and you do not know whether the money left. Everything difficult in this domain lives in that gap, and most of what an interviewer probes is whether you know the gap exists.

Core banking names the system of record for accounts: the ledger holding balances, the products layered over them, the accrual engines, the standing instructions and mandates, and the posting engine turning instructions into entries. Payments names everything carrying value across the bank's boundary — card rails, domestic credit transfers, high-value gross settlement, direct debit schemes, correspondent chains, and third-party-initiated payments riding on the bank's own rails through an API. They separate cleanly on a diagram and not at all in practice, because a payment is only real when the ledger says so, and the ledger is only trustworthy when it agrees with the rails.

The territory the rest of this page covers is the money path, and it is worth seeing whole before the argument starts.

flowchart TD
  accDescr: The money path from a customer account debited and the instruction sent to the rail, branching on whether the rail acknowledges, an acknowledged instruction running through clearing and net position, settlement between institutions and beneficiary credit and posting to reconciliation against the counterparty record, while an unacknowledged one lands in the unknown state where money may already have left and is resolved only by that same reconciliation.
  D[Customer account debited] --> S[Instruction sent to rail]
  S --> A{Rail acknowledges}
  A -->|Yes| C[Clearing and net position]
  C --> T[Settlement between institutions]
  T --> P[Beneficiary credited and posted]
  P --> R[Reconciled against counterparty record]
  A -->|No| U[Unknown - money may have left]
  U --> R

Follow the branch out of the acknowledgement. Down the left, every step has a record on both sides and the domain is bookkeeping. Down the right, the customer's balance has already fallen and no institution holds a matching record, and reconciliation is the only thing that will ever close it. Most of what follows exists to keep that branch narrow and to make it recoverable when it opens.

The distinguishing feature is that correctness conditions are external. In most systems you define what correct means. Here it is defined by a scheme rulebook you did not write, a settlement window you cannot move, an accounting standard dictating when a loss is recognised, and a supervisor entitled to ask you to reproduce a figure you published eighteen months ago. Those are not requirements to be gathered; they are the physics. And the interesting states are the intermediate ones — authorised and never captured, captured after the authorisation expired, sent and unacknowledged, settled at the rail and unposted in the ledger, posted twice from a redelivered file. Those are what the systems exist to manage, and what interviews are about.

Why we need it

Consider the gap left unmanaged. A bank sends a credit transfer, the rail times out, the service retries, the beneficiary receives the money twice. The bank now has an unfunded outflow to recover from another institution's customer who has already spent it. Nothing there is exotic; it is the default behaviour of a naive retry against a rail that does not deduplicate. Payments engineering exists as a discipline because the obvious implementation of "send money" is wrong in a way that costs real money on the first bad day.

The same pressure appears on the ledger side. A posting engine that updates a balance column instead of appending entries has destroyed the only evidence that could settle which of two conflicting figures is right. When a customer disputes their balance you have a number and no derivation; when an auditor asks how it moved from Monday to Tuesday you have two snapshots. This is why banks converged on immutable double-entry, and why designing a ledger with provable balances is among the most common design questions in the domain. It is the argument for an event log, arrived at a few centuries earlier.

The third pressure is time. Batch rails gave banks an overnight window in which everything hard happened offline: screening, limit checks, liquidity management, fraud scoring, exception handling by people. Real-time rails deleted that window, so the same controls now run inside a few seconds, in the payment path, on a rail where a payment becomes irrevocable on acceptance. That is why moving from a batch rail to instant payments is posed as a design question: removing the window does not just make things faster, it changes which failures are recoverable.

The fourth is that money movement is regulated in both directions. Beforehand, financial crime controls must be satisfied: identity established, beneficial ownership determined, parties screened, transactions monitored. Afterwards, records retained and figures reproducible if they turn out wrong. Both impose architecture — screening imposes latency and a hold state, reproducibility imposes bi-temporal storage and immutable submission snapshots, which is why restating a submitted return is a systems question rather than a compliance one. Payments is also where a bank's revenue and its losses both concentrate, so an architect who cannot connect a design choice to interchange earned or fraud absorbed will be read as technically competent and commercially naive.

The payment lifecycle, in the order money moves

Almost every confused answer traces to collapsing two lifecycle phases into one. They are genuinely distinct, happen at different times, are carried by different messages, and only one of them moves money.

Authorisation is a real-time question to the party holding the money: if I come back for this amount, will you honour it? For a card, the acquirer routes it through the scheme to the issuer, which checks card status, validates the cryptogram, scores fraud and confirms available funds. An approval creates a hold: the customer's available balance drops while the posted ledger balance stays exactly where it was, because nothing has been transferred. That distinction underpins ledger balance versus available balance and is the most commonly fumbled point in the whole domain.

Holds are dated, and their expiry generates customer-visible failures. An authorisation never captured and never explicitly reversed suppresses spending power until the issuer expires it, which is why a cancelled hotel booking ties money up for days. Capturing after the hold lapses is the mirror failure: the collection often succeeds but no longer sits behind a valid approval, so the protections it bought the merchant are weakened. How long a hold survives is set by scheme rules and varies by merchant category — a number to look up, never one to state in an interview.

Capture states what to collect. In a dual-message flow it is a separate, usually batched step, and the captured amount may legitimately differ from the authorised one: lower for a partial shipment, split across several captures, adjusted upward within scheme tolerances. In a single-message flow, common for PIN debit, authorisation and financial request are one message and there is no separate capture. Your ledger therefore models authorised, captured and settled as a state machine rather than three columns, because they diverge and the divergence is meaningful.

Clearing exchanges those records between institutions through the scheme, which matches presentments against authorisations, applies interchange and scheme fees per its rulebook, and computes each participant's net position. It runs on defined windows and produces information, not money. Netting is the point: two banks with hundreds of thousands of transactions exchange one payment, collapsing settlement risk, liquidity requirement and operational cost — and guaranteeing your postings never equal the settlement figure you receive, which is the whole subject of proving one net settlement matches the postings.

Settlement transfers between the institutions' settlement accounts and is the only phase in which money changes hands. In deferred net settlement, participants accumulate obligations and settle the net at defined times — cheap in liquidity, carrying interbank credit exposure in between, which is why such schemes hold collateral. In real-time gross settlement, each payment settles individually across accounts at the central bank, eliminating that exposure and demanding intraday funding. Finality is the concept candidates miss: it means the transfer is legally irrevocable and unconditional, and your ledger being updated is not that event.

Reconciliation is the fifth phase nobody lists, and the one making the other four trustworthy. Its match keys, tolerance bands, ageing buckets and break ownership are architecture, and a platform whose reconciliation is an afterthought cannot answer the only question anyone asks during an incident, which is how much money is currently in an unknown state.

Read down the third column. Exactly one phase moves money, and every argument in this domain about where a payment is stuck is really an argument about which of the other four it is sitting in.

The double-entry ledger underneath it

Money is recorded as immutable entries. Every movement writes at least two whose signed amounts sum to zero, balances are derived by summing entries rather than stored as a mutable field, and mistakes are corrected by compensating pairs rather than edits.

Each rule earns its place. Immutability means a disputed balance has a derivation. The balanced-pair rule gives you an invariant spanning the whole system rather than one row, so a single-sided posting from any code path is detectable by a check that does not need to know which path is buggy — stronger than validating each write, because it catches faults you did not anticipate. Correction-by-compensation leaves both the error and the fix visible, which is what an auditor needs and what an update destroys.

Deriving balances by summation raises the obvious performance objection, and the standard answer is a periodic materialised balance: a snapshot at a point in time, plus the entries since, treated as a cache that can be rebuilt from the entries rather than as the truth. If the snapshot and the recomputed sum disagree, the entries win and the disagreement is itself a detected fault. A design that cannot recompute has surrendered the property it adopted double-entry for.

Currency is part of the amount, not a label beside it. Each currency lives in its own denominated account and nothing is summed across units; a cross-currency movement is two single-currency legs joined by a conversion record carrying the rate, the source, the timestamp and the spread, because the gap between the customer's rate and the rate at which the bank covered its position is a revenue line finance will ask you to explain.

A transaction also carries at least three dates, and treating them as one causes unrecoverable confusion.

They differ routinely: a payment received late on Friday may carry Friday's value date, Monday's accounting date, and a Saturday event timestamp on a rail that never closed. Once a rail runs continuously, end of day stops being a fact and becomes a rule you declare — the subject of deciding the accounting date when the rail never closes. You assign the accounting date at posting from an explicit rule over rail and calendar, and close a period by locking and snapshotting it rather than pausing the flow. Money you cannot yet allocate goes to suspense, and suspense needs rules: every entry carries a reason code, an owner and an age, and the ageing profile is a reported control metric, because an unaged suspense account is where errors go to become permanent.

Rails, and what choosing one commits you to

The rail is not an implementation detail behind an interface. It determines your latency budget, failure semantics, reversibility, liquidity obligation and customer promise, and no abstraction hides that.

Batch credit transfer schemes run a multi-day cycle in which submission, processing and settlement fall on different days, giving a long window in which an instruction is recallable and a defined moment when it is not. Instant rails compress that to seconds and remove recall as a right. High-value gross settlement rails give finality and immediate certainty at the price of intraday liquidity and restricted hours, which is why the high-value rail being down on completion day is a crisis rather than a delay — the receiver needs finality, not funds. Direct debit inverts initiation, so the collector pulls under a mandate, and the matching consumer protection is a refund right exercisable for a period afterwards, making it a payment the payer can undo without proving anything.

Card rails are a four-party model in which the scheme routes messages and publishes rules but is not a party to the money, the issuer holds the customer's funds, and the acquirer carries the merchant relationship and its credit risk. Cross-border adds correspondent banking, where the accounts are the architecture: a nostro is your account with a correspondent in their currency, a vostro is theirs with you, and a payment either travels serially through each institution or the customer-facing message travels directly while a separate cover payment moves the funds. Your visibility ends at your own leg, which is why an end-to-end reference every party preserves is not a nicety.

So choosing a rail is choosing a failure mode, and a candidate who names one as simply better is telling you they have worked with exactly one.

ISO 20022 and what a message standard buys

ISO 20022 is not "the new XML format". It is a methodology and a repository of business models from which messages are derived. The identifiers are readable once you know the pattern: pain.001 is customer-to-bank credit transfer initiation, pacs.008 an interbank customer credit transfer, pacs.002 a payment status report, pacs.004 a return, camt.056 a cancellation request, camt.053 a bank-to-customer statement. Knowing that pain is customer-initiated, pacs is interbank clearing and settlement, and camt is cash management and reporting is a cheap way to sound like you have used it.

The substantive gains are structure and richness. Legacy formats carried party names and addresses as unparsed lines, so screening ran against a blob and monitoring could not distinguish a country from a street; structured party data, postal addresses, legal entity identifiers and purpose codes are what make automated screening precise rather than noisy, which is why financial crime teams push the migration as hard as payments teams. Structured remittance information lets a corporate allocate a receipt against invoices without a person reading a memo field, and that is the commercial case funding most migrations.

The third claimed benefit is a single model across payments, cash management, securities and reporting, reducing the count of per-rail and per-counterparty mappings an institution maintains. The qualification worth volunteering is that this one is weaker in practice, because every scheme publishes usage guidelines restricting and constraining the base messages. Two systems can both be validly ISO 20022 and fail to interoperate, since conformance is with the syntax while interoperability is with the market practice guideline, and that is where the integration effort lives.

Coexistence is the other implementation reality. While both the legacy and the new format are in use you translate in both directions, and translating rich to poor is lossy by construction. A gateway truncating a structured address into fixed-width free text has destroyed information the receiving institution's controls depend on and cannot recover, so it must be explicit about what it drops, must never silently truncate a field a control uses, and must be measured on the rate at which it degrades messages. A gateway reporting one hundred per cent successful translation is not measuring the right thing.

The end-to-end reference deserves its own mention: generated once at origination and preserved unchanged by every institution in the chain, it is what makes tracking, duplicate detection and enquiry tractable, and it is the field most often mangled by an intermediate system regenerating identifiers for its own convenience. If you have ever debugged why a payment appears twice in a downstream report, that is usually where it started.

Idempotency and the fiction of exactly-once

Nothing distributed is exactly-once, and money is no exception. You build at-least-once delivery with an idempotent effect, and the craft is making the effect idempotent at the right boundary.

Start from what a timeout tells you, which is nothing. The client stopped waiting. The request may never have arrived, may have been rejected, or may have completed and settled while the response was lost coming back. That ambiguity cannot be removed, only made safe to resolve by asking again — so a retry is correct behaviour, and the server's obligation is that a second identical request yields the same single effect and the same answer.

Four things have to be right, and they are what preventing a double charge on payment retry is graded on.

Where the effect is your own database, that shared commit is genuinely achievable: the payment row, the ledger entries, the dedupe record and the response to be replayed are one COMMIT. Where the effect is a call to another institution it is not, because you cannot enlist someone else's rail in your transaction. The pattern there is two commits with a durable intent between them — write the intent and a pending payment and commit, call out passing your reference through as the counterparty's own deduplication key, then commit the outcome. The first commit is what makes recovery possible at all; the counterparty's key handling is what makes the recovery call safe to make.

Two further things sit outside that. Retention of idempotency records is a correctness parameter: once deleted, a retry carrying that key is indistinguishable from new business, so retention must exceed the longest retry horizon any client, queue redelivery or operator replay could have. And the inbound direction has the same problem in a different shape, because rails redeliver files and messages, so every inbound item needs a natural key you enforce uniqueness on and file ingestion needs to be idempotent at the file level. Defending only the direction you initiate is a common and visible omission.

Reconciliation as a subsystem

The mechanics are a layered match. Begin with the strongest key both sides preserved and accept those automatically. What remains falls to weaker strategies: amount plus date plus counterparty, grouped matches where one of your items corresponds to several of theirs, and tolerance matching within a threshold you consciously chose. Ordering matters, because a greedy weak match consumes an item a later strong match needed.

Survivors are aged, and a one-day-old item on a rail with a known one-day lag is timing rather than error. Classifying before chasing is the difference between an operations team that works exceptions and one that drowns, and it is the discipline behind investigating a nostro break. Genuine breaks then fall into recognisable classes, and naming them is worth credit because each has a different owner and a different remedy.

That last row is the dangerous one, and it is why the strongest reconciliations run against an independently sourced record such as a correspondent's statement or the central bank's account record, rather than between two of your own systems fed from the same upstream.

Core migration and the true balance

Replacing a core is the highest-stakes programme most banks run, and the property you must prove is narrow: at one instant the new platform holds exactly the same financial position as the old. It is a gate with two independent checks that fail differently. Per-account equality catches individual records that failed to load or loaded with a truncated or misparsed amount. Control totals catch the population problems that per-account checks cannot see: a whole product portfolio omitted from the extract, a currency loaded at the wrong scale, a set of dormant accounts filtered out by a clause somebody added to make the run finish faster. Reconciling in aggregate but not per account means money moved between customers; reconciling per account but not in total means a portfolio vanished. That two-sided argument is the core of migrating a core without losing the true balance.

Balances are the easy half, and the honest way to answer the question is to walk the inventory of what else hangs off an account.

Identifiers are the ones you cannot negotiate, because they sit in systems you have no authority over. Either they migrate unchanged or you run a mapping layer, and that layer has to be in the payment path from the first minute rather than added when the first rejection arrives.

The boundary is not a line either. Outbound instructions not yet settled must be completed by the old platform or restated on the new, never both. Inbound payments during the freeze need somewhere that can hold rather than reject them. Card authorisations approved before the freeze present for settlement after it, so holds must migrate or settlements find no matching approval. And back-dated activity keeps arriving with value dates before the cutover, so decide in advance whether it posts with a back value or through an adjustment account. The TSB migration of 2018 made the wider lesson permanent: a platform that holds every balance correctly and cannot carry the login volume of the whole customer base arriving at once has failed in a way indistinguishable, from the customer's seat, from having lost their money.

Financial crime controls in the payment path

These are architecture, not someone else's queue, because they impose synchronous decisions, hold states and evidence retention.

Onboarding establishes identity: a claim, dated evidence against it, verification that the person exists and is the one presenting, and a risk rating derived from the evidence which then selects the depth of ongoing due diligence rather than treating every customer identically. That shape is the substance of designing onboarding with risk-based due diligence, and its engineering consequence is that evidence expires, so due diligence is a recurring obligation with a scheduler behind it. It also presumes the bank knows the person once rather than six times, which product-aligned architecture does not deliver by default — hence the golden customer record across products, and hence the fact that a relative calling to say the customer has died is unanswerable without one. Corporate onboarding answers three separate questions — that the entity exists, who ultimately owns and controls it, and who may act for it — and ownership resists automation because layered structures require traversing a graph, control can exist without shareholding, and registry data is frequently self-declared. Onboarding a company and beneficial ownership is a graph traversal over unreliable data with a regulatory obligation attached.

Screening and monitoring are routinely conflated and are fundamentally different controls. Screening enforces a prohibition; monitoring detects suspicion. Every architectural difference follows from that one distinction, which is what sanctions screening and a payment that hits a list is testing.

Money going backwards

Every mechanism for moving money forward needs one for moving it back, and the reverse operations are not symmetric with each other. They differ by who initiates, what has already settled, and whether the outcome is an entitlement or a request, and conflating any two of them is a reliable way to fail a card interview.

The structural point underneath all of them is that liability follows the rulebook rather than the cash. Whether the issuer or the merchant absorbs a fraudulent transaction depends on conditions like whether the chip was read, whether the card was present, and whether strong customer authentication was applied and passed, which is why a merchant's incentive to authenticate is not only to prevent fraud but to move who pays for it. Reason codes, evidence requirements and deadlines differ by scheme and region, so naming the mechanism precisely and declining to invent the deadlines is the credible answer.

Instant credit transfers have a fifth shape. Once irrevocable, a payment made under deception cannot be pulled back as of right; the sending bank can only ask. That has driven payee-confirmation services letting a sender check the destination account name before sending, and reimbursement regimes allocating the loss between institutions rather than leaving it with the victim. Both push work into the payment path: a name-check call with its own latency and availability profile, and a fraud decision that must produce a warning or a block inside the same few seconds as everything else.

Arrears through to write-off

A single missed payment moves an account along three tracks governed by different rules. The collections state advances, starting a contact strategy and possibly a fee. The impairment position may change, moving the exposure toward a stage where the provision reflects expected loss over the instrument's remaining life rather than the coming year, once credit risk is judged to have increased significantly. The credit reporting track makes the delinquency visible to bureaux.

Modelling those as one status field is the mistake, because forbearance and cure move them differently on purpose. Each track needs its own state machine and its own audit of why a transition happened, which is what from a missed payment to a written-off loan is testing. Decisioning carries a parallel requirement: a decline must be explainable to the applicant and defensible to a supervisor, meaning stored inputs, policy version and model version, which makes how a credit decision is made and explained a systems question rather than a modelling one.

Open banking and payments you did not initiate

For account information, consent is the central object and the design point is that it is a first-class server-side resource with an explicit account set, permission set and expiry, revocable from either side, against which every read is authorised. It is not a token scope. A token expresses what a client may call; consent expresses what a customer agreed to, over which accounts, for how long — and when they diverge, which they will, deriving authorisation from the token means a revocation does not bite until the token expires. Authentication stays at the bank, and adoption is won on stable, distinguishable error semantics rather than endpoint count, because a third party integrating with dozens of banks routes around the unpredictable one. That is the substance of designing an account-information API with consent.

For payment initiation, the third party instructs but never holds the money or the credentials. The bank authenticates its own customer, applies its own controls, executes on its own rails and owns the outcome — so when the payment does not arrive, the bank owes the customer an answer regardless of who initiated. The design work is a status model with honest terminal states, including an explicit unknown resolved by enquiry rather than resolved optimistically, and a redress path that makes the customer whole first and apportions fault between institutions afterwards. That ordering, remedy before attribution, is what a third-party payment that never arrived is graded on.

Degradation, and who decides when you cannot

Card authorisation has an unusual answer: the decision moves outward rather than failing. When the issuer's host is unreachable the scheme can authorise on its behalf under parameters the issuer supplied in advance, and below that the chip and terminal can approve offline against the card's own risk parameters and terminal floor limits.

flowchart TD
  accDescr: Card authorisation moving the decision outward rather than failing, branching on whether the issuer host is reachable and then on whether scheme stand-in is permitted, the scheme approving on issuer parameters or the chip and terminal deciding offline, both leaving the issuer to inherit the approval and reconcile inherited approvals on recovery.
  R[Authorisation request] --> H{Issuer host reachable}
  H -->|Yes| I[Issuer decides on live balance]
  H -->|No| S{Scheme stand-in permitted}
  S -->|Yes| T[Scheme approves on issuer parameters]
  S -->|No| C[Chip and terminal decide offline]
  T --> B[Issuer inherits the approval]
  C --> B
  B --> X[Reconcile inherited approvals on recovery]

The branch worth studying is the one that never reaches you. Approvals taken without you still bind you — they arrive afterwards as settled transactions against accounts you never checked, some without funds, some blocked, some reported stolen after you went down. So the design work is upstream, choosing stand-in parameters per portfolio that trade an acceptable loss against an acceptable decline rate, and downstream, being able to identify what came in while you were absent. This is who approves a card while the auth host times out, and it generalises: a good degradation design decides in advance who holds the decision when you do not.

Different rails degrade differently. An instant rail that does not answer leaves an unknown you resolve by enquiry rather than by resending, because resending an accepted payment is a duplicate irrevocable credit. A high-value rail cannot be substituted at all. Batch merely delays, which is exactly why batch was comfortable and why removing it was expensive. The unifying principle is that degradation is a product decision expressed in code, and the version of it that generalises beyond payments appears in the overnight risk run that will not finish before open: a number published with unknown coverage is more dangerous than a number that is missing.

What interviewers ask

Interviewers grade a small number of observable signals, and knowing which one a question aims at is worth more than knowing more facts.

The most heavily weighted is whether you keep the lifecycle phases distinct. Almost every opening question is a walk-through, and the grader listens for authorisation, capture, clearing, settlement and reconciliation staying separate in your account. The observable form of a pass is that you can be interrupted at any point with "whose money is where right now?" and answer without hesitating.

The second is whether you volunteer the unknown state. Describing only the success path and the clean failure path marks you as someone who has built systems correct whenever nothing crashes. Saying "and there is a third outcome, which is that I do not know, and here is how I resolve it" marks you as someone who has operated one.

The third is whether your invariants are checkable. Anyone can say a ledger should balance. The signal is whether you describe the check that detects it not balancing, how often it runs, who sees the result, and what happens when it fails. Same for reconciliation: naming it earns nothing, while stating match keys, tolerance and ageing policy earns a lot. The distinction is between people who state properties and people who enforce them.

The fourth is whether you know what you cannot control, and its sharper form is whether you will invent a fee percentage, a chargeback deadline or a regulation reference under pressure. "That is in the scheme's operating rules and varies by region, so I would look it up" scores better than a confident wrong number, and the confident wrong number is a serious mark against you because it suggests you would do the same in a design document.

The fifth is whether you connect design to money. Every choice here has a commercial consequence — liquidity held, fraud absorbed, interchange earned, disputes lost, customers abandoned mid-journey. Someone who can name the line that moves is being considered for architecture. This is why questions like reducing onboarding drop-off without weakening assurance exist: they cannot be answered without holding a conversion metric and a control objective in tension.

The sixth, which decides senior and staff outcomes, is whether you name the decision rights. Who stops the cutover. Who owns suspense ageing. Who sets stand-in parameters. Who accepts the residual risk when you fail open. Architecture in a bank is substantially the allocation of authority, and a design with no named owners will not survive its first incident.

Round shapes differ by seniority. Entry and mid rounds are dominated by walk-throughs and definitional distinctions. Senior rounds are dominated by scenarios with a failure already in progress, graded on triage order and on what you tell the customer. Staff rounds are dominated by trade-off framing — which rail, one cutover or tranches, what you would refuse to do. In all three, the fastest way to lose the room is a confident answer to a question with no single answer, and the fastest way to win it is to state the trade-off before stating your choice.

The mapping from question archetype to signal is stable enough to prepare against directly.

Questions

Walk me through a payment from the moment the customer presses send to the moment the beneficiary can spend the money.

Take a domestic credit transfer on an instant rail. The customer authenticates and submits. You validate the instruction, check the beneficiary against any payee-confirmation service in the market, run fraud scoring and sanctions screening synchronously, and confirm available balance including any overdraft. If that passes you debit your customer — a real ledger posting — and send the payment with an end-to-end reference. The receiving institution decides whether it can apply the credit and responds, and on acceptance settlement follows the rail's model before the beneficiary's bank credits its customer.

Three points separate an adequate version from a strong one. Your debit and the beneficiary's credit are separate postings in separate ledgers connected only by a message. Acceptance and settlement are different events, so on a deferred rail the beneficiary can have spendable funds before the interbank money has moved, which is exactly the exposure those schemes hold collateral against. And there is a fourth outcome besides accept and reject, which is no answer, resolved by enquiry rather than by resending.

Your authorisation succeeded. Has any money moved?

No. An approval is the issuer promising to honour a later collection. It reduces available balance by placing a dated hold and leaves the posted ledger balance untouched, because a posting requires an entry and nothing has been recorded. The merchant has an approval code and no funds.

This matters beyond vocabulary because everything downstream depends on hold and collection being separate. The captured amount can differ from the authorised one, the capture can arrive after the hold expires, and the hold can dangle if the merchant abandons the sale without reversing.

Why is a refund not simply the reverse of the original charge?

Because it is a new transaction. A reversal, which genuinely cancels, only exists before collection — it releases the hold and nothing needs returning. Once captured and settled, the money has been through clearing and netting: the funds are in the merchant's balance and the interbank position was settled, so there is nothing left to undo. The refund is a fresh transaction in the opposite direction with its own reference, its own clearing window and its own fee treatment.

That asymmetry is why a charge appears instantly and a refund takes days. The original was visible instantly because a hold is a local decision at the issuer, while the refund must traverse capture, clearing and settlement in the other direction before it becomes a posting on the customer's account. Being able to explain that to a product owner converts a recurring complaint into a mechanism, which is a large part of what makes a payments engineer useful outside the payments team.

The card scheme pays you one net amount a day and you posted forty thousand transactions. Prove they agree.

They will not agree, and expecting them to is the error. The control is a bridge, not an equality, with each line independently sourced. Start from the gross value of transactions presented in the window. Subtract interchange and scheme fees per the scheme's own reported figures. Adjust for chargebacks and representments in the period. Adjust for timing, because transactions near the cut-off fell into a different clearing window and some from the previous window landed in this one. Adjust for currency conversion where the scheme settled in a different currency, being explicit about the rate and when it was struck.

Whatever remains is the break, and the test is not that it is zero but that it is small and tightly aged enough to investigate individually. A control producing a large unexplained residual every day has been reduced to a plausibility check. The graded signal is whether you reach for a reconciling bridge or try to force two figures to be equal.

How do you achieve exactly-once money movement?

You do not, because exactly-once delivery is unavailable across a network you do not control. You build at-least-once delivery with an idempotent effect, then a reconciliation catching what neither can.

Concretely: the caller mints a key naming the intent, not the attempt, and reuses it on every retry of that intent. You scope it by key, endpoint and authenticated party, store a hash of the request body against it, and claim it with a unique constraint so the insert is the claim rather than a check-then-insert race. You commit the dedupe record in the same transaction as the effect where the effect is your own database; where it is an external rail you cannot, so you write a durable intent and commit, call out passing your reference as the rail's own deduplication key, then commit the outcome. A retry arriving mid-flight gets a conflict with a retry hint, because inventing a success and processing it again are both worse.

Then accept the residue. A crash between the outbound call and your commit, a rail that errored after taking the payment, and a customer submitting from two tabs all produce duplicates invisible to key-based deduplication — the last because two tabs form two genuinely distinct intents, so the mechanism is working as designed. Only reconciliation plus a business-level near-duplicate check on account, amount, reference and time proximity will find them.

The rail did not answer. Do you resend?

Not on an irrevocable rail, and this is where candidates most often reach for the wrong reflex. No answer means you do not know whether the payment was accepted, and where acceptance is final, resending risks a second irrevocable credit you can only ask the receiver to return. Resolve the unknown by enquiry: use the rail's status facility against your end-to-end reference and act once you know. If no enquiry facility exists, the payment stays in an explicit unknown state until reconciliation resolves it, and the customer is told it is in progress rather than told either outcome.

Batch rails differ because nothing has settled within the window and the scheme typically deduplicates on your file and item references. Even there the safe operation is a controlled resubmission carrying the same references rather than a fresh submission with new ones, because new references make the duplicate undetectable by anyone.

Why double-entry? I have a database with a transactions table.

Because a transactions table with a balance column cannot detect its own errors. Double-entry gives you an invariant spanning the system rather than a row: every movement writes at least two entries summing to zero, so the total across all accounts is constant and a single-sided posting from any code path is detectable by a check that does not need to know which path is buggy. That is stronger than validating each write, because it catches faults you did not anticipate.

The second reason is derivation — balances computed from entries have a provenance, so a disputed figure has an answer. The third is correction semantics: immutable entries mean a mistake is fixed by a compensating pair leaving both the error and the fix visible, which is what an auditor needs and what an update destroys. For performance you materialise balances periodically, but as a cache; if the snapshot and a recomputation disagree, the entries win and the disagreement is itself a detected fault.

How do you store a monetary amount?

As an integer count of the currency's minor unit, or a fixed-point decimal with the scale carried alongside the currency. Never binary floating point. The reason is not aesthetic: a ledger's central invariant is that a set of signed amounts sums to exactly zero, and a representation with rounding error cannot satisfy an exact-equality invariant, so the entire control framework depending on it silently stops working.

Different currencies have different numbers of minor units — some none, some three — so a hard-coded two decimal places is a bug awaiting a market expansion. Rounding needs a stated rule applied in one place, and any remainder needs a designated rounding account rather than being dropped, because a dropped remainder is a broken invariant.

What is the difference between a return, a recall, a refund and a chargeback?

They differ by who initiates, what has settled, and whether the outcome is a right or a request. A return is initiated by the receiving institution when a credit cannot be applied — closed account, invalid identifier — and travels back through the rail with a reason code. A recall is the sending institution asking the receiver to send the money back after a mistake or suspected fraud; on an irrevocable rail it is precisely that, a request the receiver may refuse, particularly where its own customer has spent the funds and will not consent.

A refund is a new merchant-initiated transaction in the opposite direction, which is worth stressing because it explains why a charge appears instantly and a refund takes days: the original hold was a local decision at the issuer, while the refund must traverse capture, clearing and settlement in the other direction before it becomes a posting. A chargeback is the card dispute mechanism initiated by the issuer under a scheme reason code, reversing a settled transaction and taking funds from the acquirer, with representment and escalation to a scheme ruling available to the merchant.

The distinction that matters in a design is right versus request. A chargeback and a return are entitlements exercised through defined mechanisms with defined windows. A recall is a negotiation. Systems built as though a recall were an operation you can perform will mislead the customer and the operations team simultaneously.

We run payments on a three-day batch rail and the business wants instant. What changes?

Everything done in the overnight window now happens inside a few seconds, in the payment path, with a measured availability obligation. Screening, fraud scoring, limit checks and available-balance calculation become synchronous and latency-budgeted, which is usually a redesign rather than an optimisation — screening a batch overnight and screening one payment in tens of milliseconds are different systems.

Reversibility disappears: the window in which an instruction could be pulled is gone, so recall becomes a request and the customer promise changes with it. Unknown states become operationally significant, sitting between a debited customer and an unconfirmed credit. Liquidity becomes continuous, because you can no longer fund a net position once a day and must hold funds around the clock including at weekends, which is a treasury change as much as an engineering one. And availability becomes an external obligation, because there is no batch to absorb a two-hour outage. Naming all four rather than only latency is what the question is grading.

What does ISO 20022 give you that a proprietary fixed-width format does not?

Structure, so party names, addresses, identifiers and purpose codes arrive in defined fields rather than free text, which is what makes screening precise and monitoring meaningful instead of matching against a blob. Richness, particularly structured remittance information, so a corporate can allocate a receipt against invoices automatically — the commercial case funding most migrations. And a single underlying model across payments, cash management, securities and reporting, reducing per-rail and per-counterparty mappings.

Two qualifications are worth volunteering. The third benefit is weaker in practice because every scheme publishes usage guidelines constraining the base messages, so two systems can both be validly ISO 20022 and still fail to interoperate; the effort lives in the guidelines, not the schema. And coexistence translation is lossy by construction, so a gateway that truncates a structured address into fixed-width text has destroyed data another institution's controls depend on. A gateway reporting one hundred per cent successful translation is measuring the wrong thing.

A payment reaches you with the originator shown only as a customer of the sending bank. What do you do?

Hold it rather than paying it on, because you cannot perform your own screening and monitoring obligations against a party you have not been told about, and paying it on passes an unscreened payment into your market. Request the missing information through the rail's enquiry mechanism and resolve the payment only when you have the detail or have decided to reject it back.

The judgement layer is the correspondent relationship: one instance is an error, a pattern is a control weakness at the sending institution and feeds your periodic review of it, potentially up to restricting or exiting the relationship. Recording the frequency makes that judgement evidenced rather than anecdotal.

The half most candidates miss is the outbound direction. Your own path must never drop fields it was given, and truncation in a format translation, an internal model with narrower fields than the rail, or a cleanup routine stripping unrecognised characters will all quietly make you the institution someone else is holding payments from. A payment arriving with the originator missing is graded largely on looking both ways.

How is sanctions screening architecturally different from transaction monitoring?

Screening enforces a prohibition and monitoring detects suspicion, and every difference follows. Screening has no risk appetite, so it runs before money moves, in the payment path, and stops the payment. It must fail closed: if the service is unavailable, payments queue, because releasing an unscreened payment is a breach while delaying a screened one is an inconvenience. Its matching is deliberately fuzzy — transliteration, name ordering, partial matches — because a miss is unacceptable and a false hit is merely work.

Monitoring tolerates misses by design, runs asynchronously over a window of behaviour rather than one transaction, produces alerts for human judgement rather than blocks, and degrades rather than breaches when delayed.

A screening hit then starts a defined sequence: hold, investigate against the specific list entry, then discount it as a false match with recorded reasoning, reject the payment, or freeze the funds and report to the authority. Where the regime prohibits tipping off you must not tell the customer why, which is a capability your customer-communication system needs rather than a policy note.

Over ninety per cent of your AML alerts are false positives. Is that a defect?

Mostly not, and defending that is the point. The base rate of laundering among transactions is extremely low, so a control tuned for recall against such a base rate cannot achieve high precision — that is arithmetic about the population, not a flaw in the rules. A monitoring system with high precision is almost certainly missing what it exists to find.

That is not an excuse for leaving it alone. Measure honestly per rule and per segment with a consistent definition, because an aggregate rate hides that a handful of rules generate most of the noise. Move volume from crude thresholds to models where the labelled outcomes support it, and retire rules that have never produced a productive alert. Shift effort from analysts to enrichment, so each alert arrives with customer context and prior disposition assembled, cutting handling time without cutting coverage.

The signal is whether you can hold a defensible position about a bad-looking metric. Promising to reduce the rate without asking what it costs in recall is proposing to weaken a control, which is the wrong direction to be caught moving. The false positive rate question rewards defending the control on principle and then improving it anyway.

Take me through onboarding a company whose ownership is four layers of holding companies.

Three questions need separate evidence: that the entity exists and is in good standing, which comes from a registry; who ultimately owns and controls it, which requires traversing to natural persons; and who may act for it, which comes from mandates and board resolutions and is independent of ownership.

Ownership is the hard one. You traverse the graph, multiplying shareholdings along each path and summing across paths, until you reach natural persons whose effective interest crosses the threshold the regime uses — commonly around a quarter of shares or voting rights, though the figure varies by jurisdiction, so it belongs in configurable policy rather than a constant. Two things break the traversal: control can exist without shareholding, through voting agreements, rights to appoint directors or documented influence, so pure arithmetic misses controllers; and registry data is often self-declared, making it evidence of what someone asserted rather than of what is true.

Where the chain cannot be resolved — a trust with discretionary beneficiaries, an opaque jurisdiction, a circular structure — record the gap, escalate under a defined policy, and either apply enhanced measures or decline. Treating unresolvable chains as a designed-for outcome rather than an error state is what earns the marks.

You have to migrate two million accounts onto a new core. How do you know the balances are right?

Make it a gate with two independent checks. Per account, opening equals closing. In aggregate, balances sum equally, debits equal credits, and the new general ledger reconciles to the old. Both are necessary because they fail differently: per-account equality catches individual records that failed to load or loaded with a misparsed amount, and control totals catch whole populations missing from the extract — a product portfolio, a currency loaded at the wrong scale, dormant accounts filtered out by a clause added to speed the run up.

The extract must come from a genuinely quiesced source, or your closing position is a moving target and the reconciliation will disagree for reasons nobody can attribute. That is why there is a freeze window, and its length is usually the hardest commercial negotiation in the programme.

Then say that balances are the tractable half, and that losing a daily interest accrual means paying twice or shorting customers across the whole book on the next application date — which is how a migration becomes a remediation programme.

At what point in a cutover does rollback stop being real?

The moment a customer transacts on the new platform. Before that, rollback is genuine: restore the old state, reopen, and you have lost time. Once someone has spent money, received a payment or drawn on an overdraft, going back means migrating those transactions in the opposite direction, under time pressure, by people awake for eighteen hours. Nobody does that successfully, so opening the doors is a commitment to fixing forward.

Saying that out loud is the point of the question, and the follow-through is where effort should go instead. Rehearsal: full-volume trials against production-scale copies, run end to end often enough that the elapsed duration is a measurement rather than an estimate. A go decision defined by named evidence and owned by someone with the standing to refuse, including an abandon time after which you reopen the old platform because the remaining window is too short to finish safely. And an argument for tranches over one big night, accepting a routing layer and a period where one customer's products sit on two platforms.

Your nostro reconciliation shows a break this morning. How do you investigate it?

Classify before chasing, because most differences are timing rather than error and chasing them consumes the capacity you need for the real ones. Match in layers: exact reference, then amount plus date plus counterparty, then grouped matches where one item corresponds to several, then tolerance matching within a threshold you consciously set. Age what survives, and a one-day-old item on a rail with a known one-day lag is timing.

For the remainder, ask which side is missing something and why. On your books and not theirs means in flight or never sent. On theirs and not yours means unposted or never yours. An amount mismatch is usually fees, FX or partial settlement. Duplicates on one side point at a redelivered file or a resubmission with fresh references.

The senior signal is knowing when the money has genuinely gone. Your ledger being updated is not the same event as settlement becoming final and irrevocable; a posting can reflect an instruction rather than a completed transfer. Confirmations from the correspondent, and the record of the settlement account itself, are what establish finality, and a reconciliation treating your own posting as evidence of settlement is reconciling a system against itself.

A third party initiated a payment from your customer's account and the money never arrived. Who owes the customer an answer?

You do. The third party instructed it but never held the money or the credentials — your customer authenticated with you, you applied your controls, you executed on your rails, so the outcome is yours. Routing the customer to the third party for an answer misallocates accountability and in most open banking regimes also misreads the rules.

The systems consequence is a status model with honest terminal states exposed identically to the third party and to your own channels: accepted, rejected with a reason, settled, returned, and an explicit unknown resolved by enquiry rather than optimistically. The failure this prevents is a third party telling the customer the payment succeeded because your API returned success on the instruction rather than on the execution.

The other graded element is redress ordering: make the customer whole first, apportion fault between institutions afterwards. A design requiring two institutions to agree who was wrong before the money comes back has placed the customer inside your dispute process.

Where does consent live in an account-information API, and what does it constrain?

On your side, as a first-class resource with its own identifier and lifecycle — an explicit account set, an explicit permission set, an expiry, and a record of when and how the customer granted it, revocable through your own channels as well as through the third party. Every read is authorised against the consent, not against a token scope.

That separation matters when they diverge, which they will. A token can be valid while the consent behind it has been revoked, expired, or narrowed because the customer closed one of its accounts. If authorisation derives from the token, revocation does not bite until the token expires, which is a data protection failure with a plausible-sounding cause.

Authentication stays at the bank: the third party never sees credentials, and strong customer authentication applies at grant and again at the intervals the regime requires. The adoption point worth adding is that third parties integrating with many banks route around the one whose errors are unpredictable, so stable and distinguishable error semantics — permission problem, consent problem, availability problem, or bad input — matter more than additional endpoints.

Your authorisation host is timing out on a third of requests. Who is approving cards?

Not you, for that third. The scheme can authorise in stand-in under parameters you supplied in advance — limits by amount, velocity, merchant category and card status — and below that the chip and terminal can approve offline against the card's own risk parameters and the terminal's floor limits. So approvals continue while your host is unreachable, and they bind you.

That is the part to say aloud, because it defines recovery. Those approvals arrive afterwards as transactions against accounts you never checked, some without funds, some blocked, some reported stolen after you went down. You cannot decline them retrospectively; you inherit them. So the work is upstream, choosing stand-in parameters per portfolio that trade an acceptable loss against an acceptable decline rate.

Partial failure adds a third population: requests that timed out symmetrically, where you do not know whether the scheme received your answer. A timeout is not a decline, and treating it as one while the customer retries creates two holds for one purchase. You need a reconciliation of in-flight requests against the scheme's record and an availability model that can release a hold discovered to be orphaned.

How do you decide which controls fail open and which fail closed?

By whether the control enforces a prohibition or manages a risk. A prohibition fails closed, because no volume of business justifies breaching it — sanctions screening is the clear case, and if it is down, payments queue. A risk-management control can fail open with a bounded appetite, because the alternative is refusing all business; stand-in authorisation is exactly that trade, and so is approving when a fraud-scoring service times out.

Two conditions make failing open defensible rather than negligent. The exposure must be bounded in advance by parameters someone with authority chose, rather than unbounded because a check did not run. And the degradation must be visible: recorded, alerted and reconciled afterwards.

The third case is the one candidates forget, and it is worse than either. Failing silently gives you the appearance of protection with none of the substance, and it is how a bank discovers months later that a rule had been disabled by a deployment. Any control that can degrade needs its own health signal, separate from the success of the transactions flowing through it.

A borrower misses a payment. What changes in your systems that morning?

Three things move independently under different rules. The collections state advances, starting a contact strategy and possibly a fee. The impairment position may change, moving the exposure toward a stage where the provision reflects expected loss over the instrument's remaining life rather than the coming year, once credit risk is judged to have increased significantly. And the delinquency becomes reportable to bureaux.

Modelling those as one status field is the mistake the question exists to find, because forbearance and cure move them differently on purpose. A borrower on a reduced payment plan may leave the collections state while remaining in the worse impairment stage, since the concession is evidence of deterioration. A borrower who repays the arrears cures the collections state while the reported history persists.

The design consequence is that the trigger is a dated event — a scheduled payment not received by its due date — and each track subscribes to it and applies its own rules, rather than one procedure attempting to update everything.

When is a loan written off, and does the customer still owe the money?

Write-off is an accounting decision taken when recovery is no longer reasonably expected, and it removes the asset from the balance sheet. It does not extinguish the debt. The borrower may still owe it, recovery activity may continue, the debt may be sold, and anything later collected is recognised as a recovery rather than a reversal of the original loan.

That imposes an awkward requirement, which is why it is asked. A written-off exposure must stay trackable — balance, history and ownership — after leaving the balance sheet, so a design treating the balance sheet as the complete system of record has nowhere to keep it. The usual shape is memorandum accounting alongside the accounting treatment, with a clear rule about which figure any given report uses.

Worth volunteering: write-off, default and impairment stage are three different concepts. An exposure can be in default and not written off, provisioned in full and not written off, and written off while still being collected.

How do you test a payments system?

By testing the states rather than the happy path. The core suite covers the intermediate states: authorised and not captured, captured after expiry, captured for less than authorised, sent and unacknowledged, accepted and unsettled, settled and unposted, posted twice from a redelivered file, returned after posting, reversed after a partial capture. Each is a state your ledger and status model must represent, and a test asserting the representation is worth more than one asserting a successful payment.

Then test invariants as properties rather than examples. Generate sequences of operations and assert after each that debits equal credits, that no derived balance disagrees with its recomputation, that available balance never exceeds ledger balance plus agreed limits, and that no two postings share an idempotency key. Property-based testing suits this unusually well because the invariants are global and cheaply checkable.

Integration needs simulators that misbehave. A counterparty stub that always answers correctly tests nothing that matters, so it must be able to time out, answer late, answer twice, redeliver a file, and return a settlement figure disagreeing with your postings — that last one being how you test the reconciliation, otherwise the least-tested and most load-bearing part of the platform.

Why does the app show one balance and the ATM another?

Because they are computing different things, often in different places. Ledger balance is the sum of posted entries. Available balance is that adjusted for authorisation holds, uncleared items, earmarks such as a court order or a pending fee, and any agreed overdraft. Both are legitimate, and a customer shown one while a channel enforces the other will reasonably conclude the bank has lost track of their money.

The design answer is that available balance is derived once, in one place, from the ledger plus a table of dated, expiring holds, and every channel consumes that derivation. The moment two channels each compute availability from their own view of holds they will disagree, and the disagreement will be defensible in both codebases, which is the hardest kind of defect to close. The complexity sits in the holds table: expiry must be enforced actively rather than filtered at read time, or an abandoned authorisation suppresses spending power indefinitely and nobody notices until the customer calls.

A figure in a regulatory return you already submitted is wrong. What happens?

Operationally: quantify the error, assess materiality against the supervisor's criteria and your own policy, notify rather than waiting to be found out, and resubmit with an explained delta so the recipient can see what changed and why.

Architecturally that needs four prerequisites, and the question is really whether you built them. An immutable snapshot of exactly what was submitted, because you cannot explain a delta against a figure you can no longer reproduce. A re-run reproducing the original output from the data as it was known at the time, which requires bi-temporal rather than as-at storage, since your sources have been corrected since. Per-line lineage back to the ledger entries, so the error is localised rather than guessed at. And completeness asserted against a declared manifest, because the most dangerous reporting error is an omission and an omission is invisible to any check validating only the rows you did include.

The wider point, connecting to a small percentage of reports being rejected every day, is that visible rejections are the smaller half. A steady rate cleared by people each morning is a known defect absorbed by labour, and it says nothing about reports accepted while being wrong. Acceptance is not validation.

The same customer exists six times across your products. Why, and what does fixing it involve?

Because each product line onboarded the person into its own system with its own identifier, which is the normal outcome of product-aligned architecture rather than a data-entry failure. Mortgages, current accounts, cards and insurance were each built or bought separately, each with a complete customer model, and nothing in that arrangement ever required them to agree.

Fixing it is a resolution layer, not a database migration. You match records probabilistically on names, dates of birth, addresses and identifiers, with a scoring model and thresholds, accepting that the false-match cost and the false-split cost are not symmetric — merging two different people is far worse than failing to merge one. High-confidence matches are automatic, a middle band goes to human review, and decisions are stored so that a later re-run does not undo them.

Then the hard part, which is what depends on the answer: aggregate exposure, financial crime monitoring across products, marketing suppression, and every obligation that attaches to a person rather than an account. That last category is what makes it non-negotiable, because an event such as a death or a fraud marker is a fact about the person that has to propagate to every product, mandate and communication.

The high-value rail is unavailable and a property completion has to happen today. What do you do?

Accept first that you cannot substitute the rail, because the receiver needs finality rather than funds. An alternative offering a slower or reversible transfer does not solve their problem even if the money arrives, and offering it without saying so is worse than saying no.

So the work is triage, finality and communication in that order. Triage: establish which payments genuinely must settle today, which is a much smaller set than the queue suggests, and get the list from the business rather than inferring it from amounts. Finality: for each, determine whether any available alternative gives equivalent certainty, including whether both parties bank with the same institution, in which case a book transfer settles internally without the rail at all. Communication: tell customers and counterparties before the window closes, because a completion that fails with warning is a bad day and one that fails silently at four o'clock is a legal problem.

Then plan the second incident, which is the recovery backlog. When the rail returns, a day's suppressed volume arrives at once against liquidity that was not funded for it, so the recovery order needs deciding in advance rather than negotiating live.

What would you refuse to design?

Senior rounds test judgement about scope as much as capability, so have an answer. Three hold up. A money-movement path with no reconciliation behind it, because such a system cannot say how much money is currently in an unknown state, and that is the only question anyone asks during an incident. A ledger permitting updates to posted entries, because at that point no balance has a provenance and no audit can conclude anything. And a cutover with no defined abandon time and no named person entitled to invoke it, because a migration whose only path is forward will be pushed past the point where it should have stopped.

Having this prepared demonstrates what the domain values most: knowing which properties are negotiable and which are the reason the system exists at all.