Build vs Buy in Fintech: The Question Most Teams Answer Too Early

Every fintech product team hits this decision, usually at the worst possible moment: a board deck is due, a client has asked for a capability you do not have, and someone senior says "can we just build it?" Within a week the decision is made. Within a year it is regretted.

The short answer: build when the capability is the reason customers choose you and you can own it for a decade. Buy when it is table stakes, heavily regulated, or changing faster than your roadmap can absorb. Most teams get this backwards because they evaluate cost before they evaluate differentiation.

This guide covers how to actually run the decision — the four questions that determine it, the costs both sides hide, the hybrid option most teams miss, and a two-week process you can run without stalling delivery.

What does build vs buy actually mean in fintech?

Build vs buy is the decision to develop a capability with your own engineering team or license it from a vendor. In fintech the decision carries weight it does not carry elsewhere, because three things travel with it: regulatory accountability, data residency and lineage, and integration into systems that were never designed to be integrated with.

The capabilities most commonly in scope:

• KYC, AML and sanctions screening — identity verification, watchlist matching, ongoing monitoring
• Core ledger and reconciliation — the record of what is owed, held and settled
• Market and reference data — pricing, instrument masters, corporate actions, symbology
• Payment rails and connectivity — messaging, clearing, settlement instructions
• Regulatory reporting — transaction reporting, trade repositories, submission and reconciliation
• Risk and margin calculation — exposure, collateral, stress and limit monitoring

Notice what these have in common. None of them is why a customer picks you. All of them will sink your roadmap if you build them badly.

Why the decision gets made too early

The failure is almost never analytical. It is procedural. The decision gets made in a conversation, before anyone has framed it as a decision at all.

Three patterns cause it:

Engineering optimism

A strong engineer scopes the happy path in an afternoon and reports back that it is "a few sprints." They are usually right about the happy path. The happy path is between ten and twenty percent of the work. The rest is edge cases, jurisdictional variation, audit trails, failure handling and the six years of maintenance nobody scoped.

Procurement fatigue

The team has been burned by a vendor before — a bad implementation, a punishing renewal, a roadmap that never shipped. So the next decision is made emotionally, against buying, regardless of merit.

Sales pressure

A prospect asks for a capability during a deal cycle. The fastest answer is "yes, we are building that." Now the decision is committed before it was ever evaluated, and the roadmap has a dependency nobody agreed to.

The fix is not a better spreadsheet. It is refusing to answer the cost question first.

The four questions that actually decide it

Run these in order. If the first two are clear, you rarely need the last two.

1. Is this capability the reason a customer chooses us?

Not "is it important." Not "do customers need it." The question is whether a customer would switch to you because of it, or leave you because a competitor does it better.

If the answer is yes, you build. Differentiating capability under someone else's roadmap is a strategic liability — you cannot ship a competitive advantage at your vendor's release cadence.

If the answer is no, you are looking at table stakes. Table stakes should be bought unless something else forces your hand.

2. How much regulatory surface does it carry?

Regulatory surface means the volume of obligation that attaches to the capability: reporting duties, evidence requirements, jurisdictional variation, examination exposure, and how frequently the rules change.

High regulatory surface argues strongly for buying — not because you cannot build it, but because you would be permanently funding a compliance-tracking function to keep it current. A screening vendor amortises rule changes across hundreds of clients. You would absorb them alone, forever, with a team that has other work.

The counter-case: where the regulator holds you accountable regardless of vendor, buying transfers the work but not the liability. Buy the engine, own the controls.

3. Where does the data gravity sit?

Data gravity is the pull that large, entangled datasets exert on everything that touches them. If the capability needs deep, low-latency access to data that already lives in your systems — positions, balances, client hierarchies, entitlements — every vendor integration becomes a synchronisation problem, and synchronisation problems become reconciliation problems.

Ask: how many times does data cross the boundary, in what direction, and what happens when the two sides disagree? If the honest answer is "constantly, both ways, and we would need a reconciliation process to detect drift," the integration cost may exceed the build cost.

4. What is the cost of being late?

Only now does timing enter. Quantify it properly: deals contingent on the capability, revenue deferred, contractual or regulatory deadlines with penalties attached.

If being late costs little, build timelines are tolerable. If a regulatory deadline is fixed and non-negotiable, buy — even at a price you dislike — and revisit later. Missing a mandated deadline is a different category of problem from paying too much for software.

Build vs buy: how the trade-offs actually compare

The costs both sides hide

Most build vs buy models compare a build estimate against a licence fee. Both numbers are wrong.

What build estimates leave out

• Maintenance in perpetuity — budget 15–25% of the original build cost annually, indefinitely
• Regulatory tracking — someone must read the rule changes and translate them into requirements
• Key-person risk — the two engineers who understand it will eventually leave
• Opportunity cost — the differentiating features not built while the team built table stakes
• Support and operations — runbooks, on-call, incident response for a system that now cannot fail

What licence fees leave out

• Implementation — routinely one to three times the annual licence in year one
• Integration engineering — your side of the boundary, which no vendor quotes
• Data migration — extraction, mapping, cleansing, parallel running, reconciliation to sign-off
• Renewal escalation — the price after you are dependent is not the price on the proposal
• Vendor due diligence — security review, outsourcing assessment, ongoing oversight obligations
• Change requests — anything outside standard configuration, billed at day rates

Model both over five years, not one. The decision frequently reverses when you extend the horizon.

The option most teams miss: buy the core, build the edge

Build vs buy is framed as binary and almost never is. The stronger pattern in fintech is to buy the commoditised engine and build the layer where your judgement lives.

Concretely:

• Buy the screening engine. Build the case management, alert triage and workflow your analysts actually use.
• Buy the market data feed. Build the normalisation, entitlement and distribution layer your products depend on.
• Buy the reporting engine. Build the enrichment, exception handling and control framework around it.
• Buy the ledger primitives. Build the product logic that makes your instruments distinct.

This works because the commoditised layer is where regulatory churn and undifferentiated complexity concentrate, while the experience layer is where customers form an opinion about you. It also preserves optionality: a well-defined internal interface means the engine underneath can be replaced without rewriting everything above it.

The discipline it demands is an abstraction boundary drawn on day one, before the vendor's data model leaks into your entire codebase. Teams that skip this end up unable to switch vendors at any price.

How to run the decision in two weeks

1. Days 1–2: Write the decision brief. One page. The capability, who needs it, the deadline and its consequence, and the four questions above answered explicitly. Circulate before anyone has an opinion about vendors.
2. Days 3–5: Scope the build honestly. Have engineering estimate the full surface — edge cases, jurisdictions, audit, operations, five-year maintenance — not the happy path. Ask what they would need to stop doing.
3. Days 6–9: Shortlist three vendors, no more. Send the same structured requirement set to each. Insist on implementation and integration estimates alongside licence pricing. Ask for two reference clients of similar size and complexity.
4. Days 10–11: Model five-year total cost, both paths. Include everything from the hidden-cost lists. Show the model, not just the conclusion.
5. Day 12: Test the hybrid. Explicitly ask where the boundary would sit if you bought the core and built the edge. If the hybrid is viable it usually wins.
6. Days 13–14: Decide, document, set reversal criteria. Record the decision, the assumptions behind it, and the specific signals that would make you revisit. Assumptions age; undocumented ones age invisibly.

Signals you chose wrong

Set these as review triggers when you make the decision, not after the damage.

You should have bought if: maintenance consistently consumes more than a quarter of team capacity; regulatory changes arrive faster than you implement them; the roadmap has slipped twice for reasons traceable to this capability; or the people who understand it have become a bus-factor conversation.

You should have built if: customers cite the capability as a reason they are leaving; the vendor's roadmap has blocked a strategic initiative more than once; renewal pricing has escalated beyond the original build estimate; or you are paying for change requests to reach behaviour you specified at the outset.

Frequently asked questions

Should a startup build or buy?

Buy almost everything except your core product. Early-stage teams have one scarce resource — engineering attention — and spending it on undifferentiated infrastructure is the most common way a promising product runs out of runway. Buy, ship, learn, and revisit once you know what actually differentiates you.

How do you calculate the true cost of building?

Take the engineering estimate, add operations and support, then add 15–25% of the original build cost per year for maintenance across a five-year horizon. Add the cost of tracking regulatory change. Finally add opportunity cost — the revenue-generating work that will not happen. The result is usually two to four times the initial estimate.

What is the biggest risk when buying fintech infrastructure?

Lock-in through data-model leakage. If the vendor's schema and semantics spread through your codebase, migration becomes structurally impossible and renewal pricing reflects that. Define your own internal interface at the boundary from day one, even when it feels like unnecessary work.

Can you change the decision later?

Yes, but the cost is asymmetric. Moving from buy to build is expensive and slow but usually feasible. Moving from build to buy means migrating data and retiring a system your operations depend on, which is harder than it appears. Set reversal criteria early and review them on a schedule rather than in a crisis.

Does regulatory accountability transfer to the vendor?

Generally not. Most regimes treat the regulated entity as accountable for outcomes regardless of who supplies the technology, which is why vendor oversight and outsourcing obligations exist. Buying transfers execution, not responsibility — you still need controls, evidence and demonstrable oversight.

The decision behind the decision

Build vs buy looks like a cost question and is actually a focus question. Every capability you build is capacity you cannot spend elsewhere, permanently, because software you own is software you maintain forever.

The teams who get this right are not the ones with the best spreadsheet. They are the ones who can state clearly what they are uniquely good at — and who treat everything else as a problem to be bought, bounded and forgotten.