How money is recorded and moved: the double-entry ledger that makes a balance derivable rather than stored, the split between authorisation, clearing and settlement, the card and real-time rails that carry value, and the reconciliation and compliance work around both.
Very high demand24 min readPayments engineer, Core banking developer, Backend engineer (ledger and money movement), Payments solution architect, Payment operations and reconciliation analyst, Financial crime / AML analyst, Product manager, paymentsUpdated 2026-07-27
Assumes you know: Relational databases and transactions, including what a unique constraint buys you, Distributed-systems basics: retries, timeouts, at-least-once delivery
Overview
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.
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.
Subsection
What it is for
Core Banking & Accounts
The account model and the ledger everything posts into
Lending & Credit
Granting, servicing and recovering money lent
Payments & Rails
Moving value between institutions, and when it is final
Cards & Acquiring
The four-party card flow and its dispute machinery
KYC & Customer Onboarding
Being allowed to serve this customer at all
AML & Financial Crime
Detecting and reporting misuse of the accounts
CLM & Customer Lifecycle
One customer view across products and systems
Risk & Capital
Aggregating exposure and proving you can absorb loss
Regulatory Reporting
Telling the supervisor, with lineage back to the ledger
Reconciliation & Settlement
Proving your records match everyone else's
Open Banking & APIs
Consented third-party access to accounts and payments
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.
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.
Loading diagram…
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.
Loading diagram…
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.
Loading diagram…
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.
Term
What it means in practice
Posting
One immutable debit or credit line against one account
Value date
The date a payment counts for interest, not when it was keyed
Hold
Funds reserved by an authorisation; not yet moved
Capture
Turning an authorisation into a claim for real money
Presentment
The acquirer submitting a captured transaction for clearing
Interchange
Fee the acquirer pays the issuer, set by scheme rules
Net settlement
Institutions exchange only the difference, not every payment
Finality
The point after which a payment cannot be unwound unilaterally
Nostro
Our account held at another bank, in their currency
Break
A difference between two records that must be explained
Return
A rail-supported push-back of a payment inside a set window
Chargeback
A scheme-governed forced reversal raised by the issuer
Stand-in
The scheme authorising on the issuer's behalf when it is down
Cut-off
The clock time after which work lands in tomorrow's batch
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.
Role
Builds or specifies
Judged on
Payments engineer
Builds
Correctness under retry and partial failure
Core banking developer
Builds, inside a vendor product
Configuration that survives an upgrade
Payments architect
Specifies
Rail choice, and what it locks in
Reconciliation analyst
Operates
Breaks explained and closed, daily
Financial crime analyst
Operates
Alerts cleared and reports filed on time
Product manager, payments
Specifies
Economics, and what the scheme rules allow
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.
Rail type
Undo mechanism
Who can start it
Practical window
Card
Refund, or chargeback by rule
Merchant, or cardholder via issuer
Long, scheme-defined
Batch debit
Return with a reason code
Payer's bank
Defined per reason code
Batch credit
Recall request, discretionary
Sending bank
Short and not guaranteed
Instant credit
None; only a request to return
Sending bank, asking nicely
None by right
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.
Loading diagram…
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.
-- 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".SELECTSUM(CASEWHEN direction ='credit'THEN amount_minor ELSE-amount_minor END)
FROM posting WHERE account_id ='acc_bob';