The transformation engine
The everyday language of banking starts with products. A current account stores money. A mortgage finances a home. A card moves value. A credit line supplies flexibility. That language is useful for customers, but it hides the common machinery. Product names tell us what the institution sells. They do not tell us why the institution must hold capital, monitor borrowers, maintain liquid assets, reconcile ledgers, prove identity, settle payments and prepare for its own failure.
A first-principles account starts one layer lower. A household wants immediate access to value but may not know when it will spend. A business needs funding now but can generate repayment only after production and sales. A seller wants final payment without examining the buyer's bank. A depositor wants a stable nominal claim without underwriting every loan behind it. Each side wants a claim with a different shape from the underlying economic activity.
The bank creates value by reshaping claims across five dimensions. It transforms time by funding longer-lived assets with liabilities that may be shorter. It transforms liquidity by making claims usable before underlying assets mature. It transforms information by screening, monitoring and compressing private evidence into decisions. It transforms risk by pooling, pricing, diversifying, absorbing and transferring losses. It transforms trust by embedding promises in contracts, capital, settlement arrangements, supervision, insurance, operational continuity and resolution.
Three ledgers, not one balance
The financial balance sheet is indispensable, but it is not a complete representation of a bank's state. A loan can be correctly booked and still rest on stale income evidence. A payment can be funded and still lack valid authority. A risk report can use accurate numbers and still apply the wrong effective policy date. To explain such failures, the bank needs three logically separate, tightly reconciled ledgers.
The funds ledger records economic quantities: assets, liabilities, equity, cash, reserves, collateral, cash-flow schedules and settlement positions. The information ledger records what was observed or inferred, from which source, as of what time, with what uncertainty and lineage. The obligation ledger records who may demand what from whom, under which contract, authority, covenant, value date, condition and priority.
These are not necessarily three databases. They are three kinds of truth. A well-designed system may store them across a core ledger, document platform, risk engine, workflow service and legal archive. The architectural requirement is that a consequential decision can reconcile all three. When they drift apart, the bank may be solvent but unable to pay, informed but unauthorised, contractually entitled but operationally unable to perform, or apparently profitable because risk has not yet been recognised.
This identity says where claims sit, not when cash arrives, how reliable an estimate is, whether a payment is final, or who had authority to create the claim. Those questions require the other ledgers.
Thought experiment one: the vault and the bank
Take two institutions with identical buildings, apps and customer service. The first is a warehouse. It accepts £100, keeps £100 in immediately available central-bank money or cash, and issues a receipt. The second accepts a £100 deposit while holding a portfolio that includes long-lived loans. Both may offer safekeeping and payments. Only the second promises liquidity against assets that cannot all be realised at face value on demand.
Varying one feature changes the control problem. The warehouse mainly faces custody, operational and fraud risk. The bank adds maturity, liquidity, credit, interest-rate and confidence risk. Deposit insurance or a lender of last resort would not explain the warehouse's basic function; they respond to fragility created by transformation. Diamond and Dybvig's influential model shows why demandable deposits can improve risk sharing while also permitting damaging runs. Diamond and Rajan later show how liquidity creation and fragility can be jointly produced by the bank's capital structure. [3] [5]
Why products emerge from mismatches
A product is a stable interface around a recurring mismatch. Current accounts promise nominal stability and access. Term deposits exchange some access for yield. Loans bring future earning capacity into the present. Credit lines sell the right, but not the obligation, to draw later. Guarantees replace one counterparty's promise with the bank's. Payments convert account balances into final transfers under a shared rule system.
This functional view is close to Robert Merton's argument that financial systems should be analysed through persistent functions even as institutions and technologies change. [7] The point is not that legal categories are irrelevant. It is that a product catalogue is downstream of the transformations. When technology alters the interface, the underlying mismatch and its controls often remain.
Deposits transform uncertainty about spending time
A deposit is a liability of the bank, not a labelled pouch of the customer's cash. Its distinctive promise is that a nominal claim can remain available even though the institution's assets have different maturities, market values and repayment risks. The customer delegates almost all asset selection and monitoring. In return, the bank undertakes to honour withdrawal and payment rights under the account contract.
This is a strong transformation because the customer does not need to match a grocery purchase to the maturity of a particular mortgage. The bank pools many inflows and outflows, holds liquid resources, forecasts behaviour and arranges funding. The apparent simplicity of an available balance is therefore the surface expression of a portfolio and operating system. The deposit product hides heterogeneity so that the claim can be used at par.
That convenience creates a confidence dependence. If every depositor insists on immediate conversion while many assets remain slow or costly to sell, the institution cannot merely accelerate the contractual cash flows. It must draw liquid buffers, obtain funding, pledge collateral, sell assets or invoke recovery arrangements. The deposit is valuable precisely because most customers need not perform those actions themselves. Diamond and Dybvig's model isolates this bargain: liquidity insurance and run vulnerability arise from the same demandable contract. [3]
Loans transform future capacity into present action
A loan gives the borrower command over resources before the financed activity has generated its returns. That is a time transformation for the borrower and an information problem for the lender. The bank must decide whether future cash flows are sufficiently likely, whether the customer has incentives to perform, and what can be recovered if the central forecast is wrong.
Pricing is only one response. The bank may reduce exposure, require borrower equity, take collateral, impose covenants, stage drawdowns, seek guarantees or reserve approval rights. Each device changes an obligation or the allocation of loss. A lower probability of default does not automatically compensate for poor recovery, concentration, long maturity or a highly correlated portfolio. The product therefore encodes a theory of behaviour, information and recourse, not merely an interest rate.
The underwriting decision compresses a large evidence set into a small number of authorised consequences: decline, approve, approve with conditions, request more evidence or escalate. Compression creates accountability. The institution should be able to reconstruct which facts supported the decision, which policy applied, which assumptions were modelled, who exercised judgement and what conditions became contractual. Without that chain, information has been summarised but not transformed into a defensible banking decision.
Payments and guarantees transform the quality of an obligation
A payment does not create the underlying purchase, salary or debt. It changes the state of that obligation by moving a recognised claim under shared rules. Before settlement, the payer may have issued an instruction and the payee may have an expectation. After final settlement, the relevant system treats the transfer as completed and limits revocation according to its rules. The economic amount may be unchanged while its legal and operational status changes completely.
A guarantee makes this substitution even clearer. A supplier may distrust a buyer's future promise but accept a bank's undertaking. The bank has not removed the buyer's performance risk. It has interposed its own balance sheet, information process and legal obligation, then charged for carrying that contingent exposure. Trade finance, letters of credit and standby facilities are product families built around this transformation of counterparty quality.
These examples show why “moving money” is too narrow a description of banking operations. The system also moves priority, finality, recourse and responsibility. A transfer with the wrong beneficiary identity, a guarantee with unauthorised wording or a credit line drawn after expiry can be fully funded and still invalid. The obligation ledger therefore determines what the funds ledger is allowed to do.
A minimal worked example: one loan, four transformations
A bakery needs £80 for an oven. Its cash will arrive over three years as bread is sold. Bank A approves the facility and credits an £80 deposit to the bakery. At that moment, Bank A records an £80 loan asset and an £80 deposit liability. The Bank of England's account of modern money creation emphasises this simultaneous balance-sheet expansion: a commercial bank does not mechanically wait for a particular saver’s deposit before creating the loan and matching deposit. Lending is nevertheless constrained by capital, liquidity, funding cost, risk appetite, expected profitability and monetary conditions. [1]
The bakery pays the oven supplier, which uses Bank B. Bank A reduces the bakery's deposit and transfers reserves through the payment system. Bank B receives reserves and credits the supplier's deposit. The loan remains at Bank A, but the newly created deposit may have moved elsewhere. Bank A has therefore transformed future bakery cash flows into present purchasing power, accepted credit risk, consumed liquidity for settlement and created a contract that must be serviced for years.
Information transformation occurs before and after approval. The bank turns accounts, cash-flow forecasts, proprietor history, collateral and sector conditions into an estimate of repayment capacity. This is not merely data collection. The institution must decide which facts are authoritative, which forecasts are assumptions and which adverse scenarios could invalidate the conclusion. Leland and Pyle argued that intermediaries can arise as a response to information asymmetry, while Diamond's delegated-monitoring theory explains why one intermediary may monitor borrowers on behalf of many ultimate funders. [6] [4]
Thought experiment two: the city of perfect information
Now imagine a city in which every borrower's future cash flows, effort and assets are public and perfectly verifiable. Keep preferences over time unchanged. A saver still wants access before a factory project matures, but there is no hidden information and no costly monitoring. Direct lending becomes easier because every investor can price the same observable risk.
One causal feature has changed: information asymmetry. The value of screening and delegated monitoring falls sharply. Yet the desire to exchange a liquid claim for a long-lived investment remains. This thought experiment separates two explanations that are often bundled together. Banks may economise on information and monitoring, and they may create liquidity across time. Neither mechanism alone explains every product or institution.
A good domain model preserves this separability. It lets an architect ask whether a process exists because information is private, because cash-flow dates differ, because losses must be pooled, because settlement needs finality, or because the public needs confidence in a promise. Different answers imply different data, controls and automation.
The clocks inside a bank
Time in banking is not a date column. Several clocks govern the same claim, and each can move while the others stand still. A loan may be contractually current today, economically weakened by new information, settled through yesterday's payment batch, and reported under an accounting period that closes next week. Systems fail when they flatten those clocks into one status.
The first is the contract clock: payment dates, rate resets, draw periods, covenants, grace periods, maturity and legal expiry. The second is the liquidity clock: when cash can leave, when collateral can be monetised and how quickly funding can be replaced. The third is the settlement clock: value date, cut-off, clearing, irrevocability and finality. The fourth is the risk-recognition clock: when new evidence should alter expected loss, limits, pricing or treatment. The fifth is the reporting clock: the as-of time, consolidation boundary and policy version under which a number becomes official.
Liquidity is a timing property, not a synonym for solvency
A bank can have assets worth more than its liabilities and still fail to meet a payment today. Conversely, it can have abundant cash while expected losses have eroded its economic capital. The distinction is elementary but operationally decisive. Solvency asks whether the value of assets can absorb obligations and losses. Liquidity asks whether acceptable means of payment are available when claims fall due.
For a horizon h, a simple cash-timing gap is:
I(h) is contractually or behaviourally expected cash inflow by horizon h; O(h) is cash outflow that may be demanded by the same horizon. A negative gap is not automatically failure. It must be covered by liquid assets, reliable funding, collateral capacity or central-bank access under applicable rules.
Basel's Liquidity Coverage Ratio addresses short-horizon resilience by requiring a stock of high-quality liquid assets against stressed net cash outflows over thirty days. The Net Stable Funding Ratio addresses a longer horizon by relating available stable funding to the liquidity characteristics and residual maturities of assets and off-balance-sheet exposures. [9] [8] These standards are more specific than the simple equation above, but their existence proves the conceptual point: cash timing deserves its own control system.
Risk recognition is an information-time transformation
Credit risk is not a fixed label attached at origination. New payment behaviour, customer accounts, collateral values, sector conditions and macroeconomic scenarios change the distribution of future cash flows. A common explanatory decomposition is:
PD is probability of default, LGD is loss given default, and EAD is exposure at default. Each term is conditional on definitions, horizon, data and model. The formula is simple; deciding when its inputs should change is not.
IFRS 9's expected-credit-loss model was designed to recognise losses more promptly than the prior incurred-loss approach and requires estimates to be updated using relevant available information. [11] This makes risk recognition a temporal information problem. The institution must know not only the estimate but also its observation date, scenario set, model version, source lineage and applicability.
BCBS 239 reaches the same issue from the reporting side. Its principles call for governance, appropriate data architecture, accuracy, completeness, timeliness and adaptability in risk data aggregation. [10] A risk number without those properties may be precise in format while unreliable in decision use.
Risk is reallocated, not made to disappear
The phrase “risk transformation” can sound as though the bank converts danger into safety. The more exact claim is that it changes who bears loss, when loss becomes visible and which resources stand in front of whom. Four operations recur.
First, selection changes the pool by accepting some exposures and refusing others. Second, pooling and diversification can make idiosyncratic outcomes more predictable when losses are not too correlated. Third, buffering places provisions, earnings and capital between asset losses and senior claims. Fourth, transfer uses collateral, guarantees, insurance, hedges, syndication or securitisation to move part of the exposure to another balance sheet.
None of these operations is free. Selection depends on evidence and can exclude worthy borrowers. Diversification fails when a common shock moves many exposures together. Collateral may fall in value exactly when default rises. A hedge introduces counterparty, basis, liquidity and operational risk. Securitisation can disperse credit exposure while weakening information about who ultimately bears it. Every risk reduction should name the residual risk and its new owner.
Consider two portfolios with the same expected loss. In the first, ten independent small borrowers may fail separately. In the second, ten borrowers depend on the same commodity price. The average loss estimate can match while the second portfolio has a much heavier joint tail. The bank's capital problem is therefore not exhausted by the expected-loss formula. In simplified economic terms, expected loss should be recognised and priced, while capital supplies loss-absorption capacity for adverse outcomes beyond the centre of the distribution. Basel's capital framework formalises several dimensions of this problem through risk-based requirements and a leverage backstop. [16]
Risk transformation also creates governance questions. A model may estimate PD, but a committee sets risk appetite. A collateral system may report value, but legal enforceability determines recoverability. A portfolio can remain within individual limits while breaching concentration tolerance. The output needed by management is not a score alone. It is an exposure view linked to assumptions, limits, mitigants, dependencies and actions.
flowchart TD A["The transformation engine"] --> B["Why products emerge from<br/>mismatches"] B --> C["The clocks inside a bank"] C --> D["How trust is manufactured"] D -. "re-test" .-> A classDef first fill:#0a1424,stroke:#B96D00,stroke-width:2px,color:#e6f3ff classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff class A first class B,C,D step
How trust is manufactured
Trust sounds psychological, but banking trust is largely institutional. A customer does not inspect the mortgage book before accepting a card payment. The merchant accepts the claim because law, accounting, settlement systems, prudential controls, supervision, deposit protection, operational routines and recovery arrangements make the claim usable without continuous bilateral investigation.
The Bank of England describes modern money as a set of IOUs and notes that bank deposits are special because people trust them to be accepted in exchange. [2] The word trust should not hide the mechanism. A trusted claim is a promise supported by enough observable structure that strangers can act on it without re-underwriting the whole institution.
That structure is layered. Identity and authority establish who may instruct an action. Contract law specifies obligations. Capital absorbs losses. Liquidity supports timely payment. Settlement rules define when transfer is final and no longer revocable. Data and reporting make risk visible. Operational resilience keeps critical services running through disruption. Deposit insurance protects covered depositors, while resolution regimes aim to preserve vital functions and allocate losses when a bank is no longer viable.
The Principles for Financial Market Infrastructures require clear and certain final settlement, at least by the end of the value date and preferably intraday or in real time where appropriate. [12] That requirement is about obligation transformation: before finality, parties may still face revocation or settlement risk; after finality, the system recognises a completed transfer under its rules.
The International Association of Deposit Insurers' core principles provide a benchmark for effective deposit-insurance systems. The Financial Stability Board's Key Attributes aim to make orderly resolution possible while maintaining vital economic functions and allocating losses according to the applicable hierarchy rather than relying on open-ended public solvency support. [13] [14] These arrangements do not make failure impossible. They change what depositors and counterparties can rationally expect when failure occurs.
Operational continuity belongs in the same trust stack. The Basel Committee defines operational resilience around a bank's ability to deliver critical operations through disruption. [15] A bank whose balance sheet is sound but whose payment, identity or ledger services are unavailable has failed a time-bound obligation. Trust therefore depends on the ability to perform, not only the ability eventually to pay.
Three characteristic breaks in coherence
The three-ledger model becomes useful when it predicts recognisable failures. The first break is between funds and obligations. A payment gateway times out after submitting an instruction, so the workflow does not know whether value moved. Retrying without readback can pay twice. The remedy is not better language reasoning. It is an idempotent instruction, a unique business key, authoritative status enquiry and an effect receipt.
The second break is between information and obligations. A hardship arrangement is approved, but an old arrears flag remains in a summary used by collections. The funds ledger may be accurate and the contract may be enforceable, yet the bank applies the wrong treatment because current entitlement was reconstructed from stale narrative. The remedy is bitemporal state, supersession, source lineage and a decision-time query against the authoritative case and account systems.
The third break is between funds and information. A portfolio appears well capitalised because collateral values, default estimates or counterparty groupings are stale. Nothing in the arithmetic engine is necessarily wrong. The information feeding it no longer describes the exposure. Reconciliation must therefore include semantic and temporal checks, not only equality of totals.
These failures have different owners. Treasury manages liquidity and funding, risk functions challenge exposure and models, operations control settlement and servicing, legal functions define enforceability, technology preserves state and recovery, and business owners hold customer outcomes. A cross-cutting system should not blur those responsibilities. It should make the hand-offs and receipts visible enough that each owner can prove its part of the promise.
A mortgage as a coupled transformation
Consider a mortgage from application through servicing. The customer sees one product. The bank operates a chain of transformations whose evidence and authority change at each stage.
At application, identity, income, expenditure, liabilities, property and purpose arrive as documents, declarations and third-party data. The first task is not to “predict approval”. It is to bind evidence to the right people, legal entities, property and point in time. A salary figure without its period, currency, employer and provenance is not yet decision-grade information.
Underwriting turns evidence into a bounded view of affordability, collateral, creditworthiness and policy fit. Some steps are calculations, some are verified lookups, some are model estimates and some require judgement. The output is a proposal with conditions, not yet a live obligation. The offer and acceptance stage converts that proposal into a contract, specifying principal, rate, term, security, repayment schedule, conditions precedent and remedies.
At completion, funds and obligations move together. The bank must confirm identity, authority, signed documents, property and legal conditions, then release value through a payment process that has cut-offs and finality. A correct credit decision does not authorise a payment by itself. The obligation ledger must say that the conditions for disbursement are satisfied and the actor has the right to cause the effect.
Servicing then reopens the information problem. Payments arrive, rates reset, balances amortise, customer circumstances change and collateral may be revalued. A missed payment can mean oversight, operational error, temporary hardship or deterioration. The correct treatment depends on current facts, contract, regulation, policy and prior commitments. Risk recognition may change before contractual default. The bank must preserve the history while reconstructing current state.
This lifecycle reveals why a language model is not the banking system. It may extract documents, identify contradictions, draft questions or explain an outcome. It does not thereby gain authority to bind the customer, book the asset, release funds, change a rate, waive a covenant or report a regulatory status. Those effects require typed actions against authoritative state and accountable decision rights.
Most AI changes the information transformation before it changes the economic transformation. That is valuable, but it should be described accurately. A credit copilot may reduce the cost of gathering and presenting evidence. It has not altered the legal maturity of the loan, the liquidity profile of funding, the capital consumed, the settlement mechanics or the identity of the accountable approver.
The banking transformation canvas
The practical test is simple: before naming a model or workflow, describe the mismatch the process exists to manage. Then identify its clocks, authoritative state, obligation, loss channel and evidence. This converts a vague banking “use case” into an architecture problem that can be tested.
| Process | Primary mismatch | Critical clock | Authoritative state | Invariant before effect | Useful machine role |
|---|---|---|---|---|---|
| Current-account payment | Usable claim must become final transfer | Cut-off, value date, finality | Ledger balance, holds, identity and entitlement | Authorised instruction, sufficient available funds, unique execution | Fraud signal, exception explanation, routing proposal |
| Mortgage origination | Long-lived asset funded and priced today | Evidence date, offer expiry, completion, maturity | Verified customer, property, income, policy and facility state | Policy, affordability, capital, conditions and approval authority | Extraction, evidence assembly, contradiction detection, memo drafting |
| Credit-line draw | Customer buys contingent future liquidity | Availability period and draw time | Limit, utilisation, covenants, blocks and authority | Facility live, headroom available, conditions satisfied | Document interpretation and anomaly triage |
| Hardship treatment | Contractual claim must adapt to changed capacity | Current customer circumstances and treatment period | Live account, verified hardship evidence, prior commitments | Eligible treatment, accountable approval, downstream suppression | Conversation summary, option comparison, explanation draft |
| Guarantee issuance | Bank substitutes its credit for a customer's promise | Issue, claim window, expiry | Facility, wording, beneficiary, limits and collateral | Exact text approved, authority valid, exposure within limit | Clause comparison and discrepancy detection |
Seven questions before an automation decision
- Which mismatch creates the process? Name time, liquidity, information, risk or trust explicitly.
- Which customer or counterparty promise must remain true? State it in operational language.
- Which clock governs the decision? Contract, settlement, liquidity, risk recognition or reporting may differ.
- Which state is authoritative at that clock? A document summary is rarely the same as live account state.
- What irreversible or difficult-to-reverse effect follows? Move value, bind the bank, change treatment, report or communicate.
- Who may propose, approve and execute? Connection to a tool is not authority to use it.
- What receipt proves the intended outcome occurred exactly once? An accepted command is not an observed effect.
This sequence changes technology selection. If the key burden is an exact balance or eligibility threshold, use deterministic retrieval and calculation. If it is ambiguity in documents, use probabilistic extraction with evidence links. If it is an enforceable effect, place a typed action contract and authority check between proposal and execution. If the outcome can be uncertain, design readback, idempotency and recovery before automating the happy path.
Control ownership follows the invariant
The canvas also prevents a common organisational mistake: assigning the whole process to whichever team owns the newest interface. The owner of a conversational channel does not own deposit entitlement. The model team does not own credit policy. The workflow team does not decide settlement finality. The platform team may provide reusable controls, but the domain owner remains accountable for the promise made to the customer.
A useful architecture decision record should therefore name one owner for each invariant. Treasury owns the liquidity assumptions used for a draw. Credit risk owns the approved risk methodology and limit interpretation. Operations owns the booking and settlement procedure. Legal or product governance owns contract wording and effective terms. Technology owns reliable execution, observability and recovery. The accountable business decision-maker owns the final use of judgement.
This separation is not bureaucracy added after design. It is how the institution keeps transformations coherent when systems, models and policies change at different speeds. A new model version should not silently alter contractual eligibility. A policy change should not reclassify historical decisions without an effective-time rule. A core migration should not change the meaning of “available balance”. The transformation canvas gives each change a set of invariants to test.
stateDiagram-v2 [*] --> Claim state "Three ledgers, not one balance" as Claim state "Thought experiment one: the<br/>vault and the bank" as Test state "Deposits transform uncertainty<br/>about spending time" as Revision Claim --> Test: expose mechanism Test --> Decision: evidence survives Test --> Revision: rival survives Revision --> Claim: narrow or rebuild Decision --> [*]
Executable artefact: a coupled transformation ledger
The following Python programme is deliberately small. It checks four gates before accepting a synthetic facility: capital, liquidity, information freshness and contractual authority. The point is not to reproduce Basel or accounting rules. It is to show that a financially affordable case can still be institutionally invalid, and that a solvent bank can still fail a cash-timing gate.
The artefact turns the central claim into a falsifiable mechanism: acceptance requires all relevant ledgers to agree, not merely a favourable risk score.
"""Synthetic banking transformation ledger.
The example checks four coupled invariants before a bank accepts a case:
1. capital can absorb the expected loss;
2. liquid assets cover modelled 30-day outflows;
3. decision evidence is current enough for the policy;
4. the proposed effect is authorised and contractually well formed.
All values are synthetic. This is an educational mechanism model, not a
regulatory calculator and not financial advice.
"""
from __future__ import annotations
from dataclasses import dataclass, asdict
from datetime import date
from typing import Dict, List
@dataclass(frozen=True)
class Policy:
minimum_capital_ratio: float = 0.10
minimum_liquidity_ratio: float = 1.00
maximum_evidence_age_days: int = 90
@dataclass(frozen=True)
class BankState:
equity: float
risk_weighted_assets: float
liquid_assets: float
thirty_day_outflows: float
@dataclass(frozen=True)
class Case:
name: str
exposure_at_default: float
probability_of_default: float
loss_given_default: float
risk_weight: float
immediate_cash_outflow: float
additional_thirty_day_outflow: float
evidence_as_of: date
decision_date: date
authorised: bool
signed_obligation: bool
@dataclass(frozen=True)
class GateResult:
gate: str
passed: bool
observed: str
required: str
@dataclass(frozen=True)
class DecisionReceipt:
case: str
decision: str
expected_loss: float
capital_ratio_after: float
liquidity_ratio_after: float
evidence_age_days: int
gates: List[GateResult]
def to_dict(self) -> Dict[str, object]:
data = asdict(self)
data["gates"] = [asdict(g) for g in self.gates]
return data
def evaluate_case(state: BankState, case: Case, policy: Policy) -> DecisionReceipt:
"""Evaluate one synthetic case and return an auditable decision receipt."""
if not 0 <= case.probability_of_default <= 1:
raise ValueError("probability_of_default must be between 0 and 1")
if not 0 <= case.loss_given_default <= 1:
raise ValueError("loss_given_default must be between 0 and 1")
if case.decision_date < case.evidence_as_of:
raise ValueError("evidence cannot be dated after the decision")
expected_loss = (
case.exposure_at_default
* case.probability_of_default
* case.loss_given_default
)
equity_after = state.equity - expected_loss
rwa_after = state.risk_weighted_assets + (
case.exposure_at_default * case.risk_weight
)
capital_ratio_after = equity_after / rwa_after if rwa_after else float("inf")
liquid_assets_after = state.liquid_assets - case.immediate_cash_outflow
outflows_after = state.thirty_day_outflows + case.additional_thirty_day_outflow
liquidity_ratio_after = (
liquid_assets_after / outflows_after if outflows_after else float("inf")
)
evidence_age_days = (case.decision_date - case.evidence_as_of).days
gates = [
GateResult(
"capital",
capital_ratio_after >= policy.minimum_capital_ratio,
f"{capital_ratio_after:.3f}",
f">= {policy.minimum_capital_ratio:.3f}",
),
GateResult(
"liquidity",
liquidity_ratio_after >= policy.minimum_liquidity_ratio,
f"{liquidity_ratio_after:.3f}",
f">= {policy.minimum_liquidity_ratio:.3f}",
),
GateResult(
"information",
evidence_age_days <= policy.maximum_evidence_age_days,
f"{evidence_age_days} days old",
f"<= {policy.maximum_evidence_age_days} days old",
),
GateResult(
"obligation",
case.authorised and case.signed_obligation,
f"authorised={case.authorised}, signed={case.signed_obligation}",
"authorised=True, signed=True",
),
]
return DecisionReceipt(
case=case.name,
decision="ACCEPT" if all(g.passed for g in gates) else "DECLINE_OR_ESCALATE",
expected_loss=round(expected_loss, 4),
capital_ratio_after=round(capital_ratio_after, 4),
liquidity_ratio_after=round(liquidity_ratio_after, 4),
evidence_age_days=evidence_age_days,
gates=gates,
)
def print_receipt(receipt: DecisionReceipt) -> None:
print(f"\n{receipt.case}: {receipt.decision}")
print(f" expected loss: {receipt.expected_loss:.2f}")
print(f" capital ratio after: {receipt.capital_ratio_after:.3f}")
print(f" liquidity ratio after: {receipt.liquidity_ratio_after:.3f}")
for gate in receipt.gates:
marker = "PASS" if gate.passed else "FAIL"
print(f" [{marker}] {gate.gate}: {gate.observed} (required {gate.required})")
def main() -> None:
policy = Policy()
state = BankState(
equity=18.0,
risk_weighted_assets=100.0,
liquid_assets=35.0,
thirty_day_outflows=20.0,
)
positive = Case(
name="Current evidence, authorised small-business facility",
exposure_at_default=10.0,
probability_of_default=0.03,
loss_given_default=0.45,
risk_weight=0.75,
immediate_cash_outflow=4.0,
additional_thirty_day_outflow=5.0,
evidence_as_of=date(2026, 6, 30),
decision_date=date(2026, 8, 15),
authorised=True,
signed_obligation=True,
)
stale_and_unsigned = Case(
name="Financially affordable, but stale and unsigned",
exposure_at_default=10.0,
probability_of_default=0.03,
loss_given_default=0.45,
risk_weight=0.75,
immediate_cash_outflow=4.0,
additional_thirty_day_outflow=5.0,
evidence_as_of=date(2025, 12, 31),
decision_date=date(2026, 8, 15),
authorised=True,
signed_obligation=False,
)
solvent_but_illiquid = Case(
name="Capital remains adequate, but cash timing fails",
exposure_at_default=2.0,
probability_of_default=0.01,
loss_given_default=0.20,
risk_weight=0.50,
immediate_cash_outflow=18.0,
additional_thirty_day_outflow=8.0,
evidence_as_of=date(2026, 8, 1),
decision_date=date(2026, 8, 15),
authorised=True,
signed_obligation=True,
)
for candidate in (positive, stale_and_unsigned, solvent_but_illiquid):
print_receipt(evaluate_case(state, candidate, policy))
if __name__ == "__main__":
main()
Assumptions and expected interpretation
The capital ratio and liquidity ratio are educational simplifications, not regulatory calculations. Expected loss uses the common PD × LGD × EAD decomposition. Evidence freshness is represented by one policy threshold, although real systems apply field-specific validity, event-driven refresh and source quality. The obligation gate requires both authority and a signed obligation.
The positive case passes all gates. The second case has the same capital and liquidity economics but fails because evidence is stale and the obligation is unsigned. The third remains above the synthetic capital threshold but fails the liquidity gate. Those outcomes isolate the three-flow thesis.
Current evidence, authorised small-business facility: ACCEPT
[PASS] capital: 0.166 (required >= 0.100)
[PASS] liquidity: 1.240 (required >= 1.000)
[PASS] information: 46 days old (required <= 90 days old)
[PASS] obligation: authorised=True, signed=True
Financially affordable, but stale and unsigned: DECLINE_OR_ESCALATE
[PASS] capital: 0.166
[PASS] liquidity: 1.240
[FAIL] information: 227 days old
[FAIL] obligation: signed=False
Capital remains adequate, but cash timing fails: DECLINE_OR_ESCALATE
[PASS] capital: 0.178
[FAIL] liquidity: 0.607
[PASS] information: 14 days old
[PASS] obligation: authorised=True, signed=TrueWhere the transformation lens stops
This framework is a domain map, not a legal definition of a bank. Jurisdictions draw boundaries around deposit taking, lending, payments, securities, insurance, money issuance and systemic importance differently. A credit union, mutual bank, Islamic bank, narrow bank, investment bank and central bank can distribute the transformations in different ways. Some financial functions are performed by capital markets, funds, insurers, fintech firms and public institutions.
The lens also does not claim that maturity transformation is always desirable or that every balance-sheet mismatch should be preserved. Narrow-banking proposals deliberately reduce some forms of transformation. Securitisation moves assets and risk across entities. Central-bank facilities alter liquidity options. Deposit insurance can reduce run incentives while changing monitoring incentives. Regulation changes the feasible design space. Diamond and Rajan explicitly show a trade-off in which stabilisation can affect liquidity creation, not a free improvement along every dimension. [5]
A second boundary concerns measurement. The figures in this article are conceptual or synthetic. They do not estimate the optimal capital, liquidity, evidence-age or automation threshold for a real institution. Those values depend on product, customer population, currency, legal entity, market access, policy, data quality and risk appetite.
A third boundary concerns causality. The three-ledger model is a practitioner synthesis that organises published mechanisms and official control domains. It has not been validated as a complete ontology of banking. An observation that would weaken it is a consequential banking process whose failures cannot be explained by funds, information, obligations or their timing and authority. Such a counterexample should extend the model rather than be renamed to fit it.
Design from the mismatch, not the product catalogue
The familiar bank is a surface: accounts, loans, cards, branches and apps. Beneath that surface is a machine for making unlike claims coexist. It brings future cash flows into the present, turns illiquid assets into usable liabilities, converts private evidence into monitored decisions, distributes losses across capital and portfolios, and makes promises credible enough for strangers to accept.
The decisive architecture shift is to model the transformation before the workflow. Ask what timing mismatch is being bridged, what information is being compressed, what risk is being retained or transferred, what obligation is being created, and what institutional supports make the claim trustworthy. Then identify the clocks, authoritative state, decision rights, evidence and recovery path.
This changes the automation programme. A model should not be given a product-shaped task such as “process a mortgage” or “handle a payment”. It should receive a bounded information problem inside a system that already knows who may act, what state is current, which limits apply, when settlement is final and how to verify the result. The economic transformation remains governed even when parts of the information transformation become probabilistic.
The bank's deepest asset is therefore not data, capital or technology in isolation. It is the ability to keep funds, information and obligations coherent across time. When that coherence holds, long-dated and uncertain promises become usable now. When it breaks, a product name offers no protection.