ALLOW, REVIEW, BLOCK Without a Black-Box Score

Support gets the ticket first. A payout is held. The customer wants a reason. If your fraud API only returned 0.81, you do not have a reason. You have a number that nobody can defend on a call, in a complaint file, or in an audit.

The useful contract is three outcomes: ALLOW, REVIEW, and BLOCK. Scoring can still exist. It should rank the queue, not hide the policy.

Put the policy in the outcome

ALLOW is the default when named rules and any score you keep agree the event is in policy. The product proceeds. Nobody writes a case note.

REVIEW is for a real signal that is still ambiguous. A new device on a quiet account. Velocity near a threshold. A possible watchlist hit that is not confirmed. Someone on the team should look, or the product should add a step-up, before you treat the customer as confirmed-bad.

BLOCK is for a pattern you have already confirmed and measured. A listed fingerprint. A confirmed watchlist hit. A card-testing burst you have seen enough times to know the collateral damage. If you have not measured that damage, you are guessing with a customer's money or login. Block is a privilege. Spend it on things you can explain.

Naiza evaluates product events with a rule engine and risk scoring. Use the score to order the review queue so analysts pick the highest-risk cases first. Use named rules for the decision you will repeat to a customer. That split is the same argument as rules versus a black-box model: a rank is useful; an unexplained decline is not a policy.

Why black-box scores fail operations

A model score without features is not a contract. Operations cannot tell the customer why the payout was held. Engineering cannot replay the policy after a rule change. An auditor cannot ask which control fired and get a sentence.

You also cannot tune what you cannot name. If last Tuesday's flash sale flooded the queue, you need to know whether it was a login-velocity rule on one IP or a generic high-risk bucket. Named rules let you raise a threshold, add an allowlist exception for a partner, or move a noisy rule back to REVIEW without rewriting the whole model.

Keep the fraud event id on your payment or login record. Support, risk, and engineering should share one key. When the customer asks why, someone opens that id and reads a rule name, not a Slack thread from three days ago. Hide the score from the customer email. Do not hide it from the analyst.

If two rules fire, record both. Do not collapse them into the higher score. The second rule is often the one someone will ask about later.

Roll out like you will have to live with it

Do not turn on BLOCK on day one for a new rule. Run it in shadow, or return REVIEW first, then enforce. That is the same posture as shadow mode versus enforcing for AML pilots: watch volume, watch false positives, then change the customer experience.

A practical sequence looks like this. Instrument the event with customer.externalId, a device fingerprint, IP, and session. Write the rule with a human name. Ship it as shadow or REVIEW. Sit with the queue for a week. Count how many cases were real, how many were families sharing a tablet, how many were a shared mobile network. Then promote the high-confidence slice to BLOCK.

If the queue is too large, do not add more signals first. Tighten the rule or raise the threshold. Scoring can help you sort. It should not be the thing you quote when someone asks why they were blocked.

The same three outcomes should show up in the product, the case system, and the weekly risk review. If engineering talks in scores and operations talks in holds, you will spend the next incident translating between them. Map ALLOW to proceed, REVIEW to friction or a queue, and BLOCK to a hard stop, and write that mapping down before the first production event.

The outcome is the policy. Everything else is evidence.