Content Library
Back
Share

Building perpetual KYB (pKYB): from vision to reality

P KYB phase2 blog

The future of KYB isn't a mystery in financial services. Most people will describe the same vision: proactive, continuous, and event-driven. Static, point-in-time checks were no longer sufficient. And yet almost nobody had actually built it. Until now.

Every conversation I had with prospects, every trip I took to our London office, validated the same thing. What they wanted was consistent policies across markets, the ability to scale confidently, and a clear, up-to-date understanding of business risk. Not just at onboarding or the annual review, but always.

Periodic KYB reviews vs. perpetual KYB reviews

UK and European financial institutions were facing growing regulatory pressure to prove they had a continuous view of risk for their business customers. The consequences were serious: significant fines and reputational damage that's hard to recover from. If you onboard a business customer and only re-verify them every few years, a sanctioned UBO could be added, or the business could shift into a significantly higher-risk industry, and you wouldn't find out until years after it happened.

One of our earliest prospects, a leading UK payments platform, made this signal impossible to ignore. They weren't willing to buy Alloy or migrate from their existing system without a promise that a real perpetual KYB (pKYB) solution was coming, one that could detect, verify, and act in real-time. What existed fell short of what they actually needed.

So why didn’t a solid pKYB solution already exist?

I found that the market had settled into three approaches, and none of them were good enough.

1. Notification-only systems 

One approach was to detect registry changes and notify clients via email. A new UBO from a high-risk jurisdiction, an industry shift, an address change. Imagine managing a portfolio of thousands of business customers and receiving an email every time any one of them had a change. Every change, whether risky or irrelevant, required a human to decide what to do with it. Clients that wanted to scale were capped by their operational headcount.

2. Walled gardens

Others offered automation but tied clients to one or two data partners. As clients grew and expanded into new markets, the cracks started to show. The data partners they needed simply weren't available, and the platform they were on couldn't offer them. The garden had walls. Global fintechs need an orchestration layer that grows with them, not one they eventually need to escape.

3. Build-it-yourself

And then there were the teams that built their own direct integrations into registries like Companies House. They could receive updates, but making sense of them was its own challenge. Registry data is often generic and lacks context. Teams end up spending hours vetting every change just to figure out which ones are material. If you can't efficiently identify and act on what you see, receiving it faster doesn't solve the problem.

Across all three, the core problem was the same: detection alone isn't enough. Acting on changes is where the real complexity lies.

Alloy was built for this

The moment it truly clicked came when I was drafting our vision statement for pKYB and realized that we'd already done this. Just not yet for businesses. Alloy had spent several years building real-time ongoing monitoring, starting with consumer fraud, and that same infrastructure was exactly what we needed. Extending that infrastructure to business verification was the natural next step.

The timing was right, too. Data partners were finally releasing registry monitoring products, and as a data-agnostic platform with over 270 data solutions orchestrating onboarding across geographies, we were uniquely positioned to deliver something differentiated.

The technology was ready. It was time to build. What I hadn't fully appreciated was what we'd actually signed up for. That became clear when I sat down in Figma to map out the future-state flows for all the pKYB use cases. Designing a shared architecture flexible enough to support all of them felt like one of those wooden ball puzzles where every piece looks straightforward until you try to make them all fit together at once.

The technical challenges of building perpetual KYB (pKYB)

If real-time consumer fraud monitoring was calculus AB, perpetual KYB was multivariable calculus. I call what came next my pKYB ninja warrior course. Every obstacle was unique. Every time we cleared one, the next was hard for a completely different reason.

Obstacle 1: The matching problem

When a registry update comes in, it can tell you a business now has three beneficial owners instead of two. You know to update the business. But which individual do you update, and which do you create as net new? The only way to solve this was to save unique data partner IDs for every entity at onboarding and use them to match during updates. This underscored something important: using one data partner for both KYB and pKYB isn't just convenient. It's architecturally necessary.

Obstacle 2: Turning a notification into action

A business isn't just a single entity. It's the business plus all its associated owners, directors, and shareholders. We needed to verify every change in that bundle, but only the entities that actually changed, not the entire group. The key insight was that orchestration and risk calculation had to be decoupled. You verify only what changed, but recalculate risk across the full business entity. 

In practice, that meant orchestration had to be selective, only verifying the entities that changed, while the risk score had to reflect the entire group, pulling in scores across every entity to recalculate overall business risk. Getting that right was one of the most important architectural decisions of the entire build, and one that directly drives cost efficiency for our clients.

Obstacle 3: Deciding what to do with a change

Not all registry data is created equal. Some changes, like a legal status update, should always be accepted automatically. Others need more scrutiny. Our design partner surfaced this perfectly: they had enriched their customers' industry classifications at onboarding, but the registry returned something far more generic. Blindly accepting it would have made their records worse, not better. That changed how we built the entire update flow. We already had a mechanism that lets clients pend a change, evaluate it, and decide whether to accept it before it flows through to action. Extending that same capability to registry monitoring was the right call, and exactly the kind of nuance we wouldn't have caught without a design partner in the room.

Each obstacle was hard. Each was hard in a completely different way. And clearing all of them is exactly why this product didn't exist before. Not because no one wanted it.

Bringing pKYB to life

Demoing pKYB to that initial prospect, now a client, was one of the most satisfying moments of the build. We traveled to their office and walked their operational, risk, and engineering teams through a scenario: a business customer added a new UBO from a high-risk jurisdiction, updated their address, and changed their industry classification to something higher risk.

It wasn't an email notification. Alloy detected the changes, verified the new UBO, recalculated risk across the group given the industry shift, and triggered EDD where the risk warranted it. All of it, automated. Only the highest risk cases escalate to a human reviewer.

Alloy's pKYB solution workflow

The room was engaged. What struck them most was how naturally pKYB extended from what they already knew Alloy to be. They were only using us for onboarding at the time, and seeing how much of that same integration could carry them straight into continuous monitoring made it feel less like a new product and more like the next chapter of the same platform. After the demo, our champion asked us to walk through what it actually took to build and maintain our pKYB solution. When he saw the numbers, it gave him everything he needed to make a compelling internal case for buying rather than building.

The next frontier: accelerating manual reviews

A complete pKYB solution doesn't stop at detection and orchestration. Business verification is notorious for high manual review rates. Reviewers are jumping between tools, gathering context from multiple sources, and piecing together a picture before they can even begin to make a decision. That's where our AI Assistant comes in. Think of it like a restaurant kitchen: they're the sous chefs, doing all the prep work so the head chef can focus on what actually needs their attention. Some dishes they can plate and send out entirely on their own. Others always need the head chef's sign-off before they go out.

Here's what that looks like for a pKYB case. A registry update comes in: a new UBO from a high-risk jurisdiction with watchlist hits, an industry shift to something higher risk, and an address change. Before a reviewer ever opens the case, Alloy's AI Assistant has already summarized why it was flagged and suggested next steps. It screens through watchlist hits and recommends a true match on a sanctions hit. It corroborates the new UBO by researching the business across the open web, confirming the industry change, and surfacing the connection. It even reviews the proof of address document and confirms whether it matches the registry update. All of it happens in one place, natively within Alloy. By the time a reviewer opens the case, the work is largely done. They're not starting from scratch. They're making a judgment call with everything they need already in front of them.

Closing the gap

A year ago, perpetual KYB was a shared vision that nobody had turned into reality. Most platforms didn't have the foundation to even get started. Having it gave us a head start, but it was just the entry point. Everything built on top of it was uncharted territory. Alloy's pKYB solution is the result of that work. For our clients, pKYB means something simple but profound: they can rest assured they're compliant, that regulators won't come knocking with findings they weren't prepared for, and that they can grow their business without hiring an army to keep up. They have everything they need, without the overhead of custom builds and point solutions.

Products like this are never invented out of thin air. They come from deep curiosity, from spending time with clients, understanding what they're trying to do and why their current tools aren't measuring up. The signals are rarely in what people ask for directly. They're in the workarounds, the tools that almost work, the goals that are just out of reach. The craft is translating that empathy into something people didn't know they needed but immediately can't imagine being without. When they see it, and it clicks, it feels a little like magic.

Related content

Back