The Build-Buy-Partner Grid — Stop Building Your Own Banking AI

Most banks are building artificial intelligence they should have bought. It is the most expensive instinct in the industry, and it hides behind a flattering story: we are a technology company now, our engineers can build anything, and the cost of writing code is falling. All three are partly true. None of them justify what the build bias actually costs.

This article gives you a single decision architecture — the Build-Buy-Partner Grid — for sourcing every artificial-intelligence capability in your bank, and shows where building in-house earns its place rather than burning it.

The economics the board rarely sees

Start with the numbers, because they reframe the whole conversation. In financial services, by some estimates between eighty-two and eighty-five percent of in-house artificial-intelligence builds fail — against a reported twenty-five to fifty percent for ordinary enterprise technology projects. When banks try to scale those builds across the enterprise, research suggests as many as ninety-five percent of pilots never reach production at all. Billions of dollars sit stranded in proof-of-concept, returning nothing on the profit-and-loss statement.

These projects do not fail because the algorithms are wrong. Most banks fail here because the data and the infrastructure underneath the model cannot carry it in production. A fraud model with near-perfect accuracy in a sandbox is useless if it cannot reach real-time transaction data behind a legacy core. As one analyst put it, these are not artificial-intelligence failures; they are infrastructure failures wearing an artificial-intelligence label.

Now compare the economics directly. A custom enterprise build runs, by reported estimates, five hundred thousand to two million dollars up front, and twelve to twenty-four months before it returns anything. A commercial platform runs fifty to two hundred thousand, and delivers measurable value in three to six months. Across three years, buying costs roughly fifty-six percent less than building, once you account for the maintenance, the retraining, and the integration that a build carries for its whole life.

So the question for the boardroom is not whether your engineers can build it. They probably can. The question is whether building it earns its place against the alternative. When the instinct is to build, leaders should ask one thing first: do we own a moat here, or are we about to rebuild something we could have bought this quarter.

The grid: two axes, four verdicts

To answer that, you need a map. Every artificial-intelligence capability in a bank can be placed on two axes, and where it lands tells you how to source it.

The first axis is Strategic Differentiation. Does this capability create a defensible advantage, or is it a commodity your competitors can buy off the same shelf? If they can, it is not an edge — it is table stakes, and building it yourself wastes scarce engineering talent.

The second axis is Internal Readiness. Do you have the proprietary data, the talent, and the architecture to build this and, the word that matters most, sustain it? A capability can be genuinely differentiating and still be the wrong build, because if you lack the real-time pipelines to feed it, the project will be abandoned no matter how good the idea was.

Cross the two axes and you get four verdicts.

That last verdict settles the question every chief information officer is asked: should we build our own model? Training a frontier model from scratch costs, by reported estimates, upward of seventy-eight to one hundred million dollars. Fine-tuning an existing one costs five hundred to five thousand — a reported saving of sixty to ninety percent. For a bank, building your own foundation model is almost never the answer. Assemble; do not build.

Where building actually pays

So where does building earn its keep? Only where you own something no vendor can sell — your own data, your own workflow.

Real-time fraud detection on your own transaction ledger qualifies: the proprietary graph and the millisecond latency are things a general vendor cannot match, which is why an institution like Capital One builds graph models on its own ledger rather than buying them. Credit underwriting on your own performance data qualifies. Systematic trading logic qualifies, because the logic is the entire competitive advantage. Bank of America built its internal knowledge assistant in-house, trained on thousands of its own vetted documents, because the value was the proprietary corpus, not the model.

But a chatbot, a document extractor, a coding assistant — those are commodities. Building them in-house spends quant talent on work a vendor already does better and cheaper. The discipline is not "never build." It is "build only the few capabilities where you alone own the moat, and buy or assemble everything else."

The three forces regulated finance adds

The grid alone will not tell you everything. In a regulated bank, three forces override the theory.

First, liability stays home. Buying a model does not move the regulatory responsibility one inch. You remain accountable to your regulator for its fairness and its outputs, so any purchase must come with audit logs and explainability good enough for your own governance. This is where the earlier framework in this series applies directly: the Ledger and the Owner — the governance you build for your own models — extend to the models you buy.

Second, speed against opportunity cost. A model you can deploy in three months often beats one you build in twenty-four, because the cost of waiting two years usually exceeds the price of the contract.

Third, lock-in. Lean entirely on one provider and you inherit its price increases and its outages — what the field now calls token inflation. The disciplined banks architect for model agnosticism, so they can swap one provider for another as the economics shift.

And remember the harder truth from the operating-model work: buying is the easy part. The value is not in the tool — it is in redesigning the operating model around it. The purchase order is not the strategy.

The proof, and the regulation that rewards it

Look at who is getting this right, and the pattern is consistent. When the edge is real but the talent is not, the strongest banks partner rather than build. HSBC did not spend years building an anti-money-laundering engine; it partnered with a specialist for contextual network analysis. Morgan Stanley did not train its own model for wealth advice; it partnered and wrapped the partner model in its own guardrails. And on the largest scale, Singapore's DBS generated close to a billion Singapore dollars in value not by building foundation models, but by orchestrating more than fifteen hundred of them across hundreds of use cases. Assemble and orchestrate; do not train from scratch.

The regulation now rewards exactly this discipline. The revised United States model-risk guidance scales oversight by materiality and pushes generative and agentic systems onto the bank to govern — out of formal scope is not out of accountability. Europe's deployer rules mean that buying a high-risk credit model still obliges you to provide human oversight, a fundamental-rights impact assessment, and a right to explanation. Europe's operational-resilience rules make concentration on a single cloud or vendor a documented risk you must manage. And Vietnam's data decree now requires vendor data transfers to be assessed before they happen. Across every jurisdiction the message is the same: outsourcing the model never outsources the liability.

There is even a systemic dimension. As more banks buy the same few models on the same few clouds, the whole system converges, and shared models can move in lockstep under stress. Concentration is no longer just your risk; it is everyone's. A sourcing strategy that builds in model agnosticism is not only cheaper and safer for your bank — it is a small contribution to a more resilient system.

The Sourcing Decision Loop

So here is the loop to run on Monday — 4 steps:

1. Score each capability for differentiation — moat or commodity.
2. Score it for readiness — can you sustain it, not just pilot it.
3. Route it — Build, Partner, Buy, or Assemble — and for any Build, demand the data moat in writing.
4. Govern the vendor — deployer controls, a concentration limit, and a model-agnostic exit before you sign.

Run that loop across your whole artificial-intelligence portfolio and the picture usually inverts. The capabilities you were about to build, you buy. The model you were about to train, you assemble. And the scarce engineering talent you were spreading thin gets concentrated on the two or three places where you genuinely own a moat — which is the only place a build was ever going to pay.

Stop building what you can buy. Build only what you alone can own.

Sources & note. Reported industry estimates, hedged as in the article: 82–85% of in-house AI builds in financial services fail (against a reported 25–50% for ordinary enterprise technology projects); research suggests as many as ~95% of pilots never reach production; buying costs roughly 56% less than building across three years ($500K–$2M custom build over 12–24 months, versus $50–200K platform delivering in 3–6 months); training a frontier model from scratch is reported at upward of $78–100M, versus $500–5,000 to fine-tune (a reported 60–90% saving). U.S. Federal Reserve / OCC / FDIC — SR 26-2 revised model-risk guidance (scales by materiality; generative/agentic AI outside formal scope but still governed). EU AI Act — deployer duties for high-risk credit models (human oversight, fundamental-rights impact assessment, right to explanation). EU DORA — third-party / cloud concentration as a documented, managed risk. Vietnam — Decree 356/2025 ex-ante assessment of cross-border data transfers to vendors. Company examples (Capital One, Bank of America, HSBC, Morgan Stanley, DBS — close to S$1B via 1,500+ models) as publicly reported. FACT discipline: all cost and failure figures are reported estimates and vary across sources.

Independent thought leadership · not affiliated with any current or past employer · compliant with Vietnam AI Law 134/2025 + PDPL.