How a bank works underneath the app: the ledger that must always balance, the rails money moves over, the identity and financial-crime controls wrapped around it, and the regulatory reporting that constrains every design decision.
27 published across 11 topics.
The account and product model, the double-entry ledger, interest and fee accrual, and end-of-day processing.
Store money as immutable double-entry rows where every movement writes at least two balanced entries, derive balances by summing those entries, correct mistakes with compensating entries instead of updates, and keep each currency in its own denominated account so nothing is ever summed across units.
Ledger balance is posted history; available balance is the money the customer can use after holds, uncleared items, earmarks and overdraft limits. Define it once so every banking channel shows the same number.
Prove the new platform's opening position equals the old platform's closing position, account by account and in control totals, before you accept a single instruction on it. Balances are the tractable half - standing instructions, accrued interest and payments in flight across the boundary are what break.
Origination, underwriting and scoring, servicing and collections, and how a credit decision is explained and audited.
A missed payment moves an account along three tracks at once - a collections state, an impairment stage, and a reported credit history - and they are governed by different rules. Most of the difficulty is that forbearance and cure reset some of them and deliberately not others.
Credit decisioning combines policy rules, affordability checks and score cut-offs, then stores the exact inputs, policy version, model version and adverse-action reason so a loan decline is explainable later.
Real-time versus batch rails, authorisation through settlement, payment initiation, returns and reversals.
Everything you did in the overnight window has to happen inside a few seconds, the payment becomes irrevocable so recall is a request rather than a right, an unanswered request leaves an unknown state you must resolve by enquiry, and liquidity plus availability become continuous obligations.
Prevent a double charge on payment retry with an idempotency key tied to the purchase intent, a unique constraint, atomic charge recording, honest in-flight retry responses and settlement reconciliation.
You cannot substitute the rail, so the work is triage, finality and communication - deciding which payments genuinely must settle today, whether any alternative gives the receiver the same certainty, and what you tell the customer before the window closes. The backlog on recovery is the second incident.
The four-party model, authorisation and capture, interchange, chargebacks, and tokenisation.
Authorisation is a real-time reservation of funds by the issuer that moves no money; capture tells the acquirer to collect the amount; clearing exchanges those records through the scheme and nets what each bank owes; settlement is the interbank transfer, after which the acquirer funds the merchant on its own schedule.
Card authorization stand-in processing decides what happens when the issuer host times out. Schemes, chips and terminals may approve within configured limits, leaving the issuer to reconcile advice messages and losses later.
Identity verification, customer due diligence, risk rating at onboarding, and perpetual KYC refresh.
Onboarding collects dated evidence against an identity claim, verifies that the person exists and is present, produces a risk rating from that evidence, and lets the rating select the depth of due diligence.
Corporate onboarding answers three separate questions - that the entity exists, who ultimately owns and controls it, and who may act for it - and ownership is the one that resists automation. Layered structures, control without shareholding and self-declared registry data are where the work really sits.
Separate abandonment from rejection per step and per segment, reorder the journey so cheap checks precede expensive ones, reuse evidence the applicant has already given, make sessions resumable and referrals visible, and hold the assurance level fixed while you change the route to it.
Transaction monitoring, sanctions and PEP screening, alert triage and case management, and false-positive economics.
Missing originator or beneficiary detail destroys the receiving bank's ability to screen and monitor, so the payment is held rather than paid on. You request the missing information, judge the correspondent relationship on how often this happens, and never let your own outbound path drop fields it was given.
Monitoring detects suspicion and tolerates misses; sanctions screening is a prohibition with no risk appetite, so it runs before the money moves and stops it. A hit is held, investigated against the list entry, then discounted, rejected, or frozen and reported to the authority.
It is mostly not a defect. Monitoring is a screening control tuned for recall against a base rate so low that high precision is arithmetically impossible, so the work is measuring the rate honestly, moving volume from rules to models and from analysts to enrichment.
Customer lifecycle management from onboarding through servicing to offboarding, and the golden-record problem behind it.
Death is a change to the person, not an instruction on one account, so it has to be recorded once and propagate to every product, mandate and communication. The hard parts are acting on an unverified notification, separating authority to inform from authority to distribute, and stopping outbound contact at once.
A golden customer record in banking is a derived identity view across product systems. Build it with scored entity resolution, source cross-references, attribute survivorship and reversible merge decisions.
Credit, market, liquidity and operational risk in engineering terms, plus exposure aggregation and stress testing.
Aggregation is easy arithmetic over hard inputs, so the design work is agreeing what may be added together, storing positions bi-temporally so a figure can be rebuilt as it was known on the day, and carrying lineage from every reported number back to the transaction that produced it.
Decide by use rather than by runtime - limit monitoring needs coverage and can tolerate approximation, while a capital or disclosure figure cannot be approximated at all. Whatever you publish has to carry its coverage and its market-data vintage, because a number with unknown gaps is more dangerous than a missing one.
Reporting obligations as a data-lineage problem: completeness, reconciliation to the ledger, and restatement.
A steady rejection rate that is cleared daily is not a healthy control - it is a known defect being absorbed by people, and it says nothing about the reports that were accepted while being wrong. Rejections you can see are the smaller half of the problem.
You quantify the error, decide materiality, tell the supervisor and resubmit with an explained delta. Building for that means an immutable snapshot of what was submitted, a re-run that reproduces it exactly, per-line lineage back to the ledger, and completeness asserted against a declared manifest rather than assumed.
Nostro and internal reconciliation, breaks and their investigation, and settlement finality.
Keep the event timestamp, the accounting date and the value date as three separate attributes, assign the accounting date at posting from a stated rule over rail and calendar, and close a period by locking it and snapshotting what it contained rather than by pausing the flow.
You classify the break before chasing it, because most differences are timing rather than error: match in layers from exact reference down to grouped and tolerance matching, age what remains, and remember that your ledger being updated is not the same event as settlement becoming final and irrevocable.
The net settlement figure is never the sum of your postings, so the control is a bridge rather than an equality - gross transactions, then fees, chargebacks, timing differences and currency conversion, each as its own explained line. Anything left over is the break, and it must be small enough to investigate.
Consent, strong customer authentication, account information and payment initiation APIs, and third-party access.
A payment initiation service instructs but never holds the money or the credentials, so the bank authenticates its own customer and owns the outcome. The design work is a status model with honest terminal states and a redress path that makes the customer whole first and apportions fault afterwards.
Consent is a first-class server-side resource with an account set, a permission set and an expiry, revocable from either side, and every data read is authorised against it rather than against a token's scope; authentication stays at the bank, and adoption is won on stable error semantics.