Orchestration is coordinating your identity, risk, and verification services into one decision flow, calling the right checks in the right order and combining their results. It lets you add, swap, or fail over vendors and adjust routing without rebuilding your core logic.
What is orchestration, in plain English?
Orchestration is the traffic controller sitting between your product and the many services that inform a risk decision: identity verification, document checks, device signals, sanctions screening, credit data, and your own models and rules. Instead of hard-coding each vendor call into your product, you route everything through one layer that decides which checks to run, in what order, and how to combine what comes back.
The payoff is control. Because the routing lives in one place, you can add, swap, or fail over vendors and change the order of checks without rebuilding your core decision logic. If a provider gets expensive or unreliable, you reroute around it; if a new signal helps, you slot it in.
In the detection stack orchestration is the connective tissue. It does not make the risk call itself so much as make sure the right inputs reach the decision, cleanly and on time. Done well it is invisible; done poorly it stacks up delay and cost.
How a request flows through the layer
A single decision can touch several vendors. Orchestration decides the sequence and stitches the answers together.
- Enter — Request arrives. An onboarding or transaction hits the orchestration layer instead of calling vendors directly.
- Route — Pick the right checks. Based on risk and context, the layer decides which services to call and in what order.
- Call — Run and combine. Chained or parallel vendor calls return results, which are merged into one view.
- Provider healthy — Proceed. Use the result and continue the flow.
- Provider slow or down — Fail over. Reroute to a backup so the decision still completes.
- Decide — Hand off one answer. The combined result feeds the decision engine for a single approve, step-up, or decline.
What it looks like in practice
In practice
A fintech's onboarding calls an identity vendor, a document check, and a sanctions screen, all wired directly into the signup code. When the identity vendor has a slow morning, signups stall, and every fix means a code change and a release.
The team moves the calls behind an orchestration layer. Now a slow identity vendor triggers automatic failover to a backup, so signups keep flowing. They also notice the layer was calling the document check on every applicant, even low-risk ones the identity vendor already cleared, paying for a check that added no new information. Reordering the flow to skip redundant checks cuts both latency and vendor spend, without touching the product code at all.
Why the trade is flexibility versus complexity
Orchestration buys you flexibility and control over both cost and coverage. You can route around outages, negotiate harder with vendors because switching is easy, and tune which checks run for which customers. That is real leverage, especially as your vendor stack grows.
The cost is complexity, and it shows up in three places. Latency, because each vendor in a chain adds delay and users feel the total. Redundant checks, because it is easy to pay two providers for the same answer and gain nothing. And fallback logic, because you need clean, tested behavior for when a provider is slow or down. Handled well, all of this is invisible to the customer. Handled poorly, orchestration stacks delays and duplicate calls that raise both cost and friction, quietly undoing the efficiency it was supposed to deliver.
What to watch in the data
- Chained latency. Each vendor in sequence adds delay; watch the end-to-end time users actually experience, not just per-vendor speed.
- Redundant checks. Two providers returning the same answer is money spent for no new information; prune overlapping calls.
- Fallback coverage. Every critical vendor needs a tested failover; an untested fallback is a future outage waiting to happen.
- Vendor error and timeout rates. Rising errors or timeouts on a provider are a signal to reroute before customers feel it.
- Cost per decision. Track spend per decision by path; an expensive route that adds little coverage is a candidate to simplify.
Quick questions
Is orchestration the same as a decision engine?
Not quite. Orchestration coordinates which services get called and combines their results; the decision engine applies rules and scores to make the final call. They work together, and some platforms bundle both.
Why route through one layer instead of calling vendors directly?
Because it centralizes control. You can add, swap, or fail over vendors and change routing without touching product code, which makes the whole stack easier to manage, cheaper, and more resilient.
How does orchestration affect latency?
Every chained vendor call adds delay, so a poorly designed flow can feel slow to users. Good orchestration parallelizes where it can and skips unnecessary checks to keep total time down.
What is a redundant check?
It is calling more than one service that returns essentially the same information, so you pay twice for one answer. Orchestration done well avoids this by routing intelligently based on what is already known.
Why is fallback logic important?
Vendors have outages and slowdowns. Without clean failover, a single provider going down can stall your whole flow. Tested fallback keeps decisions completing even when a service is unavailable.
Go deeper
- FFIEC BSA/AML Examination Manual ↗ — The manual US examiners use to assess BSA and AML programs.
- FTC Consumer Advice: Scams ↗ — US consumer guidance on current scams and fraud, and how to report them.