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.
16 published across 11 topics.
Banking and financial services fundamentals60 short answers on one page, for revising rather than studying.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 the sum of posted entries; available balance is that figure adjusted for holds, uncleared items, earmarks and any agreed overdraft. Derive it in one place from the ledger plus a table of dated, expiring holds, so every channel computes the same number for the same reason.
Origination, underwriting and scoring, servicing and collections, and how a credit decision is explained and audited.
A decision is policy rules and a scoring model composed in a fixed order, with the score compared to a cut-off set from the portfolio's loss appetite; explaining a decline means storing the exact inputs, policy version and model version used, and deriving the reason from whichever constraint actually bound.
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.
The client sends an idempotency key tied to the intent rather than the attempt, the server claims it with a unique constraint and commits that row in the same transaction as the charge, a retry arriving mid-flight is told to wait instead of given a success, and reconciliation catches what the request path cannot.
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.
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.
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.
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.
Each product line onboarded the person into its own system with its own identifier, so duplication is the normal outcome of product-aligned architecture rather than a data-entry failure.
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.
Reporting obligations as a data-lineage problem: completeness, reconciliation to the ledger, and restatement.
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.
Consent, strong customer authentication, account information and payment initiation APIs, and third-party access.
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.