Money movement and the risk map
Follow a payment from a tap on a screen to a settled obligation.
Maya buys a $40 lamp from a marketplace called Lantern. The app shows a cheerful check mark. Behind that check mark, several firms now have promises to keep. One may ship a lamp, another may owe money, and another may face a dispute weeks later. Risk engineering starts by asking what the check mark actually means. Lantern and all people, amounts, thresholds, and records in this book are fictional teaching examples.
Messages are not money
A payment message describes an instruction or a state. A ledger records obligations. Settlement discharges obligations through the relevant system. These events can occur at different times. Treating all three as one success flag makes support, reconciliation, and risk reporting disagree.
For Lantern, keep the order state separate from the payment state. An accepted authorization can justify a stock reservation without proving that cash reached the merchant. Give each state a named owner and a clear event that changes it. The useful question is not whether the API returned green. It is which obligation changed, for whom, and on what evidence.
Lantern sells a £100 ticket for a merchant. The customer sees a success screen, the merchant sees an order, and the platform sees a payment identifier. Those three observations may describe the same purchase, but none alone proves that the merchant can withdraw £100. Fees, settlement timing, reserves, and other obligations can change the amount and timing of available funds. A risk engineer follows each claim back to the system that can support it.
This is why a payment model usually needs several state machines. The order can be cancelled while the payment is captured. A refund can be accepted for processing while the customer has not yet received it. Collapsing these facts into one green status makes a screen simple and an investigation difficult. Each state needs an owner, an event that changes it, and a defined effect on money.
Inside the mechanism. A useful payment record has separate instruction, financial, and availability states. For example, instruction accepted, settlement unconfirmed, and payout held can all be true at once. Preserve the external reference and the last authoritative observation for each state. A timeout means the caller lacks a response; it does not establish that the receiver did nothing. This distinction determines whether the next safe action is a query, a retry with the same business key, or an investigation.
A concrete example. A marketplace groups lamp orders into one payout batch. The order system, processor, and ledger report different states for the same commercial activity. The batch begins with $48,000 of instructions and $46,080.00 of captured value. At the observation cutoff, $1,382.40 remains pending. After the stated refunds, fees, and restrictions, $37,094.40 is available for payout. The unresolved instruction count is 2; an unknown external result is handled separately from a known decline.
When the assumption fails. Settlement confirmation arrives after the merchant availability job. Gate availability on reconciled financial evidence and retain unknown external outcomes. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A marketplace groups lamp orders into one payout batch. The order system, processor, and ledger report different states for the same commercial activity.
- InstructionCustomer asks to pay
- ObligationParties record what they owe
- SettlementRelevant accounts exchange value
- API accepted
- Request passed an interface check
- Funds settled
- Evidence supports a financial state
Lantern payment record
Illustrative data; not a real customer record or a prescribed policy.
- Orderlamp-104
Commercial reference
- Paymentauthorized
Payment state only
- Deliverynot shipped
Separate fulfillment state
Settlement and delivery still need their own evidence
The authorization was accepted. Settlement and delivery still need their own evidence.
- Failure mode 1avoid
- The merchant received final cash. Authorization does not establish this.
- Failure mode 2avoid
- The customer cannot dispute. Later rights depend on rail and rules.
- Failure mode 3avoid
- The lamp was delivered. A payment event says nothing about delivery.
Map the participants
A card payment can involve a customer, merchant, gateway, processor, acquirer, network, and issuer. A fintech may fill more than one role, or outsource parts of a role. Brand names are less useful than responsibilities. Draw the legal and operational chain before assigning a loss.
Use a responsibility map with four questions: who authenticates the actor, who authorizes the payment, who holds the balance, and who handles a return or dispute? Add contracts as evidence. A vendor that performs screening does not automatically own the customer relationship or every compliance duty. Missing ownership is an operational defect, even when every individual service works.
Inside the mechanism. Draw each handoff with four labels: who sends the instruction, who owes the money, who holds the evidence, and who can correct an error. Those roles need not belong to one company. The customer-facing platform may need to explain a return that only its processor has observed. A complete handoff therefore carries a stable reference, an acceptance record, an accountable destination, and an exception path. A successful HTTP response proves only the contract that endpoint actually offers.
A concrete example. The platform owns the checkout screen while several partners own parts of the payment chain. A case can fall between those organizations even when each individual service responds. The case identifies 1,200 eligible records from a source population of 1,500. The required workflow completes for 1,164, but 17 completed records miss the illustrative internal target. Another 36 remain incomplete. Communication evidence covers 1,152 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. A return reaches the processor but does not reach the merchant-risk queue. Assign a durable handoff, accountable owner, and evidence of queue acceptance. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
The platform owns the checkout screen while several partners own parts of the payment chain. A case can fall between those organizations even when each individual service responds.
- CustomerInitiates a purchase
- MerchantSupplies the product
- Financial partnersAuthorize and move value
- Provider function
- Work a service performs
- Accountability
- Duty retained under law and contract
Partner map extract
Illustrative data; not a real customer record or a prescribed policy.
- Gatewaymessage routing
Does not imply deposit custody
- Issuercard account
Customer relationship
- Acquirermerchant acceptance
Merchant-side role
It connects the function to its accountable owner
A responsibility map tied to agreements. It connects the function to its accountable owner.
- Failure mode 1avoid
- A list of logos. Branding does not allocate duties.
- Failure mode 2avoid
- The fastest API response. Latency does not establish ownership.
- Failure mode 3avoid
- The largest team. Headcount does not define the contract.
Separate the risk families
Fraud asks whether an actor or claim is deceptive. Credit asks whether an obligation will be paid. Liquidity asks whether available funds arrive in time. Compliance asks whether the activity meets applicable duties. Operational risk includes failures in people, systems, and process. The same event can enter several families.
A merchant that sells concert tickets may be honest, profitable on paper, and still unable to refund customers after a cancellation. Labeling that entire loss fraud hides the funding problem. Assign a primary loss cause and record contributing causes separately. This helps teams choose controls that address the cause instead of improving a dashboard label.
A useful loss map separates the cause, the immediate exposure, and the final bearer of loss. A stolen credential can cause a fraudulent purchase; a contract can allocate the resulting loss to a merchant; a failed merchant can leave the platform with credit exposure. The risk families overlap because they describe different parts of this chain. Classifying the event once and hiding the other links can send it to the wrong control owner.
Inside the mechanism. Classify a loss by mechanism before aggregating it. A genuine merchant unable to repay a refund creates a different problem from a stolen account requesting a payout. One incident can involve both. Keep the event facts and accounting loss separate from the analytical category so a later investigation can revise the cause without rewriting the money. This also prevents fraud, credit, and operational reports from each claiming the same dollar as a separate loss.
A concrete example. A ticket seller collects money months before an event. Cancellation creates a refund obligation that can outlast the seller’s cash. The case has $420,000 of exposure. Its stated one-year PD and LGD imply $9,240.00 of expected loss, while the cover analysis leaves $288,000.00 of stress exposure. Monthly cash coverage is 1.22×. These are separate measures: one describes an average under probability assumptions, one describes available cover, and one describes a period’s funding capacity.
When the assumption fails. The event is cancelled after the seller has paid suppliers. Measure unfulfilled obligations, eligible cover, and the ability to fund the weak month. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A ticket seller collects money months before an event. Cancellation creates a refund obligation that can outlast the seller’s cash.
- EventDescribe what happened
- CauseIdentify the loss mechanism
- ControlTarget that mechanism
- Fraud loss
- Deception drives the event
- Credit loss
- An obligation remains unpaid
Cancelled festival exposure
Illustrative data; not a real customer record or a prescribed policy.
- Intentno deception established
Avoid unsupported fraud labels
- Obligationrefund tickets
Money still owed
- Cashalready spent
Liquidity and credit concerns
Failure to pay does not require deception
Credit and liquidity exposure. Failure to pay does not require deception.
- Failure mode 1avoid
- Only identity fraud. The facts do not show a false identity.
- Failure mode 2avoid
- Only network latency. The problem persists after messages arrive.
- Failure mode 3avoid
- No risk because the seller is honest. Honesty does not fund obligations.
Locate the point of no easy return
Controls become less useful when they run after the action they were meant to stop. A pre-payment check, a shipment hold, a payout delay, and a post-event investigation act at different points. Choose a control time from the harm you want to prevent.
Draw a timeline with the customer promise above it and the money movement below it. Mark the last practical moment for each intervention. A recall request after an instant payment is not a guaranteed reversal. Even when settlement is final, legal claims and investigations can continue. Technical finality and legal resolution answer different questions.
Inside the mechanism. The control point is the last practical moment at which the intended intervention can change the effect. A review after an irrevocable transfer can support recovery and investigation, but it cannot function as a pre-transfer stop. Measure the interval between evidence arrival, decision, and effect commitment. If the evidence regularly arrives after commitment, a lower model threshold will not repair the architecture. Move the control, change the promise, or state the recovery limitation.
A concrete example. Lantern promises prompt payouts while incoming funds still pass through several evidence states. A late control cannot recover an already released balance by changing a database label. The batch begins with $72,000 of instructions and $69,120.00 of captured value. At the observation cutoff, $2,073.60 remains pending. After the stated refunds, fees, and restrictions, $55,641.60 is available for payout. The unresolved instruction count is 2; an unknown external result is handled separately from a known decline.
When the assumption fails. Payout instructions leave before the funding source is confirmed. Move the intervention before release and give uncertain payments an owned recovery path. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
Lantern promises prompt payouts while incoming funds still pass through several evidence states. A late control cannot recover an already released balance by changing a database label.
- Before actionPrevent or request evidence
- During exposureLimit shipment or payout
- After lossInvestigate and seek recovery
- Prevention
- Acts before the harmful transfer
- Recovery
- Attempts to reduce an existing loss
Illustrative intervention clock
Illustrative data; not a real customer record or a prescribed policy.
- 09:00payee added
Verification opportunity
- 09:02payment sent
Value leaves sender
- 09:08recall requested
Recovery is uncertain
The check must precede the action it controls
Before release. The check must precede the action it controls.
- Failure mode 1avoid
- After a monthly report. The money may already be gone.
- Failure mode 2avoid
- Only after a complaint. That is detection after harm.
- Failure mode 3avoid
- At the next annual review. The timing misses the payment.
Write a decision contract
A risk decision needs an action, reason, scope, expiry, and owner. The word review without a queue owner is a polite way to lose a transaction. Define what the customer can do while the decision is pending and what happens if evidence never arrives.
A small contract might contain decision_id, payment_id, action, reason_codes, policy_version, decided_at, and expires_at. Store money in integer minor units with an explicit currency. Separate internal reasons from approved customer wording. A good decision record supports replay, support, audit, and appeal without exposing private signals to every reader.
Inside the mechanism. Represent a decision as an immutable event with subject, operation, permitted amount, currency, reason, evidence version, policy version, owner, and expiry. Store the recommended action and the action actually applied separately. A hold that expires requires an explicit next transition; it should not disappear merely because a cache entry expires. Link every later override or release to the original decision so the history explains both authority and outcome.
A concrete example. A review action pauses a payment but creates work for another team. The customer sees a pending status until that team makes a recorded decision. The case identifies 765 eligible records from a source population of 850. The required workflow completes for 742, but 11 completed records miss the illustrative internal target. Another 23 remain incomplete. Communication evidence covers 735 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. The decision contains no expiry or queue owner. Store the action, reason, scope, owner, expiry, and follow-up event as one contract. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A review action pauses a payment but creates work for another team. The customer sees a pending status until that team makes a recorded decision.
- InputIdentify the transaction and evidence
- DecisionRecord action and policy version
- Follow-throughAssign owner and expiry
- Bare score
- A number without an action contract
- Decision record
- An action with reasons and lifecycle
Decision specimen
Illustrative data; not a real customer record or a prescribed policy.
- Actionreview
No automatic shipment
- Ownermerchant-risk queue
Named responsibility
- Expiry30 minutes
Illustrative service target
Someone must act within a defined lifecycle
A queue owner and expiry. Someone must act within a defined lifecycle.
- Failure mode 1avoid
- A decorative risk badge. It does not route work.
- Failure mode 2avoid
- Only the model score. A score does not assign responsibility.
- Failure mode 3avoid
- The customer device color. It does not resolve ownership.
Chapter connections
Continue with Cards, authorization, and disputes to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.