Build vs Buy: AI for Financial Services

The build-versus-buy conversation in financial services has changed shape. Five years ago building meant training a model, which almost nobody could justify. Today it means assembling capable components — a hosted model, a vector store, an orchestration framework — and a competent team can demonstrate something impressive in a fortnight.

That demonstration is what makes the decision hard. The prototype is not the hard part, and the gap between a convincing prototype and something a compliance committee will approve is where most internal projects quietly end.

What building actually commits you to

The prototype is perhaps a tenth of the work. The remainder is the part nobody demonstrates.

Data connectivity

An assistant is only useful if it can reach your portfolio system, your CRM, your document store and your custodian feeds. Each integration is a project with its own authentication, formats, refresh logic and failure modes. This is consistently the largest line item and the most underestimated.

Grounding and citation

A model answering from memory will invent figures. Preventing that requires retrieval over your own data, enforced citation, and refusal when nothing relevant is found. Each of those is harder to engineer than it sounds, and the failure mode is silent — the system produces a confident wrong answer rather than an error.

Permissions

The assistant must respect entitlements already defined in your source systems. A relationship manager asking a question must not receive an answer drawn from another banker’s book. Retrofitting permissions onto a retrieval system after it works is substantially harder than designing for it.

Audit and evidence

Every question, every answer, every source, retained and queryable. Not because it is good practice, but because a regulator will eventually ask what the system told a banker on a particular date.

Ongoing maintenance

Models are deprecated. Providers change pricing and terms. Your source systems get upgraded. Someone owns this permanently — which means it is a staffing commitment, not a project.

When building is genuinely right

Three conditions, and they need to hold together.

The capability is your differentiator. If the thing you are building is what clients choose you for, build it. A firm whose edge is a proprietary research process should not outsource that process.

You already run a platform engineering function. Not a few capable developers — a team that owns production systems, on-call rotations and security review. If this would be your first such system, the AI project will also be an organisational change project.

Your requirements are genuinely unusual. A specific jurisdiction, an unusual asset mix, a workflow nobody else has. Worth testing honestly: most firms that believe their requirements are unique discover they are a configuration of a common pattern.

When buying is right

Buying wins when the capability is necessary but not differentiating — which describes most AI assistance in wealth management. Clients do not choose a private bank for the quality of its internal search.

It also wins when time matters. An eighteen-month internal build competes against firms deploying in months.

And it wins when the hard parts are already solved. Connectivity, grounding, permissions and audit are the same problems at every firm. Paying for them once, already built and already reviewed, is usually the cheaper answer even when the licence looks expensive next to a developer’s salary.

The option most comparisons miss

The question is rarely binary. The productive split is to buy the infrastructure — connectivity, retrieval, grounding, permissions, audit — and build the parts specific to your firm on top of it.

Your firm’s particular workflows, your terminology, your review process: these are configuration and extension, and they are where internal knowledge genuinely adds value. The plumbing beneath them is not where a wealth manager should be spending engineering time. This is the premise behind adopting modules for what you are missing rather than replacing or rebuilding wholesale.

Comparing honestly

When the build case is costed, four things are routinely left out.

The security review. Months, not weeks, and it happens after the system works, which is when delay is most expensive.

The second integration. The first is a project. The fifth is a maintenance burden that never ends.

Key-person risk. The engineer who built it is one resignation away from being unavailable, and internal AI systems are notoriously under-documented.

The cost of being wrong slowly. An internal build that fails usually fails after eighteen months, by which time the opportunity has moved.

Against that, the buy case has its own omissions — vendor dependency, data residency, and the real limits of configuration. Those are legitimate, and the right response is to interrogate them directly. Our guide to why regulated finance was slow to adopt AI covers what the blockers actually were.

Common questions

Is building cheaper than buying? Rarely, once connectivity, compliance engineering and permanent maintenance are costed. The prototype is cheap; the production system is not.

Does buying mean our data goes to a vendor? It should not. Ask precisely where processing occurs and where records are stored — an architecture that keeps data inside your perimeter is available, so treat anything less as a choice rather than a constraint.

How long does a bought solution take to deploy? Months, with most of the time spent on your integrations and your security review rather than the software.

What if we outgrow it? A fair question to put to any vendor. Ask what your data looks like on exit and how much of your configuration is portable.

A useful first test

Before committing either way, write down the five questions you most want the system to answer, then check how many source systems each one touches. If the answer is more than two, your project is a data connectivity project with an AI component — and that should decide where you spend your effort.

If you would like to see what the bought version looks like against your own systems, book a demo.