Why Owning the KYC Stack Beats Orchestrating It

On 2 July 2025, the Official Journal of the European Union published Commission Delegated Regulation (EU) 2025/532, and one line in it changed how compliance teams should read their own vendor contracts. The regulation requires a financial entity to assess the length and complexity of a supplier’s subcontracting chain, and it states that relying on the vendor’s risk assessment does not limit the entity’s ultimate responsibility.

The dominant KYC architecture of the last five years was built on exactly that reliance. KYC orchestration promised a single pane of glass across many providers, and it delivered on that promise. What it did not deliver was a single owner.

A stack that routes work between vendors and a stack that owns the work are different architectures, and the gap shows up in your audit trail, your approval rate, and your response time when the attack changes.

What is KYC orchestration, and what problem did it solve?

Know Your Customer (KYC) orchestration is a routing layer that sits above several identity and screening providers and decides, per user, which provider to call and in what order. A user from Vietnam might go to one document vendor, a user from Germany to another, and both might hit a third provider for sanctions screening. The orchestration layer holds the logic, and the providers hold the capability.

The model became popular because identity verification requirements vary across markets. No single provider performs equally well across all document types, countries, or use cases. A routing layer allows companies to add specialized providers where needed without replacing their entire verification setup. It also provides flexibility when a provider has limited coverage or experiences an outage. These are practical advantages, but they do not change who performs the verification decision or who remains accountable for the outcome.

Three other factors pushed teams in the same direction. Procurement wanted to swap a provider without paying for a reintegration. Product teams wanted to change a flow without shipping code. And on the risk side, a second opinion on a borderline decision looked like cheap insurance.

None of those benefits addresses the question of who is accountable when the chain produces a bad outcome. Orchestration is a control plane, and a control plane does not change who performs the check or who carries the liability.

Where does an orchestrated KYC stack actually break?

An orchestrated stack breaks in four specific places, and none of them is the routing logic itself. The router usually works. What fails is everything the router cannot reach, which is the accountability for a subcontractor’s failure, the release timeline of a model you do not own, the approval rate you lose at each handoff, and the engineering cost of keeping the connections alive.

Regulators already closed the door on shared accountability

Responsibility for a check does not transfer to whoever performs it. FATF Recommendation 17 on reliance on third parties states that where a firm relies on a third party for customer due diligence, “the ultimate responsibility for CDD measures remains with the financial institution relying on the third party.” Each provider you write to becomes another party whose failure lands on your license.

European rules go further and make the chain itself accessible. Commission Delegated Regulation (EU) 2025/532 on subcontracting arrangements, published in the Official Journal on 2 July 2025, requires a financial entity to weigh “the length and complexity of the chain of subcontractors” before an information and communications technology (ICT) provider may subcontract a service supporting critical or important functions. Article 3(1)(b) requires that the provider be able to identify all subcontractors that support critical or important functions, and Article 3(3) states that leaning on the provider’s own assessment “shall not limit the final responsibility of financial entities”. Those standards supplement the Digital Operational Resilience Act (DORA), which has been in effect since 17 January 2025.

Read together, the three make an orchestrated stack look different on paper. A routing layer calling four providers, two of which subcontract their own models, is a chain you now have to map, assess, and monitor yourself.

Owned Technology Enables Faster Response to New Fraud Attacks

Speed of response is set by whoever owns the model, not by whoever holds the contract. When a new spoofing technique appears, a vendor that licenses its liveness engine waits for its supplier to retrain, test, and release, and only then can it ship that update through its own pipeline.

Tom Gadsden, Vice President of Product at Shufti, frames ownership in terms of the machine learning teams behind the models. “The fact that we have got our own technology, we’ve got our own ML teams, and we can really quickly adapt to changing attack vectors is something that’s critical both for our largest customers but also our smallest customers, who don’t necessarily have the depth of fraud teams or cyber security teams to take all of that burden on themselves.”

Each verification layer you add has its own false rejection rate, and those rates compound rather than average. Gadsden has watched the arithmetic play out. “I’ve seen businesses put seven layers of solutions in front, losing 5-10% at each, and suddenly half your customers are turned away.”

The engineering cost of keeping many connections alive

Each provider in an orchestrated stack is a live integration with its own contract, uptime, schema, and breaking changes. Vendors quote the initial build accurately. What never appears in the business case is the permanent maintenance load that follows.

Roger Redfearn-Tyrzyk, Chief Commercial Officer at Shufti, puts a ceiling on how far that load can stretch. “Technical resources are becoming scarce and expensive, so companies don’t have the luxury of managing 12, 13, 14 different integrations.”

The load also never settles, because the threat it defends against does not sit still. Ray Blake, a former head of compliance and MLRO who now writes The Dark Money Files, describes what happens to a stack nobody tends. “You cannot buy a system, put it in place, fire and forget, and walk away, because the nature of the enemy is changing daily. It’s like when you buy a house plant, put it on the shelf, and a couple of weeks later it’s dead, you didn’t water it, you didn’t look after it. Your systems are exactly the same.”

Multiply that maintenance duty by the number of providers on the decision path, and the real cost of an orchestrated stack turns into an engineering headcount question rather than a licensing one.

What does owning the KYC stack actually mean?

Ownership means the models that produce the decision were built by the company under your contract and run on infrastructure that the company controls. A useful test is narrower than asking whether a vendor wrote every line of code. Ask instead whether any part of the decision path depends on a third party’s release schedule, license terms, or uptime.

The distinction shows up in the layers that carry actual decisions. Optical character recognition (OCR) reads the document. A forensic model decides whether that document was manipulated. A liveness model determines whether the face in front of the camera is a live human. An AML screening engine decides whether a name matches a sanctioned party and at what threshold. Every one of those is a decision you will have to explain to a regulator, and each one licensed from elsewhere is a decision explained by proxy.

Redfearn-Tyrzyk describes the shape most institutions have not yet escaped. “Even in major banks right now, every business function is siloed, onboarding is siloed, PEP and sanctions screening is siloed, KYB is siloed. Newer companies pull everything together because it’s easier to create a risk profile. It’s about bringing it all into one platform with the data flowing in; that’s what the market has been screaming out for. 

Orchestration addresses the interface between those silos, whereas ownership removes them. The practical differences show up in the questions a reviewer asks after something goes wrong. 

How do you tell an owned stack from a re-badged one?

Every vendor in this category says it owns its technology, so the claim by itself provides no information. Four questions separate the ones that do from the ones that resell. Each has a verifiable answer, and a vendor that cannot answer during a first call is telling you something. Ask them in this order, because the later answers only matter once the earlier ones hold.

• Name the subprocessors on the decision path: Ask for the list of third parties that touch a verification decision, not the broader list that touches your data. A vendor that owns its stack answers with a short list or with none. A vendor that orchestrates answers with a diagram. Both answers are legitimate, but only one matches the marketing.
• Ask who ships the fix when a new attack lands: Put a specific scenario to them. A novel injection technique starts passing its liveness check on a Monday. Who writes the patch, who tests it, and what is the median time from detection to production? Owned engines answer with one team and one timeline, while licensed engines answer with a dependency.
• Check the independent benchmark, and check what it covered: Independent testing only proves what was tested. iBeta Level 3 Conformance to ISO/IEC 30107-3 is currently the highest published tier for presentation attack detection, and it matters in this conversation because a vendor cannot submit somebody else’s engine as its own. Ask which component was tested and under which standard.
• Ask what happens when you need the stack on your own servers: Deployment is where borrowed components become visible quickly. A vendor can only offer on-premises or in-region deployment for the parts it controls, so the answer maps the ownership boundary more honestly than any architecture diagram.
• Every vendor claims ownership. Shufti can prove it: Shufti owns and develops the core technology behind its identity verification stack, including OCR, liveness, and fraud detection capabilities. With no outsourced OCR or third-party liveness SDKs on the decision path, Shufti controls how its technology is built, improved, and deployed globally.

Explore the Shufti platform

When does orchestration still make sense?

Orchestration earns its place when the data you need sits outside any single vendor. Some checks are not a technology problem at all. A national identity database, a government registry, or a bank-held record cannot be owned by an identity vendor, so reaching them means integrating with whoever holds the data.

Ammara Mukhtar, Regional Vice President at Shufti, specifically makes the point about address verification. “The future is not fully documentless, and it’s not fully document-based; the future is orchestration, dynamic flows that intelligently decide when the data layer is enough and when stronger document evidence is necessary.”

Read carefully, that is an argument about decision logic rather than about vendor count. Dynamic flows that escalate from a database check to a document check are orchestration in the useful sense, and they work best when both paths run within a single system that can weigh them against each other.

Two different activities share the word. The first, orchestrating decisions, means routing a user to the right check based on risk, geography, or signal quality, which is good engineering that every serious identity verification platform does. The second, orchestrating vendors, means routing a user to a different company depending on which check runs, which is a supply chain that behaves like one.

These situations genuinely call for the orchestrating vendors.

A market where the only accepted proof is state-run: Where a government scheme is the sole acceptable check, integration with it is required rather than a design choice.

A function outside identity altogether: Credit bureau data, payment risk scoring and similar checks sit outside any identity vendor’s scope by definition, and no amount of stack ownership changes that.

Outside those cases, the question worth asking is whether you are buying flexibility or buying a chain.

Data residency is where borrowed components show: Shufti runs the same verification stack with feature parity across cloud, on-premises, hybrid, and air-gapped deployments, with data residency available in the EU, UK, US, Asia Pacific, and the Middle East.

See the deployment options

Shufti’s approach to owning the KYC stack

If you have ever had to explain a verification decision you did not make, you know the specific discomfort of that meeting. The answer sits with a supplier; the supplier’s answer sits with theirs; and the audit pack is assembled after the fact from three systems that were never designed to agree.

Shufti builds and runs its own identity verification models rather than licensing them, so the check that produces your decision belongs to the company under your contract. That has one practical consequence worth more than any architecture diagram. When a decision is questioned, the reasoning, the model version, and the supporting evidence come from a single system and a single accountable party, which is what a reviewer actually needs.

Independent validation backs the part that is hardest to self-certify, with iBeta Level 3 Conformance to ISO/IEC 30107-3 on the liveness engine.