Money movement and the risk map

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.

Messages are not money — the flow

1. 01InstructionCustomer asks to pay
2. 02ObligationParties record what they owe
3. 03SettlementRelevant accounts exchange value

Messages are not money — the distinction

API accepted

• Request passed an interface check

Funds settled

• Evidence supports a financial state

Lantern payment record

Fictional educational excerpt / Not for execution

Lantern payment record

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Orderlamp-104

   Commercial reference

2. 2

   Paymentauthorized

   Payment state only

3. 3

   Deliverynot shipped

   Separate fulfillment state

Settlement and delivery still need their own evidence

Messages are not money — control and failure modes

Control design

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.

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.

Map the participants — the flow

1. 01CustomerInitiates a purchase
2. 02MerchantSupplies the product
3. 03Financial partnersAuthorize and move value

Map the participants — the distinction

Provider function

• Work a service performs

Accountability

• Duty retained under law and contract

Partner map extract

Fictional educational excerpt / Not for execution

Partner map extract

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Gatewaymessage routing

   Does not imply deposit custody

2. 2

   Issuercard account

   Customer relationship

3. 3

   Acquirermerchant acceptance

   Merchant-side role

It connects the function to its accountable owner

Map the participants — control and failure modes

Control design

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.

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.

Separate the risk families — the flow

1. 01EventDescribe what happened
2. 02CauseIdentify the loss mechanism
3. 03ControlTarget that mechanism

Separate the risk families — the distinction

Fraud loss

• Deception drives the event

Credit loss

• An obligation remains unpaid

Cancelled festival exposure

Fictional educational excerpt / Not for execution

Cancelled festival exposure

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Intentno deception established

   Avoid unsupported fraud labels

2. 2

   Obligationrefund tickets

   Money still owed

3. 3

   Cashalready spent

   Liquidity and credit concerns

Failure to pay does not require deception

Separate the risk families — control and failure modes

Control design

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.

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.

Locate the point of no easy return — the flow

1. 01Before actionPrevent or request evidence
2. 02During exposureLimit shipment or payout
3. 03After lossInvestigate and seek recovery

Locate the point of no easy return — the distinction

Prevention

• Acts before the harmful transfer

Recovery

• Attempts to reduce an existing loss

Illustrative intervention clock

Fictional educational excerpt / Not for execution

Illustrative intervention clock

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   09:00payee added

   Verification opportunity

2. 2

   09:02payment sent

   Value leaves sender

3. 3

   09:08recall requested

   Recovery is uncertain

The check must precede the action it controls

Locate the point of no easy return — control and failure modes

Control design

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.

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.

Write a decision contract — the flow

1. 01InputIdentify the transaction and evidence
2. 02DecisionRecord action and policy version
3. 03Follow-throughAssign owner and expiry

Write a decision contract — the distinction

Bare score

• A number without an action contract

Decision record

• An action with reasons and lifecycle

Decision specimen

Fictional educational excerpt / Not for execution

Decision specimen

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Actionreview

   No automatic shipment

2. 2

   Ownermerchant-risk queue

   Named responsibility

3. 3

   Expiry30 minutes

   Illustrative service target

Someone must act within a defined lifecycle

Write a decision contract — control and failure modes

Control design

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.

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.