DEV Community: Stuart Watkins

We spent 6 months feeding our compliance data to a major cloud AI. Here's what we got back.

Stuart Watkins — Thu, 28 May 2026 00:05:14 +0000

TL;DR: We built our first generation of compliance tooling on top of one of the big three cloud AI platforms. We fed it our screening data, our edge cases, our analyst feedback loops. After six months we realised we were training their general-purpose model with our specialist knowledge, and getting back outputs that any other team could buy off the shelf. This is what we learned, what we ripped out, and what we built instead.

The setup that felt clever at the time

When we started building out our screening logic, the path of least resistance was obvious. Plug into a major cloud AI service. Use their text models for entity resolution. Use their classification models for risk scoring. Pipe our analyst review decisions back in as feedback signal. Ship fast, iterate faster.

It felt like the right call. The infrastructure was there. The latency was acceptable. The pricing looked manageable at low volume. And honestly, the demos looked great in front of customers.

What we didn't think about hard enough: every analyst decision we sent back through that pipeline was teaching a general-purpose system how to do compliance work. Our edge cases. Our adverse media patterns. Our PEP disambiguation logic. The stuff our team had spent years getting right.

We were paying for the privilege of training someone else's model with our hardest-won expertise.

Where it actually broke

The technical problems showed up before the strategic ones. Three things hit us in the first quarter.

First, false positive rates were brutal. The general-purpose model was good at language but had no native concept of why a name match in a high-risk jurisdiction matters more than the same match in a low-risk one. We ended up wrapping the AI calls in so much custom logic that the AI was essentially doing string comparison and we were doing the actual compliance work in deterministic code on top.

Second, the model updates broke us. Twice. The platform pushed a new version of the underlying model and our risk scoring drifted. Cases that scored 0.4 on Monday scored 0.7 on Tuesday with no code change on our side. Try explaining that to a regulator. Try explaining it to a customer who has just had their entire alert queue rebalanced overnight.

Third, and this is the one that stung: our outputs started looking suspiciously similar to what other teams in our space were shipping. Same false positive patterns. Same edge case failures. Same blind spots. We were all drinking from the same well and producing the same water.

A Head of Compliance at a UK challenger bank put it to me cleanly when we were doing customer research: "If your model is the same model my last three vendors used, why am I paying you?"

The commoditisation trap

This is where the engineering problem becomes a strategic one. The big cloud AI platforms are doing what Amazon did with Basics. They watch what sells, they generalise it, and they offer the same capability to everyone at a price point that erodes specialist margins.

For compliance specifically, the layers most exposed to commoditisation are clear:

Layer	Commoditisation risk	Why
Basic identity verification	High	Document OCR and liveness are now table stakes
Sanctions list matching	High	Standardised data, standardised algorithms
Generic entity extraction	High	General LLMs are genuinely good at this
Adverse media classification	Medium	Domain nuance still matters
Behavioural transaction monitoring	Lower	Requires longitudinal customer-specific data
Jurisdiction-specific EDD workflows	Low	Regulatory nuance, country-specific patterns

If your product sits in the top three rows and you are running it on a generic cloud AI, you are in trouble. Not next year. Now. Your customers can replicate 70% of what you do with a weekend hackathon and a developer account.

The layers that resist commoditisation are the ones where domain expertise compounds: longitudinal monitoring, jurisdiction-specific workflows, the messy human judgement that wraps the model output. That is where the real product lives.

What we ripped out

We spent the next quarter doing two things in parallel.

We stopped sending analyst feedback to any external general-purpose model. Every decision our team made was a proprietary training signal. We treated it that way. The feedback loop now runs into models we control, on infrastructure we control, with versioning we control.

We also stopped using a single cloud AI as the brain. We moved to a routing pattern where different decisions go to different specialised systems. The routing logic itself became part of the product.

Here is roughly how the decision flow works now:

The key thing in that diagram is the loop at the bottom. Analyst decisions feed our models, not someone else's. The general-purpose AI is still there for narrow tasks, but it never sees the judgement layer.

What changed

Three things got measurably better.

False positive rates dropped because the specialist components were tuned for their narrow tasks rather than being asked to be good at everything. Our team stopped wrapping AI calls in defensive code and started using the outputs directly.

Versioning became boring, which is what you want. We control when our models update. Customers know what version is running. Audit trails are clean. Regulators can be shown a stable, explainable system rather than a black box that drifts every few weeks.

And, less measurable but more important: our outputs stopped looking like everyone else's. Our edge case handling is ours. Our risk scoring reflects how our customers actually think about risk. The product has a point of view again.

What I would tell you to do today

If you are building compliance tooling on top of a major cloud AI right now, three honest questions.

Where does your analyst feedback go? If the answer is "into a general-purpose model we don't control", you are subsidising your competitors and giving away the most valuable training data in your business.

What happens when the underlying model version changes? If you cannot answer that with a specific test plan, you have a regulatory exposure waiting to happen. Compliance systems need stable, explainable behaviour. Drifting model versions are not stable.

Which layers of your product are genuinely defensible? Be honest. If the answer is "all of it because we have great UX", look again. UX is not a moat in compliance. The moat is in the workflow nuance, the domain feedback loops, and the integration depth that took years to build.

The cloud AI platforms are not the enemy. They are excellent infrastructure for the right tasks. The mistake is treating them as the brain of your compliance product. They are not. You are. Or you should be.

Key takeaways

General-purpose cloud AI is great for narrow language tasks and terrible as the decision layer in a compliance product. Use it for what it is good at and stop there.
Every analyst feedback signal you send to an external model is training data you do not own. Treat that data as proprietary or watch it become someone else's commodity feature.
Model versioning matters more in compliance than in almost any other domain. If you cannot tell a regulator exactly which model version produced a decision on a specific date, you have a problem.
Commoditisation is happening at the basic verification, sanctions matching, and generic extraction layers. Build defensibility in workflow, jurisdiction nuance, and longitudinal monitoring instead.
The big cloud platforms are doing the Amazon Basics playbook. Generalise what sells. If your product looks like everyone else's, that is the trap closing.

FAQ

Should compliance teams stop using major cloud AI platforms entirely?

No. They are good infrastructure for narrow tasks like document parsing, language translation, and basic entity extraction. The mistake is using them as the decision layer or feeding proprietary analyst judgement back into them. Use them for what they are good at, control the rest.

What is the biggest risk of building KYC and AML on generic AI services?

Two risks tied together: model version drift breaking your regulatory explainability, and your analyst feedback loop training a general-purpose model that your competitors can also access. The first is an operational risk. The second is a strategic one.

How do you keep compliance AI explainable for regulators?

Control your model versioning, log every decision with the exact model version that produced it, and avoid using black-box general-purpose models as the final decision layer. Specialist models tuned for narrow tasks are easier to explain than a single large model doing everything.

Is specialist RegTech actually different from cloud AI under the hood?

The underlying machine learning techniques overlap, but the difference is in the workflow layer, the feedback loops, and the domain-specific tuning. A specialist platform should own its training data, version its models predictably, and route decisions to components built for the specific compliance task. If a vendor cannot explain how those three things work, they are probably reselling generic AI with a thin wrapper.

What should engineers ask vendors before integrating their compliance AI?

Ask where analyst feedback goes, who owns the resulting training data, how model versions are managed, and what happens during a regulatory audit when you need to explain a specific decision from eighteen months ago. The answers will tell you whether you are buying a product or renting a commodity.

We built Zenoo after living through this exact problem. If you are stitching compliance providers together on top of a generic cloud AI and the seams are starting to show, it might save you the same six months we lost.

Your sanctions screening just broke: managing 50+ data sources without burying your team

Stuart Watkins — Wed, 27 May 2026 07:50:13 +0000

TL;DR: UK compliance teams now face 50+ fragmented sanctions lists requiring real-time monitoring. Without orchestration and proper match testing, alert volumes double overnight. This article walks through the technical problem, how match tuning reduces false positives by 50-70%, and how no-code orchestration keeps your team above water.

Your compliance team screened 200 alerts yesterday. 140 were false positives. Today, you are adding 15 more sanctions lists to monitor in real-time. Without changing your approach, that is 350 alerts tomorrow, 245 of them pointless. This is not sustainable, and regulators will not accept "we are drowning in data" as an excuse for missing actual matches.

I am Stuart Watkins, CEO of Zenoo. We build compliance orchestration infrastructure, and we see this exact scenario playing out at firms across the UK right now. Let me walk you through what is actually happening, why it is happening, and what you can do about it without tripling your headcount.

The 50+ source problem is not theoretical

OFAC's SDN list grew by 3,135 entries in 2024 alone, a 25% increase year on year. That is one list. UK compliance teams must align HMT lists with OFAC, EU, and UN databases, plus sector-specific watchlists, PEP databases, adverse media feeds, and now blockchain analytics sources. The total easily exceeds 50 discrete data sources requiring real-time integration.

Post-Brexit list divergence makes this worse. HMT and EU consolidated lists are no longer in sync. A designation that appears on the EU list on Monday might not hit the UK list until Wednesday. Or it might never appear at all. Your screening infrastructure needs to handle both, plus the jurisdictional logic to know which applies to which transaction.

Then there is the transliteration problem. Arabic, Cyrillic, and Chinese names transliterate differently depending on the source. "Muhammad" has at least 15 common Latin-script variants. When you are screening across 50+ lists, each with its own transliteration conventions, the false positive rate compounds dramatically.

A Head of Compliance at a UK payments firm told us recently: "We went from manageable to unmanageable in about three months. Every new list we added did not just add new names. It multiplied the noise from every existing name."

Daily screening is already obsolete

Here is the technical reality that most screening architectures were not built for: daily batch checks are no longer sufficient. Iranian entities are using P2P crypto and DEX platforms for real-time evasion. By the time your nightly batch runs, the exposure window has been open for hours.

VASPs achieving 97% KYC success rates are combining wallet-aware screening with FATF Travel Rule adherence and enhanced due diligence for illicit address histories. They are not doing this with batch jobs. They are doing it with event-driven architectures that trigger screening on every relevant state change.

The economics are stark. Crypto firms reduce KYC onboarding costs by up to 90% through digital verification. But non-compliance risks daily fines up to £25,000. And that is before you consider the £4 billion settlement precedent that demonstrates just how seriously regulators take enforcement.

Match testing is the highest-use fix most teams skip

Before you rearchitect anything, there is a step that most compliance engineering teams skip entirely: properly testing your match settings.

Fuzzy matching, alias expansion, transliteration handling, phonetic matching. These all have configurable thresholds. Most teams deploy with vendor defaults and never revisit them. The result is a false positive rate that makes the entire screening pipeline operationally useless.

Proper testing of match settings (aliases, fuzzy logic thresholds, transliteration rules) can reduce false positives by 50-70%. That is not a marginal improvement. On a base of 200 alerts per day, a 70% reduction takes you from 140 false positives to 42. At 350 alerts, it is the difference between 245 wasted reviews and 73.

Here is how we think about match testing as a structured engineering problem:

interface MatchConfig {
  fuzzyThreshold: number;       // 0.0 to 1.0, where 1.0 is exact
  aliasExpansion: boolean;
  transliterationMode: 'strict' | 'phonetic' | 'hybrid';
  phoneticAlgorithm: 'soundex' | 'metaphone' | 'doublemetaphone';
  scriptNormalisation: boolean;  // normalise Arabic/Cyrillic to Latin
}

interface TestCase {
  inputName: string;
  expectedMatches: string[];     // known true positives from your list
  expectedNonMatches: string[];  // known false positives you want eliminated
  listSource: 'OFAC' | 'HMT' | 'EU' | 'UN' | string;
}

interface TestResult {
  config: MatchConfig;
  truePositiveRate: number;
  falsePositiveRate: number;
  missedMatches: string[];       // these are the dangerous ones
  alertVolume: number;           // projected daily alerts at this config
}

function evaluateMatchConfig(
  config: MatchConfig,
  testSuite: TestCase[],
  listsUnderTest: string[]
): TestResult {
  // Run each test case against each list with the given config
  // Compare actual matches against expected matches and non-matches
  // Return aggregate metrics
  // The key: you want to MINIMISE falsePositiveRate
  // while keeping missedMatches at ZERO
}

The critical insight: you are not optimising for a single threshold. You are optimising per list source, per script, per name origin. An OFAC fuzzy threshold of 0.75 might be perfect for Latin-script names but catastrophic for transliterated Arabic names. Your test suite needs to reflect this.

Build a test corpus from your own historical alerts. Tag every alert from the past 90 days as true positive or false positive. Then run your match config permutations against that corpus. The 50-70% false positive reduction comes from finding the config that eliminates noise without introducing missed matches.

Orchestration over integration

Once your match settings are tuned, the architectural question is: how do you screen against 50+ sources without building 50+ point-to-point integrations?

The answer is orchestration. A single workflow layer that centralises risk scoring and audit trails across jurisdictional variances without breaking existing transaction flows.

This is where no-code workflow automation becomes genuinely valuable. Not as a marketing buzzword, but as an engineering decision. Every bespoke integration you build is a maintenance liability. Every list-specific adapter you hand-roll needs updating when the list format changes (and they change constantly).

The orchestration layer handles:

Parallel screening across multiple list sources in a single workflow step
Jurisdictional routing so UK transactions screen against HMT whilst US-facing transactions hit OFAC
Consolidated risk scoring that weighs matches across sources rather than treating each as independent
Audit trail generation that regulators can actually follow during an examination
UBO mapping using AI-driven document verification and shell company detection to identify beneficial ownership patterns in sanctions evasion schemes

The UBO mapping challenge is particularly acute. Enhanced KYB integration requires tracing ownership through layers of corporate structure, often across jurisdictions with different disclosure requirements. Without orchestration, this becomes a manual research task that can take days per entity.

What actually changes when you get this right

We have seen teams go from 200 alerts per day (70% false positives) to the same coverage with 50-70% fewer false alerts. The maths is straightforward: fewer false positives means more analyst time on genuine matches, which means better regulatory outcomes and lower risk of the kind of enforcement action that generates £4 billion settlement precedents.

The 90% cost reduction in crypto KYC onboarding is not magic. It is the compound effect of digital verification, automated screening, and proper match tuning replacing manual processes that were designed for a world with five sanctions lists, not fifty.

"We used to treat every new sanctions list as a project," a compliance engineering lead at a UK VASP told us. "Now it is a configuration change. The difference in team capacity is night and day."

Where to start

If you are building compliance flows and facing this exact problem, here is the pragmatic order of operations:

Audit your current match settings. Most teams cannot tell you what fuzzy threshold they are running. Find out.
Build a test corpus from historical alerts. Tag true positives and false positives. This is your ground truth.
Run config permutations. Find the settings that cut false positives by 50-70% without introducing missed matches.
Evaluate orchestration. If you are maintaining more than three list-specific integrations, the maintenance cost already justifies a workflow layer.
Automate continuous screening. Batch processing is not sufficient for real-time evasion patterns. Move to event-driven screening.

If you are building compliance infrastructure and want to see how orchestration works with your own data, check out zenoo.com. We built Zenoo specifically for this problem: centralising KYC, KYB, and AML screening with built-in testing frameworks for match accuracy, so your team spends time on genuine risk instead of chasing noise.

Stuart Watkins is CEO of Zenoo, where we build compliance orchestration infrastructure for firms that would rather catch real matches than drown in false positives.

Why your vendor is making KYB harder than it needs to be

Stuart Watkins — Wed, 27 May 2026 07:45:15 +0000

TL;DR: KYB processes have grown 25% more complex year-over-year, 41% of firms switched vendors in 2025, and 52% of digital onboarding implementations fail due to poor API interoperability. This isn't a regulation problem. It's a vendor architecture problem. And if you're the one stitching these systems together, you already know it.

I've spent 25+ years in identity and digital trust. Most of that time, I was the vendor. I sat in account team meetings watching trust erode, day by day, as our own platform couldn't keep up with what clients actually needed. So when I tell you that most KYB vendors are optimising for their own engineering convenience rather than customer outcomes, I'm not throwing stones from outside. I helped build the glass house.

Let me walk you through what's actually going wrong, and why it matters if you're an engineer building onboarding, compliance, or identity systems.

The architecture that's holding everyone hostage

Here's the situation in plain numbers. Manual KYB still costs £15-£50 per check and takes 3 to 5 days. Automated systems should cost £5-£12 and complete in minutes. The gap between "should" and "does" is where vendor architecture falls apart.

Most KYB platforms were designed as monolithic systems. One database. One decisioning engine. One way to call the API. One way to get data back. They were built when the assumption was: "We'll be the only vendor you need." That assumption was wrong in 2019. It's catastrophic in 2026.

Rigid platforms increase KYB costs by 30% versus modular alternatives. That's not my opinion. That's Forrester. And when deepfake UBO fraud is up 40% in Q1 2026 alone, a static database that refreshes on a schedule rather than in real time isn't just inconvenient. It's dangerous.

What breaks when you try to integrate

52% of digital onboarding implementations fail due to poor API interoperability. If you've ever tried to wire up a KYB vendor's API to your existing stack, that number won't surprise you.

I use what I call the "leave the house" test for every vendor we evaluate at Zenoo:

Phone: Can we just call someone who makes decisions?
Keys: Is there quick API access so we can build and test?
Wallet: How complicated and slow is it to buy?

If a vendor fails all three, what care do you think goes into the actual product?

The pattern I've seen repeated dozens of times: a compliance team picks a vendor based on a slick demo. The engineering team starts integration. Then reality hits. Documentation scores sit at 3.5 out of 5 across the industry (from 231 data points we've tracked across compliance vendors). SDK maintenance is inconsistent. Support response times for production-critical issues are, to put it politely, a documented weakness.

So your engineers spend weeks on workarounds. Your compliance team waits. And your customers, the businesses you're trying to onboard, sit in a queue wondering why it takes 5 days to verify a company that's been on Companies House for a decade.

The false positive tax

Here's a number that should make every engineer building compliance systems wince: the industry average for KYB false positives is 18%. Nearly one in five checks flags something that isn't actually a problem.

That 18% doesn't just mean wasted API calls. It means manual review queues. It means compliance analysts spending hours chasing ghosts. It means your onboarding flow has a leak you can't fix with frontend optimisation because the problem is upstream, in the vendor's matching logic.

With proper ML models, that rate drops to 4%. From 18% to 4%. That's not a marginal improvement. That's the difference between a system that scales and one that drowns your ops team.

Why 41% of firms switched vendors in 2025

Forester reported that 41% of firms changed KYB vendors in 2025 due to platform rigidity. Forty-one percent. That's not normal churn. That's an industry-wide vote of no confidence.

And I get it, because I've been on both sides. When I was the vendor, I watched it happen in slow motion. The client asks for a feature. We say it's on the roadmap. Six months pass. They ask again. We show them a workaround. The workaround breaks something else. Trust erodes. They leave.

UK fintechs are collectively paying £2.1 billion in AML fines, and 73% report KYB as their biggest scaling bottleneck. The bottleneck isn't the regulation. It's vendors building platforms like it's still 2019.

The FCA isn't being subtle about this either. A £28M fine in April 2026 for KYB lapses specifically cited "rigid vendor tech" as a contributing factor. When the regulator starts naming your architecture in enforcement actions, the game has changed.

What actually works (and the trade-offs)

The engineering pattern that's emerging, and that I'm genuinely excited about after years of watching the old model fail, is compliance orchestration. Instead of being locked into one vendor's limitations, you connect best-of-breed KYB providers through a single API layer. Route checks based on risk profiles, costs, and speed requirements. Maintain unified reporting and audit trails.

Is it perfect? No. You're trading one kind of complexity (vendor lock-in) for another (orchestration logic). You need to think carefully about failover, about how you handle disagreements between providers, about how you version your routing rules as regulations change.

But here's the honest comparison from what we see: single-vendor KYB averages around 4.2 days per check. Composable, multi-vendor approaches bring that to 1.8 days. That's not a rounding error. That's the difference between closing a deal and losing it.

One thing you can do today

If you're an engineer maintaining a KYB integration right now, do this: count the hours your team spent last month on workarounds for vendor limitations. Not building features. Not improving your product. Just patching around someone else's architectural decisions.

That number is your vendor tax. And if it's anything like what I've seen across dozens of implementations, it's a lot higher than you think.

We built Zenoo to solve exactly this. If you're stitching compliance providers together and burning engineering time on vendor workarounds, it might save you the same pain.

Jonnie Davis is VP Sales & Partnerships at Zenoo, where he works with compliance and engineering teams who are tired of vendor lock-in. He's spent 25+ years in identity and digital trust, mostly as the vendor, which is why he knows where the bodies are buried.

We built an alert triage system. Then we watched analysts ignore it.

Stuart Watkins — Wed, 27 May 2026 07:40:15 +0000

TL;DR: 95% of AML alerts are noise. We spent years assuming better detection models would fix that. They didn't. The real problem was that our systems couldn't talk to each other. Context, not cleverness, is what separates signal from noise.

I'm going to tell you about a mistake we made early on at Zenoo, because I think most teams building compliance infrastructure are making the same one right now.

We had a client, a mid-size UK payments company, whose compliance team investigated roughly 10,000 AML alerts every month. Statistically, 9,500 were complete rubbish. The other 500 contained maybe three genuine risks worth escalating. Their analysts were spending 80% of their time chasing ghosts, whilst real money laundering slipped through cracks in outdated detection systems.

They asked us to help. We said yes. And then we got it wrong for a while.

The obvious fix that wasn't

Our first instinct was the same as everyone else's: tune the detection rules. Tighten the thresholds. Reduce the volume.

It sort of worked. We cut alert volume by maybe 15%. But the false positive rate barely moved. The 95% noise figure just applied to a slightly smaller pile. Analysts were still drowning, just in a marginally shallower pool.

The reason, which took us longer to see than I'd like to admit, is that AML screening in isolation is fundamentally context-blind. A transaction monitoring system flags a payment because it matches a pattern. But it doesn't know that the KYC check completed two days ago already verified the sender's source of funds. It doesn't know that the sanctions screening system cleared the counterparty six hours earlier. Each system is doing its job perfectly. Together, they're generating chaos.

This is the bit that frustrated me most. We had good technology. Our clients had good technology. And yet the output was still 95% noise.

Alert fatigue is an engineering failure, not a people problem

Here's what happens when you throw 9,500 false positives at a compliance team every month. They stop looking carefully. Of course they do. They're human. You would too.

I spoke to a Head of Compliance at a UK challenger bank about this last year. She described her team's daily workflow as "professional whack-a-mole." Alerts come in, analysts triage them as fast as possible, the queue never gets shorter, and the genuinely suspicious activity hides in the mass of noise like a needle in a haystack made of other needles.

The industry calls this alert fatigue. I'd call it an engineering failure. If your system generates 95% false positives, you haven't built a detection system. You've built a distraction engine.

And the volume is getting worse. Over the past 2 years, the number of AML alerts hitting compliance teams has climbed significantly. Regulatory scope is expanding (hello, AMLA). Transaction volumes are up. New payment rails mean new patterns to screen. The pile grows faster than teams can hire.

What actually fixed it

The breakthrough, and I use that word carefully because it took us months of iteration, was connecting the systems rather than improving them individually.

When your AML screening can see the results of the KYC check that already ran on the same entity, the alert changes. When your sanctions screening result is available in the same context as the transaction monitoring flag, the analyst doesn't need to open four tabs and cross-reference manually. The orchestration layer does that before the alert ever reaches a human.

This isn't AI magic. It's plumbing. It's making sure that when System A flags something, it can see what Systems B, C, and D already know about that entity. Most of the 95% noise disappears not because you've built a smarter model, but because you've given your existing models the context they were missing.

We rebuilt our orchestration layer around this principle. Instead of each compliance check running in its own silo, every check has access to the full context of everything else we know about that entity. The alert that comes out the other end isn't just "this transaction looks suspicious." It's "this transaction looks suspicious AND here's everything else we know, which is: nothing else is wrong."

That second alert gets closed in seconds. The first one used to take an analyst 20 minutes.

The honest trade-offs

I should be straight about what this doesn't solve.

Orchestration adds complexity. You're now dependent on the availability of multiple systems, and if one is slow or down, your alert context is incomplete. We've had incidents where a provider API timeout meant alerts shipped without sanctions context, and our client's team had to triage them manually anyway. We've got better at handling this (graceful degradation, cached results, priority queues), but it's not a solved problem.

Documentation is another area where the industry, us included, could do better. When you're connecting five or six providers through an orchestration layer, the integration documentation needs to be exceptional. Ours scores 3.5 out of 5 based on the feedback we track. That's not good enough and we know it.

And pricing models for orchestrated compliance are genuinely hard to get right. You're asking clients to forecast volumes across multiple check types, and that's difficult when they're scaling. We hear this from clients regularly.

What I'd tell you if you're building this yourself

If you're an engineer at a fintech stitching together AML, KYC, and sanctions providers right now, here's what I wish someone had told me three years ago.

Stop trying to reduce false positives by tuning individual systems. It's a local optimum that doesn't move the needle on the real problem. The 95% false positive rate isn't because your AML tool is bad. It's because your AML tool is blind to everything your other tools already know.

Invest the time in building (or buying) an orchestration layer that shares context across checks. The complexity is real, but the payoff is dramatic. Your analysts go from spending 80% of their time on noise to spending their time on the alerts that actually matter.

And if you're evaluating vendors for this, ask them one question: when an alert fires, what context from other compliance checks is available at the point of triage? If the answer is "none, that's a different system," you're going to end up where we started. Drowning in 9,500 alerts that mean nothing.

We built Zenoo to solve this exact problem. If you're connecting compliance providers and watching your team drown in false positives, it might save you the same pain we went through.

Stuart Watkins is CEO of Zenoo. He's spent 6 years building compliance infrastructure and still spends too many Saturday nights debugging orchestration edge cases.

KYB compliance requirements: what the regulations actually demand

Stuart Watkins — Wed, 27 May 2026 07:30:16 +0000

TL;DR: Global organisations faced £1.23 billion in KYC/AML penalties in H1 2025. TD Bank's £3 billion fine exposed what happens when KYB systems cannot answer basic questions about beneficial ownership. This article breaks down what regulators actually require, where most implementations fall short, and how to structure verification workflows that hold up under scrutiny.

TD Bank's £3 billion penalty was not just about money laundering. It was about a compliance system that could not answer basic questions about customer relationships. When regulators asked about beneficial ownership structures, the bank's fragmented KYB processes could not provide coherent answers.

That is not a one-off. £1.23 billion in global KYC/AML penalties landed in H1 2025 alone. And when you dig into the enforcement actions, the pattern is consistent: the failures are not exotic. They are structural. Organisations either did not collect the right data, did not verify it properly, or could not retrieve it when asked.

If you are building KYB verification systems, this matters. Regulations do not care about your architecture. They care about outcomes. So let us walk through what they actually demand.

The four pillars regulators actually check

Every KYB framework, whether it is EU AMLD5/6, the US Corporate Transparency Act, or the UK's Money Laundering Regulations 2017, boils down to four core obligations. The naming varies. The substance does not.

1. Customer Identification Programme (CIP)

You need to collect and verify foundational business documents: certificate of incorporation, business registration, ownership structure documents, and UBO details for anyone with 25% or more ownership or control.

The implementation question for developers is: what does your data model look like?

interface BusinessEntity {
  registeredName: string;
  registrationNumber: string;
  jurisdictionCode: string; // ISO 3166-1 alpha-2
  incorporationDate: string; // ISO 8601
  registeredAddress: Address;
  ubos: UltimateBeneficialOwner[];
  documents: VerificationDocument[];
}

interface UltimateBeneficialOwner {
  fullName: string;
  dateOfBirth: string;
  nationality: string;
  ownershipPercentage: number; // Must capture >= 25% threshold
  controlType: 'direct_ownership' | 'indirect_ownership' | 'voting_rights' | 'other_control';
  verificationStatus: 'pending' | 'verified' | 'flagged' | 'expired';
  lastVerifiedAt: string; // ISO 8601
}

interface VerificationDocument {
  type: 'certificate_of_incorporation' | 'business_registration' | 'proof_of_address' | 'ubo_declaration' | 'cr12' | 'shareholder_register';
  issuedAt: string;
  expiresAt: string | null;
  documentAgeInDays: number; // Proof of address: enforce 3-month limit
  verificationResult: DocumentVerificationResult;
}

interface DocumentVerificationResult {
  status: 'match' | 'mismatch' | 'unverifiable';
  crossReferencedAgainst: string; // e.g., 'Companies House', 'BRS Kenya'
  discrepancies: string[];
  verifiedAt: string;
}

The documentAgeInDays field is not optional. Most jurisdictions enforce a 3-month document age limit for proof of address. If your system accepts a utility bill from eight months ago, you have a compliance gap.

2. Customer Due Diligence (CDD)

CDD goes beyond collecting documents. You are assessing risk based on industry, geography, UBO nationality, and source of funds. This is where most implementations get lazy.

A risk scoring function needs to account for multiple dimensions:

type RiskLevel = 'low' | 'medium' | 'high' | 'prohibited';

interface RiskAssessment {
  entityRisk: RiskLevel;
  jurisdictionRisk: RiskLevel;
  industryRisk: RiskLevel;
  uboRisk: RiskLevel;
  compositeScore: number; // 0-100
  requiresEDD: boolean;
  factors: RiskFactor[];
}

interface RiskFactor {
  category: 'jurisdiction' | 'industry' | 'ownership_opacity' | 'pep_exposure' | 'adverse_media' | 'sanctions_proximity';
  description: string;
  weight: number;
  source: string; // Which data provider or registry flagged this
}

function requiresEnhancedDueDiligence(assessment: RiskAssessment): boolean {
  return (
    assessment.compositeScore > 70 ||
    assessment.uboRisk === 'high' ||
    assessment.jurisdictionRisk === 'high' ||
    assessment.factors.some(f => f.category === 'pep_exposure')
  );
}

The EU's AMLD6 adds personal criminal liability for compliance officers. That changes the conversation. When a compliance head can face prosecution, your risk scoring system had better be defensible, not just functional.

3. Sanctions and AML screening

Every business entity and every UBO must be screened against OFAC, UN, and EU sanctions lists at a minimum. This is non-negotiable across every jurisdiction we work in.

The technical challenge is not the initial screen. It is the ongoing monitoring. A UBO who was clean at onboarding can appear on a sanctions list three months later. Your system needs to handle that.

interface ScreeningResult {
  entityId: string;
  screenedAt: string;
  listsChecked: ('OFAC_SDN' | 'UN_CONSOLIDATED' | 'EU_SANCTIONS' | 'UK_SANCTIONS' | 'PEP_LISTS')[];
  matches: ScreeningMatch[];
  nextScheduledScreen: string; // Perpetual KYB requires this
}

interface ScreeningMatch {
  listSource: string;
  matchedName: string;
  matchScore: number; // Fuzzy match confidence
  matchType: 'exact' | 'fuzzy' | 'alias';
  requiresManualReview: boolean;
}

4. Recordkeeping and audit readiness

This is the one that caught TD Bank out. You can run every check perfectly and still fail compliance if you cannot retrieve the evidence when regulators ask for it.

Accessible verification records for audits are not just a compliance requirement. They enable faster subsequent verifications and reduced operational overhead. If your first verification of a business entity takes 30 days but your second takes just as long because you cannot find the first one, you have an architecture problem.

The UBO verification bottleneck

Here is where theory meets painful reality. Manual UBO retrieval takes 24 to 30 days. With AI-powered automation, the same process completes in 2 to 3 minutes.

That is not a typo. 30 days versus 3 minutes.

The delay comes from chasing documents across multiple registries, waiting for responses from foreign jurisdictions, and manually cross-referencing ownership chains. When a business has a multi-layered holding structure spanning three countries, an analyst can spend weeks tracing UBOs back to natural persons.

The automation path looks like this: pull registry data via API, cross-reference against multiple sources in parallel, flag discrepancies for human review, and auto-approve clean cases. The verification timeline spectrum runs from automated approvals in minutes, to manual reviews in 1 to 3 business days, to complex cases extending longer.

The factors that determine where a case falls on that spectrum are predictable: jurisdiction transparency, ownership complexity, document availability, and whether the entity operates in a high-risk sector.

The document accuracy problem nobody talks about

Here is a data point that should worry anyone building verification systems: Kenyan KYB checks reveal that 3% of CR12 documents contain mismatched shareholder or director data versus Business Registration Service records.

3% sounds small until you consider volume. If you are processing 10,000 business verifications a year, 300 of them have documents that do not match registry data. Your system needs to catch that programmatically, not rely on an analyst spotting the discrepancy in a PDF.

interface DocumentCrossReference {
  documentSource: string; // e.g., 'uploaded_cr12'
  registrySource: string; // e.g., 'brs_kenya'
  fieldsCompared: FieldComparison[];
  overallMatch: boolean;
  mismatchCount: number;
}

interface FieldComparison {
  fieldName: string; // e.g., 'director_name', 'shareholder_percentage'
  documentValue: string;
  registryValue: string;
  matches: boolean;
  discrepancyType?: 'spelling' | 'outdated' | 'conflicting' | 'missing';
}

This is not a Kenya-specific problem. Every jurisdiction has data quality issues in its business registries. The UK's Economic Crime and Corporate Transparency Act 2023 is trying to address this. From 18 November 2025, Companies House mandates ID verification for new and existing directors and persons with significant control. Existing entities have 12 months to comply.

That is a step forward. But it does not solve the problem for cross-border verification, where you are pulling from registries with wildly different data quality standards.

AMLD5's hidden complexity

Most teams treat KYB as an onboarding event. Run the checks, collect the documents, approve the entity, move on. AMLD5 says otherwise.

The directive mandates periodic UBO reviews and data gap assessments beyond initial onboarding. This means your system needs to handle perpetual KYB: monitoring for ownership changes, watchlist additions, and registry updates on an ongoing basis.

The compliance officers who understand this are the ones building event-driven architectures rather than batch processes. A UBO ownership change should trigger a re-assessment automatically, not wait for a quarterly review cycle.

Industry-specific requirements

Financial services face stricter requirements than crypto exchanges applying KYB to institutional clients, though the gap is narrowing. The EU's MiCA regulation, effective 2026, extends KYB obligations to virtual asset service providers (VASPs) under the FATF Travel Rule.

The practical difference is mostly about enhanced due diligence thresholds and source-of-funds verification depth. Financial services regulators expect more granular ownership tracing. Crypto regulators are still building their enforcement muscle, but the direction of travel is clear.

Where most implementations break down

The real challenge is not any single verification step. It is coordinating CIP, CDD, sanctions screening, and recordkeeping across multiple vendors and data sources in a single coherent workflow.

We built Zenoo to solve exactly this orchestration problem. Instead of stitching together five different provider APIs with custom glue code that nobody wants to maintain, you configure the full verification flow in one place. The compliance logic stays consistent, the audit trail stays complete, and your team spends time on genuine risk decisions instead of fighting integration bugs.

If you are building compliance flows and this resonates, check out zenoo.com. 30 minutes. Your data. No slides.

The real cost of getting this wrong

TD Bank's £3 billion fine came with operational restrictions, leadership changes, and decade-long compliance monitoring. That is not just a financial penalty. It is a business constraint that affects every strategic decision for years.

The organisations that avoid this outcome are not the ones with the most expensive compliance tools. They are the ones with verification systems that can answer any question a regulator asks, quickly, accurately, and with a full audit trail.

That is the bar. Everything else is noise.

Stuart Watkins is CEO of Zenoo, the compliance orchestration platform that connects identity verification, screening, and risk decisioning in a single configurable workflow.

Why 92.5% of identity checks should be automatic (and yours probably aren't)

Stuart Watkins — Wed, 27 May 2026 07:25:09 +0000

TL;DR: Webull Brazil moved from 75.7% to 92.5% auto-approvals by layering device intelligence underneath traditional KYC. Manual reviews collapsed from 19.2% to 2.5%. They caught 7,650+ remote-access fraud devices in a single quarter. Here is the technical breakdown, the TypeScript patterns, and why your document-first flow is optimising for the wrong threat model.

The problem nobody wants to quantify

Last quarter, a crypto platform called Drift lost $285 million because their verification focused on identity documents rather than access patterns. North Korean hackers used legitimate credentials on compromised devices. Perfect KYC, catastrophic outcome.

Meanwhile, most compliance teams are still burning analyst hours confirming that obvious legitimate users are, in fact, legitimate. At 200 daily applications with a 19.2% manual review rate, you are burning 38 analyst hours every single day on cases that device intelligence could resolve in seconds. Scale that to a quarter and the operational drag is brutal.

Webull Brazil decided to measure it. Then they fixed it.

What Webull Brazil actually changed

The traditional KYC flow looks like this:

interface TraditionalKYCFlow {
  documentUpload: PassportData | DriverLicenceData;
  videoInterview?: SelfieComparison;
  nameScreening: SanctionsCheck;
  manualReview: boolean; // binary: yes or no
}

type PassportData = {
  documentNumber: string;
  expiryDate: Date;
  nationality: string;
  ocrConfidence: number;
};

type DriverLicenceData = {
  licenceNumber: string;
  issuingAuthority: string;
  expiryDate: Date;
  ocrConfidence: number;
};

type SanctionsCheck = {
  sanctionsList: string[];
  pepsStatus: boolean;
  adverseMedia: MediaResult[];
};

type MediaResult = {
  source: string;
  severity: 'low' | 'medium' | 'high';
  datePublished: Date;
};

type SelfieComparison = {
  matchScore: number;
  livenessCheck: boolean;
};

The problem is not data quality. Passport OCR works fine. Name screening catches obvious matches. But sophisticated fraudsters do not use their real names on sanctions lists. They use clean documents, often genuine ones, obtained through identity theft or document mills.

Worse, this creates a binary decision: approve or manually review. No middle ground, no risk scoring based on behaviour. That is exactly why 19.2% of Webull's applications needed human review before the upgrade.

Their new approach layers device and location signals underneath the traditional checks:

interface DeviceProfile {
  deviceFingerprint: string;
  isEmulator: boolean;
  hasRemoteAccess: boolean;
  locationSpoofing: boolean;
  deviceAge: number;
  appIntegrity: IntegrityCheck;
}

interface LocationData {
  gpsCoordinates: [number, number];
  networkLocation: [number, number];
  locationConsistency: number; // 0 to 1
  velocityCheck: boolean;
  geofenceStatus: 'inside' | 'outside' | 'unknown';
}

interface IntegrityCheck {
  isRooted: boolean;
  hasVPN: boolean;
  suspiciousApps: string[];
  screenRecording: boolean;
}

interface EnhancedKYCFlow {
  deviceIntelligence: DeviceProfile;
  locationVerification: LocationData;
  traditionalKYC: TraditionalKYCFlow;
  riskScore: number;
  autoDecision: 'approve' | 'review' | 'reject';
}

This changes the question from "Is this person who they claim to be?" to "Is this person behaving like a legitimate user from a trusted environment?"

The numbers that matter

Here is what Webull Brazil achieved in three months:

Metric	Before	After	Change
Auto-approval rate	75.7%	92.5%	+16.8 percentage points
Manual review rate	19.2%	2.5%	-16.7 percentage points
Remote-access devices flagged	Not tracked	7,650+	New capability
Manual review reduction	Baseline	87% drop	Operational savings

The compound effect is significant. If your compliance team handles 1,000 applications weekly, that is 167 fewer manual reviews per week. At £50 per review (conservative estimate for analyst time), you are saving £435,000 annually on operational costs alone.

And those 7,650 flagged devices? Traditional document checks would have missed them entirely. Better security and lower costs. Not opposing forces.

Progressive risk scoring in practice

Instead of binary approve/reject, implement layered scoring:

interface RiskWeights {
  deviceIntegrity: number; // 40% weight
  locationConsistency: number; // 30% weight
  traditionalSignals: number; // 30% weight
}

function calculateRiskScore(profile: EnhancedKYCFlow): number {
  let risk = 0;

  // Device integrity (40% weight)
  if (profile.deviceIntelligence.isEmulator) risk += 40;
  if (profile.deviceIntelligence.hasRemoteAccess) risk += 35;
  if (profile.deviceIntelligence.appIntegrity.isRooted) risk += 15;

  // Location consistency (30% weight)
  if (profile.locationVerification.locationConsistency < 0.7) risk += 30;
  if (!profile.locationVerification.velocityCheck) risk += 20;

  // Traditional signals (30% weight)
  if (profile.traditionalKYC.nameScreening.pepsStatus) risk += 25;
  if (profile.traditionalKYC.documentUpload.ocrConfidence < 0.95) risk += 15;

  return Math.min(risk, 100);
}

interface Decision {
  action: 'auto_approve' | 'enhanced_review' | 'reject';
  confidence: number;
  flaggedSignals: string[];
}

function makeDecision(riskScore: number): Decision {
  if (riskScore <= 15) {
    return { action: 'auto_approve', confidence: 0.95, flaggedSignals: [] };
  }
  if (riskScore <= 45) {
    return {
      action: 'enhanced_review',
      confidence: 0.75,
      flaggedSignals: ['moderate_risk'],
    };
  }
  return {
    action: 'reject',
    confidence: 0.90,
    flaggedSignals: ['high_risk'],
  };
}

The key insight: catch fraud at device level, not document level. Remote access tools, emulators, and location spoofing are immediate red flags that no amount of document verification can overcome.

The compliance workflow that ties it together

Implementing this approach means rethinking your compliance architecture:

interface RiskSignal {
  type: 'device' | 'location' | 'behavioural' | 'document';
  severity: 'low' | 'medium' | 'high' | 'critical';
  timestamp: Date;
  detail: string;
}

interface DeviceFlag {
  deviceFingerprint: string;
  flagReason: string;
  flaggedAt: Date;
  associatedUsers: string[];
}

interface VerificationDecision {
  applicationId: string;
  autoApproved: boolean;
  riskScore: number;
  deviceFingerprint: string;
  flaggedReasons?: string[];
  reviewRequired: boolean;
}

interface ComplianceWorkflow {
  processApplication: (data: DeviceProfile & LocationData) => VerificationDecision;
  updateRiskProfile: (userId: string, newSignals: RiskSignal[]) => void;
  flagSuspiciousDevices: (threshold: number) => DeviceFlag[];
}

Document verification workflows that include manual review average 3.2 hours per check. Device intelligence APIs typically return risk scores in under 200ms. That is the difference between a 47 second onboarding and a 3.2 hour one.

Three things to do differently

Instrument device behaviour from day one. Collect device fingerprints, location data, and network analysis during onboarding. This data becomes more valuable over time as patterns emerge. Retrofitting it later is painful.

Design for false positive optimisation. Traditional KYC optimises to avoid false negatives (missing bad actors). Device intelligence lets you optimise for false positives (reducing manual review) without compromising security. Webull's 87% reduction in manual reviews proves this is not a trade-off.

Measure operational metrics alongside security metrics. Track manual review rates, analyst hours per decision, and automated approval percentages. If 90% or more of your applications can be auto-approved safely, why are your analysts reviewing 75% of them manually?

Before you rebuild everything

Device intelligence requires mobile SDK integration, real-time risk scoring APIs, fraud signal databases, and location verification services. Most teams underestimate the engineering effort. Webull's 92.5% auto-approval rate took three months to achieve, not three weeks.

You do not have to build all of this in-house. Platforms like Zenoo orchestrate these checks across multiple providers, so your team can implement device intelligence without rebuilding the entire compliance stack. The goal is better signals, not more infrastructure.

The identity verification landscape is shifting from document theatre to behavioural analysis. The brutal maths: at $0.47 per automated check versus 3.2 hours of analyst time for manual review, the economics are not even close.

Teams that recognise this shift early will build sustainable advantages. Those that cling to manual processes will find themselves overwhelmed by threats they cannot scale to meet.

Stuart Watkins is CEO of Zenoo, the compliance orchestration platform for fintechs and regulated businesses across Europe and the Middle East.

Building AMLA-Ready Systems: A Developer's Technical Roadmap

Stuart Watkins — Wed, 27 May 2026 07:20:08 +0000

Your compliance team just dropped a bombshell in the Monday standup: "We need to be AMLA-ready by July 2026, and our current AML stack won't cut it." As a developer, you're now staring at 18 months to rebuild critical financial crime prevention systems that need to process millions of transactions while maintaining microsecond response times.

The Anti-Money Laundering Authority (AMLA) isn't just another regulatory checkbox. It's a fundamental shift in how European financial institutions must architect their compliance infrastructure. For developers, this means rethinking data pipelines, API designs, and monitoring systems from the ground up.

Why Your Current Architecture Won't Survive AMLA

Most existing AML systems were built for periodic batch processing and manual review workflows. AMLA demands real-time risk assessment with comprehensive audit trails. If your transaction monitoring system currently processes overnight batches, you're looking at a complete architectural overhaul.

The technical challenges are substantial:

Real-time transaction scoring with sub-100ms latency requirements
Immutable audit logs for every decision point
Dynamic risk model updates without system downtime
Cross-border data sharing with strict privacy controls
Scalable event streaming for high-frequency trading environments

Designing for Real-Time Compliance

The shift to real-time monitoring fundamentally changes your data architecture. Traditional ETL pipelines won't handle the velocity requirements. You need event-driven systems built around streaming platforms like Apache Kafka or AWS Kinesis.

Here's a basic event streaming setup for transaction monitoring:

from kafka import KafkaProducer, KafkaConsumer
import json
import asyncio

class TransactionProcessor:
    def __init__(self):
        self.producer = KafkaProducer(
            bootstrap_servers=['localhost:9092'],
            value_serializer=lambda x: json.dumps(x).encode('utf-8')
        )

    async def process_transaction(self, transaction):
        # Real-time risk scoring
        risk_score = await self.calculate_risk(transaction)

        # Publish to compliance topic
        self.producer.send('compliance-events', {
            'transaction_id': transaction['id'],
            'risk_score': risk_score,
            'timestamp': transaction['timestamp'],
            'decision': 'approved' if risk_score < 0.7 else 'review'
        })

        # Audit trail
        self.producer.send('audit-log', {
            'event_type': 'transaction_processed',
            'transaction_id': transaction['id'],
            'risk_factors': self.get_risk_factors(transaction),
            'model_version': '1.2.3'
        })

The key insight here is separating your business logic from compliance events. Every decision point must be auditable, which means your application architecture needs to be instrumented from day one.

Building Immutable Audit Systems

AMLA's audit requirements go far beyond traditional logging. You need cryptographically verifiable audit trails that can prove the integrity of your compliance decisions months or years later.

Consider implementing an event sourcing pattern where every state change is stored as an immutable event:

type ComplianceEvent struct {
    ID          string    `json:"id"`
    Timestamp   time.Time `json:"timestamp"`
    EventType   string    `json:"event_type"`
    UserID      string    `json:"user_id"`
    Data        []byte    `json:"data"`
    Hash        string    `json:"hash"`
    PrevHash    string    `json:"prev_hash"`
}

func (e *ComplianceEvent) CalculateHash() string {
    record := e.ID + e.EventType + e.UserID + string(e.Data) + e.PrevHash
    h := sha256.New()
    h.Write([]byte(record))
    return hex.EncodeToString(h.Sum(nil))
}

func (store *AuditStore) AppendEvent(event ComplianceEvent) error {
    lastEvent, err := store.GetLastEvent()
    if err != nil {
        return err
    }

    event.PrevHash = lastEvent.Hash
    event.Hash = event.CalculateHash()

    return store.persistEvent(event)
}

This creates a blockchain-like audit trail where tampering with any historical record becomes immediately detectable.

API Design for Cross-Border Data Sharing

AMLA requires seamless information sharing between financial institutions across EU member states. Your APIs need to handle complex authentication, data sovereignty requirements, and real-time notifications.

Design your compliance APIs with these principles:

# OpenAPI spec for AMLA compliance endpoint
paths:
  /compliance/suspicious-activity:
    post:
      summary: Report suspicious activity
      security:
        - OAuth2: [compliance.write]
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                transaction_id:
                  type: string
                  format: uuid
                risk_indicators:
                  type: array
                  items:
                    type: string
                jurisdiction:
                  type: string
                  enum: [DE, FR, IT, ES, NL]
                data_classification:
                  type: string
                  enum: [public, restricted, confidential]

Pay special attention to data classification. Different risk indicators have different sharing rules under GDPR and AMLA. Your API design must enforce these rules at the schema level.

Infrastructure Considerations for Scale

AMLA compliance isn't just about functionality – it's about performing that functionality at scale. A major European bank processes over 50 million transactions daily. Your infrastructure needs to handle this volume while maintaining audit integrity.

Consider a microservices architecture with dedicated compliance services:

# docker-compose.yml for compliance infrastructure
version: '3.8'
services:
  risk-engine:
    image: compliance/risk-engine:latest
    environment:
      - KAFKA_BROKERS=kafka:9092
      - REDIS_URL=redis:6379
    resources:
      limits:
        memory: 2G
        cpus: "1.0"

  audit-service:
    image: compliance/audit-service:latest
    volumes:
      - audit-data:/var/lib/audit
    environment:
      - POSTGRES_URL=postgresql://audit:password@postgres:5432/audit

  notification-service:
    image: compliance/notifications:latest
    environment:
      - AMLA_ENDPOINT=https://amla.europa.eu/api/v1
      - WEBHOOK_SECRET=${WEBHOOK_SECRET}

The separation of concerns here is crucial. Each service has a single responsibility and can be scaled independently based on load patterns.

Monitoring and Observability

Your compliance system is only as good as your ability to observe its behaviour. AMLA audits will examine not just what decisions you made, but how quickly you detected and responded to problems.

Implement comprehensive observability:

import prometheus_client
from prometheus_client import Counter, Histogram, Gauge

# Compliance-specific metrics
transactions_processed = Counter('compliance_transactions_total', 
                               'Total transactions processed', 
                               ['status', 'risk_level'])

processing_latency = Histogram('compliance_processing_seconds',
                             'Time spent processing transactions')

false_positive_rate = Gauge('compliance_false_positive_rate',
                           'Current false positive rate')

@processing_latency.time()
def process_compliance_check(transaction):
    try:
        result = perform_compliance_check(transaction)
        transactions_processed.labels(
            status='completed',
            risk_level=result.risk_level
        ).inc()
        return result
    except Exception as e:
        transactions_processed.labels(
            status='failed',
            risk_level='unknown'
        ).inc()
        raise

The 18-Month Implementation Strategy

With 18 months until AMLA goes live, your development roadmap needs careful prioritisation. We explored this in depth on the Zenoo blog, but here's the technical perspective:

Months 1-6: Foundation

Migrate to event-driven architecture
Implement immutable audit logging
Set up real-time monitoring infrastructure

Months 7-12: Integration

Build AMLA-compliant APIs
Implement cross-border data sharing
Develop automated reporting systems

Months 13-18: Optimisation

Performance tuning for production scale
Comprehensive testing and validation
Staff training and documentation

The technical debt you accumulate in the first phase will haunt you in the final months. Build it right from the start, even if it takes longer initially.

Testing Your AMLA Implementation

Compliance systems require different testing strategies than typical business applications. You need to test not just happy paths, but regulatory edge cases and audit scenarios.

import pytest
from unittest.mock import Mock

class TestComplianceWorkflow:
    @pytest.fixture
    def mock_transaction(self):
        return {
            'id': 'txn_123',
            'amount': 50000,
            'currency': 'EUR',
            'sender_country': 'DE',
            'receiver_country': 'NL',
            'timestamp': '2024-01-15T10:30:00Z'
        }

    def test_high_risk_transaction_triggers_manual_review(self, mock_transaction):
        # Test that transactions above threshold trigger review
        processor = ComplianceProcessor()
        result = processor.evaluate_transaction(mock_transaction)

        assert result.requires_manual_review is True
        assert 'high_amount' in result.risk_factors

    def test_audit_trail_completeness(self, mock_transaction):
        # Verify every compliance decision is auditable
        processor = ComplianceProcessor()
        processor.evaluate_transaction(mock_transaction)

        audit_events = processor.get_audit_trail(mock_transaction['id'])
        assert len(audit_events) > 0
        assert all(event.has_required_fields() for event in audit_events)

Your test suite should include scenarios for cross-border transactions, high-risk jurisdictions, and various suspicious activity patterns that AMLA will scrutinise.

Final Thoughts

AMLA compliance isn't just a regulatory requirement – it's an opportunity to build better, more observable, and more reliable financial systems. The architectural patterns required for AMLA compliance (event sourcing, immutable audit trails, real-time processing) are the same patterns that create resilient, scalable applications.

The 18-month countdown is real, but with proper planning and the right technical approach, your team can build systems that not only meet AMLA requirements but set a new standard for compliance technology architecture.

Start with your data flows. Everything else follows from there.

We replaced 73 hours of weekly alert triage with 10 AI agents. Here is what the architecture looks like.

Stuart Watkins — Wed, 27 May 2026 06:55:09 +0000

TL;DR: Most compliance teams spend 73 hours a week on alert triage. Around 95% of those alerts are noise. We built 10 AI agents that investigate alerts in parallel, reversing the time ratio so analysts spend 70% of their time on genuine risk instead of confirming nothing is wrong. This post walks through the architecture, the pain points that drove it, and what actually changed.

Last month, a compliance engineer at a European neobank showed me their Grafana dashboard. 200 alerts a day. Average handling time: 22 minutes per alert. That is 73 hours of analyst time per week, burned on triage.

The worst part? By the FCA's own estimates, around 95% of those alerts turn out to be false positives. Senior analysts, people you are paying £75k or more, spending their days confirming that nothing is wrong.

If you are building compliance infrastructure and this sounds familiar, this post is for you.

The problem is not detection. It is investigation.

Threshold-based transaction monitoring systems are good at flagging. They are terrible at context. A £9,500 transfer triggers the same alert whether it is a first-time sender to a high-risk jurisdiction or a recurring payment to a known supplier.

The analyst then has to pull together data from four or five sources manually: transaction history, screening results, corporate registry data, adverse media, and prior case notes. That is the 22 minutes. Not the decision. The assembly.

McKinsey's 2024 KYC/AML Benchmark found that banks across North America, Europe, and Asia-Pacific allocate 10-15% of full-time employees to KYC and AML tasks. Most of that time goes to manual data reconciliation, document collection, and routine alert processing. The actual risk judgement, the thing you hired analysts for, gets squeezed into whatever time is left.

Why threshold-based systems keep failing

If you have worked with traditional AML monitoring, you know the pattern:

interface ThresholdRule {
  ruleId: string;
  metric: 'transaction_amount' | 'frequency' | 'jurisdiction_risk';
  operator: 'gt' | 'lt' | 'eq';
  threshold: number;
  action: 'flag' | 'block' | 'escalate';
}

const legacyRules: ThresholdRule[] = [
  {
    ruleId: 'CTR-001',
    metric: 'transaction_amount',
    operator: 'gt',
    threshold: 9500,
    action: 'flag',
  },
  {
    ruleId: 'FREQ-003',
    metric: 'frequency',
    operator: 'gt',
    threshold: 5,
    action: 'escalate',
  },
];

Rigid. Context-free. Every rule generates alerts independently, with no correlation between them. The system does not know (or care) that the customer has made this same payment monthly for two years.

The industry is shifting toward AI-driven predictive analytics that analyse transaction records, ambient risk metrics, and behavioural trends. But most teams I talk to are still stuck on the threshold model, drowning in alerts they cannot turn off because the regulator expects a documented reason for every rule change.

What a multi-agent investigation architecture looks like

When we built this at Zenoo, we made a deliberate choice: not a chatbot. Not a single model doing everything. 10 agents, each with a specific investigation responsibility.

Here is a simplified version of how the orchestration works:

interface InvestigationAgent {
  agentId: string;
  role: AgentRole;
  dataSources: string[];
  outputSchema: string;
  maxLatencyMs: number;
}

type AgentRole =
  | 'transaction_pattern'
  | 'screening'
  | 'adverse_media'
  | 'corporate_registry'
  | 'pep_check'
  | 'jurisdiction_risk'
  | 'behavioural_baseline'
  | 'document_verification'
  | 'network_analysis'
  | 'case_synthesis';

interface AlertInvestigation {
  alertId: string;
  customerId: string;
  agents: InvestigationAgent[];
  status: 'pending' | 'investigating' | 'synthesised' | 'escalated';
  startedAt: number;
  completedAt: number | null;
}

interface SynthesisResult {
  alertId: string;
  riskScore: number;
  recommendation: 'dismiss' | 'review' | 'escalate';
  evidence: AgentFinding[];
  confidence: number;
}

interface AgentFinding {
  agentRole: AgentRole;
  finding: string;
  dataSource: string;
  relevance: number;
}

The key design decisions:

Parallel, not sequential. All 10 agents run concurrently against the same alert. The case_synthesis agent waits for findings from the other nine before producing a recommendation. This is what collapses the investigation time.

Each agent owns its data source. The screening agent connects to sanctions lists. The corporate_registry agent pulls UBO data and cross-references it. The adverse_media agent runs real-time searches. No agent tries to do everything.

Typed output schemas. Every agent returns a structured AgentFinding with a relevance score. The synthesis agent does not have to parse free text. It works with structured evidence.

Human-in-the-loop for escalations. The agents investigate. Analysts decide. The 70/30 time ratio reversal means analysts now spend 70% of their time on genuine risk cases and 30% on reviewing dismissed alerts, instead of the other way around.

How perpetual KYC fits in

One of the architectural patterns we see gaining traction is perpetual KYC (pKYC): continuous, event-driven monitoring rather than periodic reviews. When a customer's status changes (a new PEP designation, a sanctions list update, a significant change in transaction behaviour), the system automatically recalculates their risk score and triggers a review if needed.

This is the "event-driven compliance" shift the industry has been talking about, and it maps cleanly to an agent-based architecture. Each status change event fans out to the relevant agents. The synthesis agent determines whether the change is material enough to warrant analyst attention.

For KYB specifically, this matters even more. Manual KYB processes take 24 to 30 days on average. AI-powered verification can reduce that to 2 to 3 minutes for UBO verification and cross-referencing against global sanctions lists. But the real value is not just speed at onboarding. It is continuous monitoring of corporate structures that change.

AMLD5 mandates online personal information checks for financial businesses and emphasises KYB in AML compliance. Paired with PSD2's API-based data sharing requirements, the regulatory direction is clear: automated, continuous, and auditable.

What actually changes

The Head of Compliance at a UK challenger bank we work with put it bluntly: "We were hiring analysts to feed the alert queue. Now we are hiring analysts to investigate actual risk."

The numbers tell the story. When you take 200 daily alerts and run them through 10 investigation agents in parallel, the 95% that are false positives get documented, evidenced, and dismissed automatically. The remaining 5% arrive on an analyst's desk with a full investigation package: transaction patterns, screening results, corporate registry data, adverse media findings, and a synthesised risk assessment.

That is the difference between a chatbot and an investigation architecture. A chatbot answers questions. Agents do the work.

If you are building compliance flows

The compliance failures in KYC, AML, and fraud controls are the top cause of neobank shutdowns. Weak controls are not just a regulatory risk. They are an existential one.

If you are an engineer building these systems, the architecture choices you make now (threshold vs. predictive, sequential vs. parallel, chatbot vs. multi-agent) determine whether your compliance team scales or drowns.

We have built this at Zenoo so teams do not have to architect it from scratch. 10 agents. Full investigation pipeline. Not a chatbot.

If you are building compliance integrations and want to see how the orchestration works with your own data, check out zenoo.com.

Stuart Watkins is CEO of Zenoo, where he builds compliance infrastructure for fintechs and financial institutions.

The KYB glossary: 47 terms your compliance team actually uses

Stuart Watkins — Wed, 27 May 2026 06:45:03 +0000

TL;DR: Terminology mismatches between compliance vendors cause real integration failures. This glossary defines 47 KYB terms your compliance team actually uses, organised by workflow stage, with enough regulatory context to stop you shipping broken configurations. Bookmark it. You will need it.

Three weeks lost to a string mismatch

A compliance team we work with spent three weeks debugging a KYB workflow failure last year. Alerts were firing on every single entity check. The root cause was not a code defect. Their sanctions provider and their entity verification vendor used the term "enhanced screening" to mean completely different things. One meant risk-scored PEP matching. The other meant document-level verification with source-of-funds checks. The integration layer treated them as interchangeable. They were not.

This is not an edge case. When technology now handles 100% of identity checks and transaction monitoring in modern KYB frameworks, inconsistent terminology does not just confuse people. It breaks pipelines.

I have compiled the 47 terms that actually come up in implementation conversations, mapped to the regulations that mandate them and the workflow stages where they matter. If you are building compliance integrations, or configuring a platform that orchestrates multiple providers, this is the reference you keep open in a tab.

Core entity and identity terms

These are the foundations. Get these wrong and every downstream check inherits the confusion.

1. Know Your Business (KYB)

The process of verifying the legitimacy of a company before entering a business relationship. Distinct from KYC, which focuses on individuals. KYB covers entity existence, ownership structure, regulatory status, and risk profile.

2. Know Your Customer (KYC)

Identity verification for individuals. In a KYB context, KYC applies to the natural persons behind the entity: directors, shareholders, UBOs.

3. Ultimate Beneficial Owner (UBO)

The natural person who ultimately owns or controls the legal entity. Most jurisdictions set a threshold (commonly 25%) above which a person must be identified and verified. Getting UBO identification wrong is one of the fastest ways to fail an audit.

4. Legal Entity Identifier (LEI)

A 20-character alphanumeric code assigned to legal entities participating in financial transactions. Useful for unambiguous entity resolution across data sources.

5. Corporate Registry

The government-maintained database where companies are incorporated and file statutory documents. In the UK, that is Companies House. Under ECCTA 2023, March 2026 reports show companies expanding digital verification services to integrate directly with these registries at scale.

6. Authorised Signatory

An individual with legal authority to sign documents and enter agreements on behalf of the entity. Not always the same as a director or UBO.

7. Nominee Shareholder

A person or entity holding shares on behalf of the real owner. Nominee structures are not inherently suspicious, but they require deeper investigation to identify the true beneficial owner.

8. Shell Company

A legal entity with no active business operations or significant assets. Often legitimate (holding structures, SPVs), but a common vehicle for money laundering when layered.

9. Person of Significant Control (PSC)

UK-specific term for individuals who hold significant influence or control over a company. Filed with Companies House and a key data point in any UK-focused KYB workflow.

10. Certificate of Incorporation

The official document confirming that a company has been legally registered. The starting point for entity verification.

11. Articles of Association

The internal rules governing a company's operations. Relevant for KYB because they define decision-making authority and share structures.

Due diligence terms

This is where most terminology confusion lives. The gap between CDD and EDD is not academic. It maps directly to different API calls, different data requirements, and different regulatory obligations.

12. Customer Due Diligence (CDD)

The standard verification of customer and beneficial owner identities before establishing a business relationship. Mandated by UK MLR 2017 Regulation 27, which covers core KYB entity checks. CDD is your baseline.

13. Enhanced Due Diligence (EDD)

Additional checks triggered by high-risk scenarios. Under MLR 2017 Regulation 33, high-risk clients like PEPs trigger mandatory EDD procedures. EDD is not "more CDD". It involves different data sources, different risk thresholds, and different approval workflows. Teams that conflate CDD and EDD waste time running the wrong checks on the wrong entities.

14. Simplified Due Diligence (SDD)

Reduced checks permitted for demonstrably low-risk situations. Rare in practice, because most compliance teams default to CDD as a safety net.

15. Source of Funds (SoF)

Verification of where the money in a transaction originates. A core EDD requirement.

16. Source of Wealth (SoW)

Verification of how the individual or entity accumulated their overall wealth. Broader than SoF and typically required for high-net-worth or PEP-connected entities.

17. Risk Assessment

A written evaluation of money laundering and terrorist financing risks, required under MLR 2017 Regulation 21. This is not a one-time exercise. It should inform every configuration decision in your compliance platform.

18. Risk Appetite

The level of risk an organisation is willing to accept. Defined by the business, not the regulator. Your risk appetite determines your CDD/EDD thresholds, your screening sensitivity, and your auto-approve criteria.

19. Risk Scoring

The algorithmic or rule-based assignment of a risk level to an entity based on multiple data points. The output of risk scoring determines whether the entity proceeds through CDD or escalates to EDD.

Screening and monitoring terms

Screening is where multi-vendor terminology gaps cause the most integration damage. ComplyAdvantage, Sumsub, and other providers use varying definitions for the same concepts, creating training complications and configuration errors for teams using multiple vendors.

20. Politically Exposed Person (PEP)

An individual who holds or has held a prominent public function. PEP status is a primary trigger for EDD. Modern frameworks automate 100% of PEP screening, but the definition of "prominent public function" varies by jurisdiction and provider.

21. Sanctions Screening

Checking entities and individuals against government-maintained sanctions lists (OFAC, EU, UN, UK HMT). A hard block: sanctioned entities cannot be onboarded. Period.

22. Adverse Media Screening

Searching news and media sources for negative information about an entity or its connected persons. Sometimes called "negative news screening". The scope and freshness of media sources vary significantly between providers.

23. Watchlist

A consolidated list of sanctioned individuals, entities, and PEPs maintained by a screening provider. Not the same as a government sanctions list; watchlists aggregate multiple source lists.

24. Fuzzy Matching

An algorithm that returns results for approximate, not just exact, name matches. Essential for catching transliterated names, aliases, and misspellings. Also the primary driver of false positives.

25. False Positive

A screening alert that, upon investigation, does not represent an actual match. Industry data consistently shows false positives are the dominant compliance cost driver. Reducing them without increasing false negatives is the core screening optimisation problem.

26. True Positive

A screening alert that, upon investigation, confirms an actual match. The signal in the noise.

27. Ongoing Monitoring

Continuous review of business relationships to ensure data currency and transaction alignment with risk profiles. Mandated by UK MLR 2017 Regulation 28. Not a periodic review. Ongoing means ongoing: triggered by events, not calendars.

28. Transaction Monitoring

Automated analysis of financial transactions to detect patterns indicative of money laundering, terrorist financing, or fraud. Runs continuously and generates alerts for analyst review.

29. Threshold-based Alerts

Alerts triggered when a transaction exceeds a predefined value or frequency. Simple, high false-positive rate, but still a regulatory expectation.

30. Suspicious Activity Report (SAR)

A formal report filed with the relevant Financial Intelligence Unit (FIU) when suspicious activity is detected. In the UK, filed with the NCA. Non-negotiable obligation with strict timelines.

Workflow and orchestration terms

This is where implementation meets regulation. If you are building or configuring compliance workflows, these terms map directly to your architecture decisions.

31. Workflow Orchestration

The coordination of multiple compliance checks (identity, screening, risk scoring, document verification) into a single, sequenced flow. This is the layer where terminology consistency matters most, because orchestration platforms must translate between different provider vocabularies. It is the exact problem that leads teams to platforms like Zenoo, which unify different provider terminologies into a consistent framework.

32. Multi-vendor Integration

Connecting two or more third-party compliance providers into a single workflow. The source of most terminology confusion, because each vendor defines and labels their checks differently.

33. API Orchestration

Using APIs to sequence and coordinate calls to multiple compliance services. Distinct from simple API integration because orchestration involves conditional logic, error handling, and data mapping between providers.

34. Decisioning Engine

The rules or ML-based system that takes inputs from screening, verification, and scoring and produces a pass/fail/refer outcome. The final step before an entity is onboarded or escalated.

35. Case Management

The system for tracking, investigating, and resolving compliance alerts and escalations. Where analysts spend most of their time.

36. Audit Trail

A complete, timestamped record of every check, decision, and action taken during a compliance process. MLR 2017 Regulation 40 requires 5-year record retention, meaning your audit trail must be durable, immutable, and queryable for at least five years after the business relationship ends.

37. Four-eyes Principle

A control requiring two independent reviewers to approve high-risk decisions. Common in EDD workflows and SAR filing.

38. Straight-through Processing (STP)

An entity passes all checks and is onboarded without manual intervention. The goal for low-risk entities. Your STP rate is one of the best indicators of how well your workflow is configured.

39. Manual Review Queue

The backlog of entities that failed STP and require human analyst investigation. The size of this queue is directly proportional to your false positive rate and your screening sensitivity settings.

Regulatory and framework terms

These are the three critical regulations that come up in almost every KYB implementation conversation, plus the broader frameworks they sit within.

40. MLR 2017 Regulation 27

The UK regulation mandating core KYB entity checks, including CDD. The starting point for any UK-focused compliance workflow.

41. MLR 2017 Regulation 33

The risk escalation regulation. Triggers mandatory EDD procedures for high-risk clients, including PEPs. Clear understanding of the risk threshold terminology in Reg 33 is essential for correct workflow configuration.

42. MLR 2017 Regulation 47

Requires firms to maintain documented policies, controls, and procedures for mitigating ML/TF risks. This is the regulation that demands procedure standardisation, and it is the regulatory basis for having a consistent glossary in the first place.

43. MLR 2017 Regulation 40

The 5-year record retention requirement. Every check, every assessment, every record: retained for at least five years post-relationship.

44. MLR 2017 Regulation 28

Mandates ongoing monitoring. Not periodic. Ongoing. Your platform configuration must reflect this.

45. ECCTA 2023 (Economic Crime and Corporate Transparency Act)

UK legislation that expands Companies House verification powers and introduces new identity verification requirements for directors and PSCs. March 2026 reports show this is driving significant expansion of digital verification services.

46. FATF Recommendations

The 40 recommendations from the Financial Action Task Force that form the global baseline for AML/CFT frameworks. Most national regulations (including MLR 2017) are implementations of FATF guidance.

47. AML Directive (AMLD)

The EU's Anti-Money Laundering Directives. Currently on the sixth iteration (6AMLD). Relevant for UK firms with EU clients or operations, and a common source of cross-jurisdictional terminology differences.

Why this glossary exists as a technical problem

The head of compliance engineering at a UK challenger bank put it to us this way: "We spent more time in the first quarter mapping field names between providers than we did writing business logic. Every vendor calls the same check something different, and our orchestration layer has to translate all of it."

That is not a training problem. It is an architecture problem. When your sanctions provider calls something "enhanced screening" and your entity verification vendor uses the same label for a completely different process, your integration layer needs an explicit mapping. And that mapping needs to be maintained, versioned, and tested.

With technology now handling 100% of PEP and sanctions screening in modern frameworks, inconsistent terminology does not just slow down onboarding. It corrupts your automated decisioning. A misconfigured label means the wrong check runs, the wrong risk score is assigned, and the wrong decision is made. All without a human ever seeing the error.

Keeping this useful

Bookmark this page. Share it with your compliance team and your engineering team. When you are configuring a new provider integration or debugging a workflow that is producing unexpected results, check the definitions here against what your vendors actually mean.

If you are building compliance flows that orchestrate multiple providers, check out zenoo.com. It is built to solve exactly the terminology and orchestration problem this glossary documents.

30 minutes. Your data. No slides.

Stuart Watkins is CEO of Zenoo, the compliance orchestration platform for fintechs and regulated businesses.

Why Your API Gateway Might Be Your Biggest Compliance Liability

Stuart Watkins — Wed, 27 May 2026 06:35:03 +0000

Why Your API Gateway Might Be Your Biggest Compliance Liability

Your microservices architecture handles thousands of customer verification requests per hour. Data flows between services, gets cached in Redis, logged to Elasticsearch, and backed up to S3. Everything works beautifully until your compliance team drops a bombshell: "We need to demonstrate GDPR compliance for all customer data processing within 48 hours."

Suddenly, your elegant distributed system becomes a compliance nightmare. Where exactly does customer data live? Which services process PII? How do you implement data deletion across 20 microservices? This isn't just a theoretical problem — 83% of organisations report that their technical architecture actively hinders compliance efforts.

The Hidden Compliance Debt in Modern Applications

Compliance isn't just a business problem anymore. It's deeply embedded in your technical decisions. Every API endpoint you design, every database schema you create, and every third-party service you integrate carries compliance implications.

Consider a typical user onboarding flow:

# Seemingly innocent user registration
@app.route('/api/users', methods=['POST'])
def create_user():
    user_data = request.get_json()

    # Store in primary database
    db.users.insert(user_data)

    # Queue for email verification
    celery.send_task('send_verification_email', args=[user_data])

    # Log for analytics
    analytics.track_event('user_registered', user_data)

    # Cache for performance
    redis.setex(f"user:{user_data['id']}", 3600, json.dumps(user_data))

    return {'status': 'created'}

This simple endpoint has just created compliance obligations across four different systems. Under GDPR, you now need to track, audit, and potentially delete this data from all locations. Your innocent performance optimisation just became a compliance liability.

Data Residency: The Geographic Minefield

Cloud-native applications often span multiple regions for performance and reliability. But compliance regulations don't respect your architectural decisions. Russia's data localisation laws require citizen data to be stored domestically. China's Cybersecurity Law has similar requirements. Even GDPR has specific rules about data transfers outside the EU.

Here's where it gets technically complex:

# Kubernetes deployment that might violate data residency
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: user-service
        image: myapp/user-service:v1.2.3
      nodeSelector:
        # This could place EU citizen data in US nodes
        zone: performance-optimised

Your autoscaler optimises for performance, but compliance requires geographic awareness. You need deployments that understand data sovereignty:

# Compliance-aware deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-eu
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: user-service
        image: myapp/user-service:v1.2.3
        env:
        - name: DATA_REGION
          value: "EU"
      nodeSelector:
        kubernetes.io/region: eu-west-1
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: compliance-zone
                operator: In
                values: ["gdpr-compliant"]

The Audit Trail That Breaks Your Database

Compliance requires detailed audit logs: who accessed what data, when, and why. For a traditional application, this might mean adding a few database triggers. For microservices, it's an architectural challenge.

Every data access needs context:

// Compliance-aware data access
type ComplianceContext struct {
    UserID      string    `json:"user_id"`
    RequestID   string    `json:"request_id"`
    Purpose     string    `json:"purpose"`
    LegalBasis  string    `json:"legal_basis"`
    AccessedAt  time.Time `json:"accessed_at"`
    AccessedBy  string    `json:"accessed_by"`
    DataFields  []string  `json:"data_fields"`
}

func (s *UserService) GetUser(ctx context.Context, userID string, purpose string) (*User, error) {
    // Create audit record before data access
    auditCtx := ComplianceContext{
        UserID:     userID,
        RequestID:  getRequestID(ctx),
        Purpose:    purpose,
        LegalBasis: deriveLegalBasis(purpose),
        AccessedAt: time.Now(),
        AccessedBy: getCurrentUser(ctx),
    }

    user, err := s.repo.FindByID(userID)
    if err != nil {
        return nil, err
    }

    // Log specific fields accessed
    auditCtx.DataFields = getAccessedFields(user)
    s.auditLogger.Log(auditCtx)

    return user, nil
}

This audit data grows fast. A busy application might generate millions of audit events daily. Your compliance requirements just became a big data problem.

Third-Party Services: The Compliance Wild Card

Modern applications integrate dozens of third-party services. Each integration is a potential compliance risk. Your Stripe integration processes payment data under PCI DSS. Your Twilio SMS service handles customer communications. Your analytics platform tracks user behaviour.

The challenge isn't just technical, it's contractual and legal:

// Hidden compliance risks in common integrations
const integrations = {
  stripe: {
    complianceFrameworks: ['PCI-DSS'],
    dataProcessing: 'payment information',
    dataRetention: '7 years',
    dataLocation: 'global'
  },

  segment: {
    complianceFrameworks: ['GDPR', 'CCPA'],
    dataProcessing: 'behavioral analytics',
    dataRetention: 'indefinite',
    dataLocation: 'US primary'
  },

  intercom: {
    complianceFrameworks: ['GDPR', 'CCPA'],
    dataProcessing: 'customer communications',
    dataRetention: 'customisable',
    dataLocation: 'US/EU hybrid'
  }
};

Building Compliance into Your Architecture

Compliance-first architecture starts with data classification. Not all data requires the same protection level:

# Data classification schema
from enum import Enum

class DataSensitivity(Enum):
    PUBLIC = "public"          # Marketing content, public profiles
    INTERNAL = "internal"      # Operational data, logs
    SENSITIVE = "sensitive"    # PII, contact information
    RESTRICTED = "restricted"  # Financial data, identity documents

class DataClassification:
    def __init__(self, sensitivity: DataSensitivity, 
                 retention_period: int,
                 geographic_restrictions: List[str] = None):
        self.sensitivity = sensitivity
        self.retention_period = retention_period
        self.geographic_restrictions = geographic_restrictions or []

    def storage_requirements(self):
        if self.sensitivity == DataSensitivity.RESTRICTED:
            return {
                'encryption': 'AES-256',
                'access_logging': True,
                'backup_encryption': True,
                'geographic_isolation': True
            }
        # ... other levels

Your data models should embed compliance metadata:

class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    email = db.Column(db.String(120), 
                     data_classification=DataClassification(
                         DataSensitivity.SENSITIVE, 
                         retention_period=2555  # 7 years in days
                     ))
    payment_method = db.Column(db.Text, 
                              data_classification=DataClassification(
                                  DataSensitivity.RESTRICTED,
                                  retention_period=3650,
                                  geographic_restrictions=['PCI-compliant-regions']
                              ))

The Platform Approach: Orchestrating Compliance

At Zenoo, we've seen organisations struggle with the complexity of implementing compliance across distributed systems. The solution isn't to bolt compliance onto existing architecture, but to build platforms that handle compliance orchestration.

Modern compliance platforms provide APIs that abstract the complexity:

// Compliance-orchestrated user verification
const verificationResult = await zenoo.verify({
  type: 'individual',
  data: userData,
  checks: ['identity', 'sanctions', 'pep'],
  jurisdiction: 'EU',
  retentionPolicy: 'gdpr-standard'
});

if (verificationResult.approved) {
  // Platform handles audit trails, data retention, geographic compliance
  await createUser(userData);
}

The Cost of Compliance Neglect

Ignoring compliance in your architecture isn't just risky, it's expensive. The average cost of retrofitting compliance into existing systems is 3-5x higher than building it in from the start. Plus, non-compliance penalties can be severe: GDPR fines can reach 4% of global turnover.

We explored this in depth on the Zenoo blog, looking at how organisations can balance innovation with regulatory requirements.

Making Compliance a Technical Advantage

Compliance doesn't have to slow down development. Well-designed compliance architecture can actually improve your system:

Better data governance leads to higher data quality
Audit requirements drive better observability
Data classification enables more targeted performance optimisation
Privacy controls often improve security posture

The key is treating compliance as a first-class architectural concern, not an afterthought. Your future self (and your compliance team) will thank you.

Start with data classification, build audit trails into your data access patterns, and consider geographic data placement from day one. The regulatory landscape will only get more complex, but your architecture can be ready for it.

Building Compliance APIs: Why Single-Vendor Solutions Break at Scale

Stuart Watkins — Wed, 27 May 2026 06:30:05 +0000

Building Compliance APIs: Why Single-Vendor Solutions Break at Scale

Your compliance API just hit 10,000 KYC checks per day, and suddenly your single-vendor solution is throwing 504 timeouts during peak hours. Sound familiar?

I've watched countless engineering teams face this exact scenario. What starts as a simple integration with one KYC provider becomes a distributed systems nightmare when business requirements evolve. Let me walk you through the architectural decisions that can save you months of technical debt.

The Hidden Complexity of Compliance Infrastructure

Compliance APIs look deceptively simple from the outside. Send a user's details, get back a pass/fail response. But peek under the hood and you'll find:

Document verification services with 99.2% uptime (not 99.9%)
Identity databases that rate-limit aggressively during fraud spikes
Sanction screening APIs that can take 30+ seconds for complex cases
Regional data residency requirements that fragment your architecture

When you're building on a single vendor, you're essentially running a distributed system with only one node. Every outage becomes your outage. Every performance bottleneck becomes your bottleneck.

// What your code looks like with a single vendor
async function performKYC(userData) {
  try {
    const result = await singleVendorAPI.verify(userData);
    return result;
  } catch (error) {
    // If this fails, your entire KYC pipeline is down
    throw new Error('KYC verification failed');
  }
}

When Single Vendors Make Sense (Yes, Really)

Despite the scaling issues, single-vendor solutions aren't inherently wrong. They excel in specific scenarios:

Early-stage startups processing fewer than 1,000 verifications monthly often benefit from the reduced integration overhead. Your engineering team can focus on core product features rather than building compliance infrastructure.

Highly regulated industries with strict audit requirements sometimes prefer the simplified compliance story. Having one vendor means one security assessment, one data processing agreement, one point of regulatory responsibility.

Geographically constrained businesses operating in a single region might find that one vendor covers all their regulatory requirements without the complexity of routing logic.

But here's the critical insight: these advantages disappear the moment you need to scale beyond your vendor's limitations.

The Orchestration Alternative: Building Resilient Compliance

Orchestration platforms flip the script. Instead of being locked into one provider's infrastructure decisions, you get to make your own architectural choices:

// Orchestration approach with failover
async function performKYC(userData, config) {
  const providers = config.providers; // [vendorA, vendorB, vendorC]

  for (const provider of providers) {
    try {
      const startTime = Date.now();
      const result = await provider.verify(userData);

      // Log performance metrics
      metrics.recordLatency(provider.name, Date.now() - startTime);

      if (result.confidence > config.minimumConfidence) {
        return result;
      }
    } catch (error) {
      // Log error and try next provider
      logger.warn(`Provider ${provider.name} failed:`, error);
      continue;
    }
  }

  throw new Error('All KYC providers failed');
}

Designing Your Orchestration Layer

The key to successful orchestration lies in understanding that compliance providers aren't commodity APIs. Each has different strengths, pricing models, and failure modes.

Provider Selection Logic

# Example routing configuration
routing_rules:
  - condition: "country == 'GB'"
    primary_provider: "uk_specialist"
    fallback_providers: ["global_provider_a"]

  - condition: "document_type == 'passport'"
    primary_provider: "document_specialist"
    fallback_providers: ["global_provider_b"]

  - condition: "risk_score > 7"
    providers: ["high_accuracy_provider"]
    require_manual_review: true

Handling Response Normalisation

Different vendors return data in completely different formats. Your orchestration layer needs to normalise these into a consistent schema:

interface NormalisedKYCResult {
  status: 'approved' | 'rejected' | 'manual_review';
  confidence: number; // 0-10 scale
  checks: {
    identity: CheckResult;
    document: CheckResult;
    address: CheckResult;
    sanctions: CheckResult;
  };
  metadata: {
    provider: string;
    processingTime: number;
    costInCredits: number;
  };
}

function normaliseVendorAResponse(rawResponse: VendorAResponse): NormalisedKYCResult {
  return {
    status: mapVendorAStatus(rawResponse.verification_result),
    confidence: rawResponse.score * 10, // Vendor A uses 0-1 scale
    checks: {
      identity: {
        passed: rawResponse.identity_check === 'PASS',
        details: rawResponse.identity_details
      },
      // ... map other fields
    },
    metadata: {
      provider: 'vendor_a',
      processingTime: rawResponse.processing_time_ms,
      costInCredits: calculateCost(rawResponse.service_level)
    }
  };
}

Performance Monitoring and Circuit Breakers

In a multi-vendor setup, monitoring becomes crucial. You need real-time visibility into each provider's performance:

class ProviderCircuitBreaker {
  constructor(provider, config) {
    this.provider = provider;
    this.failureThreshold = config.failureThreshold || 5;
    this.resetTimeout = config.resetTimeout || 60000;
    this.state = 'CLOSED'; // CLOSED, OPEN, HALF_OPEN
    this.failureCount = 0;
  }

  async call(method, ...args) {
    if (this.state === 'OPEN') {
      if (Date.now() - this.lastFailureTime > this.resetTimeout) {
        this.state = 'HALF_OPEN';
      } else {
        throw new Error(`Circuit breaker OPEN for ${this.provider.name}`);
      }
    }

    try {
      const result = await this.provider[method](...args);
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      throw error;
    }
  }

  onSuccess() {
    this.failureCount = 0;
    this.state = 'CLOSED';
  }

  onFailure() {
    this.failureCount++;
    this.lastFailureTime = Date.now();

    if (this.failureCount >= this.failureThreshold) {
      this.state = 'OPEN';
    }
  }
}

The Infrastructure Trade-offs

Here's where it gets interesting from an ops perspective. Orchestration introduces complexity that your infrastructure needs to handle:

Latency considerations: Your P95 response time is now bounded by your slowest provider, not your fastest. You'll need timeout strategies and async processing for slow checks.

Cost optimisation: Different providers have different pricing models. Some charge per API call, others use credit systems, some have monthly minimums. Your orchestration layer should route based on cost efficiency, not just accuracy.

Data residency: GDPR and other regulations mean you can't always use your preferred provider. Your routing logic needs to understand where data can legally be processed.

Implementation Patterns That Work

After working with compliance teams at Zenoo, I've seen a few patterns that consistently work:

Start with two providers minimum - Even if you're small, the redundancy pays for itself during the first major outage
Build provider-agnostic data models first - Don't let your database schema mirror one vendor's API structure
Implement gradual rollouts - When adding new providers, route 5% of traffic initially and monitor quality metrics
Cache aggressively - Many compliance checks on the same user data within 24 hours can use cached results

We explored this in depth on the Zenoo blog, examining how different orchestration strategies impact both technical performance and regulatory compliance outcomes.

The Bottom Line for Engineering Teams

Single-vendor solutions optimise for initial development speed at the cost of long-term flexibility. Orchestration platforms optimise for operational resilience at the cost of initial complexity.

The inflection point typically occurs around 5,000-10,000 monthly verifications, when provider limitations start impacting user experience. But the architectural decisions you make early determine how painful that transition becomes.

If you're building compliance infrastructure today, assume you'll need multiple providers eventually. Design your data models, error handling, and monitoring with that future in mind. Your future self (and your on-call rotation) will thank you.

Stuart Watkins is CEO of Zenoo, a compliance orchestration platform that helps engineering teams build resilient KYC and AML infrastructure.

Why Your Identity Verification API Keeps Breaking (And How to Build Resilient Auth Systems)

Stuart Watkins — Wed, 27 May 2026 06:25:04 +0000

Why Your Identity Verification API Keeps Breaking (And How to Build Resilient Auth Systems)

Your identity verification service just went down. Again. The third-party KYC provider you integrated six months ago is returning 500 errors, your users can't sign up, and your product manager is asking why the "simple" identity check is taking three hours to fix.

If this sounds familiar, you're experiencing the hidden complexity of digital identity verification. While it might seem like a straightforward API call, identity verification sits at the intersection of multiple fragmented systems, regulatory requirements, and data sources that change without warning.

The Technical Reality Behind Identity Verification

Modern identity verification isn't a single service—it's an orchestration of multiple data sources, each with different APIs, response formats, and reliability characteristics. When you call what looks like one endpoint, here's what typically happens under the hood:

// What you think you're doing
const result = await identityProvider.verify({
  documentImage: userDocument,
  selfieImage: userSelfie,
  personalData: userData
});

// What's actually happening
const documentCheck = await ocrProvider.extractData(userDocument);
const livenessCheck = await biometricProvider.verifyLiveness(userSelfie);
const sanctionsCheck = await complianceProvider.checkSanctions(userData);
const addressCheck = await dataProvider.verifyAddress(userData.address);
const fraudCheck = await fraudProvider.assessRisk(userData);

// Then somehow aggregate all these results
const result = aggregateResults([documentCheck, livenessCheck, sanctionsCheck, addressCheck, fraudCheck]);

Each of these services has different uptime guarantees, response times, and failure modes. When one fails, your entire verification process fails.

Why Single-Provider Solutions Create Technical Debt

Most developers start with a single identity verification provider because it seems simpler. You integrate one SDK, make one API call, and move on. But this approach creates several technical problems:

1. Vendor Lock-in with No Fallback Strategy

// Typical single-provider implementation
class IdentityVerifier {
  constructor() {
    this.provider = new VendorAProvider(apiKey);
  }

  async verify(userData) {
    try {
      return await this.provider.verify(userData);
    } catch (error) {
      // What now? No fallback option
      throw new Error('Identity verification failed');
    }
  }
}

When this provider goes down, changes pricing, or fails to meet new regulatory requirements, you're forced into an emergency migration.

2. Hidden Regional Limitations

Identity verification providers often have different capabilities across regions. Your chosen provider might excel at UK driving licences but struggle with German ID cards. By the time you discover this, you're already committed to their data formats and integration patterns.

3. Compliance Gaps That Appear Over Time

Regulatory requirements change frequently. A provider that meets today's AML requirements might not support tomorrow's new sanctions lists or enhanced due diligence rules.

Building Resilient Identity Architecture

The solution isn't to avoid identity verification—it's to architect your system for the inevitable changes and failures. Here's how to build a resilient identity verification system:

Design for Multiple Providers from Day One

class IdentityOrchestrator {
  constructor() {
    this.providers = {
      primary: new ProviderA(configA),
      secondary: new ProviderB(configB),
      compliance: new ComplianceProvider(configC)
    };
    this.rules = new VerificationRules();
  }

  async verify(userData, options = {}) {
    const strategy = this.selectStrategy(userData.region, options.riskLevel);

    try {
      const results = await Promise.allSettled([
        this.providers[strategy.primary].verify(userData),
        this.providers.compliance.checkSanctions(userData)
      ]);

      return this.aggregateResults(results, strategy.rules);
    } catch (error) {
      return this.fallbackVerification(userData, strategy);
    }
  }

  selectStrategy(region, riskLevel) {
    // Route based on data residency, provider strengths, cost
    return this.rules.getStrategy(region, riskLevel);
  }
}

Implement Circuit Breakers for Each Service

class ProviderCircuitBreaker {
  constructor(provider, threshold = 5, timeout = 60000) {
    this.provider = provider;
    this.failures = 0;
    this.threshold = threshold;
    this.timeout = timeout;
    this.state = 'CLOSED'; // CLOSED, OPEN, HALF_OPEN
    this.nextAttempt = Date.now();
  }

  async call(method, ...args) {
    if (this.state === 'OPEN') {
      if (Date.now() < this.nextAttempt) {
        throw new Error('Circuit breaker is OPEN');
      }
      this.state = 'HALF_OPEN';
    }

    try {
      const result = await this.provider[method](...args);
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      throw error;
    }
  }

  onSuccess() {
    this.failures = 0;
    this.state = 'CLOSED';
  }

  onFailure() {
    this.failures++;
    if (this.failures >= this.threshold) {
      this.state = 'OPEN';
      this.nextAttempt = Date.now() + this.timeout;
    }
  }
}

Build Provider-Agnostic Data Models

Different providers return data in different formats. Standardise early:

class VerificationResult {
  constructor(rawResult, providerType) {
    this.id = generateId();
    this.timestamp = Date.now();
    this.provider = providerType;
    this.status = this.normaliseStatus(rawResult.status);
    this.confidence = this.normaliseConfidence(rawResult.score);
    this.checks = this.normaliseChecks(rawResult.checks);
    this.metadata = {
      raw: rawResult,
      processingTime: rawResult.processingTime,
      version: rawResult.apiVersion
    };
  }

  normaliseStatus(providerStatus) {
    // Map different provider statuses to standard enum
    const statusMap = {
      'PASS': 'VERIFIED',
      'SUCCESS': 'VERIFIED',
      'APPROVED': 'VERIFIED',
      'FAIL': 'REJECTED',
      'DECLINED': 'REJECTED',
      'REVIEW': 'MANUAL_REVIEW'
    };
    return statusMap[providerStatus] || 'UNKNOWN';
  }
}

Monitoring and Observability

Identity verification systems need comprehensive monitoring because failures often cascade:

class IdentityMetrics {
  static recordVerification(provider, result, duration) {
    metrics.increment('identity.verification.attempts', {
      provider,
      status: result.status,
      region: result.region
    });

    metrics.histogram('identity.verification.duration', duration, {
      provider,
      check_type: result.checkType
    });
  }

  static recordFailure(provider, error, context) {
    metrics.increment('identity.verification.failures', {
      provider,
      error_type: error.type,
      retry_attempt: context.retryCount
    });
  }
}

The Path Forward

The identity verification landscape will continue evolving. New regulations will emerge, providers will change their offerings, and user expectations will shift. The key is building systems that can adapt without requiring complete rewrites.

At Zenoo, we've seen how orchestration platforms can abstract away this complexity while maintaining flexibility. We explored this in depth on the Zenoo blog (https://zenoo.com/blog/the-identity-crisis), but the core principle remains: architect for change from the beginning.

Conclusion

Your identity verification API doesn't have to keep breaking. By designing for multiple providers, implementing proper circuit breakers, and maintaining provider-agnostic data models, you can build systems that gracefully handle the inevitable failures and changes in the identity verification ecosystem.

The initial investment in this architecture pays dividends when you need to add new providers, handle regional requirements, or recover from service outages. Your users get a more reliable experience, and your engineering team spends less time on emergency fixes and more time building features that matter.

Start small—add a fallback provider for your most critical verification flows. Then gradually expand your orchestration capabilities as your system grows. Your future self will thank you when the next provider outage becomes a minor blip instead of a major incident.