Underwrite the merchant business

Merchant underwriting evaluates the business and the exposure created by processing for it. Identify the product, customer, delivery timing, refund promise, and payment flow. A business registration proves that an entity exists; it does not prove the entity can fulfill its promises.

Write the model in one sentence: this merchant collects this amount from these customers for this service at this time. Then test the sentence against the website, contracts, financial records, and transaction plan. If the explanation changes across documents, resolve the discrepancy before deciding which controls are suitable.

A merchant application often describes a product category. Underwriting needs the actual promise made to customers. A business that sells a book for immediate shipment has a different exposure timeline from one that sells a course beginning in six months. Both may have the same monthly payment volume, but the second holds more unfulfilled obligations at a given moment.

Lantern therefore maps order creation, customer payment, fulfillment, refund rights, and merchant payout on one timeline. The distance between collecting money and delivering value is a source of exposure. The analysis then asks what resources remain if the merchant stops trading during that interval. Revenue growth can make the business look stronger while increasing the amount the platform may need to return to customers.

Inside the mechanism. Start with what the customer buys and when the merchant finishes the promise. A digital download, annual subscription, travel booking, and future event ticket leave different open obligations. Measure unfulfilled value by cohort and expected completion date. Revenue received today may support obligations far into the future. The underwriting question is therefore not only whether sales are growing, but what the platform may owe if fulfillment stops at the worst point.

A concrete example. The merchant collects fees now for classes delivered over several months. The payment stream and the unfulfilled service obligation move on different schedules. The case has $690,000 of exposure. Its stated one-year PD and LGD imply $17,077.50 of expected loss, while the cover analysis leaves $504,000.00 of stress exposure. Monthly cash coverage is 1.33×. 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. New sales grow while the backlog of undelivered classes also grows. Measure open promises and stress cancellation exposure instead of using sales as a substitute for capacity. 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

The merchant collects fees now for classes delivered over several months. The payment stream and the unfulfilled service obligation move on different schedules.

01Reference conditionAdvance-sale training provider↗02Failure and stressAdvance-sale training provider↗03Controlled responseAdvance-sale training provider↗

Start with the economic promise — the flow

1. 01OfferIdentify the promised product
2. 02DeliveryLocate when the obligation is met
3. 03FailureIdentify refund and loss exposure

Start with the economic promise — the distinction

Entity existence

• Business is registered

Operating viability

• Business can fulfill its promises

Promoter business model

Fictional educational excerpt / Not for execution

Promoter business model

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

1. 1

   Saleconcert ticket

   Customer buys future access

2. 2

   Deliverysix months later

   Long open obligation

3. 3

   Failurerefund demand

   Potential correlated exposure

Registration alone cannot establish fulfillment ability

Start with the economic promise — control and failure modes

Control design

Underwrite the operating promise. Registration alone cannot establish fulfillment ability.

Failure mode 1avoid

Approve from the certificate only. It does not show the business model.

Failure mode 2avoid

Treat all card merchants alike. Delivery and liability differ.

Failure mode 3avoid

Ignore refund terms. They shape the open obligation.

Determine who is merchant of record, who receives settlement, who pays suppliers, and who bears refunds and chargebacks. A marketplace can present one brand while several entities perform these functions. Contracts and actual fund flows must agree.

Create a flow diagram with every legal entity and account boundary. Include refunds, reserves, and partner fees, not just incoming sales. A mismatch between the contractual seller and the visible checkout can confuse customers and complicate disputes. Escalate unclear models to the responsible legal and compliance owners before treating an account identifier as a complete answer.

Inside the mechanism. Trace who contracts with the customer, who receives proceeds, who performs the service, and who bears refunds or disputes. A marketplace label does not answer those questions by itself. Record partner agreements and actual operating behavior separately where they differ. A platform can retain customer-facing obligations while depending on a merchant or supplier for recovery. That dependency belongs in the exposure model and in the evidence needed for approval.

A concrete example. The platform connects buyers and several sellers while contracts allocate different refund and payment responsibilities. A customer-facing brand does not reveal the final loss bearer. The case has $940,000 of exposure. Its stated one-year PD and LGD imply $15,510.00 of expected loss, while the cover analysis leaves $656,000.00 of stress exposure. Monthly cash coverage is 1.33×. 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. A seller defaults and the platform’s contingent obligation becomes payable. Map the legal promise, cash location, recovery rights, and concentration before assigning cover. 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

The platform connects buyers and several sellers while contracts allocate different refund and payment responsibilities. A customer-facing brand does not reveal the final loss bearer.

01Reference conditionMarketplace liability chain↗02Failure and stressMarketplace liability chain↗03Controlled responseMarketplace liability chain↗

Map the payment and liability chain — the flow

1. 01ContractIdentify the seller and obligations
2. 02FundsTrace settlement and payouts
3. 03LiabilityAssign refunds and losses

Map the payment and liability chain — the distinction

Brand on screen

• Customer-facing name

Merchant of record

• Entity responsible in the payment arrangement

Marketplace chain

Fictional educational excerpt / Not for execution

Marketplace chain

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

1. 1

   CheckoutLantern

   Visible platform

2. 2

   Sellervendor-12

   Underlying supplier

3. 3

   Refund ownercontract-defined

   Must match the actual arrangement

Both are needed to understand responsibility

Map the payment and liability chain — control and failure modes

Control design

Match agreements to actual fund flows. Both are needed to understand responsibility.

Failure mode 1avoid

Assume the logo owns every obligation. Branding does not determine all legal roles.

Failure mode 2avoid

Ignore supplier payouts. They can remove funds needed for refunds.

Failure mode 3avoid

Use only the bank account nickname. It does not establish the legal entity.

Delivery exposure depends on how much business remains unfulfilled and how failures correlate. A merchant with many tickets for one event has concentration even if it has thousands of customers. Customer count is not the same as independent risk.

Estimate undelivered value by cohort and delivery date. Identify common suppliers, venues, platforms, and geographic events that can disrupt many orders together. Ask how the merchant would handle a cancellation or supplier failure. The point is to test a plausible loss path, not to forecast every possible disaster.

Inside the mechanism. Concentration matters along the failure mechanism: one event, supplier, customer, destination, or funding source can dominate a portfolio that appears diversified by merchant count. Group obligations by the common cause that could fail together. Test the effect of delayed or cancelled fulfillment at the relevant time. Averaging across merchants can hide the peak open promise precisely when cash has already left the platform.

A concrete example. Several merchants use one supplier for popular seasonal inventory. Their account names are different but a common shipment delay can affect all of them. The case has $1,250,000 of exposure. Its stated one-year PD and LGD imply $34,375.00 of expected loss, while the cover analysis leaves $862,000.00 of stress exposure. Monthly cash coverage is 1.33×. 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 shared supplier stops shipping during the peak sales period. Aggregate the common exposure and connect limits and payout terms to fulfillment evidence. 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

Several merchants use one supplier for popular seasonal inventory. Their account names are different but a common shipment delay can affect all of them.

01Reference conditionConcentrated fulfillment supplier↗02Failure and stressConcentrated fulfillment supplier↗03Controlled responseConcentrated fulfillment supplier↗

Test fulfillment and concentration — the flow

1. 01CohortGroup open customer promises
2. 02DependencyFind shared failure causes
3. 03StressEstimate a correlated refund event

Test fulfillment and concentration — the distinction

Many buyers

• Large customer count

Diversified exposure

• Losses do not depend on one common event

Event concentration

Fictional educational excerpt / Not for execution

Event concentration

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

1. 1

   Customers4000

   Many individual buyers

2. 2

   Venueone

   Shared dependency

3. 3

   Open ticket value320000 USD

   Correlated delivery obligation

Many customers can still share one failure cause

Test fulfillment and concentration — control and failure modes

Control design

Measure shared delivery dependencies. Many customers can still share one failure cause.

Failure mode 1avoid

Use customer count as diversification proof. The venue can fail for everyone.

Failure mode 2avoid

Ignore future delivery dates. They determine the exposure window.

Failure mode 3avoid

Assume insurance always pays. Coverage and exclusions need evidence.

Evidence should test the important claims. Bank activity can support cash-flow claims, supplier agreements can support delivery plans, and complaint records can challenge the customer experience. No single document tells the whole story.

Use a documented discrepancy process. A missing document may be a simple administrative gap; a contradiction may be more serious. Record the question being resolved, acceptable evidence, and the decision owner. Avoid collecting a large pile of unrelated documents because it looks thorough. More data increases handling cost and privacy exposure without necessarily improving the decision.

Evidence is most useful when it tests a specific part of the business story. A sample of supplier records can support a claim about access to stock; fulfillment records can support a claim about delivery timing; financial information can support an estimate of repayment capacity. None proves the entire application. Record the claim, the evidence examined, its date, and the unresolved limitation. This makes a conditional approval understandable to the next reviewer and reduces the chance that a polished presentation substitutes for the operating facts.

Inside the mechanism. Evidence should test the specific business story. Inventory records help one merchant type; supplier capacity or service completion evidence may matter more for another. Reconcile claimed sales to payment and fulfillment observations where appropriate and authorized. A polished document is not an independent confirmation. Keep the source, date, and limitations of each item so later monitoring can identify which part of the original approval assumption has changed.

A concrete example. A merchant’s explanation is tested against evidence appropriate to its activity. A document is useful when it supports a specific claim rather than merely filling a checklist. The case identifies 986 eligible records from a source population of 1,450. The required workflow completes for 956, but 14 completed records miss the illustrative internal target. Another 30 remain incomplete. Communication evidence covers 946 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A polished business plan substitutes for evidence of stock, delivery, and repayment resources. Tie each material claim to dated evidence and preserve any unresolved limitation. 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 merchant’s explanation is tested against evidence appropriate to its activity. A document is useful when it supports a specific claim rather than merely filling a checklist.

01Reference conditionProportionate merchant evidence↗02Failure and stressProportionate merchant evidence↗03Controlled responseProportionate merchant evidence↗

Verify the story with proportional evidence — the flow

1. 01ClaimName the fact that matters
2. 02EvidenceChoose a relevant independent source
3. 03ResolveDocument the remaining uncertainty

Verify the story with proportional evidence — the distinction

Missing evidence

• A claim remains unsupported

Contradictory evidence

• Sources disagree on the same claim

Fulfillment evidence

Fictional educational excerpt / Not for execution

Fulfillment evidence

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

1. 1

   Claimstock already purchased

   Merchant statement

2. 2

   Supportsupplier invoice

   Purchase evidence

3. 3

   Gapdelivery confirmation absent

   Stock receipt still unproven

Each request should improve the decision

Verify the story with proportional evidence — control and failure modes

Control design

Request evidence tied to the unresolved claim. Each request should improve the decision.

Failure mode 1avoid

Collect unrelated personal records. They may add no useful support.

Failure mode 2avoid

Treat absence as automatic fraud. Missing and false are different.

Failure mode 3avoid

Ignore contradictions after one positive check. The conflict still needs resolution.

An underwriting result can approve a defined model with limits, reserve terms, review triggers, and prohibited changes. Document the scope so the merchant and operations teams know what was approved. A vague approved status is hard to enforce when the business changes.

Connect conditions to monitoring. If the approval assumes delivery within seven days, the team needs evidence when delivery extends to ninety days. Conditions should have an owner, data source, and response. Review restrictions for proportionality and customer impact. The goal is a sustainable relationship whose assumptions remain visible.

Inside the mechanism. An approval can define an operating envelope: product scope, currencies, expected volume, average and maximum ticket, fulfillment horizon, payout terms, and review triggers. Store the reasons and evidence behind the envelope. Monitoring can then detect a material departure rather than applying an arbitrary generic threshold. A condition must have an owner and a response; an unenforced condition in an approval memo is not an operating control.

A concrete example. An approval can permit a limited amount of activity under conditions that respond to the actual exposure. Review triggers need to be observable after launch. The case has $385,000 of exposure. Its stated one-year PD and LGD imply $8,046.50 of expected loss, while the cover analysis leaves $273,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. The merchant changes products and delivery timing without updating its approved terms. Reassess amount, duration, reserves, and monitoring when the economic promise changes. 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

An approval can permit a limited amount of activity under conditions that respond to the actual exposure. Review triggers need to be observable after launch.

01Reference conditionConditional merchant approval↗02Failure and stressConditional merchant approval↗03Controlled responseConditional merchant approval↗

Make approval conditional and reviewable — the flow

1. 01Approve scopeState the permitted model
2. 02Set conditionsDefine measurable boundaries
3. 03Monitor changeRevisit broken assumptions

Make approval conditional and reviewable — the distinction

One-time status

• Approved without operating context

Conditional approval

• Defined model and review triggers

Approval record

Fictional educational excerpt / Not for execution

Approval record

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

1. 1

   Modelimmediate-delivery goods

   Approved scope

2. 2

   Change triggeradvance sales

   Different exposure

3. 3

   Ownermerchant underwriting

   Responsible reviewer

Unobserved conditions cannot be enforced reliably

Make approval conditional and reviewable — control and failure modes

Control design

Tie conditions to measurable monitoring. Unobserved conditions cannot be enforced reliably.

Failure mode 1avoid

Approve all future business models. The original evidence may not support them.

Failure mode 2avoid

Set a limit without an owner. Breaches may receive no response.

Failure mode 3avoid

Keep conditions hidden from operations. The team cannot apply them consistently.

Continue with Credit risk and repayment capacity to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.