By Stuart Watkins, CEO, Zenoo
In January, one of the largest identity verification providers in Europe experienced a 14-hour outage. During that window, every client relying solely on that provider could not onboard new customers. Payment processors could not verify merchants. Neobanks could not open accounts. Lending platforms could not run credit checks. Fourteen hours of dead air.
The firms that had a backup plan kept operating. The firms that did not lost a day of revenue, scrambled to apologise to customers stuck in half-completed applications, and then had an uncomfortable conversation with their boards about why a single vendor failure could halt their business.
This is not a theoretical risk. It is an operational reality that most compliance teams have never stress-tested.
The single-vendor model is a concentration risk
Most fintechs and mid-market financial institutions run their KYC on a single provider. One API integration, one contract, one relationship. It makes sense from an implementation perspective: less engineering effort, simpler vendor management, lower initial cost.
But it also means that your ability to onboard customers, verify identities, screen against sanctions lists, and run ongoing monitoring all depend on one company's infrastructure staying operational, one company's data quality remaining consistent, and one company's commercial terms remaining acceptable.
We have seen all three fail in the past 12 months.
A Head of Compliance at a UK-licensed payments company described their experience: "Our provider changed their pricing model with 60 days' notice. Our per-check cost went up 40%. We had no alternative integrated, so we had no negotiating position. We just had to accept it."
Concentration risk in KYC providers mirrors the kind of concentration risk regulators expect you to manage in your customer portfolio. If having 30% of your revenue from a single client is a risk that needs mitigation, why is having 100% of your compliance infrastructure from a single vendor any different?
Data quality varies by jurisdiction, and your provider will not tell you
Every KYC provider claims global coverage. The numbers on their marketing pages look impressive: 190 countries, 200 countries, "global" coverage. But coverage and data quality are not the same thing.
A provider might cover 190 countries in the sense that they can run an identity check in 190 countries. But the depth and reliability of that check varies enormously. Document verification in the UK, where the DVLA database is well-structured and widely accessible, is a fundamentally different proposition from document verification in a jurisdiction where identity documents have fewer security features and registry data is incomplete.
When you rely on a single provider, you inherit their coverage gaps without knowing where they are. Your system reports a "pass" for an identity verification in jurisdiction X, but the underlying check may have been significantly less thorough than the same check in jurisdiction Y. The pass/fail output looks the same. The risk is not the same.
This matters for regulatory purposes. If a regulator asks you to demonstrate that your identity verification processes are appropriate for the jurisdictions you operate in, you need to be able to explain what checks were performed, what data sources were used, and how comprehensive the coverage is. "Our vendor said it passed" is not a compliance position.
API outages are more common than vendors admit
Most KYC providers report uptime of 99.5% to 99.9%. That sounds excellent until you do the maths. 99.5% uptime means 43.8 hours of downtime per year. 99.9% means 8.76 hours. For a business that processes hundreds or thousands of verifications per day, even a few hours of downtime has material commercial impact.
And those are the planned numbers. Unplanned outages, degraded performance (where the API responds but with significantly increased latency or error rates), and partial outages (where some check types work but others do not) are more common than headline uptime figures suggest.
We monitor API availability across multiple KYC providers as part of our orchestration platform. The reality is that most providers experience some form of degraded service multiple times per month. Usually it is brief (minutes rather than hours), but even brief interruptions disrupt customer journeys and create operational headaches.
"We had a candidate go through our onboarding flow during a provider outage. The identity check failed silently. The candidate assumed they had been rejected and went to a competitor. We only found out when we audited our error logs two weeks later. One customer might not sound like much, but it was a corporate account worth six figures in annual revenue."
The commercial trap: no alternative means no negotiation
Vendor lock-in is not just a technology problem. It is a commercial problem. When your entire compliance operation depends on a single provider, you have no credible alternative to reference during contract renewals. The provider knows this. Your procurement team knows this. And the resulting negotiation dynamic favours the vendor every time.
We have seen providers increase pricing by 25 to 40% at renewal when they know the client has no integrated alternative. Migration timelines for KYC providers typically run 3 to 6 months, including re-integration, testing, and regulatory notification. That timeline gives you no real bargaining power in a negotiation with 60 to 90 days' notice.
The firms that negotiate effectively are the ones that have already integrated a second provider, even if they are not using it at full volume. The existence of a working alternative changes the conversation entirely.
Orchestration is not about having more vendors. It is about having options.
The solution is not to replace single-vendor dependency with multi-vendor complexity. Managing six separate API integrations, six contracts, six sets of documentation, and six different data formats is a nightmare that most compliance teams rightly want to avoid.
The solution is an orchestration layer that sits between your application and your verification providers. One integration point. Multiple providers behind it. Intelligent routing that sends each check to the best provider for that specific check type, jurisdiction, and risk tier.
When a provider goes down, traffic routes to the next best alternative automatically. When a provider's data quality degrades in a specific jurisdiction, you switch routing for that jurisdiction without changing anything else. When a provider raises prices, you have a working alternative already integrated and tested.
This is what we built Zenoo to do. Not because orchestration is an interesting technical challenge (though it is), but because we saw compliance teams getting trapped by single-vendor dependency and paying for it in operational risk, commercial bargaining power, and regulatory exposure.
What to look for in your current setup
Here are five signs that your single-vendor dependency is a risk that needs addressing.
1. You have no documented failover plan. If your primary provider goes down right now, what happens? If the answer is "we wait," that is a business continuity gap.
2. Your provider's data quality varies by jurisdiction, but your processes treat all results equally. A pass in the UK and a pass in a lower-coverage jurisdiction are not equivalent. If your system does not differentiate, you have a risk calibration problem.
3. You accepted a price increase at the last renewal because you had no alternative. If your procurement team does not have negotiating power, you are overpaying.
4. You have never tested your provider's claimed coverage against actual results. Run a sample of verifications in your key jurisdictions and check the underlying data sources. You may be surprised by what you find.
5. Your compliance team cannot explain what data sources underlie each check type. If the verification is a black box, you cannot defend it to a regulator.
