.png){kind=logo}
.jpeg)
%201.png){kind=logo}
01 · RECEIVE
Read the task
Identify the required outcome and available customer context.
KYC orchestration to balance compliance, cost and conversion
A modern KYC orchestration layer coordinates business data providers, identity checks, screening, risk scoring and reviews across multiple vendors so you reach clean decisions faster. Instead of hard-coding flows, teams configure rule-based routing, conditional logic and fallbacks that adapt to country, product and live risk signals. The result is smoother onboarding, fewer false positives and clear audit trails. With Ondorse, orchestration turns policy into outcomes you can measure without slowing delivery.
What KYC orchestration really does
From signal to decision
At its core, orchestration is a workflow engine. It selects the right KYC tasks per applicant, switches providers when needed, escalates checks, or triggers manual review. Think of it as the control plane for your data provider, identity verification and AML stack, with automation first organised in tasks.
An application starts on web or mobile using the white-labeled onboarding Portal. The applicant drops data, fills-in forms and conducts IDV. The system gathers device, IP, geography and form consistency. Rules map those signals to the right level of due diligence. Low-risk applicants follow a light path with a fast vendor. Risky patterns escalate to enhanced checks, extra documents or manual investigation. Each step emits events, reason codes and evidence so product analytics and compliance stay aligned.
Example: a domestic ID on a known device passes selfie match and clean IP, so the light path completes with minimal friction. Another case shows a proxy ASN plus proof of address mismatch. Orchestration adds targeted questions, falls back to a second IDV after a timeout, and keeps reason codes and evidence for both attempts. The audit trail explains every choice.
.webp)
Essential capabilities of an orchestration layer
Before you shortlist platforms, validate these features on real traffic. Each capability should be configurable in a no-code builder and enforceable at runtime.
Use this checklist to evaluate how well a platform automates routing, resilience and explainability:
Conditional routing by country, segment, device risk or velocity, with simple versioning and approvals.
Multi-vendor strategy to pick the best IDV, liveness or screening provider per context, with fallbacks on timeouts or poor coverage.
A/B testing and shadow tests to compare pass rate, latency and cost safely.
Policy-to-logic mapping so CDD and EDD rules become executable conditions instead of static PDFs.
Explainability with reason codes and evidence attached to each decision.
Event model and webhooks so product, risk and data teams share the same timeline.
Case handover to AML investigations with queues, ownership and maker checker.
Analytics for pass rates, drop offs, alert volumes and cost per successful verification.
Why not just use one vendor
No single provider wins everywhere. Coverage, latency and accuracy vary by country, document family and device profile. AML orchestration lets you combine strengths, reduce blind spots and keep leverage in negotiations, all while automating failover and SLA enforcement.
Designing risk based flows
Light, standard and enhanced paths
Spend effort where it pays back and remove friction where it does not. A clear segmentation model keeps decisions consistent and defensible; automation applies it 100% of the time.
Define three paths at minimum, then let orchestration assign them based on score, signals and context. This keeps conversion high for clean segments and depth for risky ones.
Here is a simple baseline that teams can adapt by market, product and risk appetite:
Light: fast IDV and basic screening for low-risk applicants and geographies.
Standard: stronger liveness, proof of address when justified, and full sanctions, PEP and negative news screening.
Enhanced: additional documents, targeted questionnaires and manual review for high-risk sectors or signals.
Policy to logic, with governance
Governance matters as much as checks. Express rules as policy as code with versioning, approvals and maker checker so updates ship without an app release. Keep data lineage for inputs and outputs plus explicit consent records. In Ondorse, compliance writes, product publishes, and the engine enforces.
How orchestration fits in your stack
Orchestration sits between your front end flows and verification providers. It should reduce complexity, not add a new silo. Clear contracts and events keep everything in sync.
These adjacent systems close the loop from onboarding to investigations and reporting:
Customer onboarding: pre-checks, guidance and retries to lift first-try success.
IDV, liveness and screening APIs: normalized fields and consistent errors.
Risk scoring: scores that raise or lower due diligence in real time.
Case management: automatic investigations with evidence attached.
Data warehouse and BI: events and outcomes for long term analysis and lookbacks.
Implementation roadmap
Start focused, measure results, then expand coverage. The goal is to turn policy into an operational risk orchestration flow quickly and safely.
Use the sequence below to shorten time to value and control change risk:
Define segments and required checks, including evidence to store for each decision.
Model rules in plain language, then translate them into executable conditions.
Integrate the first vendor per check type and set timeouts and fallback behavior.
Instrument events and webhooks so product analytics and compliance see the same truth.
Run a controlled test on a small cohort, compare pass rate, latency and cost, and document results.
Roll out by market or product and keep a change log for audits.
Measuring ROI
Orchestration succeeds when it improves acceptance, reduces losses and lowers unit costs. Keep metrics simple and review weekly with a shared dashboard.
Track the following KPIs and segment them by country, path and provider mix:
Acceptance rate of legitimate users by segment and market.
False positive rate in sanctions and adverse media, plus average investigation time.
Cost per successful verification including vendor spend and internal effort.
Time to decision for account opening and for escalations to EDD.
Stability: incident counts, timeout rates and fallback frequency per provider.do
Security and privacy
Identity data is sensitive. The orchestration layer must enforce data minimization, strict RBAC and short retention by default, without manual steps.
Enable the following safeguards as defaults to stay compliant and audit ready:
Encryption in transit and at rest with key rotation.
Least privilege access with SSO and granular roles.
Data residency options for regulated regions and clear deletion flows.
Server side calls for high risk actions and clean separation of secrets.
Industry patterns
Building blocks are consistent, but thresholds and triggers vary by sector. Automation lets you change depth by country, device risk and product tier without bloating the journey.
Fintech and banks
Fast account opening with reliable checks. Light path for low-risk markets, standard path with stronger liveness and screening, and enhanced path with proof of address and manual review when signals justify it. Results are explainable and audit ready.
Crypto and digital assets
Higher inherent risk and frequent policy changes make multi vendor routing and frequent re-screening valuable. Decision logs support regulators and banking partners.
Marketplaces and payments
Verify buyers and sellers and reduce chargebacks. Business onboarding adds KYB and UBO checks with registry data. Rules adapt to ticket size, geography and product category.
Buyer checklist
Many tools look similar on paper. Real differences appear in coverage, control and operating cost. Validate these on your data before you choose.
Assess platforms with this short list so you compare like for like:
Encryption in transit and at rest witCoverage and accuracy by country, document type and device profile.h key rotation.
Control through rules you can adjust without a release cycle.
A/B testing and robust analytics to validate changes safely.
Time to value with quality SDKs, clear docs and a realistic sandbox.
Total cost of ownership including vendor mix and manual workload.
Support with transparent incidents, status pages and change notices.
Notes on authorship and review
Updated October 2025. Reviewed by a compliance lead. Aligned with public guidance from FATF and European supervisory bodies.
Next steps
If you are evaluating KYC orchestration, start by mapping segments and required checks. Choose a platform that supports multi vendor routing, clear reason codes, and native handover to AML case management. Ondorse approaches these needs with policy as code, portable vendor integrations and evidence-first decisioning so teams can prove impact and stay audit ready.
Explore what modern ops teams have built with Ondorse
From banks to insurance and payment companies, meet our customers
Ready to take the manual work out of KYC/B?
Unlock the power of automation
Easy setup that takes just a few days
Friendly human support based in Europe
Frequently asked questions
Buyers often ask how KYC orchestration differs from a simple workflow tool or how to keep conversion high while strengthening controls. Here are concise answers:
How is KYC orchestration different from a workflow builder
Can we raise acceptance without raising fraud
How long does implementation take
KYC orchestration layer
Route every KYC check through the right provider
Coordinate identity, business and AML data providers with conditional routing, fallback logic and consistent outputs. Ondorse helps teams change provider strategy without rebuilding the customer journey or losing execution context.
Need to design the process first? Read the KYC workflow guide.
execution trace · request 84721
INCOMING TASK
Verify business and beneficial owners
Routing policy
version 12
country = FR
entity = SAS
registry ID present
timeout = 4s
PRIMARY
Registry source A
FALLBACK
Registry source B
ENRICHMENT
Ownership source
NORMALISED OUTPUT
Company verified · UBO review required
1.8s
Definition
What is KYC orchestration?
KYC orchestration is the runtime layer that selects, calls and coordinates verification and screening providers according to customer context, policy rules, availability, performance and cost.
It sits between the KYC workflow and the underlying data providers. The workflow defines which outcome is required. Orchestration decides how to obtain it, handles technical responses and returns a consistent result to the rest of the system.
A workflow builder is the interface for configuring steps and rules. Orchestration is the execution layer that applies routing, retries, fallbacks and provider-specific mappings while the flow is running.
Runtime execution
How the orchestration layer handles a check
Every request moves through the same control loop, even when the provider and customer context change.
02 · SELECT
Apply routing rules
Choose the provider strategy for market, risk and product.
03 · EXECUTE
Call providers
Send the mapped request and enforce timeouts and retries.
04 · NORMALISE
Translate results
Return consistent fields, status and reason codes.
05 · OBSERVE
Record the trace
Measure latency, cost, errors, fallback and final outcome.
Conditional provider routing
Select providers according to context
Provider selection should reflect measured coverage and performance. It should not rely on unsupported assumptions about a market or customer group.
Illustrative routing policy
Company verification in three markets
The routing logic uses country, entity type, available identifiers, required fields and provider health to choose an execution strategy.
France
Use the preferred registry source when the company identifier is present. Add ownership enrichment when the required UBO data is incomplete.
United Kingdom
Use the configured Companies House source and apply a second source only when the workflow requires additional ownership evidence.
Other market
Select the provider with validated coverage for that entity type and route unsupported cases to a controlled alternative.
Provider degraded
Pause, retry or use the approved fallback according to task criticality and the configured incident policy.
Illustrative logic only. Actual provider availability, coverage and routing rules depend on the Ondorse configuration and customer requirements.
Multi-provider strategy
Use more than one provider for a reason
A second provider creates value only when the orchestration policy explains when and why it should be used.
Coverage strategy
Route by market or document
Select providers according to validated coverage, data availability and supported document types.
Goal: reduce unsupported journeys.
Resilience strategy
Fallback on technical failure
Use an approved alternative when the primary source times out or returns a technical error.
Goal: contain provider incidents.
Quality strategy
Escalate ambiguous results
Call another source when a result lacks the confidence or evidence required by policy.
Goal: improve decision context.
Cost strategy
Match depth to the task
Avoid expensive enrichment when a simpler source already satisfies the required outcome.
Goal: control unit economics.
Testing strategy
Compare providers safely
Use a bounded test or shadow call to compare coverage, latency, errors and cost.
Goal: make changes with evidence.
Migration strategy
Change without a hard cutover
Shift traffic gradually and monitor outcomes before retiring the previous integration.
Goal: reduce migration risk.
Resilience
Make provider failure an explicit execution path
Fallback does not mean sending every failed request blindly to another provider. The response should depend on the failure type, task and customer state.
Without orchestration
The product integration owns every provider-specific error and recovery decision.
1
The provider times out.
2
The customer sees a generic failure or restarts.
3
Engineering investigates provider-specific logs.
4
A fallback requires a product release.
With an orchestration policy
The execution layer classifies the error and applies the approved response.
1
The timeout is recorded against the provider and task.
2
The policy retries, falls back or holds the request.
3
The customer journey receives a consistent status.
4
The trace preserves both attempts and the final outcome.
Provider abstraction
Normalise outputs without hiding useful detail
Applications should not need to understand every provider’s status codes. Reviewers still need access to relevant source evidence and provider-specific context.
One stable contract for the product
Map provider-specific payloads to a controlled internal schema, while retaining the raw evidence or source reference required for review and audit.
statusCompleted, pending, review required or technical failure.
reason_codesStructured explanations used by workflow and analytics.
evidenceRelevant source results and reviewable supporting material.
provider_traceProvider, attempt, time, latency and technical outcome.
confidenceSource confidence where meaningful and appropriately interpreted.
cost_contextUsage information needed for unit-cost analysis.
Architecture choices
Orchestration versus direct provider integrations
Direct integrations remain valid for simple and stable needs. Orchestration becomes more valuable as providers, markets and routing policies multiply.
| Consideration | Orchestration layer | Direct integrations |
|---|---|---|
| Provider selection | Central conditional routing | Selection implemented in each product flow |
| Error handling | Consistent retry, fallback and status policy | Provider-specific logic maintained internally |
| Output model | Normalised contract with source context | Different payload and status model per provider |
| Provider change | Configuration and controlled traffic shift | Integration and release work may be required |
| Observability | Cross-provider execution trace and metrics | Telemetry assembled across integrations |
| Best fit | Multiple providers, markets or frequent strategy changes | One provider and a stable, narrow use case |
Orchestration analytics
Measure provider performance per task and context
A global pass rate can mislead. Compare providers by country, input quality, document or entity type, workflow route and customer outcome.
Coverage
Requests the provider can complete.
BY MARKET AND TYPE
Latency
Response time and timeout distribution.
P50, P95, P99
Technical errors
Failures unrelated to customer risk.
BY PROVIDER
Fallback rate
Requests requiring another execution path.
BY REASON
Cost per outcome
Provider usage per successful result.
BY STRATEGY
Buyer checklist
How to evaluate a KYC orchestration platform
Test the platform with provider failures and conflicting results, not only a clean demonstration case.
1
Provider and task coverage
Confirm the checks, markets, documents and entity types relevant to your use case.
2
Routing flexibility
Review supported conditions, priorities, branching and change controls.
3
Failure semantics
Distinguish technical failure, unsupported input, ambiguity and customer risk.
4
Fallback governance
Inspect retries, limits, loops, evidence and the customer experience during incidents.
5
Data normalisation
Check stable contracts without losing provider-specific context required for review.
6
Testing controls
Ask how teams compare strategies before shifting production traffic.
7
Execution observability
Review traces, latency, cost, errors and final customer outcomes.
8
Security and data handling
Confirm access, encryption, retention, residency and deletion requirements.
Implementation roadmap
Introduce orchestration one task at a time
Start with a provider interaction where routing, resilience or output consistency creates measurable value.
PHASE 1
Inventory providers
Map tasks, payloads, errors, coverage, costs and dependencies.
PHASE 2
Define the contract
Agree on stable statuses, reasons, evidence and event semantics.
PHASE 3
Configure one route
Implement primary, retry, fallback and hold behaviour for one task.
PHASE 4
Compare and expand
Measure execution quality before adding providers, markets and use cases.
Common questions
KYC orchestration FAQ
How is KYC orchestration different from a workflow builder?
A workflow builder is the interface used to configure steps, rules and outcomes. Orchestration is the runtime layer that selects and calls providers, applies retries or fallbacks, normalises outputs and records the execution trace.
Why use multiple KYC providers?
Providers can differ by market coverage, supported documents, data availability, latency and commercial model. A multi-provider strategy is useful when those differences matter to the customer journey or operational resilience.
Does orchestration automatically guarantee provider failover?
No. Failover must be configured and tested for each task. Some failures should trigger a retry or alternative provider, while others should pause the request or require review.
Can orchestration reduce KYC costs?
It can help teams avoid unnecessary checks, select appropriate sources and measure provider usage. Actual savings depend on volume, routing policy, contracts, provider performance and manual workload.
What data should an orchestration trace contain?
A useful trace includes the task, routing policy version, provider attempts, timestamps, technical outcomes, normalised result, relevant source evidence and the final workflow response.
How should providers be compared?
Compare providers on representative traffic and segment results by market, document or entity type, input quality and workflow context. Review coverage, latency, technical errors, outcome quality and cost together.
Related KYC resources
Connect orchestration to the full KYC stack
This page owns provider execution and routing. The related pages cover process design, configuration, integrations and specific verification needs.
KYC software
Evaluate the complete platform and lifecycle.
PLATFORM GUIDE →
KYC workflow
Design the stages, decisions and exceptions.
PROCESS GUIDE →
KYC workflow builder
Configure workflow rules visually.
BUILDER →
KYC/AML API integration
Connect execution events to product systems.
API INTEGRATION →
KYB verification
Verify companies, ownership and representatives.
KYB →
Customer onboarding software
Manage applicant data collection and UX.
ONBOARDING →
Account-opening fraud prevention
Add fraud signals to routing decisions.
FRAUD PREVENTION →
Provider integrations
Review available Ondorse integrations.
MARKETPLACE →
Review your KYC provider strategy
Bring your current integrations, markets and incident pain points. Ondorse can map where routing, normalisation and fallback logic would simplify execution.