Build, buy, or borrow: choosing a core banking path

Every growing institution eventually confronts its core system. The one that got them here — often a heavily customised package, sometimes a spreadsheet estate with a database attached — is now the constraint on what they can launch, and somebody asks whether to buy a proper platform or build.

The debate almost always gets argued on five-year cost, and it is almost never actually decided on cost. It is decided on control, and being honest about that upfront produces better outcomes.

Buying makes sense when your requirements are genuinely standard, when the vendor's roadmap points where you are going, and when regulatory change in your market is something you would rather someone else tracked. That last point is undersold. A serious vendor absorbs the cost of every compliance change across their whole client base. If you are a small institution in a market with an active regulator, that alone can justify the licence.

Buying goes wrong in a specific, predictable way: heavy customisation. An institution buys a platform, then pays to modify it until it matches how they already work. They now have the cost structure of a vendor product and the maintenance burden of custom software, plus an upgrade path that is effectively closed because every release re-breaks the modifications. We have met institutions four major versions behind, paying full maintenance, unable to move.

If you buy, the discipline is to change your processes to fit the product wherever the process is not a genuine differentiator. That is an organisational decision, not a technical one, and it needs executive backing before the contract is signed rather than negotiated painfully afterwards.

Building makes sense when the thing in question is how you actually compete. If your advantage is a lending methodology nobody else runs, or a distribution model built around agents, or a product designed for a market segment the packages ignore, then buying means asking a vendor to build your differentiator into a product they also sell to your competitors. That is a bad trade regardless of price.

Building goes wrong in an equally predictable way: underestimating the unglamorous surface area. The interesting part — the lending logic, the product engine — is perhaps a fifth of the work. The rest is user administration, permissions, audit trails, statements, general ledger integration, batch processing, reconciliation, regulatory extracts, data migration. None of it is a differentiator. All of it is mandatory, and all of it has to be right.

Which is why the answer is usually neither, in the pure form. It is borrow: take a solid platform for the commodity core — accounts, ledger, customers, tellering — and build only where you actually differ, integrating properly through documented interfaces rather than by writing into someone else's database.

That approach depends entirely on one thing, and it should dominate your evaluation: whether the platform has real, documented, supported APIs, and whether you can get to your own data. A core system that cannot be extended cleanly will become the ceiling on everything you do for the next decade, no matter how good its screens are today. We would take a merely adequate system with excellent interfaces over an excellent closed one, every time, without much hesitation.

Two things to insist on in any procurement. Get a data extract clause in writing — your data, in a documented format, on demand, without a professional services engagement. And test the API during evaluation, with your own engineers, against a real environment. Not a slide about the API. The actual API. The gap between the two is where most of the disappointment in this industry lives.

Decide what you are genuinely differentiated at. Buy the rest. Refuse to be locked out of your own data.

That is most of the decision.