Before you build your own KYB: six questions worth answering honestly

At some point, most compliance-forward fintechs ask the same question. We have an engineering team. We know our requirements. Why are we paying someone else to do something we could build ourselves?

It is a reasonable question. And for a small number of companies, building in-house is the right answer. But the path from "we could build this" to "we have built this, and it works, and it stays working as regulation shifts" is longer and more expensive than most teams estimate at the start. These are the six things worth examining before you commit.

1. Are you counting the real cost of vendor access?

The comparison that usually kicks off the build conversation is a simple one: platform license fee versus engineering salaries. The platform number feels concrete. The engineering number feels like something you already have.

What gets missed is the cost of the data itself.

KYB is not one integration. It is many. Company registry data alone requires connections to hundreds of national sources, each with different formats, coverage windows, and reliability. Individual identity verification vendors carry significant minimum annual commitments. Add AML screening, document verification, address checks, and UBO data, and you are managing half a dozen commercial relationships, each with its own contract, SLA, and integration to maintain.

Platforms that sit above this layer have negotiated volume rates across a wide range of data providers. You get the benefit of that purchasing power at a fraction of what it would cost to replicate those relationships from scratch.

When Keyrock ran the numbers before choosing Dotfile, they estimated that building and maintaining their own solution over three years would cost roughly €800,000. And that was before accounting for the automation capabilities they would have struggled to replicate internally. Read the full Keyrock case study.

2. Have you modelled what happens when you expand to a second market?

Building a KYB onboarding flow for one jurisdiction is not hard. Building one that works across multiple jurisdictions, with different registry formats, different document requirements, different regulatory logic, and different language support, is a different problem entirely.

Every new market means a new integration. New data sources. New conditional logic. New document types. New edge cases your initial architecture did not anticipate. If your build is optimised for one country today, it is not ready for the next one without meaningful rework.

A well-designed platform handles this at the configuration layer. New jurisdiction, a few parameters. The underlying plumbing is already there.

This is the part of the build decision that looks fine in year one and becomes a significant liability in year two, when expansion is no longer hypothetical.

3. Do you know what a compliant audit trail actually requires?

Regulators are no longer reading your policies. They are auditing your product. The expectation now is a detailed, evidence-based record of every verification decision: what was checked, when, against which source, with what outcome, and why the analyst concluded what they did.

Building a client-facing onboarding flow is manageable. Building the case management layer underneath it, the audit trail, the risk scoring engine, the document storage, the decision logging, is a substantially larger project. And it needs to be right. Incomplete audit trails are an increasingly scrutinised area.

Most teams that decide to build the front-end portal still end up needing the backend infrastructure that a platform provides. The onboarding is the visible part. The defensibility is in what sits behind it.

4. What happens when a vendor changes their API?

Every integration you build, you own. When a registry changes its data format, when an IDV provider updates their SDK, when a screening vendor deprecates an endpoint, someone on your team is absorbing that change.

In a portfolio of five or six integrated data providers, API changes are not rare events. They are part of the maintenance overhead that never appears in the initial build estimate. And because compliance integrations are often handled by a small number of engineers who also own other infrastructure, maintenance work competes directly with product development.

Build costs compound over time. A purpose-built platform spreads that development cost across many customers. The platform vendor's entire engineering function is focused on keeping those integrations current. For most fintechs, that is not a fight worth picking.

5. How confident are you in your UBO resolution logic?

Beneficial ownership is where in-house builds most commonly break down. Mapping a simple company structure is straightforward. Resolving multi-layered ownership chains across jurisdictions, including entities in opaque structures, holding companies, or jurisdictions with limited registry access, requires logic and data that takes years to develop.

The enforcement actions regulators are pursuing are not primarily about missing documents. They are about ownership structures where the real beneficial owner was not identified because the verification stopped at the wrong layer.

An in-house build that handles 80% of ownership structures correctly is a compliance liability, not a compliance programme. Getting to 95%+ requires access to data and resolution logic that is genuinely hard to replicate independently.

6. Is compliance infrastructure your core product or your context?

There is a useful distinction between what a company builds because it differentiates them, and what they build because they need it to operate. The compliance teams we speak to almost always land in the same place: the product experience, the pricing model, the customer relationships, the speed of onboarding, those are core. The compliance infrastructure underneath is context. It has to be excellent and defensible, but it is not the thing that makes you win in your market.

Engineering time spent on compliance infrastructure is engineering time not spent on what makes the product better. That trade-off rarely shows up in a build vs buy spreadsheet, but it is often the most consequential part of the decision.

Investors prefer to see engineering talent focused on unique customer experiences and proprietary value. Building a comprehensive compliance layer from scratch can span years. A well-implemented platform can be live in 6 to 12 weeks.

The honest answer on build vs buy

Building makes sense when compliance is genuinely your core product, when you have scale that justifies the investment, and when you have the engineering capacity to absorb ongoing maintenance without pulling focus from the product. Those conditions exist for some companies. They do not exist for most.

For the majority of fintechs and financial institutions, the question is not really build or buy. It is how much of the infrastructure layer to own, and where to draw the line. The most common pattern we see is teams that start by building the front-end portal and progressively hand off the harder layers: case management, audit trails, UBO resolution, ongoing monitoring, to a platform that has already solved them.

The build decision is rarely wrong because the ambition was too high. It is usually wrong because the maintenance cost was underestimated and the market moved before the system could keep up.

Dotfile is an AI-native business verification platform built for compliance teams that need KYB to be fast, defensible, and ready for anywhere. Book a demo.