PAYMENT RISK · OCTOBER 2026
Blocking more transactions is not the same as preventing more loss.
Evaluate fraud systems by their effect on matured fraud loss, legitimate payment acceptance and review workload. Combine provider risk signals with transparent business rules, and keep consequential decisions accountable rather than relying on an unexplained model score.
Define the merchant decision and tradeoff
A payment-risk decision may allow, block, request further authentication or route for review. Each has a cost. Allowing fraud can create chargeback and operational loss; blocking legitimate customers can lose contribution and harm trust. The goal is an acceptable balance for your business, not the maximum rejection rate.
Define fraud loss on a consistent basis: transaction date cohort, matured disputes, fees, recoveries and the relevant revenue or payment denominator. Keep attempted fraud, blocked suspicious transactions and confirmed loss separate. A model score is not a label of proven fraud.
Segment by market, product, payment method and customer history. A single threshold may behave differently across these groups. Document policy decisions and exceptions so a reviewer can distinguish a deliberate risk choice from an unexplained model change.
Combine risk signals, rules and account controls
Stripe Radar documents transaction risk evaluation and merchant-defined rules. Adyen’s documentation describes payment risk management. These sources establish available control concepts; they do not prove a universal fraud-reduction percentage or a cross-vendor winner. Stripe risk evaluation; Stripe rules; Adyen risk management
Use provider signals alongside contextual controls such as account age, unusual device or delivery changes and transaction velocity where lawfully available. Keep collection proportionate and protect sensitive information. Do not treat any single attribute as sufficient proof of misconduct.
Rules can encode clear constraints and known patterns; learned models can capture combinations that are difficult to specify manually. Graph methods can help analyze relationships when good entity data exists, but they are not a guarantee of detecting every ring. Link quality, labels and operational review remain essential.
Make human review consistent and auditable
A review record should show the transaction, relevant signals, rule hits, account context and requested evidence. Define approve, decline, additional verification and escalation outcomes. Keep reviewer decisions and reasons separate from the model’s initial recommendation.
Avoid asking a language model to judge a customer’s honesty from writing style. Use it, if appropriate, to summarize approved evidence or identify missing fields. It must not invent risk evidence, infer protected characteristics or rewrite the rationale after a decision is made.
For identity and payment-detail changes, establish a separate verification procedure. Synthetic media and impersonation risks justify stronger source and channel validation, but this guide does not rely on an invented global deepfake-growth statistic. A convincing voice or document is one input, not proof of authority.
Evaluate with matured outcomes and a fair comparison
Build historical cohorts with enough time for disputes and recoveries to mature. Record changes in policy, authentication, traffic source and customer mix. Labels may be incomplete: a blocked payment rarely reveals whether it would have been legitimate, and a chargeback reason may not perfectly identify fraud.
Compare candidate policies in shadow mode where available, then use a controlled rollout appropriate to your risk tolerance. Track fraud loss, approval rate, review rate, dispute costs and customer friction together. Inspect segments with low volume and high consequence rather than trusting an overall average.
Avoid leakage in model evaluation. Fields created after a dispute should not be treated as information available at the original decision. Keep development and evaluation periods separate. Verify how the provider’s score and rules performed on the data and decision conditions actually present at payment time.
Plan changes and incidents before scaling
Set policy ownership between risk, payments, customer service and engineering. Record who can change thresholds, deploy rules or approve exceptions. Review changes against expected loss and legitimate acceptance before promotion.
Define an outage policy with payment and risk owners. Whether to fail open, fail closed or limit transactions depends on the specific risk and business impact; do not let an assistant decide ad hoc. Preserve decision logs and make reversal or customer remediation possible when a rule blocks legitimate activity.
Include provider charges, authentication, reviews, dispute handling, integration and customer recovery in the business case. Ask vendors for current written scope and terms. Numerical savings claims require attributable data and a credible comparison, not anonymous case stories or a homemade vendor score.
Compare the choices
| Control | Benefit to test | Tradeoff |
|---|---|---|
| Provider risk model | Broad transaction signal analysis | Score interpretation and local segment behavior. |
| Merchant rules | Clear policy and rapid known-pattern response | Overblocking and maintenance. |
| Additional authentication | Stronger evidence for selected payments | Customer friction and incomplete coverage. |
| Manual review | Context and exception judgment | Delay, cost and reviewer consistency. |
Worked example: make the decision concrete
Illustrative threshold decision: a merchant considers a rule that prevents an assumed $3,000 of fraud loss but rejects 100 legitimate orders. At an assumed $20 contribution per order, lost contribution is $2,000. If added review and recovery cost is $500, the estimated net operating benefit is $500 before other effects. These inputs are hypothetical arithmetic, not a claimed merchant result.
The team must validate both prevented loss and false declines; neither can be read directly from the count of blocked payments. It should also investigate customer complaints and segment effects. A higher fraud-block count alone could describe a worse commercial policy.
Failure modes to plan for
Common failures include stale labels, duplicate identities, post-outcome data leakage and threshold changes that shift risk to another channel. Keep the event-time evidence and analyze the complete payment journey.
Another failure is declaring victory before chargebacks mature. Report provisional cohorts as provisional and revisit them. Where customer rights, authentication or data use have legal implications, review the specific jurisdiction and processing context with qualified owners instead of claiming universal compliance from a product feature.
Your useful next step
Create a matured payment cohort and a combined scorecard for loss, legitimate approval and review cost. Test one policy change in a controlled manner, with a named owner, rollback route and documented customer-friction checks.
Questions and answers
Are rules obsolete now that models exist?
No. Rules can express explicit policy and known patterns, while models can combine broader signals. Evaluate their joint effect on loss, acceptance and review workload.
Does a high risk score prove fraud?
No. It is a risk signal under the provider’s model. Decisions should consider available evidence, policy and the appropriate review or authentication path.
How do we measure false declines?
Use available review outcomes, customer follow-up and controlled comparisons, while acknowledging incomplete labels. Do not equate every blocked transaction with prevented fraud.
Should we build our own fraud model?
Only with suitable event-time data, labels, engineering and risk ownership. A provider-led approach may be more practical; compare complete operating requirements rather than assumed model superiority.
Sources and evidence scope
Primary sources checked on 11 October 2026. Product pages establish vendor-described features; they do not establish independent comparative performance. Worked examples are explicitly illustrative. Implementation recommendations are editorial guidance.
- Stripe Radar risk evaluation — Documents transaction risk evaluation and fraud prevention controls.
- Stripe Radar rules — Documents merchant-defined fraud rules and actions within Radar.
- Adyen risk management — Documents payment risk management and fraud controls.
Research Path