Banking & Payments

What this area actually covers

Banking and payments is about recording and moving value between parties who do not trust each other, under rules written by someone who is not you. Interviewers probe two halves separately. The ledger: how a balance comes to exist, how a transfer is represented, how you prove afterwards that nothing was created or destroyed. The rails: the schemes, networks and file formats that carry an instruction between institutions, each with its own timing and reversal rules.

Plenty gets wrongly bundled in. Underwriting and collections are a neighbouring domain — a loan account lives on a ledger, but deciding to lend is not payments work. Order matching and custody belong to capital markets, where "settlement" means something related but distinct. Fraud detection is usually another team's model, and the payments part is where that decision hooks into the flow.

The thing that surprises people arriving from product engineering is how much of the work is evidence. A retail application is judged on whether it did the right thing; a bank is judged on whether it can demonstrate afterwards that it did, to a customer, an auditor and a supervisor, years later, from records it was obliged to keep in a particular way. That obligation reaches all the way into the schema.

The eleven areas underneath

This section breaks into eleven subsections, and they are not eleven views of the same thing. A payments engineer and a financial-crime engineer work in the same building on entirely different objects, and a candidate who conflates them is easy to spot. Read the tour below before you pick where to start, because the fastest way to sound fluent is to know which of these a question belongs to.

Core Banking & Accounts is the product and account model itself: what an account is, which products can be opened against a customer, how the double-entry ledger is laid out, how interest and fees accrue day by day, and what happens in the end-of-day batch that closes a business date. It exists as a separate area because everything else in banking posts into it. Open it for the account and product data model, accrual mechanics, value dating, and why a "day" in a bank is an explicit object rather than a wall clock.

Lending & Credit covers originating a loan, deciding whether to grant it, servicing it across years and pursuing it when repayment stops. It is separate because the governing question is different: not "did the money move correctly" but "can you justify this decision to the applicant and the regulator". Expect amortisation schedules, credit policy versus scoring models, delinquency buckets and the audit trail behind a refusal.

Payments & Rails is the movement itself — initiation, the split between real-time and batch rails, how an instruction is validated, cleared and settled, and what returns and reversals are available on each rail. It is the area with the most vocabulary per square inch, because every scheme names the same idea differently. Open it for rail selection, timing, finality and the failure modes of each.

Cards & Acquiring is a rail with enough machinery to need its own area: the four-party model, dual-message authorisation and capture, interchange and scheme fees, the chargeback lifecycle, and tokenisation. Cards behave unlike every other rail, chiefly because a card payment can be reversed by rule months after settlement. Read it for the money flow between issuer, scheme, acquirer and merchant, and for what a dispute costs.

KYC & Customer Onboarding is the process that turns an applicant into a customer the bank is allowed to serve: identity verification, customer due diligence, sanctions and adverse-media checks, a risk rating, and periodic or perpetual refresh of all of it. It is separate from account opening because the verification lifecycle outlives the account form. Open it for how identity evidence is modelled, what triggers enhanced due diligence, and why "perpetual KYC" is a data-freshness problem rather than a form.

AML & Financial Crime is what happens after onboarding: monitoring transactions for patterns worth investigating, screening against sanctions and politically exposed person lists, triaging alerts into cases, and filing reports. It exists separately because its economics are unusual — the vast majority of alerts are false positives, and tuning that rate is itself the engineering problem. Expect rules and models, case management, and the strict rule that a customer must not be told they are under investigation.

CLM & Customer Lifecycle is the customer as a long-lived entity rather than a signup: onboarding through servicing to offboarding, across products and often across legal entities. Its defining difficulty is the golden record — producing one authoritative view of a customer who exists in six systems under five spellings. Open it for identity resolution inside a bank, and for what "offboarding" means when records must be retained after the relationship ends.

Risk & Capital translates credit, market, liquidity and operational risk into things an engineer builds: exposure aggregation across products and counterparties, limit checking, and stress testing. It sits apart because it consumes everyone else's data and is judged on completeness rather than latency. Read it for why aggregating exposure is hard when the same counterparty appears under different identifiers in each source.

Regulatory Reporting is the obligation to tell a supervisor what you hold and what you did, on a schedule, in a defined format. Treat it as a data lineage problem: every figure must reconcile to the ledger, be traceable to source, and be restatable when it turns out to be wrong. Open it for lineage, reconciliation controls, and the mechanics of a restatement.

Reconciliation & Settlement is the daily proof that your records and somebody else's agree — internal reconciliation between subsidiary ledgers and the general ledger, nostro reconciliation against accounts you hold at other banks, and the investigation of every break. It earns its own area because it is the control that catches everything the other areas got wrong. Expect matching strategies, break categories, ageing, and settlement finality.

Open Banking & APIs is regulated third-party access to accounts and payment initiation: consent capture and revocation, strong customer authentication, account information and payment initiation interfaces. It is separate because the hard parts are consent lifecycle and liability rather than API design. Open it for how consent is modelled as a first-class, expiring, revocable object.

Where it sits in a real business

Everything else is a story about how postings get created. A correct financial system is double-entry: every economic event is recorded as postings whose debits and credits sum to zero across at least two accounts. A transfer is not a subtraction followed by an addition — it is one immutable transaction holding both legs, and if you cannot write both you write neither.

So a balance is derived, not stored: it is the sum of postings against an account up to a point in time. Cache it if you must, but the cache is never the truth, and a design where the balance is authoritative and postings are a side-effect log eventually produces a number nobody can explain.

-- Postings are immutable, and amounts are integer minor units:
-- money in floating point is a value you cannot reconcile.
INSERT INTO posting (transaction_id, account_id, direction, amount_minor, currency) VALUES
  ('txn_8f21', 'acc_alice', 'debit',  250000, 'INR'),
  ('txn_8f21', 'acc_bob',   'credit', 250000, 'INR');

-- This query is the only definition of "balance".
SELECT SUM(CASE WHEN direction = 'credit' THEN amount_minor ELSE -amount_minor END)
FROM posting WHERE account_id = 'acc_bob';

Minor units are not a stylistic preference. ISO 4217 gives each currency an exponent, and they differ: most have two decimal places, the Japanese yen has none, and a handful including the Kuwaiti and Bahraini dinar have three. A system that assumes two decimal places everywhere will silently multiply or divide by a hundred at a border. Storing integers in the currency's own minor unit, and carrying the currency code beside every amount, removes an entire class of defect that is otherwise found by a customer.

The accounts those postings hit are not only customer accounts. A working ledger has internal accounts too: a suspense account for money that has arrived without enough information to place it, clearing accounts that hold value mid-flight between two systems, fee income accounts, and a nostro account representing money the bank holds at another bank. The rule of thumb is that every place money can sit, including places it can only sit for four seconds, needs an account, because otherwise those four seconds are invisible and unauditable.

Authorisation, clearing and settlement

Above the ledger sit the rails, where the load-bearing distinction is authorisation, clearing and settlement. Authorisation asks in real time whether the funds and the permission are there, and usually creates a hold rather than a movement. Clearing exchanges transaction detail and establishes who owes whom. Settlement moves value between the institutions' own accounts, typically at a central bank. The gaps between them are where operational reality lives: an authorised card payment never captured expires, and a captured one still has not settled for the merchant.

Those gaps are best held as an explicit state machine rather than a set of boolean columns, because every transition has a timeout and a compensating action attached to it.

stateDiagram-v2
    [*] --> Initiated
    Initiated --> Authorised
    Initiated --> Declined
    Authorised --> Captured
    Authorised --> Expired
    Captured --> Settled
    Settled --> Disputed
    Settled --> Refunded
    Disputed --> Settled
    Declined --> [*]

The transition worth staring at is Authorised to Expired. Nothing happens to cause it — it is the absence of an event, and a system with no timer on that edge will hold a customer's funds against a shipment that never went out.

The four-party card model

Cards run the four-party model. The card comes from an issuer, the merchant is signed up by an acquirer, and the scheme — Visa, Mastercard, RuPay and others — sits between the two banks, setting the rules and running the network. The cardholder-to-merchant relationship is commercial, but no money flows along it: value moves issuer to scheme to acquirer to merchant, net of interchange and scheme fees the rules allocate. American Express and Discover historically ran a three-party model in which the same organisation both issues and acquires, which is why their pricing and dispute behaviour do not always match the schemes.

sequenceDiagram
    participant C as Cardholder
    participant M as Merchant
    participant A as Acquirer
    participant S as Scheme
    participant I as Issuer
    C->>M: Presents card
    M->>A: Authorisation request
    A->>S: Routed request
    S->>I: Authorise
    I-->>S: Approved, funds held
    S-->>A: Approved
    A-->>M: Approved
    M-->>C: Goods and receipt

What to notice is that the customer walks away satisfied at the bottom of this diagram and no money has moved. Capture happens later, clearing that night, settlement a day or more after that. Every one of those later steps can fail independently of the approval the customer saw.

Cards also carry the most elaborate dispute machinery, because a chargeback is a scheme-governed reversal raised long after settlement, on a reason code, with deadlines that bind both sides. The merchant may represent the transaction with evidence, and unresolved cases escalate to pre-arbitration and arbitration under scheme rules. Losing on a technicality — missing a deadline, supplying evidence in the wrong form — is common and is a systems failure rather than a commercial one.

Account-to-account rails

Account-to-account rails split by timing, and timing decides reversibility. Real-time rails — UPI in India, FedNow and RTP in the United States, SEPA Instant Credit Transfer in the euro area, Faster Payments in the UK — are credit-push, near-instant, continuously available, and credit the beneficiary with finality. There is no technical undo: recovering a mistaken payment means asking the receiving bank to return it, which is why authorised push payment fraud is so damaging here.

Batch rails differ. ACH in the United States and NEFT in India process in windows and settle on a deferred net basis, and NEFT's round-the-clock operation made it continuously available without making settlement real-time. Batch rails carry return rights — an ACH debit can be returned with a reason code inside defined windows, and the window for a consumer disputing an unauthorised debit is considerably longer than the one for insufficient funds — so a direct-debit collection is provisional in a way an instant credit never is. Keep the names straight: RTGS is high-value gross settlement, IMPS is India's older instant retail rail, and SWIFT is interbank messaging rather than a settlement system.

Because instant rails have no undo, the industry has pushed the control upstream into the moment before the payer confirms. The UK's Confirmation of Payee checks the beneficiary name against the account before the payer commits, and the EU's instant payments legislation requires an equivalent verification of payee for euro credit transfers. This is worth understanding as a pattern rather than a feature: when you cannot reverse an action, the only remaining control is to make the mistake harder to commit.

sequenceDiagram
    participant P as Payer
    participant SB as Sending bank
    participant N as Scheme switch
    participant RB as Receiving bank
    P->>SB: Payment instruction
    SB->>N: Payee name check
    N->>RB: Verify name on account
    RB-->>N: Close match
    N-->>SB: Close match
    P->>SB: Confirms anyway
    SB->>N: Credit transfer
    N->>RB: Credit beneficiary
    RB-->>N: Accepted and final

The interesting edge is the sixth line. A "close match" is not a decline, and the payer is allowed to proceed; who bears the loss when they proceed and it turns out to be fraud is a policy question that different jurisdictions have answered differently, with the UK requiring reimbursement of most authorised push payment fraud victims and splitting the cost between the sending and receiving firms.

Messaging formats

Instructions travel as messages, and two families dominate. Card networks have long run on ISO 8583, a compact positional format built for expensive network links, still underneath most authorisation traffic. Everything else is converging on ISO 20022, an XML-based standard organised into message families: pain for payment initiation from a customer, pacs for interbank clearing and settlement, and camt for cash management and statements.

ISO 20022 matters to engineers for one reason above the rest: it carries far more structured data than the formats it replaces. A legacy wire had a free text field where the remittance information went; the equivalent ISO 20022 message has structured party identification, purpose codes and remittance references. That richness is why sanctions screening and reconciliation get better after a migration, and also why migration is painful — you cannot invent structured data you never captured, so a coexistence period involves truncating rich messages down to old ones and losing information on the way.

None of it is trusted until it is reconciled. Each day you compare your postings against the settlement files and statements the schemes and banks send, and work the differences — the breaks — until every one is explained.

The words you will hear on day one

Vocabulary is a gate in this domain, and it is used without explanation. These are the terms most likely to appear in the first meeting, with the meaning that matters rather than the dictionary one.

Two of these cause more confusion than the rest. Value date is not a timestamp; it is the date the payment is treated as effective for interest and position purposes, and it can be earlier or later than the moment the record was written. And finality is a legal property rather than a technical one: a payment is final when the scheme's rules and the relevant law say a participant can no longer reverse it, which may be before or after your database commits.

Who does this work

The builders are backend and platform engineers on ledger, gateway, card-issuing or scheme-connectivity teams. A day is less algorithmic than outsiders expect: modelling a new payment type as postings, implementing a scheme message or ISO 20022 mapping, handling a webhook that arrived twice, writing the job that finds out when you got it wrong. Core banking developers work inside vendor platforms, where the skill is knowing what the platform will not let you do.

The operators are a distinct population, and engineers who ignore them build systems nobody can run. Reconciliation analysts work the daily break report, and your tooling is their tooling. Financial crime analysts clear monitoring alerts and file regulatory reports. Product managers and architects choose the rail, and that choice silently fixes reversibility, cost and failure modes.

There is a third population worth naming because it decides your release cadence. Second-line risk and compliance functions review changes to anything touching customer money, monitoring rules or regulatory figures. They are not an approval queue you route around; in a supervised firm the evidence that they reviewed a change is itself a control the regulator inspects. Engineers who treat them as an obstacle ship slowly and unhappily, and engineers who bring them a clear description of what changed and what could go wrong ship faster than either.

Demand, adoption and how that is changing

Demand is very high and structural rather than fashionable. Regulators keep mandating capability against hard deadlines: instant-payment obligations in the EU, ISO 20022 migration across high-value and cross-border messaging, open-banking access, strong customer authentication. Real-time rails have moved expectation to instant, irrevocable and always-on, which invalidates architectures built around a nightly batch. And embedded finance means firms that are not banks now run ledgers, so these skills are hired well outside banking.

Three specific pressures explain most of the current hiring. The first is migration: a scheme deadline is not negotiable, and every institution connected to a rail that is changing format must fund the work whether or not it wants to. The second is fraud liability. As instant rails removed the ability to claw money back, jurisdictions have been reallocating who pays when a customer is tricked into sending it, and reallocated liability turns directly into engineering budget for controls, name checking and monitoring. The third is the long tail of firms that hold customer funds without being banks — marketplaces, payroll providers, gig platforms — which discover late that they have built a ledger by accident and need someone who knows what a good one looks like.

The plumbing at the edges is commoditising: card acceptance, tokenised wallets and payout APIs are bought rather than built. What is not commoditising is ledger design, reconciliation, dispute handling and correctness under retries — where a provider hands you a primitive and the consequences of misusing it stay yours.

What makes it hard

Correctness is defined externally and audited. Most software can be wrong for an hour and be forgiven; here an error becomes a customer's missing money and a break someone clears by hand.

The conceptual leap is that money movement is eventually consistent across organisations you cannot coordinate with. You cannot hold a database transaction open across your ledger and a scheme, so you get in-between states — authorised not captured, submitted not settled, credited by you and rejected by them — and each needs a name, a timeout and a compensating action.

Delivery gives you at-least-once; the business demands exactly-once effect. You close that gap by making every mutating operation idempotent on a caller-supplied key, enforced by a uniqueness constraint at the ledger, so a retry collapses into the original posting. Duplicated payouts and double charges are among the most common serious incidents here, and they are nearly always a retry meeting a system with no deduplication key. Note where the constraint lives: idempotency implemented in application memory, or in a cache, is idempotency that disappears when a pod restarts at the worst possible moment.

There is no rollback, only compensation

The second difficulty follows from the first. Once an instruction has left your building, you cannot undo it — you can only issue a second, opposite instruction and hope it succeeds. That distinction has consequences a transactional mindset does not prepare you for. A reversal is a new event with its own postings, its own failure modes and its own timing, so a ledger records a mistake and its correction rather than pretending the mistake never happened. An account can be overdrawn by a correction. And the compensating action is not always available: what a rail lets you do depends entirely on which rail it is.

The column that matters is the last one. A design that assumes payments can be cancelled is a design that has only ever been tested against cards.

Compliance shapes the design before you start

KYC means an account has a verified-identity lifecycle and cannot spring from a signup form. The customer record carries evidence, an expiry on that evidence, and a risk rating that decides how often it must be refreshed and how much scrutiny each transaction gets. Building this as a form that writes a boolean is the classic mistake, because the obligation is ongoing rather than point-in-time.

AML puts sanctions screening and transaction monitoring in the flow, requires alerts to be investigable years later, and forbids telling a customer they are under investigation. That last constraint has a direct engineering consequence: an account restriction imposed for financial-crime reasons cannot surface a truthful error message, so your status model needs internal reasons that never reach a customer-facing string. Screening is also inherently fuzzy — names transliterate, dates of birth are partial, and the same person appears on a list in three spellings — so the tuning question is which false-positive rate you can afford to have humans clear.

PCI DSS makes the cardholder data environment a defined scope you work to shrink, usually by tokenising so the card number never lands in your systems, and by never storing the card verification value after authorisation. The cheapest compliance posture is the one where the sensitive data was never yours: a hosted field or a provider-issued token keeps whole systems out of scope, and pulling card data into your own logs for debugging convenience pulls those logs into scope with it.

Finally, cross-border payments add originator and beneficiary information requirements, so a transfer must carry identifying detail about both ends rather than just an amount and an account. This is why a "simple international payment" API involves so many mandatory fields, and why dropping one causes a rejection from a correspondent bank two hops away, days later.

Reconciliation and the breaks that live there

Reconciliation deserves separate treatment because it is the control that catches everything else, and because it is the part most under-designed by engineers who have never watched an operations team work a break report.

The mechanic is simple. You hold your own record of what happened; a counterparty — a scheme, a correspondent bank, a payment provider — sends you theirs, usually as a file on a schedule. You match the two, and every unmatched or mismatched item is a break that a human must explain. What makes it hard is that matching is rarely one-to-one: a settlement file arrives net of fees, one payout may cover forty transactions, and a partial refund appears on one side before the other.

flowchart TD
    A[Ingest settlement file] --> B[Match on scheme reference]
    B --> C{Reference found}
    C -->|Yes| D[Compare amount and currency]
    C -->|No| E[Unmatched item]
    D --> F{Values agree}
    F -->|Yes| G[Reconciled and closed]
    F -->|No| H[Value break]
    E --> I[Ageing queue for investigation]
    H --> I

The path worth designing carefully is the ageing queue at the bottom. A break that nobody closes is not neutral: it is either money you are owed and have not claimed, or money you owe and have not paid, and its age is the single most useful metric an operations team has. Systems that report a break count without reporting break age hide the problem that actually matters.

Break categories are worth learning as vocabulary because they map to different causes. A timing break is a real transaction that appears on one side before the other and will resolve itself tomorrow. A value break means both sides agree something happened but disagree on the amount, which is usually fees, foreign exchange or rounding. A missing item on their side often means an instruction you believe you sent never arrived. A missing item on your side is the frightening one, because it means money moved that your ledger knows nothing about.

Why study it

Learn this if you want systems where correctness is the product, or if you are interviewing near a bank, fintech, payment provider or marketplace that holds funds. It is also the fastest education available in idempotency, immutability and audit design, which transfer to anything with money-like semantics: subscriptions, credits, loyalty points, usage billing.

There is a second, less obvious argument. This domain forces you to design for the case where your dependency is another organisation with its own release schedule, its own outage and no obligation to answer your support ticket today. That is a genuinely different discipline from designing against services your own company operates, and it makes you better at every integration you touch afterwards.

Skip it if you want quantitative work — pricing, risk modelling and trading live in capital markets and lending. If you want the shortest path to a well-paid backend role generally, a distributed-systems foundation is faster, because this domain asks you to carry vocabulary and regulation on top of engineering. And if you find governance intolerable rather than merely tedious, be honest with yourself early: the review that slows your release down is not going away, because it is the thing the licence depends on.

Your first hour

Build a ledger small enough to hold in your head, then try to break it. In any language with a local database, create a posting table with transaction id, account, direction, amount in minor units and currency, plus a transactions table carrying a unique idempotency_key. Write one function that transfers value by inserting both legs inside a single database transaction, and one that returns a balance purely by summing postings. Never write an UPDATE.

Then do the three things that turn the exercise into understanding. Call your transfer twice with the same idempotency key and confirm the second call returns the first result rather than moving money again. Add a check rejecting any transaction whose legs do not sum to zero, and try to insert an unbalanced one. Finally, compare your postings against a small CSV you have deliberately corrupted — one extra row, one missing, one with a different amount — and print the breaks by category.

If you have longer, add the piece that turns a toy into something recognisable: a fee. Charge two per cent on each transfer, posting the fee to an income account in the same transaction, and watch what happens to your zero-sum check when the fee does not divide evenly into minor units. Deciding where the rounding remainder goes, and writing it down, is the moment the exercise starts teaching you the domain rather than the syntax.

You end with a ledger, a passing idempotency test, a break report and one written decision about rounding.

What this is not

It is not accounting, though it borrows double-entry from it: you build the system of record an accountant consumes, not the financial statements. It is not fraud modelling, which is an analytics discipline that plugs into payment flows. And it is not cryptocurrency — blockchains are a different settlement model with different finality and custody properties, and none of the rail or regulatory knowledge transfers as-is.

It is also not one system, and candidates who speak about "the payments platform" reveal that they have seen one screen of it. A bank runs a core ledger, one connector per rail, a gateway, a screening engine, a case management tool, a reconciliation platform and a reporting warehouse, joined by files and messages rather than a shared database. The interesting work is almost always at those seams.

Above all, a payment API integration is not payments expertise. Charging a card through a provider is a week's work. Knowing what your ledger looks like when that provider times out after taking the money, and how you discover the next morning that it happened at all, is the domain.

A balance is a question you ask the postings, never a number you keep and defend.