Every bank faces this question eventually. Core system replacement. Digital channel. Payments hub. Data platform. Lending system. The list goes on.

Should you build it yourself or buy from a vendor?

The consulting answer is always "it depends." Which is true and also useless. After enough of these decisions, I've developed a clearer framework.

When to build vs. buy in banking technology

Buy when the capability is a utility

If the functionality is standard across banks, and differentiation doesn't matter, buy it. Core processing, general ledger, payments switching — these are utilities. They need to work reliably, securely, and cost-effectively. They don't need to be unique.

Buying a utility lets you focus your resources on things that actually differentiate you. It also transfers risk to the vendor. When the payments system goes down, it's their problem, not yours.

Build when the capability is strategic

If the functionality is central to how you compete, and you can do it better than vendors, build it. Digital customer experience, data analytics, underwriting models — these are areas where differentiation matters.

Building gives you control. You can move faster, iterate more, and create capabilities that competitors can't buy off the shelf. It also creates intellectual property that can become an asset over time.

The gray area

Most decisions fall in the middle. The capability matters, but vendors offer reasonable solutions. The build option is attractive, but expensive. The buy option is available, but constraining.

In these cases, I use three tests.

Test one: Is the vendor's roadmap aligned with your needs?

Vendors build for their entire customer base. If your needs are unique, you'll be waiting for features that may never come. If your needs are common, the vendor's roadmap probably serves you well.

Test two: Can you integrate it cleanly?

Every vendor system creates integration points. If those integrations are simple and standard, buying is easy. If they're complex and custom, you're effectively building anyway — just on top of someone else's platform.

Test three: Can you support it?

Vendor systems require internal expertise. If you can't staff that expertise, you're dependent on the vendor for everything — support, enhancements, troubleshooting. That dependency has a cost, even if it's not on the invoice.

The hidden cost of build

Building seems expensive because the costs are visible. Developer salaries. Infrastructure. Tooling. Maintenance. Support.

But buying has hidden costs too. License fees escalate. Customization costs accumulate. Vendor relationships require management. Integration complexity grows. And you're always constrained by what the vendor decides to build.

I've seen banks spend more on vendor customizations over five years than it would have cost to build the system themselves. I've also seen banks spend millions building systems that vendors could have provided for a fraction of the cost.

The hidden cost of buy

The real cost of buying isn't financial. It's strategic. When you buy, you cede control over your roadmap. Your ability to innovate is bounded by what your vendors provide. Your differentiation is limited to what you can build on top of their platforms.

For commodity capabilities, this is fine. For strategic ones, it's dangerous.

What I've learned

Build when you must. Buy when you can. But be honest about which is which.

Most banks buy too much. They treat everything as a utility, then wonder why they can't differentiate. They outsource their core capabilities, then struggle to innovate.

Some banks build too much. They treat everything as strategic, then wonder why their costs are high and their timelines are long. They build systems that vendors could have provided, then struggle to maintain them.

The right answer is a portfolio. Buy the utilities. Build the differentiators. And be ruthless about knowing the difference.