Transaction risk and decision economics
Use signals, uncertainty, and cost to choose proportionate actions.
A rule blocks every large purchase. Fraud falls. So does the business. The interesting engineering problem is to protect good payments while finding harmful ones, with imperfect evidence and a clock that keeps moving.
Define the unit of decision
A payment attempt, an order, a customer, and a merchant are different units. One order may generate several attempts. A customer-level restriction can affect many orders. Choose the unit before creating labels or measuring approval.
Give each decision a stable identifier and link it to the relevant entities. Separate raw attempt counts from unique purchase counts. Otherwise, repeated retries can make approval appear worse and make a busy customer appear like many unrelated people. The action should also have a scope: blocking one payment is different from closing an account.
- EntityChoose the decision unit
- LinkConnect attempts to the purchase
- ScopeDefine what the action affects
- Attempt
- One submission to a payment path
- Order
- One commercial purchase with possible retries
Attempt grouping
Illustrative data; not a real customer record or a prescribed policy.
- Orderorder-77
Single purchase
- Attempts4
Three retries plus original
- Approved orders1
Do not count four purchases
Retries change the denominator
Measure attempts and orders separately. Retries change the denominator.
- Failure mode 1avoid
- Treat every retry as a new customer. That fragments the identity.
- Failure mode 2avoid
- Close accounts for every payment error. Action scope exceeds the evidence.
- Failure mode 3avoid
- Hide retry failures. Operational friction remains relevant.
Use signals with known meaning
A risk signal is evidence, not a verdict. Device history, amount change, destination novelty, and prior outcomes can all help. Their value depends on data quality, freshness, population, and the event being assessed. A missing value should remain distinguishable from a known safe value.
Write a feature definition with its event window, source, units, and availability time. For example, successful payments in the previous hour excludes the current attempt and must be computed from events available then. Test boundary times and delayed events. A model cannot repair a feature that means different things in training and production.
- DefineSpecify window source and units
- ComputeUse available event-time evidence
- ValidateCompare offline and online results
- Zero prior events
- Known empty history
- Missing history
- The system cannot establish the value
Velocity feature record
Illustrative data; not a real customer record or a prescribed policy.
- Windowprevious 60 minutes
Excludes current attempt
- Countunknown
Source unavailable
- Fallbackbounded review policy
Do not coerce to zero
Unknown history differs from no history
Preserve missingness explicitly. Unknown history differs from no history.
- Failure mode 1avoid
- Replace all missing values with safe. That silently changes the risk meaning.
- Failure mode 2avoid
- Include future events. The model could not see them in production.
- Failure mode 3avoid
- Use an undocumented window. Results become hard to reproduce.
Choose actions by expected consequence
A score becomes useful when connected to an action. Compare expected fraud loss, margin, customer friction, review cost, and available evidence. The comparison is a decision aid, not permission to ignore legal restrictions. Mandatory prohibitions remain constraints.
In a simple teaching example, a $200 payment with a 1 percent loss probability and full loss severity has $2 expected loss. If incremental contribution before risk is $6, the expected remainder is $4 before other costs. Change severity, recovery, or probability and the result changes. Never confuse expected value with a promise about one transaction.
Suppose a legitimate payment contributes $4 and a fraudulent payment can lose $100. A model score cannot be compared directly with either amount unless its probability meaning is established. Even with a calibrated probability, the decision also depends on how a review or authentication step changes outcomes. A challenge that prevents some losses may also cause good customers to leave. Estimate these effects separately and state which costs are missing from a simplified calculation.
The best action can differ for two payments with the same predicted probability. One may involve immediate delivery of a transferable asset; another may allow a shipment hold and reliable recovery. The model describes evidence about an outcome. The policy applies that evidence to the action available at this point in the transaction.
- EstimateProbability and loss severity
- CompareMargin friction and review cost
- ConstrainRespect mandatory restrictions
- Expected loss
- Average loss under assumptions
- Realized loss
- Actual outcome for a payment or cohort
Illustrative economics
Illustrative data; not a real customer record or a prescribed policy.
- Amount200 USD
Exposure assumption
- Loss probability1 percent
Assumed calibrated probability
- Expected loss2 USD
200 times 0.01
Expected loss depends on both
State the probability and severity assumptions. Expected loss depends on both.
- Failure mode 1avoid
- Treat expected loss as guaranteed. Individual outcomes vary.
- Failure mode 2avoid
- Approve prohibited activity for profit. Legal constraints are not a pricing input.
- Failure mode 3avoid
- Use an uncalibrated score as probability. Score scale may not represent likelihood.
Use a ladder of interventions
Approve, request stronger evidence, review, limit, delay, and decline have different effects. Select an action that can reduce the specific uncertainty before harm occurs. A document request does little for a suspected compromised session if it does not test current control.
Each intervention needs a completion route. Set a queue owner, timeout, and permitted customer actions. Measure whether the intervention produces useful evidence. If nearly every review ends in approval without new information, the queue may be an expensive delay. If reviewers lack authority to act, the queue is a storage system for unresolved risk.
- UncertaintyName the unresolved fact
- InterventionChoose a relevant check
- ResolutionDefine the next state and owner
- Targeted friction
- Tests the uncertain fact
- Blanket friction
- Adds effort without useful evidence
Intervention contract
Illustrative data; not a real customer record or a prescribed policy.
- Concernnew destination
Specific uncertainty
- Actionverify payee change
Relevant evidence
- Expirydefined by product
No indefinite limbo
A useful check changes the evidence
Match the intervention to the uncertainty. A useful check changes the evidence.
- Failure mode 1avoid
- Request unrelated paperwork. Volume does not establish the missing fact.
- Failure mode 2avoid
- Review without an owner. The decision cannot reliably progress.
- Failure mode 3avoid
- Delay indefinitely. Unbounded holds create customer harm.
Evaluate what the control misses
Observed loss is shaped by prior decisions. Declined payments do not produce the same outcomes as approved payments. A policy can appear safe simply because it refuses nearly everything. Compare loss with approval, customer impact, and the composition of traffic.
Use controlled evaluation where lawful and suitable, and analyze uncertainty when labels are unavailable. Review false positives through appeals and representative samples. Monitor the loss distribution, not just an average. A stable average can hide a new high-loss segment. Every metric should have an owner who knows its denominator and its blind spots.
A decline policy hides part of its own outcome. A stopped transaction cannot reveal exactly what would have happened if the platform had allowed it. Counting every decline as prevented fraud rewards aggressive controls regardless of customer harm. Use reviewed samples, mature outcomes, and carefully governed evaluation methods to estimate the blind spots. Keep measured results separate from assumed prevention. A dashboard becomes more useful when it shows uncertainty than when it gives an unsupported precise savings total.
- ObserveLink actions to mature outcomes
- CompareAccount for population differences
- InvestigateFind misses and false restrictions
- Observed approved loss
- Outcomes for accepted traffic
- Total policy quality
- Includes rejected good traffic and other costs
Policy comparison
Illustrative data; not a real customer record or a prescribed policy.
- Policy A95 percent approval
Broader accepted population
- Policy B50 percent approval
Different selection
- Loss comparisonneeds context
Rates alone cannot rank them
Selection affects the observed loss rate
Compare outcomes with acceptance and mix. Selection affects the observed loss rate.
- Failure mode 1avoid
- Rank policies only by lowest loss. Declining everything can look artificially safe.
- Failure mode 2avoid
- Assume rejected traffic was fraudulent. Its outcomes may be unknown.
- Failure mode 3avoid
- Ignore appeals. They can reveal false-positive patterns.
Chapter connections
This chapter builds on Account takeover and account recovery. Continue with Scams, money mules, and social engineering to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.