Fraud Rules & Risk Controls Engine. @fraud-rules-engine

The Fraud Rules & Risk Controls Engine sprint puts a configurable risk layer into your transaction or account path: rules your risk team can change without a deployment, scoring inputs from your own data and third-party signals, and automated actions — allow, block, hold, step-up — applied consistently. It replaces the usual alternative: risk logic scattered through application code, changeable only by engineers.

The finish state is a live engine evaluating every in-scope event, a rule configuration surface owned by the risk team, a review queue where held items get worked with full context, and outcome tracking that shows each rule's hit rate and false-positive cost — so rules are tuned on evidence.

Rules Engine & Configuration

A rule evaluation engine in the transaction path — thresholds, velocity checks, list matching, and combinations — with versioned, auditable rule changes owned by risk, not engineering.

Scoring Inputs & Signals

Signal wiring from your event history, device and network data, and optional third-party fraud scores, normalized so rules can use them uniformly.

Automated Actions

Configured outcomes per rule: allow, block, hold for review, or trigger step-up verification — applied at latency compatible with your payment flow.

Review Queue & Outcomes

A queue for held events with decision capture, plus outcome reporting per rule so precision and cost are visible and tunable.

1. Scope — Map fraud patterns, event flows, and latency budget; fix the initial rule set, actions, and review workflow with your risk team.
2. Build — Build the engine, signals, actions, and queue; replay historical events to validate rules against known fraud and known-good traffic.
3. Handover — Deploy in monitor-only mode, then enforce rule by rule; hand over tuning documentation and queue runbooks.

The Fraud Rules & Risk Controls Engine is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

Is this machine-learning fraud detection?

No — it is the rules-and-controls layer, which most teams need first and which any ML scoring later plugs into as another signal. The engine is built so a model score is just one more input.

Will rules add latency to payments?

The latency budget is fixed at scoping and engineered to — synchronous evaluation for in-path decisions, asynchronous evaluation for account-level rules that can act after the fact.

What if we have no risk team yet?

The sprint still lands a sensible starter rule set and the review workflow, with tuning documentation written for whoever owns risk next. Onboarding-time controls are covered separately by the KYC & KYB Workflow Integration.