Build, buy, or partner for AI in regulated European financial services — the honest tradeoffs across capability, compliance, time-to-production, and lock-in. Criteria that should decide.
Most build-vs-buy framings in financial services are presented as binary. In practice the choice is three-way: build in-house, buy from a vendor, or partner with a specialist. Each path has different cost curves, compliance burdens, time-to-production, and lock-in profiles. None is universally right. The institution that decides on the basis of vendor pitches, peer-bank precedent, or internal political bias tends to pick the wrong path for its use case; the institution that decides on the basis of a small set of evaluation criteria, applied honestly, picks the path that fits.
This article covers the three options without advocacy, the six criteria that should decide between them, when each path is the right answer (and where each has costs the pitch deck does not show), how to evaluate vendors and partners, and what financial institutions should weigh before committing.
Build in-house. The institution staffs and runs its own AI engineering function. Models, infrastructure, deployment, and ongoing operation are owned internally. Full control, full cost, full responsibility.
Buy from a vendor. The institution consumes AI capability through an external API, SaaS product, or off-the-shelf platform. Fast deployment, ongoing dependency, the vendor's pricing model and roadmap determine cost trajectory.
Partner with a specialist. The institution works with a vertical AI provider — typically focused on financial services or a specific use case — that builds and operates a tailored deployment, often combining the partner's models, the institution's data, and shared operational responsibility.
None of these is the right answer in the abstract. Each is the right answer for some institutions and some use cases. The article that follows is criteria-led, not advocacy-led — if it ends up sounding like one path wins, that's a flaw in the writing, not the framing.
These are the dimensions that determine which option fits a given use case. Different use cases within the same institution may resolve them differently — there is no single answer per institution.
Capability ceiling. Does this AI need to be at the frontier (closed-source foundation models) or is sufficient capability available from an open-weight model? Frontier capability biases toward buy (the major API vendors); sufficient capability opens up build and partner paths.
Data sovereignty. Does customer data, transactional data, or other regulated content need to stay within the institution's perimeter? Strict sovereignty biases against public-tier API; favours build, partner, or enterprise-tier API arrangements.
Compliance burden. What does the institution have to evidence to the FCA, BaFin, FINMA, or the relevant national authority? EU AI Act high-risk obligations, DORA register and exit-strategy requirements, Consumer Duty outcomes evidence — these are heavier on regulated workloads (complaints, AML, credit decisioning) than on internal productivity.
Time-to-production. Build: typically 12-24 months. Buy: weeks to months. Partner: 3-9 months depending on integration. The right answer often depends on whether the business case can absorb a longer timeline.
Operating-model fit. Can the institution absorb the deployment's output? Even a working AI fails commercially if the operating model around it isn't ready. This is the same point made in the pilot-to-production article — applied here to the build/buy decision.
Lock-in tolerance. How much does vendor dependency matter? An institution comfortable with a single API vendor across all AI workloads has different criteria from one trying to maintain optionality. Lock-in considerations are increasingly regulatory as well as commercial — DORA's exit-strategy requirements turn vendor concentration into a documented risk.
Build wins when the AI itself is a competitive differentiator and the institution has the capacity to invest in it. Examples include a trading firm building proprietary signal-extraction models, a bank building credit-decisioning AI it considers its operational moat, or an insurer building underwriting AI on data that no third party has access to.
The build path requires AI engineering capacity (ten to thirty engineers depending on scope), an MLOps function, and the patience for a 12-24 month initial deployment. The five-year cost of these is often comparable to or higher than the five-year cost of a partner arrangement; institutions costing the build path on engineering salaries alone undercount by a meaningful margin.
The honest counterweight: most FS institutions don't have this capacity, even if their CIOs would like to. Building looks attractive in the budget meeting because the cost lives in salaries that are already in the OPEX baseline; it looks less attractive eighteen months in when the deployment is six months behind schedule and the regulatory documentation is in worse shape than a partner deployment would have produced. The right question is not "can we build this?" but "is this the AI we want to spend two years building, and what are we not building during that time?"
Buy wins when the use case is low-volume, free of PII, and outside the regulated perimeter. Research summarisation, internal memo drafting, market intelligence, code completion for non-customer-facing applications. The hosted API providers are well-suited to these workloads; the contractual and compliance burden is real but manageable.
Buy is also the right answer for early experimentation. An institution exploring whether a use case has value before committing to a deployment path can use a hosted API for the proof-of-concept, then re-evaluate the path once value is established. As covered in the hidden costs piece, the API path has its own cost dynamics at scale, but for evaluation it's hard to beat.
The honest counterweight: the moment the use case crosses into regulated territory — customer data, regulated outcomes, PII at volume — the buy path's compliance overhead expands rapidly. DPIA, DORA register entries, sub-processor chain management, exit-strategy documentation. The institution that scales an API-based pilot into a regulated production use case often discovers the compliance work is comparable to a partner deployment without the partner's compliance experience to draw on.
Partner wins when the workload is regulated, high-volume, PII-rich, and dependent on institution-specific context. Complaints triage, AML alert handling, fraud detection in customer journeys, call-centre automation, KYC. These workloads benefit from a partner who has done similar deployments at other regulated institutions, understands the regulatory documentation surface, and can bring deployment patterns the institution would otherwise discover the hard way.
The institution brings the data, the operating model, and the domain expertise. The partner brings vertical AI capability, regulatory familiarity, and a deployment shape that has survived prior regulator reviews. The result, where it works, is a deployment in 3-9 months that the institution operates with the partner's support and can defend in regulatory dialogue.
The honest counterweight: partner quality varies enormously. The market includes specialists with deep FS experience and credible regulator-facing track records, and it includes resellers of general-purpose AI dressed up in FS terminology. Distinguishing them requires the same evaluation discipline the institution would apply to any critical vendor — references in your jurisdiction, demonstrable regulatory experience, architectural transparency. A bad partner is worse than no partner; a good partner outperforms either build or buy on time, cost, and regulatory defensibility for regulated high-volume PII-rich workloads.
The same evaluation framework applies whether the institution is evaluating a buy or a partner path. Five criteria distinguish vendors and partners worth trusting from those worth declining.
The institution that evaluates partners with the same rigour it applies to ICT third-party vendors avoids the most common partner failure mode: choosing on chemistry, discovering on deployment.
Four considerations cut across the three paths and frame the final decision.
Total cost of ownership over five years. Vendor and partner pitches typically focus on year-one cost. Build pitches focus on incremental engineering cost. Both undercount. A realistic five-year TCO model includes deployment, integration, ongoing operation, compliance maintenance, regulatory documentation updates, retraining or model refresh cadence, and exit costs in year five. The cheapest path on year-one cost is rarely the cheapest path on TCO.
Regulatory risk concentration versus governance complexity. A single partner across multiple AI workloads concentrates risk in that partner; multiple partners across multiple workloads diffuse risk but multiply governance overhead. Neither pattern is correct in the abstract; the institution chooses based on its risk appetite and its governance capacity.
Internal AI capability roadmap. Does this deployment build the institution's own AI capability, or remove the need to build it? Both are legitimate choices — some institutions explicitly want to outsource AI capability to partners; others see internal AI capability as a strategic asset. The decision should be deliberate, not implicit.
Reversibility. Which option is easiest to walk back from if it doesn't work? Build is hardest to reverse (sunk engineering investment). Buy is easiest (cancel the contract). Partner is in between (depends on exit terms). Institutions that want optionality should weight reversibility heavily.
Build, buy, and partner are three legitimate paths, not two with a fudge in the middle. Each is right for some use cases and some institutions; none is universally right.
The decision should be criteria-led, not advocacy-led. Capability ceiling, data sovereignty, compliance burden, time-to-production, operating-model fit, and lock-in tolerance are the six dimensions that resolve the question. Different use cases within the same institution may resolve them differently.
For regulated, high-volume, PII-rich workloads — the complaints, AML, fraud, call-centre, and KYC use cases where most FS institutions deploy AI — the partner path is structurally well-suited. For frontier-capability use cases without PII, buy from an API vendor. For competitive-moat use cases where the institution has the engineering capacity, build.
Whichever path is chosen, evaluate the supplier (vendor or partner) with the same rigour applied to any critical third-party arrangement. Reference customers, regulatory documentation track record, architectural transparency, exit terms, and editorial integrity in the sales conversation are the discriminators.
If your institution is evaluating an AI deployment path and wants to pressure-test the build / buy / partner decision against the criteria here — including the operating-model fit and the regulatory documentation burden — we can help you work through it.
Related reading:
Stop renting generic models. Start building specialized AI that runs on your infrastructure, knows your business, and stays under your control.