Risk and trust decisions in payments: a design for calibrated, policy-constrained fraud controls

1Context and motivation

Payment risk was long framed around card-not-present fraud: velocity checks, address mismatches, block lists, a manual review queue and chargeback handling. The scope a commerce platform has to cover is now wider. Account-to-account transfers, wallets and instant payouts move money with different reversal rules from cards; marketplaces add merchant and payout risk to buyer risk; and account takeover, refund abuse and promotion abuse cut across onboarding, payment and support.

Statistical and machine learning methods have been applied to fraud detection for decades, in credit card fraud, money laundering, telecommunications fraud and intrusion detection¹. The same literature notes why prevention alone does not hold: fraudsters adapt, and given time they find ways around fixed measures¹. A rule set written against last quarter's attacks therefore loses accuracy as attackers change, while each rule added to cut losses also blocks some genuine customers.

We treat risk as a family of decisions rather than one approve or decline gate. Onboarding, authorization, step-up authentication, payout timing, reserves, refunds and disputes each choose an action under uncertainty, and each can draw on the same signals. This paper describes the architecture we propose for those decisions. We describe the design and the reasons for each part; we do not report its effects, because we have not measured them.

2What makes the problem hard

Three properties of payment fraud data shape the design, and all three are documented for credit card fraud detection².

• Class imbalance. Genuine transactions far outnumber fraudulent ones, so a model that predicts "genuine" for everything scores well on accuracy and is useless.
• Concept drift. Customer habits change and fraudsters change strategy, so the relation between inputs and the fraud label moves over time^{2, 3}.
• Verification latency. Only a small set of transactions is checked by investigators in time; most labels arrive later, through chargebacks or customer reports, if at all².

A fourth property is adversarial. Most learning methods assume the data does not respond to the classifier, but in fraud detection an adversary actively manipulates inputs to produce false negatives, and a deployed classifier can degrade quickly as the adversary learns to defeat it⁴. The design therefore assumes that any model will decay and builds retraining, drift monitoring and rule updates into normal operation.

3Design principles

• Rules for obligations, models for judgement. Sanctions screening, mandatory strong customer authentication and regulatory holds are hard constraints applied before any model is consulted. Everything else is a scored decision.
• Probabilities, not flags. Every model outputs a calibrated probability, because the action policy compares expected costs and a miscalibrated score moves every threshold⁵.
• One signal layer, many decisions. Onboarding, payment, payout and dispute decisions read from the same feature store, so evidence found in one is visible to the others.
• Trust accumulates and decays. A clean history lowers friction over time, and old evidence loses weight.
• Every adverse decision is explainable and contestable. A decline, hold or reserve comes with its main contributing factors and a path to change the outcome.
• Change is staged. New models and thresholds run in shadow, then on a small share of traffic, with guardrails on loss and false declines.

4Architecture

The engine is a platform service called at onboarding, authorization, payout, refund and dispute. It returns risk probabilities, a trust state, a recommended action (approve, challenge, hold, increase reserve, decline) and the top contributing features.

4.1Signals and features

Inputs fall into four groups: transaction attributes (amount, currency, method, issuer range, merchant category, channel, time), account and behaviour (account age, login and device history, refunds, chargebacks), merchant attributes (business verification outcome, category, geography, dispute history), and external lists (sanctions and politically exposed persons) where the law requires them. Each signal carries consent and residency flags, and only fields that a decision uses are collected.

Raw transaction fields carry little information on their own. Aggregating a customer's recent transactions (counts and amounts over trailing windows, by merchant or country) and encoding the time of day as a periodic variable both add predictive signal for card fraud, and evaluation should weight errors by their financial cost rather than count them equally⁶. The feature layer computes these aggregates with the same code online and offline.

4.2Supervised fraud models

Each risk domain (transaction fraud, account takeover, merchant risk, refund abuse) has its own supervised model. For tabular features the design uses gradient-boosted trees, which scale to large, sparse data⁷. Training addresses imbalance by resampling or reweighting the minority class; combining over-sampling of the minority class with under-sampling of the majority class is one established method⁸. Because labels arrive late, the training set for a given week is built only from transactions whose label window has closed, and the small set of investigator-verified cases is weighted separately from labels inferred from chargebacks².

Scores are then calibrated. Boosted trees push predicted probabilities away from 0 and 1, and Platt scaling or isotonic regression on held-out data corrects this distortion⁵. Calibration is checked per region and per payment method, since a model calibrated on the whole population can be miscalibrated on a subgroup.

4.3Anomaly detection

Supervised models only recognise patterns that have been labelled. Anomaly detectors flag behaviour that departs from the normal profile without needing labels; the techniques differ in the assumption they make about what separates normal from anomalous points, and that assumption decides whether a technique suits a domain⁹. For high-volume streams the design uses isolation-based detection, which isolates anomalies directly rather than modelling normal points and runs in linear time with low memory¹⁰. Anomaly scores do not decline payments on their own; they route cases to review and become features for the next supervised model.

4.4Trust histories

Interactions with strangers carry risk, and reputation built from past behaviour is one long-standing way such risk has been managed online¹¹. The trust layer keeps a state per account, device and merchant: tenure, volume, clean transaction streak, disputes won and lost, and verified identity steps. Evidence decays with age, so a long-dormant account does not keep the trust it earned years ago. Trust lowers friction, for example by skipping optional step-up checks or releasing payouts sooner; it never overrides a hard rule.

4.5Decision engine

The decision engine applies the policy layer first, then chooses the action with the lowest expected cost given the calibrated probability, the transaction amount, the margin at stake, and the expected behaviour of genuine customers when challenged. Table 2 works through this model. Thresholds are set per region and payment method, because base fraud rates, available authentication steps and reversal rules differ.

Table 1 summarises the components, the problem each addresses and the evidence behind it.

Component	Problem it addresses	Evidence
Policy layer before models	Learned scores cannot be allowed to override legal obligations	Design choice
Supervised models on aggregated features	Raw transaction fields carry weak signal	6, 7
Imbalance-aware training	Rare fraud class is ignored by accuracy-driven training	8, 2
Label windows and verified-case weighting	Late and partial labels bias training	2
Probability calibration	Boosted scores distort probabilities and move thresholds	5
Isolation-based anomaly detection	New attack patterns have no labels yet	9, 10
Drift monitoring and scheduled retraining	Fraud strategies and customer habits change	3, 4
Decaying trust histories	Good long-term customers face the same friction as new ones	11
Cost-weighted evaluation	Counting errors equally ignores their financial cost	6
Group error-rate audit	Errors fall unevenly across regions or groups	12
Reasons and recourse for adverse decisions	Customers and merchants cannot see or change why they were blocked	13, 14

Source: our design, with the works cited in the table.

5A worked expected-cost model

The action policy compares three options for one transaction. Approve earns the margin on a genuine sale and loses the amount plus a chargeback fee on a fraudulent one. Challenge (step-up authentication) loses some genuine buyers who abandon, and stops most, not all, fraud. Decline earns and loses nothing on the transaction. With fraud probability p, margin G, fraud loss L, genuine abandonment under challenge s, and share of fraud stopped by the challenge c, the expected values are (1 minus p) times G minus p times L for approve, (1 minus p) times (1 minus s) times G minus p times (1 minus c) times L for challenge, and 0 for decline.

Quantity	Value	Type
Transaction amount	100	Input (currency units)
Margin on a genuine sale, G	20	Input
Fraud loss if approved, L (amount plus a 15 unit fee)	115	Input
Genuine abandonment under challenge, s	0.10	Input
Share of fraud stopped by challenge, c	0.90	Input
Approve at p = 0.005	19.33	Computed
Challenge at p = 0.005	17.85	Computed
Approve at p = 0.05	13.25	Computed
Challenge at p = 0.05	16.53	Computed
Challenge at p = 0.80	negative 5.60	Computed
Approve to challenge threshold, p = sG / (sG + cL)	0.019	Computed
Challenge to decline threshold, p = (1 minus s)G / ((1 minus s)G + (1 minus c)L)	0.61	Computed

Source: Worked model; inputs in the table.

Two points follow from the arithmetic. First, the thresholds act on probabilities, so a model whose scores are not calibrated shifts every boundary, which is why calibration is a design requirement rather than a refinement⁵. Second, the thresholds depend strongly on s, the share of genuine buyers who abandon a challenge, which is not known in advance and differs by method and region. The model omits the longer-term cost of a false decline on the customer relationship; that cost is real but would have to be estimated before it could enter the policy.

6Evaluation

Before any claim about fraud loss, approvals or friction could be made, a deployment would need the following.

• Cost-weighted offline evaluation. Models are compared on the money they save and lose, with each error weighted by its cost, not on accuracy or area under a curve alone⁶.
• Realistic label timing. Offline tests replay transactions in time order and reveal labels only when they would have arrived, so the test reflects verification latency².
• Drift checks. Feature distributions and calibration are monitored over time, and a drift alert triggers review and retraining³.
• Controlled threshold experiments. Threshold and challenge-policy changes go through registered experiments with guardrail metrics on fraud loss and false declines¹⁵. A small randomised holdout of transactions approved below the decline threshold supplies unbiased labels for retraining.
• Group audits. False-positive and false-negative rates are reported by region, payment method and merchant category. One criterion requires equal true positive rates across groups, and a learned predictor can be post-processed to meet it¹²; which criterion applies is a policy choice the design leaves explicit.

7Fairness, recourse and privacy

Risk models learn from historical decisions and outcomes. If a region, issuer or business type was scored as risky in the past, the data can carry that judgement forward and produce disproportionate declines and holds. The group audit above is the first control; the second is that protected attributes and their close proxies are excluded from features unless a legal basis requires them.

An adverse decision should be explainable and changeable. For each decline, hold or reserve the engine records the top contributing features using additive feature attributions¹³. Explanation is not enough on its own: people affected by a model's decision should have a way to change the inputs that led to it, and for linear classifiers it is possible to check whether such recourse exists¹⁴. The design therefore pairs each adverse action with a stated path, such as completing an identity step, verifying a payout account or contacting review. High-impact decisions, such as offboarding a merchant or holding large balances, go to a human reviewer.

On privacy, the design collects only fields used by a decision, hashes device and account identifiers, keeps records in their region of origin, and limits how long behavioural data is kept.

8Limitations

• No measurements. We have not measured this design on any fraud loss, approval, friction or fairness outcome. Every benefit implied here is a hypothesis to be tested with the evaluation above.
• Labels are biased by past decisions. Transactions that were declined never produce a fraud label, so models learn only from what earlier policies let through. A randomised holdout reduces this bias at a direct cost in fraud loss.
• Adversaries adapt to the design itself. Drift monitoring detects change after it happens; it does not prevent an adversary from probing thresholds⁴.
• The cost model is incomplete. Table 2 omits the long-term cost of false declines and the operating cost of review, and its inputs are hypothetical.
• Recourse results are narrower than the design. The recourse method we cite applies to linear classifiers¹⁴; for tree ensembles the design relies on stated procedural paths rather than a computed check that recourse exists.
• Regulation is out of scope. Anti-money-laundering programmes, sanctions screening and authentication rules are treated as given constraints. Their design needs specialised frameworks this paper does not cover.
• Regional detail is coarse. Country-level rules and fraud types differ more than per-region parameters can capture.

9Conclusion

We have described a design that treats payment risk as a set of decisions over calibrated probabilities: hard rules first, supervised models trained for imbalance and delayed labels, anomaly detection for unlabelled patterns, decaying trust histories, and an expected-cost policy, with reasons and recourse for adverse outcomes. Each part rests on published methods, summarised in Table 1, and Table 2 shows how calibration and the unknown abandonment rate drive the thresholds. The design has no evidence of its own effect yet. The next step is a cost-weighted, time-ordered offline replay on one payment method, followed by a registered threshold experiment, and a report of what is measured.