Do I need an engineer to change a rule?

No. A policy is an event, a set of conditions and an action, and all three are edited in the dashboard. Your fraud or trust team saves the change and the next request is evaluated against it. Nothing about a rule is compiled into your app, so there is no release to wait for.

Can I pass my own fields into a rule?

Yes. Send what your product already knows, such as plan tier, account age or a geo restriction, along with the evaluation, and a condition can read it exactly like a Rupt signal. Your custom fields and your own lists sit in the same builder as device_count, ip_is_vpn and email_is_disposable.

How fast is a verdict?

42ms at p50, evaluated against live signal data rather than a nightly batch. That is fast enough to hold the request on the verdict, so a repeat signup is stopped before the account exists instead of being cleaned up afterwards.

What happens when two policies match?

Every enabled policy for that event is evaluated, then the highest-priority match wins. Priority is a number you set per policy and it sorts descending, so a blocklist policy at 100 beats a challenge policy at 80 on the same request. The dashboard still shows you every policy that matched, not only the one that decided.

Can I test a policy before it goes live?

Yes. Every policy belongs to one of two environments, development or production, and your API key decides which set runs. Build the rule in development, point staging or a test integration at it, watch what it does, then move it to production once it behaves. Policies can also be enabled and disabled one at a time.

How does this relate to the challenge engine?

A challenge is one of the six actions a policy can take. The rules engine decides that a request is worth questioning, and the challenge decides how the person proves otherwise, by email or SMS. You pick the challenge configuration on the policy itself, so one rule can verify while another denies outright.

Fraud rules engine: no-code allow, challenge, block

1Compose

Your fraud team writes the rules, not your engineers.

A policy is an event, a stack of conditions and an action. Pick the events it runs on, build the conditions in the dashboard, and choose what happens on a match. Nothing about it is a code change.

Policies /Builder

Live

New policy

On LoginSign upAccess

Match all of

networkip_is_vpnis_truetrue

useremail_is_disposableis_truetrue

devicedevice_countgt2

behaviorevent_countgt3 per ip / 1 hr

listin_listeqknown_abuse

Then Deny saved to development

Enabled policies, priority order

100

block-known-abuse

in_list eq known_abuse

Wins

challenge-signup-burst

event_count gt 3 per ip

Matched

review-vpn-signups

ip_is_vpn is_true

Matched

trust-known-devices

device_count lte 2

Skipped

What the verdict can do

allowContinues, nothing held

denyRefused and redirected

challengeVerify by email or SMS

suspendAccount and sessions cut

add_to_listWritten to a list

remove_from_listCleared from a list

code: 0 code
operators: 12 operators
environments: 2 environments

2Evaluate

Every signal, list and aggregation is queryable from a rule.

Device, network, email, behavior, account history, your own custom fields, and counts over a window. Every enabled policy for the event is evaluated on the request, then the highest-priority match wins.

Policies /Priority

Live

New policy

On LoginSign upAccess

Match all of

networkip_is_vpnis_truetrue

useremail_is_disposableis_truetrue

devicedevice_countgt2

behaviorevent_countgt3 per ip / 1 hr

listin_listeqknown_abuse

Then Deny saved to development

Enabled policies, priority order

100

block-known-abuse

in_list eq known_abuse

Wins

challenge-signup-burst

event_count gt 3 per ip

Matched

review-vpn-signups

ip_is_vpn is_true

Matched

trust-known-devices

device_count lte 2

Skipped

What the verdict can do

allowContinues, nothing held

denyRefused and redirected

challengeVerify by email or SMS

suspendAccount and sessions cut

add_to_listWritten to a list

remove_from_listCleared from a list

signals: 100+ signals
to 24 hr: 1 min to 24 hr
policy wins: 1 policy wins

3Act

Six actions, one verdict, back in under 50ms.

Allow, challenge, deny, suspend, add to a list or remove from one. The verdict returns on the same request, and changing what a policy does never touches your build.

Policies /Actions

Live

New policy

On LoginSign upAccess

Match all of

networkip_is_vpnis_truetrue

useremail_is_disposableis_truetrue

devicedevice_countgt2

behaviorevent_countgt3 per ip / 1 hr

listin_listeqknown_abuse

Then Deny saved to development

Enabled policies, priority order

100

block-known-abuse

in_list eq known_abuse

Wins

challenge-signup-burst

event_count gt 3 per ip

Matched

review-vpn-signups

ip_is_vpn is_true

Matched

trust-known-devices

device_count lte 2

Skipped

What the verdict can do

allowContinues, nothing held

denyRefused and redirected

challengeVerify by email or SMS

suspendAccount and sessions cut

add_to_listWritten to a list

remove_from_listCleared from a list

actions: 6 actions
p50 verdict: 42ms p50 verdict
deploys: 0 deploys

Detect

Act

Free tools

By use case

By industry

Developers

Learn

Define the rules. We'll run them.

Combine 100+ device, network and behavioral signals with your own business logic to allow, challenge or block any action. Sub-50ms verdicts, no deploy.

No-code policies for your fraud team, built for real-time decisions.

Your fraud team writes the rules, not your engineers.

Every signal, list and aggregation is queryable from a rule.

Six actions, one verdict, back in under 50ms.

Signals, lists, and your context.

100+ built-in signals

Lists and blocklists

Your business logic

Aggregations

Questions teams ask about the rules engine:

Write your first policy this week.