You get four possible outcomes right away with each payment request: approve, decline, review, or step up. Each outcome comes with a reason, so you don't have to interpret a score later.

Rules that need to run quickly return results within the payment window. You can set each rule to run either instantly or in the background. This way, urgent checks happen right away, while more complex analysis, like looking across accounts, happens in the background and sends you an event when it's done. You can always dig as deep as you need without being limited by the payment window.

It's up to you. You can use our challenge flow, or handle the step-up verification in your own app. Either way, the result is recorded in the same place, so your audit trail stays complete no matter where the challenge happens.

That's not the goal. Having four outcomes means you don't have to decline payments just because you're unsure. If something looks suspicious but not clearly wrong, it goes to review or step up instead of being declined. Each rule's performance is measured by confirmed fraud and false positives, so you can see how precise each rule is.

Yes. Each customer's risk tier, segment, and expectations are built into the fraud rules. High-risk customers face different checks, not just stricter versions of the same rules. If fraud is confirmed, the customer's risk tier goes up, and the next payment will be checked by new rules.

You're protected from day one with rules that catch known fraud patterns, and anomaly detection starts working right away too. As you confirm fraud cases, a model trained on your own data will kick in, so you never have a cold start.

Only the detection logic is shared. If an institution creates a rule that finds a new fraud pattern, that logic can be anonymized and shared with the network. No customer data, sessions, transactions, or thresholds are shared, and each rule is shared only if you choose to opt in.

We look at how the session behaves, not just the transaction details. Things like hesitation, copying and pasting beneficiary details, unusual urgency, or signs that someone is following instructions are all signals we use, since the payment itself may look fine.

We track shared devices, shared beneficiaries, and repeated funding paths across accounts. This lets us spot a mule network as a whole, instead of seeing just a group of accounts that look normal on their own.

Each decision includes the rules and model version used, the signals that contributed, and a clear reason. If there's a dispute, you can answer it directly from the record instead of piecing it together from logs.