Build vs buy: the real cost of a core banking system

Sooner or later every fintech founder prices the same decision: build the core banking system in-house, or license one and configure it. The naive comparison — a license fee on one side, a few developer salaries on the other — is almost always wrong, because the two columns do not contain the same things.

The honest comparison is total cost of ownership over the life of the product: the build, the permanent maintenance, the security and compliance upkeep, and the revenue you do not earn while you build. We build core banking software, so we obviously have a position — but the calculation below is the one we would want to see if we were the buyers.

What "a core banking system" actually means

Most build-vs-buy estimates go wrong before any number is written down, because the scope is understated. The banking app your customers see is the visible fraction of the system. A production-grade core is four products in one:

• The transactional core: a double-entry ledger that stays balanced under concurrent load, where every balance is derived from the ledger and reconciled daily against every provider.
• The customer product: the banking app itself, onboarding with KYC and KYB tiers, multi-currency accounts, transfers, cards — and, increasingly, crypto wallets with real key custody behind them.
• The second product nobody scopes: an operations back office for compliance queues, transaction monitoring, fee configuration, reporting and granular staff roles.
• The invisible layer: an append-only audit trail, two-factor flows beyond login, rate limiting, device fingerprinting, and key management that keeps secrets out of code and database.

The build path: what the budget actually contains

A realistic in-house build needs senior backend engineers with financial-systems experience, frontend engineers, DevOps and security, QA, and product coordination that understands compliance. Teams that reach production quality are rarely smaller than six to ten senior people — and the scarce profile, engineers who have already run ledgers and custody in production, is exactly the one that is hardest to hire and to keep.

On timeline, the pattern is consistent: one to two years to reach what a mature platform provides on day one. The time does not go into screens; it goes into ledger correctness under concurrency, provider integrations that each bring their own sandbox quirks and certification steps, security hardening, and the long tail of edge cases that only appear with real customers and real money.

And the spending does not end at launch. Providers change APIs, blockchain networks upgrade, regulations move, dependencies rot. An in-house core is not a project that ends; it is a permanent team you are committing to fund for as long as the product exists.

The costs that never make the spreadsheet

• Opportunity cost: every month spent building the ledger is a month the product is not in the market. The competitors who licensed their core are onboarding customers and iterating on pricing while you are still integrating providers.
• Hiring risk: the build plan assumes the team that starts it finishes it. Losing one of two engineers who understand the ledger mid-build is a schedule event measured in months.
• The correctness tail: a ledger that is 99% correct is not almost done — it is a generator of support tickets, reconciliation breaks and regulatory incidents. The last 1% costs more than the first 99%.
• Security as an operation: penetration tests, key rotation, incident response, monitoring and alerting — recurring costs that exist whether or not anything goes wrong.
• Compliance upkeep: KYC document expiry, evolving crypto-asset rules, new reporting obligations. The work recurs every year and cannot be deferred.
• The back office: in-house builds routinely treat staff tooling as an afterthought, and the operations team inherits a SQL console. Every regulator and auditor who looks at that will make you rebuild it properly.
• Localization: shipping in many languages with real right-to-left support is cheap when designed in from day one and expensive to retrofit after the product is built.

The buy path: what you pay for and what remains yours

On the buy side the technology column is explicit: a license or rental for the platform, with serious vendors pricing modules, chains and languages individually so the bill tracks what you actually activate, plus the infrastructure the instance runs on. What buying does not remove: your regulatory licenses or partner arrangements, your commercial agreements with providers, your operations staff, your distribution. Those costs belong to the operator on either path — buying removes the engineering mountain, not the business.

The honest costs of buying are dependency-shaped: the roadmap is not fully yours, and the platform is only as good as its worst module. The mitigations are things you can verify before signing: a dedicated instance with your own database and your own encrypted secrets, so leaving the vendor is a migration rather than a hostage negotiation; provider integrations kept behind an abstraction, so the agreements are yours and providers can be replaced; modular licensing, so you pay only for what you switch on; and evidence that the platform has processed real customers and real money.

When building in-house is the right call

Build-vs-buy is not a rhetorical question with a predetermined answer. Building is right when at least one of these is true:

• The infrastructure is the product: you are selling the ledger, the custody or the banking-as-a-service capability itself, so owning it is the business.
• Your differentiation lives in requirements no vendor covers — not features a vendor is missing this quarter, but capabilities structurally outside what platforms do.
• You already have a senior team with production core-banking experience, and the runway to fund them for years without revenue.
• A regulator or parent company imposes full in-house control of the stack as a condition you cannot negotiate.

A five-question framework

• Differentiation: will a customer ever choose you because your ledger is home-grown? If your edge is product, distribution or pricing, the core is plumbing — essential, but not yours to reinvent.
• Timeline: can the business absorb one to two years without revenue while the core is built, in a market that is not waiting?
• Team: do you have, or can you realistically hire and retain, engineers who have operated money-moving systems in production?
• Three-year cost: compare build cost plus a permanent maintenance team against license plus activated modules over three years — never launch cost against launch cost.
• Exit: what does leaving look like on each path? In-house, the risk is key people walking out with the knowledge. With a vendor, demand a dedicated instance, your own database and your own keys, and the exit is a migration.

Where Coreza sits in this decision

Coreza is the buy column, built to survive the checklist above: each client runs a dedicated instance on AWS with its own database and its own encrypted secrets, every module — chains, languages, tokens included — is individually licensed so the price tracks what you activate, and provider integrations sit behind an abstraction so the commercial agreements stay yours.

A version of this core has been running in production at a regulated European fintech since 2024, and a new instance deploys in weeks: branding, modules, languages and chains are configuration, not engineering. If you are running the build-vs-buy numbers, that is the comparison we invite you to make — three-year cost against three-year cost, with the hidden column filled in.