Allow, challenge, review, block: a practical fraud decision model

Fraud teams often talk about scores, but products need actions. A score of 73 means little until your backend knows what to do.

RequestGuard uses a practical decision model: allow, challenge, review, or block.

Allow

The request looks acceptable for the current event. Continue the flow and store the request ID for later analysis.

Use this for normal signups, checkout attempts, form submissions, and API actions where the risk is low.

Challenge

The request is uncertain. Add friction, but do not reject the user outright.

Challenges can include email verification, CAPTCHA, OAuth login, magic link confirmation, or another step-up check. This is useful when signals are suspicious but not conclusive.

Review

The request deserves manual or delayed handling. Review is useful when the user may be legitimate but the business impact is high.

Examples include digital goods fulfillment, high-value checkout, bulk exports, team invites, API-credit issuance, or marketplace seller onboarding.

Block

The request is high risk for the current event. Stop it before it creates cost.

Block decisions should be reserved for clear abuse patterns: disposable identity plus suspicious network plus repeated behavior, or known automation targeting sensitive flows.

Implementation

switch (assessment.decision) {
  case "allow":
    return continueFlow();
  case "challenge":
    return requireVerification();
  case "review":
    return createLimitedAccess();
  case "block":
    return stopRequest();
}

Why this model works

The four states let your product respond proportionally. You reduce false positives, keep conversion cleaner, and make fraud policy easier to explain.