How to build an anti-fraud flow in a decision engine
The engine doesn't detect the deepfake: it orchestrates your identity, anti-fraud and bureau providers, crosses their signals with your rules and decides approve, reject or refer to review.
Updated July 2026 · 8 min read
In short
A decision engine doesn't replace your identity or anti-fraud provider: it orchestrates them. It connects each provider (bureau or REST node), queries them in parallel (concurrent node), crosses their signals with your rules, geolocation and models, and decides in milliseconds to approve, reject or refer to manual review — with a contingency path if a provider goes down and a full trace of every decision.
Fraud isn't solved with a single tool or a single provider. It's solved by coordinating several —identity, anti-fraud, bureau, device signals— at the moment of decision, and turning all those signals into an action: approve, reject or send to review. That is exactly a decision engine's job.
What the engine does in fraud, and what it doesn't
It's worth being precise, because this is where a decision engine gets confused with an anti-fraud provider. The engine doesn't verify facial biometrics, doesn't detect a deepfake and doesn't validate a document by itself: identity and anti-fraud specialists do that.
What the engine does is the missing layer between those providers and the approval: it coordinates them, crosses their signals with your rules and models, and decides what to do with each application. Without that layer, each institution ends up wiring providers by hand and resolving the conflicts between them in code.
- The identity provider detects; the engine decides what to do with that signal.
- The engine combines several sources into one decision, in milliseconds.
- Every decision is traced: which signals came in and why it resolved that way.
Step 1 — Connect the providers
Each external provider enters the flow as a node. Pre-integrated ones (certified bureaus and web services) connect through the bureau node, which manages credentials, tokens and API keys, caches queries so you don't pay twice for the same data, and handles timeouts. Any identity, anti-fraud, device-intelligence or list provider that isn't pre-integrated connects through a REST node to its API.
The result: identity, anti-fraud, bureau and device signals become available as variables inside the same policy, with no integrations wired outside the engine.
- Bureau node: certified providers, with credentials, caching and timeout.
- REST node: any identity/anti-fraud/device/list API.
- Every signal becomes a policy variable.
Step 2 — Query them in parallel
In fraud, latency matters: chaining five queries one by one keeps the customer waiting. The concurrent node runs several data nodes at once, so identity, anti-fraud and bureau are queried in parallel and the flow advances at the speed of the slowest one, not the sum of them all.
That pattern —querying several sources in parallel and keeping what arrives— is what the industry calls a data waterfall.
- The concurrent node cuts total time to the slowest source.
- It lets you build a waterfall: query, and escalate to another source if needed.
- Lower friction without giving up the number of checks.
Step 3 — Cross signals, geolocation and rules
With the signals inside, you apply the rules. The matrix node lets you build scorecards and fraud rule matrices. The expression syntax includes geographic operations: comparing declared location against the device's, measuring distances or validating zones. And if you have your own fraud model, the model node or the Python node runs it within the same flow.
This is where your criteria become the decision: not what an isolated provider says, but how all the signals combine according to your policy.
- Matrix: fraud scorecards and rules.
- Geographic operations: declared vs. device geolocation.
- Model / Python node: your fraud score, without migrating your environment.
Step 4 — Decide: the three lanes
Fraud is rarely binary. Most applications are clearly legitimate or clearly fraudulent, but there's a gray band that shouldn't be auto-approved or auto-rejected. The decision, switch and binary nodes route each case to one of three lanes: automatic approval, automatic rejection and manual review.
Defining well what falls into the gray band is the difference between a risk team drowning in cases and one that only looks at the ones that truly warrant it.
- Automatic approval: clean signals.
- Automatic rejection: clear fraud per your rules.
- Manual review: the gray band, with all the evidence ready for the analyst.
Step 5 — Contingency, traceability and testing
An identity provider goes down, and the question is what happens to the application. The bureau node exposes a query-error variable that enables a contingency path: if the provider doesn't respond, the flow can route to review, retry with another source or apply a more conservative rule, instead of stalling or approving blindly.
Every decision is traced with the signals that came in and the rules that were applied —the evidence a fraud case always ends up needing—. And before touching production, champion/challenger lets you test a new anti-fraud rule on live traffic, in parallel with the current one, to see if it improves without risking the operation.
- Contingency path if a provider fails (no blind approvals).
- Every decision traced: signals, rules and outcome.
- Champion/challenger: test fraud rules without risk.
Technical documentation
How this is implemented in the engine, step by step.
Common questions
Does uFlow detect fraud by itself?+
Not in the sense of verifying biometrics or detecting a deepfake: your identity and anti-fraud providers do that. uFlow is the layer that orchestrates them —queries them, crosses their signals with your rules and models— and decides to approve, reject or refer to review. The specialist detects; the engine decides.
Can I connect the anti-fraud provider I already use?+
Yes. If it's certified, it connects through the bureau node (credentials, caching, timeout); if not, through a REST node to its API. This works for identity, anti-fraud, device intelligence or lists. Every signal becomes a variable inside the same policy.
What happens if an identity provider goes down mid-decision?+
The bureau node exposes an error variable that enables a contingency path: route to review, retry with another source or apply a more conservative rule. The decision doesn't stall or approve blindly when a signal is missing.
Related topics
Champion / Challenger: testing a new credit policy without risking the portfolio
How to evaluate a new credit policy against the one already in production, measuring its real impact on a slice of live traffic before you adopt it.
Model riskModel risk management: governing scoring and ML models in credit decisions
Scoring and ML models sharpen credit decisions but add model risk: bias, drift, weak explainability. Govern them with validation, monitoring and audit trails.
ProductHow the uFlow decision engine does it
Governance, versioning and traceability built into the engine, without slowing the business down.
Explore all guides or read the glossary.
Would this work for your decisioning process?
Transform your credit assessment process with the decision engine.