Build vs Buy KYB: What Banks and Fintechs Need to Know Before They Decide

Almost every bank and fintech with a serious onboarding volume reaches the same crossroads eventually. The existing KYB process — some combination of spreadsheets, a generic case-management tool, a couple of registry API integrations, and a screening vendor — has stopped scaling. Cases take too long, analysts spend their days copying data between systems, and the audit trail is patched together after the fact. Somebody on the executive team says the word "platform" and the question moves from "how do we fix this" to "do we build it ourselves or buy it from a vendor?"

The answer is rarely as obvious as either camp inside the organisation makes it sound. Engineering will quote a build timeline that turns out to be optimistic by a factor of two. Compliance will quote a buy timeline that turns out to be optimistic by a factor of three if the wrong vendor is chosen. This article is for the people in the room who have to make that call honestly — what each path actually costs, where each one fails, and the criteria that should drive the decision.

The real cost of building in-house

The headline cost of building a KYB platform in-house is engineering salaries, and that number alone is usually enough to give finance leaders pause. A credible minimum viable team is four to six engineers, a product manager, a designer, and at least one compliance subject-matter expert embedded full-time. At fully-loaded London or New York rates, that team costs somewhere between £1.5m and £2.5m a year before any infrastructure or third-party data costs are added. And that team will be busy for eighteen months to two years before the platform handles the same range of cases that a mature vendor product handles on day one.

The less-visible cost is everything else. Every external data source — Companies House, Transparenzregister, RCS, the equivalent registry in every jurisdiction you operate in — needs a connector, a retry strategy, a rate-limit budget, and a maintenance owner for the lifetime of the platform. Every IDV vendor, every screening provider, every adverse media source needs the same. Webhook receivers need HMAC verification per vendor. PDF extraction needs OCR pipelines that handle the long tail of corporate document formats. Risk scoring needs a configurable rule engine. Tenant isolation, audit logging, role-based access, encryption-at-rest with key rotation, and SOC 2 / ISO 27001 controls all need to be designed in from the start, not bolted on later.

None of this is impossible. Engineering teams build harder things every quarter. But the platform you end up with after two years is functionally equivalent to what you could have bought on day one — except now you also own the maintenance burden, the on-call rotation, and the compliance liability for every line of code. The fully-loaded five-year cost of an in-house build at a mid-sized bank is rarely under £8–10m once everything is honestly counted. For most institutions that number is hard to justify against any vendor benchmark.

The real cost of buying

Buying is not free either, and the failure modes are different but no less expensive. The headline cost is licensing — typically a per-case or per-tenant fee plus implementation services. For a bank doing thousands of KYB cases a year, that lands in the low-to-mid six figures annually, plus a one-time implementation cost that varies wildly by vendor.

The hidden costs of buying badly are vendor lock-in, bundled data providers, and slow change management. A platform that forces you to use its own IDV supplier, its own screening provider, and its own KYB data sources gives the vendor pricing power over every check you run, and gives you no leverage to optimise the components you depend on. A platform whose configuration changes require a professional services ticket and a four-week SLA will turn every compliance policy update into a project. A platform built without proper multi-tenancy will make every audit a manual export exercise. Any of these can erase the cost advantage of buying over a build within eighteen months.

The right vendor evaluation criteria are the ones we covered in our KYB onboarding software guide — vendor-agnosticism, configurable risk rules, UBO automation, audit trail completeness, and implementation speed. A platform that scores well on those five is a platform that will not turn into an expensive mistake.

Risk and compliance considerations

The regulatory dimension cuts both ways. When you build in-house, every line of code that touches a customer record is your team's responsibility — for testing, for security review, for the audit response when something goes wrong. The upside is total control: if an examiner asks why a particular case was approved, your engineers can trace the decision path from input to output. The downside is total liability: there is no vendor to point at, no SOC 2 report to hand to procurement, no upstream patches when a vulnerability lands.

When you buy, much of that responsibility shifts to the vendor — but only contractually, not operationally. Your bank is still the regulated entity. If the vendor's UBO chain resolution misses a sanctioned individual three layers up, your bank takes the enforcement action, not the vendor. The right contractual protections (right-to-audit, data residency, breach notification SLAs, exit assistance) are essential, and the right vendor will provide them without resistance. A vendor who resists those clauses is telling you what their priorities are.

Where this matters most is in beneficial ownership and identity verification. UBO chain resolution across jurisdictions is one of the hardest things to get right, and one of the easiest things for a regulator to find fault with later. We cover the specific mistakes banks make here in our UBO verification guide. Whether you build or buy, your platform has to handle layered ownership structures, inconsistent registry data, and nominees in a way that survives examination — and the platform has to produce the evidence trail to prove it.

When build genuinely makes sense

There are real cases where building in-house is the right answer. A tier-one bank with thousands of corporate cases a day, an established platform engineering culture, and a compliance function that wants every rule encoded in code their team controls, may legitimately prefer to build. A specialist institution operating in a single jurisdiction with idiosyncratic regulatory requirements that no vendor caters to — for example, certain regional payment-service providers or domestic-only commercial lenders — may find no off-the-shelf platform fits.

A fintech whose entire commercial moat is something adjacent to KYB — say, a regtech selling its own UBO data product — may need full control of the platform stack because the platform is the product. And an institution with strict on-premise or sovereign-cloud requirements that no vendor supports may have no other option.

Outside these specific cases, the calculus rarely favours building. A mid-sized bank or a growth-stage fintech that builds its own KYB platform is almost always doing engineering work that does not differentiate the business, with a team that could otherwise be working on the products customers actually pay for.

When buy is the obvious choice

For most banks and fintechs, buy is the obvious choice when the requirements are not exotic and the timeline matters. If you need to onboard corporate customers across multiple jurisdictions, run sanctions and PEP screening, verify beneficial ownership, and produce an audit trail that satisfies AMLD6 and the FCA, you are describing exactly what every mature KYB platform already does. Building it again at your institution will not produce a competitive advantage; it will produce a two-year project that ends with you owning the same capabilities you could have rented.

The decision then becomes about which vendor, not whether to use one — and the right vendor is the one whose platform is vendor-agnostic, configurable, and fast to deploy. That is the bar that justifies buying instead of building.

How to make the decision

A useful exercise: take the five-year fully-loaded cost of building, including engineering salaries, infrastructure, third-party data, security and compliance work, on-call burden, and the opportunity cost of the engineers not working on something else. Compare it to the five-year fully-loaded cost of buying from a credible vendor, including licensing, implementation, integration work, and the cost of any data providers you bring yourself. If the build number is not at least 2x the buy number and the platform you would build is not meaningfully differentiated from what you can buy, buy.

Then evaluate vendors against the criteria above — vendor-agnosticism, configurable rules, UBO automation, audit trail, implementation speed — and pick the one that scores highest, not the one with the most familiar logo. The right platform should pay for itself in analyst time saved and audit risk avoided inside the first year, and the difference between the right vendor and the wrong one is usually larger than the difference between buying and building.

If you would like to see how First Mile Labs handles the build-vs-buy question in practice — including bring-your-own API keys, no-code rule configuration, automated UBO resolution, and a default audit trail — get in touch or see the platform.