Add fraud signals to a workflow

A verification workflow can do more than confirm an applicant’s documents; it can also watch for the patterns that suggest an applicant is not who they appear to be. The Fraud signals section of the workflow editor is where you turn that on. It lets you collect device and network intelligence during verification and add rules that decide what happens when something looks suspicious.

Fraud screening is opt-in per workflow. A workflow you do not configure here runs exactly as before, with no extra device collection. You can keep it off for low-risk workflows and switch it on only where the friction is justified.

Before you start

You need the Owner, Admin, or Manager role to edit a workflow. Members can view a workflow but cannot change its fraud settings.

Open the workflow editor in one of two ways:

• New workflow. Open Dashboard → Workflows → New workflow. See Create a verification workflow template for the rest of the editor.
• Existing workflow. Open Dashboard → Workflows, then pick the workflow you want to edit.

The Fraud signals section appears as its own card in the editor, alongside the check toggles.

How fraud detection works

Fraud detection runs quietly in the background while the applicant completes their verification. It looks for suspicious patterns (for example, a single device used to start many verifications, or a connection that hides its true location) and turns what it finds into a finding your reviewers can see.

A few principles shape the whole feature:

• It informs, it does not auto-reject. A fraud signal can tag a verification for reviewer attention, send it to manual review, or influence whether the platform routes it to review. It can never decline an applicant on its own. A person always makes the final call. This is a deliberate fairness guarantee: the editor never even offers a “decline” action for a fraud rule.
• It is outcome-focused. You configure what should happen when a workflow sees something suspicious; the platform owns the detection itself and tunes it over time.
• It respects your data region. Device and network intelligence is processed in the same region as the rest of the workflow’s data, and it never crosses regions. See Where is my data hosted?.

When cross-session signals are evaluated

Most fraud signals (such as IP reputation, automation, and device velocity) can be assessed from what the platform observes while the applicant is on the page, so they are ready early in the verification.

A few signals compare one applicant against others. Repeat applicant, Identity ring, and Impossible travel are the clearest examples: they look for the same person applying again under different details, a cluster of verifications that link together as one coordinated group, or the same identity appearing from two locations too far apart to be plausible. To make any of these comparisons, the platform first needs the applicant’s verified identity details, and those become available only after the applicant finishes their verification steps. For that reason, these cross-session signals are evaluated once the verification is complete, not while the applicant is still filling out the form or before they submit.

This timing has two practical consequences worth knowing:

• A brand-new applicant has nothing to compare against. The first time someone verifies, there is no earlier matching verification on record, so a repeat-applicant, identity-ring, or impossible-travel signal cannot fire on that first attempt. The signal can only fire on a later verification that matches an earlier one.
• The finding appears after completion, not mid-journey. When a cross-session signal does fire, its finding is attached to the verification once it finishes and shows up for your reviewers then. It does not interrupt the applicant partway through, and it never ends their journey on its own.

If you expect a repeat applicant to be caught the moment they start a second verification, this is why it is surfaced a little later instead: the comparison can only run once there are verified identity details to match on.

Turn on device intelligence

The first control in the Fraud signals section is a single switch:

Collect device intelligence for this workflow

Turns on privacy-preserving device and network fingerprinting during verification so the rules below have signals to act on. Off by default.

Leave it off and the fraud rules below have no device signals to evaluate. Turn it on for a workflow when you want device and network patterns considered as part of verification.

This switch is off by default for every workflow. It is a conscious choice to collect device intelligence, so you turn it on only where your verification policy calls for it. Applicants on a workflow that has it on see a brief, plain-language security notice during their journey; see What the applicant sees below.

What fraud detection costs

Fraud detection is a billable item in live mode, priced at $0.45 per verification. The charge applies once per verification (not per rule and not per check) and only on verifications built from a workflow that has fraud detection enabled (that is, device intelligence is switched on, or the workflow has at least one active fraud rule). A workflow with fraud detection left off is never charged the fraud fee. The fee is in addition to the price of the check types the workflow runs; see Wallet and balance for how per-verification charges debit your wallet in live mode.

In test mode, fraud detection is free and fully disabled: a test verification runs no fraud screening, produces no fraud finding, and is charged no $0.45 fee. The $0.45 and every other charge apply to live mode only: test mode runs every check free, with synthetic results and no wallet. (No outside device-intelligence lookup happens in test mode either.) To see what a verification will cost in live mode, the workflow editor shows the per-verification price as you build it.

Add a fraud rule

A fraud rule has three parts: a signal to watch, what should happen when it fires, and whether the rule is active. Click Add fraud rule to add a row, then fill it in.

Choose a signal

Each rule watches one kind of suspicious pattern. The editor offers these signals:

Signal	What it watches for
IP reputation	Connections from a network with a poor reputation, including known datacenter, proxy, and Tor-exit addresses.
Automation / bot signal	Behavior that looks automated rather than a real person.
Device velocity	Many verification attempts coming from one device.
Repeat applicant	A person the platform has seen apply before: the “same person, different details” pattern.
Impossible travel	A location that jumps further or faster than a person could move between two verification attempts.
Identity ring	A cluster of verifications that link together as one coordinated group, rather than independent applicants.
Email risk	A risky email address: a disposable address, a machine-generated-looking domain, or a username that does not read as a real name.
Behavior anomaly	Signs that the form was filled out by automation rather than a person: for example, a browser running under automation control.
Geo mismatch	The country of the connecting IP address does not match the country the applicant declared in their address.

Pick the one that matches the abuse you want to catch. You can add more than one rule to a workflow (for example, one rule for device velocity and another for bot signals), up to a maximum of 100 rules per workflow.

Choose what happens when it fires

The When it fires control sets the rule’s action. There are three choices:

Action	What it does
Tag for reviewer attention	Records a reviewer-visible annotation on the verification so a reviewer has the context that this rule matched. It does not route the verification to review and does not drive its outcome on its own.
Send to manual review	Routes the verification to manual review so a human decides before the verification completes.
Influence the review decision	Weighs the matched rule alongside everything else when the platform decides whether the verification needs manual review, rather than acting outright.

There is no “decline” action, by design: a fraud rule can surface a concern, but only a person can decline an applicant.

When a workflow has more than one rule set to Influence the review decision, those rules combine: each one that matches adds its weight to the others. The more rules that match, the more weight accumulates, and the more likely the verification is routed to manual review. This weight is internal to the platform; applicants never see a score, value, or count at any point in the process.

Name the rule and keep it active

Give the rule a short, recognizable Rule name (the editor pre-fills one you can change). Leave Active on for the rule to run; switch it off to keep a rule’s configuration without using it, which is useful while you tune a workflow.

To remove a rule, use the Remove link on its row.

Save the workflow

Fraud rules and the device-intelligence switch save with the rest of the workflow when you save it. As with the rest of the editor, your changes apply to future verifications built from the workflow: verifications already in flight keep the configuration they started with. See Create a verification workflow template for how workflow versioning works.

What your reviewers see

When a fraud rule fires on a verification, it produces a finding the same way a watchlist match or a document concern does. Because a fraud finding is about the whole verification rather than one specific check, it appears in the reviewer’s findings list under a Session-level group.

A reviewer opens the verification, reads the finding alongside the rest of the evidence, and makes the call. Findings set to Send to manual review hold the verification in awaiting_review until a reviewer acts. See Manually review a verification for the reviewer’s side of this flow.

What the applicant sees

Applicants do not see fraud rules, signals, or findings: fraud screening is invisible to them and never blocks their journey on its own.

The one thing an applicant may notice is a short security notice, shown only on a workflow that has device intelligence switched on:

To help keep your account secure, we check device and network signals during verification. This includes how you fill out the form (such as how long steps take and how many times you paste) and an approximate region based on your IP address. We never record what you type.

The notice is informational. The applicant completes the same verification steps either way, and a fraud signal never ends their journey with an error. For the full applicant walkthrough, see What the applicant sees.

A suggested setup

A practical starting point is to turn on device intelligence and add one or two rules set to Tag for reviewer attention first. That records context for your reviewers without changing how verifications flow, so you can see what the signals catch before you escalate any of them to Send to manual review.

For the check types you run alongside fraud rules, see Choose the right check types. For terminology, see the Glossary.