ALLOW, REVIEW, BLOCK Without a Black-Box Score
Ship fraud policy as explainable outcomes. Use scoring to rank, rules to decide, and REVIEW-first rollouts before you enforce BLOCK.
The useful contract for a fraud API is three outcomes: ALLOW, REVIEW, and BLOCK. A 0.81 model score with no features is not a contract. Operations cannot tell a customer why the payout was held, and auditors cannot replay the policy.
Put policy in the outcome
- **ALLOW** when rules and scores agree the event is in policy.
- **REVIEW** when the signal is real but ambiguous: new device, velocity near threshold, possible watchlist match.
- **BLOCK** when you have a confirmed pattern (listed fingerprint, confirmed watchlist hit, card-testing burst) and you have measured collateral damage.
Naiza evaluates product events with an adaptive rule engine and risk scoring. Use scoring to order the review queue. Use named rules for the decision you will defend. See rules vs black-box ML.
Roll out like a grown-up
Shadow or REVIEW-first, then enforce. That is the same posture as shadow mode vs enforcing for AML pilots. Keep the event id on your payment or login record so support, risk, and engineering share one key.
Definitions that belong next to this policy: velocity checks, account takeover, and transaction monitoring.