Build vs. Buy: Should Your Bank Build an AI Agent or License One?

Why This Question Comes Up Every Quarter

Every bank we talk to has had this debate at the executive level at least once. The CTO has a team that thinks they can build it. The CCO is worried about model risk for anything not built to a finance bar. The CFO has the line item for either approach. And someone on the board read about another bank that did the opposite of what is being proposed and is asking why.

I have been on both sides of this — at a regulated platform vendor and as the technical lead on a build inside a top-50 bank. So this is the framework I would use today.

The Two Decisions Hiding Inside One

"Build vs. buy" usually conflates two questions that should be separated.

The first is the platform question. Do you build the LLM orchestration, retrieval, telephony, eval harness, and compliance controls, or do you license a platform that has them. This is the big architectural call.

The second is the workflow question. Once you have a platform, do you build each workflow (the underwriting follow-up agent, the collections agent, the after-hours service agent) or do you take packaged ones and configure them.

Most banks should be on a licensed platform and should build the workflows themselves where they have an edge. The middle path. The reasons follow.

What "Build" Actually Costs

A serious in-house AI agent platform for regulated banking needs, at a minimum:

• A retrieval system with citations, versioning, and change control
• A prompt and configuration management system that meets SR 11-7 change control
• A telephony stack with PCI redaction and recording controls
• Real-time speech-to-text and text-to-speech tuned for finance vocabulary
• An eval harness, golden set tooling, and a production sampling system
• A second-line model risk dashboard
• Integrations to the LOS, core, CCaaS, CRM, and document store
• A 24/7 SRE capability for the production system
• A security posture good enough for SOC 2 Type II and bank InfoSec review

The team to build this is not small. We have seen banks staff it with eight to fifteen engineers, plus product, design, and a compliance lead. At loaded cost, that is $4–8M a year before the agent does anything for a borrower. The first workflow ships in 9 to 14 months. Time-to-value is the single biggest reason build programs underperform.

What "Buy" Actually Costs

A regulated-finance AI agent platform priced honestly runs $250K to $2M a year for a mid-size bank, depending on volume and use cases. The first workflow ships in 8 to 12 weeks. The platform vendor handles the eval harness, the citation enforcement, the compliance controls, and the upgrades. The bank's team focuses on the policy library, the workflow design, the integrations into their stack, and the second-line MRM work that cannot be outsourced.

The cost gap closes only when the bank is large enough that the build-team cost is a small percentage of total spend on AI service operations, and when the bank has a differentiated reason to own the platform. For most banks under $50B in assets, the math does not get there.

When Build Is the Right Call

A short list of conditions. Build the platform if:

• The bank has $50B+ in assets and a serious AI engineering bench already in production with non-AI systems
• There is a differentiated workflow that no vendor can serve and the workflow is core to the franchise
• The compliance and risk org has the bandwidth to validate every component the team produces
• The board has already decided that AI infrastructure is a strategic asset, not a cost center
• The five-year horizon is long enough to amortize the build

Even when these are true, most banks who build still license parts of the stack — the LLM, the speech models, the telephony — because doing it all from zero is rarely defensible.

When Buy Is the Right Call

The conditions to buy:

• The bank is under $50B in assets, or above it but does not have an AI engineering bench
• Time-to-value is the constraint (a regulator commitment, a frontline staffing crunch, a competitive pressure)
• The compliance org wants to focus its capacity on validating workflows, not validating infrastructure
• The use cases needed are well-served by what exists in the market

This describes most banks. Buy is the right answer for them.

What "Buy" Should Mean

A "buy" decision is not turnkey. The bank still owns the policy library, the workflow design, the integrations, the change control, the model risk file, and the borrower experience. The vendor owns the platform, the model controls, the upgrade path, and the SRE. A good vendor relationship has a clear line on each of these. We see programs fail because the bank assumed the vendor was doing things the vendor was not doing — usually the policy library or the eval set.

The Vendor Diligence Questions That Matter

Most RFPs miss the questions that actually predict program success. The ones we would ask:

• What is the change-control process for prompts and retrieval indexes? Who can change what, with what approvals?
• What does the production eval and sampling pipeline look like? Can we see the dashboard?
• How does the model card for each component map to SR 11-7? Will validators have what they need?
• What is the integration timeline for our specific core, LOS, and CCaaS?
• What is the audit pack on the day the agent goes live? Show it to me.
• How do you handle disclosure versioning when state law changes?
• Who answers the phone at 2 a.m. when the agent is offline?

If a vendor cannot answer all of these on the first call, the program will be rocky.

A Hybrid Pattern That Works

The pattern we see succeed at mid-size banks: license a regulated-finance AI platform for the infrastructure and the standard workflows. Build a small platform team in-house — three to five people — to own the policy library, the workflow design, the eval set, and the integrations. Treat the vendor as a partner the way the core processor is a partner: critical, scrutinized, replaceable in principle but not in practice.

This pattern gets banks to a working AI program in a quarter, not a year, and it builds the in-house muscle that pays back in the second and third workflow. It also keeps the model risk file clean, because the lines between vendor and bank responsibility are explicit.

The Decision Memo

The memo that goes to the board should answer five things:

1. Which workflows are in scope, and what is the projected lift on each
2. The total cost of build vs. buy over five years, including the second-line and InfoSec lift
3. The time-to-value for the first three workflows
4. The model risk and audit posture under each option
5. The exit and replacement path if the chosen path stops working

If the memo cannot answer all five, the decision is not ready to make.

The Honest Bias

I run a regulated-finance AI platform, so my bias is visible. The framework above is the one I used at the bank before I came over to the vendor side, and it is the one I would use today if I were sitting in a CIO seat. The right answer for most banks is a licensed platform plus a small, sharp in-house team. The wrong answer is a build program staffed below what the work requires, or a buy program where no one inside the bank owns the outcome.