I’ve spent years in Compliance across payments and fintech, and if there’s one debate I’ve heard more than any other, it’s this one.

In every company, it’s the same three options, just with different branding:

• Do nothing and accept long onboarding times, high drop-offs, frustrated customers and a process held together by spreadsheets and sheer willpower. And let’s be honest, probably one heroic analyst named Alex who knows where everything lives and hasn’t taken a proper holiday in 18 months.

Sure, this option doesn’t cost anything upfront. It lets you focus on BAU and your internal teams know the pain well but it won’t solve your onboarding delays, customer churn or operational inefficiencies. It doesn’t scale, invites errors and leaves you exposed to audit failures and staff burnout.

• Build it in-house because “we’ll do it better,” but every hour spent on edge case handling or registry parsing is an hour not building what makes your product special. You’re burning cycles on foundational plumbing instead of delivering features that drive revenue, retention or real customer value.

You do get full control over the workflow and design, tailored to your product and customers. But it’s resource heavy, slow to scale across jurisdictions and hard to maintain. Plus, your team ends up fighting the same problems vendors have already solved.

• Buy from a vendor and gain access to infrastructure that’s already solved 90% of your problems before you’ve written a single line of code including the stuff you didn’t even realise would be a problem until after you go live. You finally get a fighting chance at onboarding that’s fast, compliant and doesn’t make your ops team want to cry. Here’s where vendors like Detected have spent the time to get it right with flexible data models, configurable workflows and integrations that don’t break every time a registry changes. These aren’t just features, they’re the result of solving painful edge cases over and over.

You’ll still need to go through vendor evaluation, integration and some light configuration to make it your own and it might not cover every niche scenario out of the box. But it comes with constant updates, access to multiple data sources, registry intelligence, and ongoing support without sinking months of internal dev time.

I’ve lived in all three.

I’ve sat at my desk at 6pm on a Friday, manually reviewing excel spreadsheets and PDFs because there was no workflow and writing yet another email with the subject line:“Just one more request…”said no Compliance analyst ever with a straight face.

I’ve built business cases the size of small novels trying to get a budget for a vendor switch, only for it to be shelved again and again.

And I’ve joined “we’ll build it ourselves” projects that started with energy and optimism that quietly fell apart under the weight of edge cases, competing priorities and a product team that just didn’t have the bandwidth.

I always had both feet in the “just buy it” camp and now that I work at a company building KYB infrastructure and I see what it takes to actually do it well, I’ve also got both hands in that camp too. That said, picking the right vendor is never as simple as it sounds. There’s always big claims, lookalike features and the joy of navigating procurement hell. It’s way too easy to end up with a shiny demo and a product that doesn’t solve the issues you were trying to solve. I wrote about that exact challenge inthis articlebecause choosing to buy shouldn’t feel like crossing your fingers and hoping it works out.

So I’ll be blunt, unless KYB is your product — don’t build it.Not now, not later and not as a side project.

So if you’re still thinking: "How hard can it be?" Let’s break that illusion right now.

KYB Looks Simple, That’s the Trap

On the surface, KYB looks like an easy little checklist, collect and verify:

• Business name
• Business details (company number, address etc)
• Directors and UBOs
• Screen for PEPs and Sanctions
• Approve or reject

Simple, right?

But that’s the dream. The reality:

• Different countries = different documents, different regulations, different expectations
• Different company types = different ownership structures, different roles to verify
• Different registries = different access, different formats or sometimes… no access at all

In the UK, we’re lucky. Companies House is centralised and (partly) reliable. One place to find limited company info, directors, UBOs and documents. But across the pond it’s a different story. In the US, you’re dealing with 50+ state registries, each with their own rules, formats and access (or lack of it). No consistency, no standardisation, no APIs and often, no data at all.

That said, this isn’t just something we talk about from the side lines. We’re actively supporting customers across the US and have recently run demos with several US fintech's struggling with exactly this, trying to automate KYB but hitting blockers due to patchy data and lack of structure. One customer came to us after their in-house system couldn’t reliably confirm company existence across multiple states. We’ve built for that reality and our platform reflects it.

And that’s only two countries and just trying to confirm the company exists.

Now also add in:

• Trusts and charities
• Multinational UBO structures
• Verifying individuals across different entity types and role
• Risk-based workflows
• Risk assessment
• Enhanced due diligence
• Standardised review process
• Ongoing monitoring
• Audit trails and escalation logic… and this is just naming a few

And this is where most companies run into trouble…. They have an application form that collects the same basic data for everyone regardless of industry, country or corporate structure. No logic to adjust for what a Gibraltar based trust might need. No prompts for enhanced documentation from a high-risk sector and no smart routing for edge cases that don’t fit the usual mould.

Even worse, most in house systems don’t capture the kind of granular, explainable audit trail that regulators increasingly expect. It’s no longer enough to just have an accept/decline decision. They want to see the why behind it. Why was the business approved, what rule was triggered, who overrode the decision and why and what evidence supported it and where is it stored.

Regulators expect clever documentation of risk based decision, version history of rule changes, consistent escalation logic and traceability for every action taken during onboarding and beyond. If you can’t show that in a structured, accessible way, you’re one audit away from a sticky situation and a remediation plan.

And that’s the thing, you can absolutely build a “happy path” but KYB rarely lives in the happy path. Yes, the edge cases are where things usually break, with unusual structures, missing documents and the high risk jurisdictions that stall onboarding and ruin SLA’s but even the standard cases need to be fast, structured and consistent. If your standard journey isn’t streamlined, scalable and auditable, you’re creating inefficiency at volume and burning time on the very process that should be effortless.

Why “We’ll Build It” Never Ends How You Think It Will

Most people that don’t work in Compliance think KYB is easy and have no idea how complex it actually is. Collect some company info, run a few checks and move on. What’s all the fuss about?

I’ve also been in the meetings and I’ve heard the logic:

• “Our engineers are smart.”
• “We want control.”
• “Let’s build something that fits us perfectly.”

And honestly, they’re not wrong, of course the engineers are smart but would you ask your cardiologist to rewire your house just because they’re good with their hands? But here’s what most companies don’t account for:

• You’re not just building a workflow, you’re building a compliance platform.
• You’re not just pulling registry data, you’re interpreting risk and regulation and legal nuance…. in code.
• And when regulations change (and they will), you’re the one on the hook for keeping it up to date.

Staying up to date isn’t an annual or quarterly task, it’s a constant update. You need someone tracking regulatory updates across every jurisdiction you operate in, reviewing typologies, adapting risk scoring logic and ensuring all of that is reflected in how your system works. That’s not something you do once, that’s constant building and maintenance.

In those same meetings, I’ve heard things like:

“We’ll collect company data, UBOs, directors, run eKYC, check for PEPs, sanctions and adverse media and we will auto approve”.

Even for low risk businesses, that’s not enough and for high risk customers? That doesn’t even scratch the surface.

Especially if you are onboarding entities in regulated sectors like crypto, gambling or financial services. The level of documentation, scrutiny and evidence is significantly higher and this continues to grow as regulators tighten expectations across the board.

Here’s the thing, KYB vendors exist for a reason. That reason being that they’ve spent years, millions of pounds and have entire product teams solely focusing on one problem. They’ve been through audits, integrated with hundreds of data sources, built logic for scenarios you haven’t even seen or thought about and experienced and handled exceptions most teams never think to prepare for.

Meanwhile, most companies I’ve worked at? They’re running lean teams, have overloaded roadmaps and product leads who are already stretched thin.

What starts as “this will be live next quarter” becomes 18 months+ of firefighting and that’s if the project even makes it that far. If it does go the distance, I can bet it will be very basic and a one size fits all process, that struggles to even deal with the happy path. For the unhappy path, you are back to emails and spreadsheets.

Even when it technically works, the user experience is often an afterthought. I’ve seen internal KYB tools with five step forms that confuse customers, give unclear error states, no save/resume flows, no ability to send parts to other people if they aren’t the correct person to complete everything and zero feedback on what’s missing. That kind of UX costs you conversions and makes onboarding feel like a chore.

I’ve seen internal teams launch MVP’s that couldn’t support multi-entity structures, couldn’t flag conflicting registry data and couldn’t track changes over time. By the time they realised? The team that built it had already moved on or it is coming in ‘phase two’ but phase two never happens.. With a KYB vendor, you’re not just buying code, you’re buying continuity.

The Hidden Cost of Building

Here’s what people forget, it isn’t just about the initial build. Yes, building it is hard but maintaining it? That’s the part that isn’t accounted for. New regulations, new markets, new risk categories…. The list goes on.

Every time your engineers are fixing registry formatting issues or updating sanction screening logic, they’re not building the features your customers actually care about. The ones that drive growth, retention or revenue. Onboarding is a cost of doing business, not your core product. It needs to work, it needs to be compliant but it will never be the reason a customer chooses you, though it might might be the reason they choose someone else. So why use your best people reinventing the plumbing?

Every time your ops team escalates a case because your KYB tool can’t handle a foreign charity, you’re not just losing time, you’re burning trust, morale and headcount. And when the regulator comes knocking and says “show me your KYB decision trail for this business from 2022” if you’ve built it in-house, you’d better hope someone remembered to save all the right pieces in all the right places.

The cost of building KYB isn’t just in the code. It’s in the opportunity cost, the compliance risk and the people who have to deal with it when it doesn’t work.

I’ve seen teams burn through full quarters just trying to rework basic questions in a form and I’ve seen internal KYB tools stuck in limbo because the one engineer that understood the flow left the company....and now the KYB system is a haunted house no one wants to enter because when they left everyone was too scared to touch it and that’s not just a risk that is a liability. These aren’t technical failures, they’re structural risks that get worse over time.

Buying Isn’t Perfect but It Buys You Time, Scale and Sanity

Let’s be clear, buying KYB tools doesn’t mean pressing a button and walking away.

You still need to configure it to your process and risk appetite, integrate it with your existing systems (if that is the route you are taking) and adjust your process (yes, probably for the better). No vendor will solve 100% of your problem out of the box and some vendors do make promises that they can’t deliver or as I touched on in a previous article, features that you thought were included aren’t and come with a high price tag.

But here’s what the good ones do bring: scale, speed, expertise and a head start. They’ve already done the messy work. They’ve already been burned by the edge cases and they’ve invested the time and money into building something robust so you don’t have to start from zero.

More than that, good vendors also bring institutional memory and real life examples from other businesses. They’ve seen what doesn’t work at 20 other companies. They’ve refined flows based on what auditors flagged, what regulators pushed back on and what risks the teams missed the first time around. You’re not just getting tech, you’re getting real insight and experience of every client that came before you. When you build in house, you’re solving problems in a vacuum. Good vendors are constantly learning from clients, regulators and from data shifts and evolving their products accordingly. That collective learning becomes an advantage and internal builds rarely get that feedback loop as most customers will just go somewhere else and won’t take the time to complain or feedback.

Using vendors you also get to stand on that and layer on your own logic, workflows and nuance. You can spend the time on a clearly scoped project to implement, integrate and roll out instead of an open-ended build which will be a much shorter and impactful project. And when the regulations change (which they will), you aren’t scrambling to rebuild your platform overnight or falling into the non compliant category. With the right vendor, this is measured in weeks, not years. You go live faster, get feedback sooner and improve onboarding without derailing your entire roadmap.

I’ve Been You

If you're reading this and your company is debating what to do, I’ve been you. I’ve:

• Written the requirements
• Built the workflows
• Sat with engineers testing every flow manually
• Created workaround docs for the edge cases
• Presented to leadership to explain why it’s still not working
• Fielded audit questions I wasn’t ready for

I know what it’s like to fight for the right thing… and not get it. And now that I’m working for a company that is building KYB full-time, I know what it actually takes to make it good.

I’ve been the person who had to manually backfill KYB logic in an audit trail system. I’ve spent nights before board meetings trying to explain why onboarding was taking 3x longer than forecasted. I’ve had to give the same explanation to three different stakeholders: ops, product and sales because the tooling just wasn’t keeping up.

If that sounds familiar, you’re not alone and you’re not wrong for wanting something better. KYB doesn’t need to be your Everest but it shouldn’t feel like quicksand either.

My advice?

• Don’t build it unless KYB is your business.
• Don’t build it unless you’re ready to staff an entire team to own it, forever.
• Don’t build it unless you’re doing something so unique that no one else could do it better.

Final Thought: Let Your Team Build What Matters

You have brilliant people. Use them to build what makes your company great.

If KYB is slowing you down, distracting teams or draining resources, hand that load to someone else. Focus on what has an impact for your customers and let the specialists handle what’s under the hood.

Still unsure? Ask someone who’s built it before. Odds are, they’ll lean in quietly and say... “Yeah. We wish we hadn’t.”