A complete risk system: the Lantern case

Define the product and open promises

The proposed product accepts card and bank payments and offers earlier seller payouts. The new ticket category creates long delivery exposure. Document the legal entities, merchant-of-record arrangement, customer terms, funds flow, and accountable partners before designing a score.

The central exposure is clear: Lantern may release usable money while refund or return obligations remain. Fraud, credit, liquidity, and compliance controls all contribute, but none replaces the others. The launch scope should specify eligible merchants, supported rails, delivery assumptions, and the conditions that require a new review.

Lantern’s launch team can describe the product in one sentence: customers pay merchants now, merchants fulfill later, and eligible proceeds become available for payout under defined conditions. The short sentence contains several separate promises. The customer expects the right amount to reach the right merchant, the merchant expects accurate availability, and the platform must preserve records and respond when fulfillment fails.

The system case ties those promises to earlier chapters. Payment state tracks the movement request. The ledger records obligations. Underwriting sets permitted exposure. Fraud controls govern suspicious actions. AML and sanctions processes handle their distinct responsibilities. Treasury confirms usable funding, and operations owns unresolved events. No single score or vendor response replaces this division of work.

Inside the mechanism. Treat the product promise as a set of dated obligations. Rapid access to merchant proceeds can create exposure while funding, fulfillment, or dispute outcomes remain uncertain. Record the party responsible for each promise and the resources needed to keep it under stress. Product, risk, finance, and operations need the same definitions so a faster customer experience does not conceal a larger open obligation.

A concrete example. A platform can promise rapid merchant access to funds before the underlying transactions are final. The interval creates a funding and recovery exposure. The case has $740,000 of exposure. Its stated one-year PD and LGD imply $29,185.60 of expected loss, while the cover analysis leaves $343,000.00 of stress exposure. Monthly cash coverage is 1.32×. 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. Marketing shortens the payout promise without changing underwriting or liquidity capacity. Map the promise to loss timing, usable cover, and funding needs before changing limits. 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.

Follow a worked case3 conditions · 36 figures

A platform can promise rapid merchant access to funds before the underlying transactions are final. The interval creates a funding and recovery exposure.

Product promises and exposure: reference condition figure preview

01Reference conditionProduct promises and exposure

Product promises and exposure: failure and stress figure preview

02Failure and stressProduct promises and exposure

Product promises and exposure: controlled response figure preview

03Controlled responseProduct promises and exposure

Define the product and open promises Define the product and open promises — the distinction These concepts answer different questions. Read each definition in the context of the section. Home goods Shorter expected delivery cycle Advance tickets Longer correlated delivery obligation — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Define the product and open promises Launch brief Fictional teaching record. Underwriting condition. Launch brief Illustrative data; not a real customer record or a prescribed policy. New category event tickets Changed business model Payout before event Platform exposure Review trigger material delivery change Underwriting condition The control system must address the actual product — Fictional teaching record. Underwriting condition. Chapter sources · Open image

Define the product and open promises Define the product and open promises — control and failure modes The control system must address the actual product. The branches show why alternative designs fail. Control design Define the promise and exposure before the score. The control system must address the actual product. Failure mode 1 Reuse retail approval for all ticket sellers. The delivery risk differs. avoid Failure mode 2 Treat early payout as settled certainty. Open obligations remain. avoid Failure mode 3 Launch without role and funds mapping. Accountability gaps will surface later. avoid — The control system must address the actual product. The branches show why alternative designs fail. Chapter sources · Open image

Create the minimum decision and data contracts

Lantern records payment, order, merchant, and payout as separate entities. Each event has a stable ID, event time, knowledge time, currency, and version. The decision record links the evidence to the action and policy.

A compact teaching record below shows the intended relationship. It contains fictional references, not customer data. The application keeps raw identity evidence in restricted storage and uses references in the decision stream.

{
  "decision_id": "decision-204",
  "payment_id": "payment-811",
  "merchant_id": "merchant-52",
  "amount_minor": 4000,
  "currency": "USD",
  "action": "review",
  "policy_version": "payout-v3",
  "reason_codes": ["DELIVERY_EXPOSURE_REVIEW"]
}

Inside the mechanism. The minimum system needs stable contracts for identity, intent, decision, financial effect, evidence, and casework. Each contract has an authoritative writer, identifier, state model, and reconciliation path. Link them through a business action key without collapsing their meanings. A payment can be financially complete while a related investigation remains open; the data model must support both facts.

A concrete example. A product needs stable records for identity, payment intent, decision, ledger effect, case, and evidence. Each record has a responsible writer and reconciliation path. The case identifies 18,130 eligible records from a source population of 18,500. The required workflow completes for 17,586, but 264 completed records miss the illustrative internal target. Another 544 remain incomplete. Communication evidence covers 17,410 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. Teams use incompatible identifiers and cannot trace one customer action across systems. Define shared identifiers, state transitions, ownership, and the minimum audit fields. 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.

Follow a worked case3 conditions · 36 figures

A product needs stable records for identity, payment intent, decision, ledger effect, case, and evidence. Each record has a responsible writer and reconciliation path.

Minimum system contracts: reference condition figure preview

01Reference conditionMinimum system contracts

Minimum system contracts: failure and stress figure preview

02Failure and stressMinimum system contracts

Minimum system contracts: controlled response figure preview

03Controlled responseMinimum system contracts

Create the minimum decision and data contracts Create the minimum decision and data contracts — the distinction These concepts answer different questions. Read each definition in the context of the section. Order fulfilled Commercial promise completed Payout released Seller received value under the financial workflow — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Decision contract

Fictional educational excerpt / Not for execution

Decision contract

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

Paymentpayment-811
Source transaction
Actionreview
No automatic release
Policypayout-v3
Reproducible decision version

One success flag cannot explain the whole lifecycle

Fictional teaching record. Reproducible decision version. Chapter sources · Open image

Create the minimum decision and data contracts — control and failure modes

Control design

Link distinct entities through stable references. One success flag cannot explain the whole lifecycle.

Failure mode 1avoid: Put raw documents in every decision event. That spreads sensitive evidence.
Failure mode 2avoid: Use floating amounts without currency. Money loses a stable interpretation.
Failure mode 3avoid: Omit the policy version. Historical actions become difficult to explain.

One success flag cannot explain the whole lifecycle. The branches show why alternative designs fail. Chapter sources · Open image

Layer controls around the loss paths

Underwriting checks the seller’s model and capacity. Fraud controls assess account access, transaction evidence, and payout changes. AML monitoring compares activity with the relationship. Sanctions controls apply the relevant restrictions before prohibited activity proceeds. Treasury checks eligible liquidity.

For this case, an early payout requires the mandatory checks, a valid merchant scope, and available exposure capacity. The system reserves capacity atomically and uses an idempotent payout operation. Post-event reconciliation and monitoring remain necessary. Layering means each control addresses a distinct failure path; it does not mean every control repeats the same score.

Inside the mechanism. Map controls to loss paths and intervention points. Identity evidence, transaction decisions, exposure limits, reserves, and case review can overlap. Do not add their claimed benefits as though each prevented a separate loss. State which control changes the action, which limits severity, and which only improves detection or recovery. Evaluate the combined customer and financial outcome under a coherent population definition.

A concrete example. Identity checks, transaction controls, limits, reserves, and case review act at different points in the loss path. Their effects are not automatically independent or additive. The rule flags 1,058 of 32,000 mature platform transactions. Of those flags, 589 meet the synthetic target, giving 55.67% precision. It misses 147 target events. Under the stated cost assumptions, residual loss and operating friction total $39,652. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.

When the assumption fails. The risk report adds each control estimate and claims more prevented loss than was exposed. Trace each loss mechanism and distinguish overlapping evidence from incremental intervention. 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.

Follow a worked case3 conditions · 36 figures

Identity checks, transaction controls, limits, reserves, and case review act at different points in the loss path. Their effects are not automatically independent or additive.

Layered loss-path controls: reference condition figure preview

01Reference conditionLayered loss-path controls

Layered loss-path controls: failure and stress figure preview

02Failure and stressLayered loss-path controls

Layered loss-path controls: controlled response figure preview

03Controlled responseLayered loss-path controls

Layer controls around the loss paths Layer controls around the loss paths — the distinction These concepts answer different questions. Read each definition in the context of the section. Pre-release control Prevents or bounds the new exposure Post-release control Detects and resolves later developments — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Layer controls around the loss paths Payout gate Fictional teaching record. Concurrency-safe limit. Payout gate Illustrative data; not a real customer record or a prescribed policy. Merchant scope approved category Underwriting condition Screening valid required disposition Mandatory control Capacity reserved atomically Concurrency-safe limit Layering should add coverage rather than duplicate labels — Fictional teaching record. Concurrency-safe limit. Chapter sources · Open image

Layer controls around the loss paths Layer controls around the loss paths — control and failure modes Layering should add coverage rather than duplicate labels. The branches show why alternative designs fail. Control design Assign each control to a distinct loss path. Layering should add coverage rather than duplicate labels. Failure mode 1 Let a low fraud score override sanctions. Authority differs. avoid Failure mode 2 Use non-atomic capacity checks. Concurrent payouts can exceed limits. avoid Failure mode 3 Stop monitoring after release. Returns and customer obligations continue. avoid — Layering should add coverage rather than duplicate labels. The branches show why alternative designs fail. Chapter sources · Open image

Walk through a combined failure

During a busy evening, the screening service times out and the bank-payment return feed is delayed. Lantern applies the approved screening contingency to affected releases and marks return-history features unavailable. It does not convert missing returns into a clean history.

Operations receives a defined incident with the held population, partner contacts, and customer communication plan. After services recover, workers replay events idempotently, reconcile held payouts, and review any changed exposure. The recovery record includes unresolved cases. This walkthrough tests the interaction of controls rather than assuming each vendor failure occurs alone.

Consider a busy sales day when the screening provider slows down and merchant payouts are due. The team first applies the approved dependency-failure policy to affected new actions. It then separates payments with a known final decision from requests with an unknown outcome, preserves the original identifiers, and checks funding availability before releasing obligations. Customer messages describe the actual state. When the provider recovers, the team resolves the pending population and reconciles results. This combined event tests technical recovery, financial correctness, control coverage, and operational ownership at the same time.

Inside the mechanism. In the combined incident, stale features weaken decisions while a partner outage creates unknown payouts and review demand rises. The response first contains the risky effect, then classifies affected actions and restores required evidence. Reconciliation determines what can be replayed. Returning all services to green does not by itself resolve duplicate effects, missing holds, or customer messages issued during the incident.

A concrete example. A data delay, partner outage, and rising review queue can turn a small detection gap into a larger financial exposure. The response needs one coherent population of affected actions. 810 intended requests generate 850 processing attempts under this retry assumption. Capacity is 970 attempts per interval, and the critical path consumes 150 ms of a 230 ms budget. The request-based SLO view observes 100 bad requests against an illustrative allowance of 100. These measurements must be connected to the financial effect and control evidence before declaring recovery.

When the assumption fails. The platform retries unknown payouts while risk features are stale and reviewer capacity is reduced. Contain the relevant effects, restore required evidence, and reconcile actions before resuming. 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.

Follow a worked case3 conditions · 36 figures

A data delay, partner outage, and rising review queue can turn a small detection gap into a larger financial exposure. The response needs one coherent population of affected actions.

A combined platform incident: reference condition figure preview

01Reference conditionA combined platform incident

A combined platform incident: failure and stress figure preview

02Failure and stressA combined platform incident

A combined platform incident: controlled response figure preview

03Controlled responseA combined platform incident

Walk through a combined failure — the distinction

Unknown return history: Data feed is delayed
No returns observed with complete data: Different evidence state

These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Combined failure record

Fictional educational excerpt / Not for execution

Combined failure record

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

Screeningtimeout
Required control unavailable
Return feeddelayed
Feature quality degraded
Payoutheld under contingency
No invented clean result

Multiple failures must not create false clearance

Fictional teaching record. No invented clean result. Chapter sources · Open image

Define launch evidence and ongoing ownership

Lantern’s launch evidence includes a reviewed applicability map, merchant conditions, tested data coverage, decision replay, concurrency tests, settlement reconciliation, accessible customer messages, and an exercised incident process. Each item has an owner and a concrete acceptance result.

The final decision records remaining limitations, permitted rollout scope, stop conditions, and monitoring. A staged release can limit exposure while the team validates actual behavior. The textbook’s central lesson is visible here: a risk control is complete when the intended behavior has evidence across the full lifecycle. The next product change starts the same disciplined process again.

Inside the mechanism. Launch evidence should demonstrate ordinary operation, credible failure behavior, financial reconciliation, case capacity, and recovery. Each material promise needs an owner and an observable success condition. Keep unresolved limits visible and tie approval to the actual product scope. After launch, changes in volume, partners, terms, and customer activity can invalidate earlier evidence and require renewed review.

A concrete example. Launch evidence should show that the promised service works under normal and credible failure conditions. Ownership continues as volume, partners, and product scope change. The case identifies 1,463 eligible records from a source population of 1,540. The required workflow completes for 1,419, but 21 completed records miss the illustrative internal target. Another 44 remain incomplete. Communication evidence covers 1,405 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A launch checklist is signed while recovery, case capacity, and funds reconciliation remain untested. Require observable service evidence with named owners and repeat review after material change. 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.

Follow a worked case3 conditions · 36 figures

Launch evidence should show that the promised service works under normal and credible failure conditions. Ownership continues as volume, partners, and product scope change.