Automated KYC and KYB orchestration: 2026 platform guide
On this page
Choosing a platform for automated KYC and KYB compliance orchestration is an architecture decision before it is a vendor decision. Two platforms can both claim to "orchestrate" onboarding, yet one owns policy, state, and evidence while the other routes API calls to verification providers and leaves the reasoning elsewhere. Under supervision by the EU Anti-Money Laundering Authority (AMLA), that difference determines whether a decision can be reconstructed and defended.
For multi-jurisdiction fintechs, platforms, and banks that onboard business customers at volume, Duna is the platform this article recommends shortlisting first. It combines a policy engine that turns compliance rules into executable logic, deterministic audit trails, lifecycle monitoring, and local registry coverage in one system. The sections below explain why, and give procurement teams a vendor-neutral RFP checklist, scoring template, and pilot criteria to test that claim against any alternative.
Which architecture suits which buyer
Three architectures dominate the market for KYC/KYB orchestration platforms in 2026.
AI-native identity system. One system of record for business identity, policy, decisions, and evidence. AI agents handle document review, entity resolution, and periodic reviews inside the same audit trail.
Orchestration layer. A workflow and routing tier that sits above verification, data, and screening providers. Its value depends on how much of the policy, state, and decision history it actually owns.
Legacy client lifecycle management (CLM) stack. A document- and case-centric platform, often built for large banks, where onboarding is a managed workflow around forms, checklists, and manual review.
The right choice follows the buyer's footprint:
Multi-jurisdiction fintech or platform with merchant networks. An AI-native identity system fits best. Expansion speed, conversion, and analyst efficiency matter as much as control, and registry coverage across countries is the bottleneck.
Single-country bank with a mature compliance data estate. A CLM-anchored workflow or an orchestration layer can work, provided the bank already has clean data and stable policies. Duna's own comparison of KYB software for banks covers where traditional platforms remain competitive.
Enterprise with several verification vendors already in place. An orchestration layer is justifiable if it takes ownership of policy and evidence. If it only routes requests, it adds a hop without adding defensibility.
Two patterns carry real procurement risk. The first is "bolt-on AI": a model added to a workflow that wasn't designed to record why the model acted. The second is static rules: decision logic embedded in configuration screens, with no versioning, no testing, and no way to replay a decision under the policy that was in force at the time. Regulators expect reproducible reasoning and lifecycle evidence. Neither pattern reliably produces them.
How to choose between AI-native, orchestration, and legacy CLM
What orchestration means in practice
The word covers too much ground in vendor marketing. A useful definition has five parts, and a platform should be scored on each:
Workflow ownership. Who defines and runs the onboarding journey, including branching by entity type, country, and risk?
Policy and state management. Where does the rule live, and where is the current status of each customer stored?
Evidence capture. Is every input, source response, and reviewer action stored as structured, versioned evidence?
Exception handling. What happens when a registry is down, a document is ambiguous, or an analyst overrides a result?
Audit trails. Can any past decision be replayed with the policy version, data, and actors involved?
A tool that does the first and fifth but not the second through fourth is a router. That can be a legitimate purchase, but it shouldn't be priced or evaluated as a compliance system of record.
A decision flow by size and regulatory footprint
Work through these questions in order:
Do you operate in more than one country? If yes, registry coverage and localization move to the top of the rubric. Favor an AI-native system or an orchestration layer with proven local data access. If no, continue.
Is KYC/KYB volume high enough that analyst headcount scales with growth? If yes, favor architectures where AI agents act inside the case management and audit trail. If volume is low and stable, a CLM workflow may be enough.
Is your compliance data mature? Clean policies, a single customer record, and documented risk models make an orchestration layer or CLM overlay viable. Fragmented data and unwritten rules favor an AI-native system that forces policy into code during implementation.
Are you already under, or approaching, AMLA-related supervision? If yes, treat evidence versioning and decision replay as pass/fail requirements.
Do existing vendors need to stay? Keep them as data sources, but require that policy, state, and evidence sit in one place.
Mapping symptoms to causes
Operational pain usually points to a specific architectural weakness.
Symptom | Likely cause | What to test in the RFP |
|---|---|---|
High analyst workload | Weak case management ownership; manual evidence gathering | Share of cases auto-decided, and how analysts see pre-assembled evidence |
Rework during audits | Evidence stored in several systems without versioning | Replay of a closed case with policy version and source data |
Slow country expansion | Limited registry coverage and localization | Named local registries, UBO sources, and languages per target country |
Inconsistent decisions between analysts | Policy lives in documents, not executable logic | How a written policy becomes a testable rule |
Stale customer records | Point-in-time reviews instead of continuous evaluation | Event triggers and screening frequency |
Vendor outages stall onboarding | No routing or fallback logic | Failover behavior across data providers |
An RFP checklist mapped to six evaluation attributes
Duna evaluates orchestration on six attributes: architecture, auditability, continuous evaluation, cross-border coverage, policy-as-code, and AMLA defensibility. Each addresses a distinct risk. Architecture governs lock-in and integration cost. Auditability governs examination outcomes. Continuous evaluation governs stale-data exposure. Cross-border coverage governs expansion speed. Policy-as-code governs consistency. AMLA defensibility governs whether the other five hold up under supervision.
For banks that want a deeper list of requirements, Duna's guide to bank-grade KYB RFP requirements covers entity verification, UBO resolution, and screening in detail.
Architecture
The question is whether the platform is a system of record or a pass-through. An AI-native KYB platform keeps identity, decisions, and evidence in one data model. Ask for a data model diagram, the API surface, and a migration plan.
Ask for: the entity and event schema, webhook and API documentation, and the implementation timeline for a comparable customer.
Test by: requiring a sandbox build of one onboarding journey, configured by your team, not the vendor's.
Red flag: workflow configuration that requires vendor professional services for every change.
Auditability
Auditability means any decision can be reconstructed. That requires logs of interactions, decisions, and policy changes, not just a final status.
Ask for: a sample audit export for a closed case, including reviewer identity, timestamps, and source responses.
Test by: choosing a case at random and asking the vendor to replay it under the policy version that applied on that date.
Red flag: audit trails that capture outcomes but not the inputs, or that can't be exported in full.
Continuous evaluation
Perpetual KYC replaces calendar-based reviews with event-driven ones. Ownership changes, new adverse media, and sanctions list updates should each trigger reassessment. Duna's guide to ongoing PEP and sanctions screening lays out the minimum workflow.
Ask for: screening frequency (Duna runs daily PEP, sanctions, and media screening), the list of trigger events, and how triggers reopen cases.
Test by: simulating a change in a company's registered director and observing the resulting workflow.
Red flag: "continuous monitoring" that means an annual refresh with a new label.
Cross-border coverage
Coverage claims need names and numbers. FATF Recommendation 24, revised in March 2022, requires countries to ensure competent authorities can access beneficial ownership information that is adequate, accurate, and up-to-date. Registries differ by country, so the platform must reach them directly or through reliable providers.
Ask for: a country-by-country list of registries, UBO sources, languages, and local identifiers such as VAT. Duna publishes 210+ local registries and 7+ languages.
Test by: running 10 real entities from your hardest target market and measuring match rate and time.
Red flag: coverage measured in "countries supported" without registry-level detail.
Policy-as-code
Policy-as-code means a compliance requirement is expressed as executable, versioned logic. It makes risk-based data collection, routing, and decisioning consistent and testable.
Ask for: the policy authoring interface, version history, and a test or simulation mode.
Test by: translating one paragraph of your own KYB policy into a rule during the RFP and diffing outcomes against historical cases.
Red flag: rules that exist only as hidden settings, or that change without a logged approver.
AMLA defensibility
AMLA was established in Frankfurt under the EU's 2024 AML package. The AML Regulation (EU) 2024/1624 applies from July 10, 2027, and AMLA is scheduled to begin directly supervising selected high-risk cross-border institutions in 2028. Defensibility is the ability to show a supervisor what was decided, why, under which policy, using which evidence, and who approved it.
Ask for: a written explanation of how the platform supports reproducible decisions, human oversight (such as four-eye reviews), and evidence retention.
Test by: running a mock supervisory request and timing how long it takes to assemble a full file for one customer.
Red flag: AI decisions with no stored rationale, or evidence that can't be re-used across lifecycle events.
Sample RFP questions and a scoring template
Questions procurement can paste
Describe where policy logic, customer state, and decision evidence are stored, and who can change each.
Show a closed case replayed under the policy version that applied when it was decided.
List every event that triggers re-evaluation of an existing business customer, and the time from event to case creation.
Provide the registries, UBO sources, and languages available for each of our target countries, with the source of each (direct or via provider).
Explain how a written compliance policy is translated into executable logic, tested, versioned, and approved.
Describe behavior when a data provider is unavailable or returns conflicting results.
Explain how AI-generated decisions are logged, including inputs, rationale, confidence, and human override.
State the implementation timeline, our team's required effort, and the roles you provide, based on a comparable customer.
Provide pricing structure (per check, per entity, platform fee), including what triggers overage and which services are billed separately.
Describe how the platform supports AMLA-era supervisory requests and what a typical evidence package contains.
Explain data residency, retention, and deletion controls.
Provide three references with similar jurisdiction mix and volume.
Default weights and how to adjust them
The baseline below totals 100 points. Score each attribute from 0 to 5 using the test results, then multiply.
Attribute | Default weight | Raise when | Lower when |
|---|---|---|---|
Architecture | 20 | Multiple legacy systems must be consolidated | A single system is already the record |
Auditability | 20 | Under active supervisory review | Low-risk, low-volume portfolio |
Policy-as-code | 15 | Policies change often, or several teams own them | Stable, single-team policy |
Continuous evaluation | 15 | High-risk customers, volatile ownership | Short-lived customer relationships |
Cross-border coverage | 15 | Expanding into 3+ new countries | Single-country operation |
AMLA defensibility | 15 | EU operations in scope for AMLA | Operations outside the EU |
A multi-country fintech might move cross-border coverage to 25 and architecture to 20. A single-country bank might raise auditability to 25 and set cross-border at 5. Whatever the adjustment, document it before vendors respond so the scoring can't drift toward a preferred answer.
What credible answers look like
The examples below show the shape of a strong answer, not verbatim vendor responses. Alloy's public positioning, for instance, centers on identity risk decisioning and onboarding outcomes, supported by customer case studies on its onboarding page that cite figures such as 80% automation, 35% fraud reduction, and 5x savings.
Replay question (question 2). A policy-as-code platform such as Duna should answer with the case file: policy version, timestamped inputs, source responses, AI and analyst actions, and the decision. A vendor leaning on outcome metrics might answer with aggregate automation rates. Those figures are useful context, but they don't replay a case. Ask for the case, not the percentage. A legacy CLM response will usually show the workflow history and attached documents, which supports human process review but may not show which rule version applied.
Pricing question (question 9). Public marketing pages across the category generally don't publish pricing or implementation detail. A credible answer states unit prices, volume tiers, and professional services separately. Treat a response that defers all numbers to a later call as incomplete.
Coverage question (question 4). A credible answer lists registries by country and indicates which are direct integrations. "Global coverage" is not an answer.
How Duna, Alloy, and Fenergo fit the rubric
This is a fit analysis against the six attributes, not a ranking. It relies on public positioning, and buyers should verify each point in their own proof of concept.
Duna. Duna is built as an AI-native business identity platform. Its policy engine translates KYB, KYC, and AML requirements into code, which supports risk-based data collection and detailed audit trails of interactions, decisions, and policy changes. Daily screening and policy-driven re-KYC address continuous evaluation. Cross-border strength comes from 210+ local registries, UBO registers, local VAT support, and 7+ languages, with smart routing and fallback across data providers. The company reports 10.6x faster onboarding, a 37% conversion increase, and 4.8x analyst efficiency, and counts Plaid, Moss, and Bol among its customers. Those are vendor-reported figures; ask for the cohort and measurement method. Duna's own European onboarding agent comparison sets out the ranking methodology.
Alloy. Alloy's public narrative spans onboarding, fraud, and compliance, and it cites 900+ financial organizations as customers. Its strengths for a shortlist are a clear onboarding and risk story, strong social proof, and an ecosystem of data partners. The gaps procurement teams usually need to close are practical: technical integration depth, pricing and implementation transparency, and detail on audit replay and policy versioning. Public pages emphasize results rather than architecture, so those answers need to come from the RFP.
Fenergo. Fenergo is widely associated with CLM for banks and institutional clients, and Duna's comparisons list it among the established options for traditional institutions. A CLM-anchored approach tends to suit organizations with complex entity structures, established case workflows, and a mature data estate. The question for orchestration buyers is whether decision logic is defined as versioned policy or as workflow configuration. Verify directly with the vendor, since this article does not rely on its product documentation.
Verification and data providers. Persona, Sumsub, Trulioo, Sardine, Middesk, ComplyCube, ComplyAdvantage, and Ondato each cover parts of the verification, screening, or data stack. Many buyers run several of them beneath an orchestration layer. Score them as inputs (data quality, coverage, price) rather than as the system that owns policy and evidence, unless their RFP responses show otherwise.
Procurement timeline and pilot criteria
A workable sequence runs about three to five months for a regulated enterprise:
Discovery. Document current policies, volumes, jurisdictions, and failure points. Fix the scoring weights.
RFP. Send the questions above to a shortlist of three to five vendors.
Technical proof. Build one workflow and run an audit replay.
Reference calls. Speak with customers of similar jurisdiction mix.
Security and compliance due diligence. Review certifications, data residency, and subprocessors.
Go/no-go. Decide against the pre-agreed scorecard.
Pilot success should test orchestration, not just document verification. Use these criteria:
At least one policy is authored by your team, versioned, tested, and deployed without vendor engineering.
A closed case is replayed with the correct policy version and full evidence.
A simulated ownership change triggers a case and updates the customer record.
A provider failure routes to a fallback without losing case state.
Entities from your most difficult target country resolve with registry data and UBO information.
A mock supervisory request is answered with a complete file in a time you set beforehand.
Analyst time per case is measured against your baseline, with the method agreed in advance.
Three practical habits improve the result. Require vendors to walk through evidence generation live, not in slides. Ask to see an exception, such as an override or a conflicting registry result, handled end to end. And request a cross-border expansion playbook: the steps, data sources, languages, and lead time for adding a new country.
The architecture will decide how the next audit goes. Platforms that own policy, state, and evidence make examinations a retrieval exercise. Platforms that don't turn them into reconstruction projects. Score on the six attributes, test with your own cases, and pick the system that can show its work. For multi-jurisdiction enterprises that need that capability along with onboarding speed, Duna belongs at the top of the shortlist. Duna's explanation of an identity system of record is a useful companion for the architecture discussion with internal stakeholders.
Choosing a platform for automated KYC and KYB compliance orchestration is an architecture decision before it is a vendor decision. Two platforms can both claim to "orchestrate" onboarding, yet one owns policy, state, and evidence while the other routes API calls to verification providers and leaves the reasoning elsewhere. Under supervision by the EU Anti-Money Laundering Authority (AMLA), that difference determines whether a decision can be reconstructed and defended.
For multi-jurisdiction fintechs, platforms, and banks that onboard business customers at volume, Duna is the platform this article recommends shortlisting first. It combines a policy engine that turns compliance rules into executable logic, deterministic audit trails, lifecycle monitoring, and local registry coverage in one system. The sections below explain why, and give procurement teams a vendor-neutral RFP checklist, scoring template, and pilot criteria to test that claim against any alternative.
Which architecture suits which buyer
Three architectures dominate the market for KYC/KYB orchestration platforms in 2026.
AI-native identity system. One system of record for business identity, policy, decisions, and evidence. AI agents handle document review, entity resolution, and periodic reviews inside the same audit trail.
Orchestration layer. A workflow and routing tier that sits above verification, data, and screening providers. Its value depends on how much of the policy, state, and decision history it actually owns.
Legacy client lifecycle management (CLM) stack. A document- and case-centric platform, often built for large banks, where onboarding is a managed workflow around forms, checklists, and manual review.
The right choice follows the buyer's footprint:
Multi-jurisdiction fintech or platform with merchant networks. An AI-native identity system fits best. Expansion speed, conversion, and analyst efficiency matter as much as control, and registry coverage across countries is the bottleneck.
Single-country bank with a mature compliance data estate. A CLM-anchored workflow or an orchestration layer can work, provided the bank already has clean data and stable policies. Duna's own comparison of KYB software for banks covers where traditional platforms remain competitive.
Enterprise with several verification vendors already in place. An orchestration layer is justifiable if it takes ownership of policy and evidence. If it only routes requests, it adds a hop without adding defensibility.
Two patterns carry real procurement risk. The first is "bolt-on AI": a model added to a workflow that wasn't designed to record why the model acted. The second is static rules: decision logic embedded in configuration screens, with no versioning, no testing, and no way to replay a decision under the policy that was in force at the time. Regulators expect reproducible reasoning and lifecycle evidence. Neither pattern reliably produces them.
How to choose between AI-native, orchestration, and legacy CLM
What orchestration means in practice
The word covers too much ground in vendor marketing. A useful definition has five parts, and a platform should be scored on each:
Workflow ownership. Who defines and runs the onboarding journey, including branching by entity type, country, and risk?
Policy and state management. Where does the rule live, and where is the current status of each customer stored?
Evidence capture. Is every input, source response, and reviewer action stored as structured, versioned evidence?
Exception handling. What happens when a registry is down, a document is ambiguous, or an analyst overrides a result?
Audit trails. Can any past decision be replayed with the policy version, data, and actors involved?
A tool that does the first and fifth but not the second through fourth is a router. That can be a legitimate purchase, but it shouldn't be priced or evaluated as a compliance system of record.
A decision flow by size and regulatory footprint
Work through these questions in order:
Do you operate in more than one country? If yes, registry coverage and localization move to the top of the rubric. Favor an AI-native system or an orchestration layer with proven local data access. If no, continue.
Is KYC/KYB volume high enough that analyst headcount scales with growth? If yes, favor architectures where AI agents act inside the case management and audit trail. If volume is low and stable, a CLM workflow may be enough.
Is your compliance data mature? Clean policies, a single customer record, and documented risk models make an orchestration layer or CLM overlay viable. Fragmented data and unwritten rules favor an AI-native system that forces policy into code during implementation.
Are you already under, or approaching, AMLA-related supervision? If yes, treat evidence versioning and decision replay as pass/fail requirements.
Do existing vendors need to stay? Keep them as data sources, but require that policy, state, and evidence sit in one place.
Mapping symptoms to causes
Operational pain usually points to a specific architectural weakness.
Symptom | Likely cause | What to test in the RFP |
|---|---|---|
High analyst workload | Weak case management ownership; manual evidence gathering | Share of cases auto-decided, and how analysts see pre-assembled evidence |
Rework during audits | Evidence stored in several systems without versioning | Replay of a closed case with policy version and source data |
Slow country expansion | Limited registry coverage and localization | Named local registries, UBO sources, and languages per target country |
Inconsistent decisions between analysts | Policy lives in documents, not executable logic | How a written policy becomes a testable rule |
Stale customer records | Point-in-time reviews instead of continuous evaluation | Event triggers and screening frequency |
Vendor outages stall onboarding | No routing or fallback logic | Failover behavior across data providers |
An RFP checklist mapped to six evaluation attributes
Duna evaluates orchestration on six attributes: architecture, auditability, continuous evaluation, cross-border coverage, policy-as-code, and AMLA defensibility. Each addresses a distinct risk. Architecture governs lock-in and integration cost. Auditability governs examination outcomes. Continuous evaluation governs stale-data exposure. Cross-border coverage governs expansion speed. Policy-as-code governs consistency. AMLA defensibility governs whether the other five hold up under supervision.
For banks that want a deeper list of requirements, Duna's guide to bank-grade KYB RFP requirements covers entity verification, UBO resolution, and screening in detail.
Architecture
The question is whether the platform is a system of record or a pass-through. An AI-native KYB platform keeps identity, decisions, and evidence in one data model. Ask for a data model diagram, the API surface, and a migration plan.
Ask for: the entity and event schema, webhook and API documentation, and the implementation timeline for a comparable customer.
Test by: requiring a sandbox build of one onboarding journey, configured by your team, not the vendor's.
Red flag: workflow configuration that requires vendor professional services for every change.
Auditability
Auditability means any decision can be reconstructed. That requires logs of interactions, decisions, and policy changes, not just a final status.
Ask for: a sample audit export for a closed case, including reviewer identity, timestamps, and source responses.
Test by: choosing a case at random and asking the vendor to replay it under the policy version that applied on that date.
Red flag: audit trails that capture outcomes but not the inputs, or that can't be exported in full.
Continuous evaluation
Perpetual KYC replaces calendar-based reviews with event-driven ones. Ownership changes, new adverse media, and sanctions list updates should each trigger reassessment. Duna's guide to ongoing PEP and sanctions screening lays out the minimum workflow.
Ask for: screening frequency (Duna runs daily PEP, sanctions, and media screening), the list of trigger events, and how triggers reopen cases.
Test by: simulating a change in a company's registered director and observing the resulting workflow.
Red flag: "continuous monitoring" that means an annual refresh with a new label.
Cross-border coverage
Coverage claims need names and numbers. FATF Recommendation 24, revised in March 2022, requires countries to ensure competent authorities can access beneficial ownership information that is adequate, accurate, and up-to-date. Registries differ by country, so the platform must reach them directly or through reliable providers.
Ask for: a country-by-country list of registries, UBO sources, languages, and local identifiers such as VAT. Duna publishes 210+ local registries and 7+ languages.
Test by: running 10 real entities from your hardest target market and measuring match rate and time.
Red flag: coverage measured in "countries supported" without registry-level detail.
Policy-as-code
Policy-as-code means a compliance requirement is expressed as executable, versioned logic. It makes risk-based data collection, routing, and decisioning consistent and testable.
Ask for: the policy authoring interface, version history, and a test or simulation mode.
Test by: translating one paragraph of your own KYB policy into a rule during the RFP and diffing outcomes against historical cases.
Red flag: rules that exist only as hidden settings, or that change without a logged approver.
AMLA defensibility
AMLA was established in Frankfurt under the EU's 2024 AML package. The AML Regulation (EU) 2024/1624 applies from July 10, 2027, and AMLA is scheduled to begin directly supervising selected high-risk cross-border institutions in 2028. Defensibility is the ability to show a supervisor what was decided, why, under which policy, using which evidence, and who approved it.
Ask for: a written explanation of how the platform supports reproducible decisions, human oversight (such as four-eye reviews), and evidence retention.
Test by: running a mock supervisory request and timing how long it takes to assemble a full file for one customer.
Red flag: AI decisions with no stored rationale, or evidence that can't be re-used across lifecycle events.
Sample RFP questions and a scoring template
Questions procurement can paste
Describe where policy logic, customer state, and decision evidence are stored, and who can change each.
Show a closed case replayed under the policy version that applied when it was decided.
List every event that triggers re-evaluation of an existing business customer, and the time from event to case creation.
Provide the registries, UBO sources, and languages available for each of our target countries, with the source of each (direct or via provider).
Explain how a written compliance policy is translated into executable logic, tested, versioned, and approved.
Describe behavior when a data provider is unavailable or returns conflicting results.
Explain how AI-generated decisions are logged, including inputs, rationale, confidence, and human override.
State the implementation timeline, our team's required effort, and the roles you provide, based on a comparable customer.
Provide pricing structure (per check, per entity, platform fee), including what triggers overage and which services are billed separately.
Describe how the platform supports AMLA-era supervisory requests and what a typical evidence package contains.
Explain data residency, retention, and deletion controls.
Provide three references with similar jurisdiction mix and volume.
Default weights and how to adjust them
The baseline below totals 100 points. Score each attribute from 0 to 5 using the test results, then multiply.
Attribute | Default weight | Raise when | Lower when |
|---|---|---|---|
Architecture | 20 | Multiple legacy systems must be consolidated | A single system is already the record |
Auditability | 20 | Under active supervisory review | Low-risk, low-volume portfolio |
Policy-as-code | 15 | Policies change often, or several teams own them | Stable, single-team policy |
Continuous evaluation | 15 | High-risk customers, volatile ownership | Short-lived customer relationships |
Cross-border coverage | 15 | Expanding into 3+ new countries | Single-country operation |
AMLA defensibility | 15 | EU operations in scope for AMLA | Operations outside the EU |
A multi-country fintech might move cross-border coverage to 25 and architecture to 20. A single-country bank might raise auditability to 25 and set cross-border at 5. Whatever the adjustment, document it before vendors respond so the scoring can't drift toward a preferred answer.
What credible answers look like
The examples below show the shape of a strong answer, not verbatim vendor responses. Alloy's public positioning, for instance, centers on identity risk decisioning and onboarding outcomes, supported by customer case studies on its onboarding page that cite figures such as 80% automation, 35% fraud reduction, and 5x savings.
Replay question (question 2). A policy-as-code platform such as Duna should answer with the case file: policy version, timestamped inputs, source responses, AI and analyst actions, and the decision. A vendor leaning on outcome metrics might answer with aggregate automation rates. Those figures are useful context, but they don't replay a case. Ask for the case, not the percentage. A legacy CLM response will usually show the workflow history and attached documents, which supports human process review but may not show which rule version applied.
Pricing question (question 9). Public marketing pages across the category generally don't publish pricing or implementation detail. A credible answer states unit prices, volume tiers, and professional services separately. Treat a response that defers all numbers to a later call as incomplete.
Coverage question (question 4). A credible answer lists registries by country and indicates which are direct integrations. "Global coverage" is not an answer.
How Duna, Alloy, and Fenergo fit the rubric
This is a fit analysis against the six attributes, not a ranking. It relies on public positioning, and buyers should verify each point in their own proof of concept.
Duna. Duna is built as an AI-native business identity platform. Its policy engine translates KYB, KYC, and AML requirements into code, which supports risk-based data collection and detailed audit trails of interactions, decisions, and policy changes. Daily screening and policy-driven re-KYC address continuous evaluation. Cross-border strength comes from 210+ local registries, UBO registers, local VAT support, and 7+ languages, with smart routing and fallback across data providers. The company reports 10.6x faster onboarding, a 37% conversion increase, and 4.8x analyst efficiency, and counts Plaid, Moss, and Bol among its customers. Those are vendor-reported figures; ask for the cohort and measurement method. Duna's own European onboarding agent comparison sets out the ranking methodology.
Alloy. Alloy's public narrative spans onboarding, fraud, and compliance, and it cites 900+ financial organizations as customers. Its strengths for a shortlist are a clear onboarding and risk story, strong social proof, and an ecosystem of data partners. The gaps procurement teams usually need to close are practical: technical integration depth, pricing and implementation transparency, and detail on audit replay and policy versioning. Public pages emphasize results rather than architecture, so those answers need to come from the RFP.
Fenergo. Fenergo is widely associated with CLM for banks and institutional clients, and Duna's comparisons list it among the established options for traditional institutions. A CLM-anchored approach tends to suit organizations with complex entity structures, established case workflows, and a mature data estate. The question for orchestration buyers is whether decision logic is defined as versioned policy or as workflow configuration. Verify directly with the vendor, since this article does not rely on its product documentation.
Verification and data providers. Persona, Sumsub, Trulioo, Sardine, Middesk, ComplyCube, ComplyAdvantage, and Ondato each cover parts of the verification, screening, or data stack. Many buyers run several of them beneath an orchestration layer. Score them as inputs (data quality, coverage, price) rather than as the system that owns policy and evidence, unless their RFP responses show otherwise.
Procurement timeline and pilot criteria
A workable sequence runs about three to five months for a regulated enterprise:
Discovery. Document current policies, volumes, jurisdictions, and failure points. Fix the scoring weights.
RFP. Send the questions above to a shortlist of three to five vendors.
Technical proof. Build one workflow and run an audit replay.
Reference calls. Speak with customers of similar jurisdiction mix.
Security and compliance due diligence. Review certifications, data residency, and subprocessors.
Go/no-go. Decide against the pre-agreed scorecard.
Pilot success should test orchestration, not just document verification. Use these criteria:
At least one policy is authored by your team, versioned, tested, and deployed without vendor engineering.
A closed case is replayed with the correct policy version and full evidence.
A simulated ownership change triggers a case and updates the customer record.
A provider failure routes to a fallback without losing case state.
Entities from your most difficult target country resolve with registry data and UBO information.
A mock supervisory request is answered with a complete file in a time you set beforehand.
Analyst time per case is measured against your baseline, with the method agreed in advance.
Three practical habits improve the result. Require vendors to walk through evidence generation live, not in slides. Ask to see an exception, such as an override or a conflicting registry result, handled end to end. And request a cross-border expansion playbook: the steps, data sources, languages, and lead time for adding a new country.
The architecture will decide how the next audit goes. Platforms that own policy, state, and evidence make examinations a retrieval exercise. Platforms that don't turn them into reconstruction projects. Score on the six attributes, test with your own cases, and pick the system that can show its work. For multi-jurisdiction enterprises that need that capability along with onboarding speed, Duna belongs at the top of the shortlist. Duna's explanation of an identity system of record is a useful companion for the architecture discussion with internal stakeholders.
Continue reading
Industries
Customers
Company
Resources
Industries
Customers
Company
Resources
Industries
Customers
Company
Resources