A founder asked me last week whether building her own core would set her apart. Fair question - and my honest answer was: probably not. For most launch-stage fintechs, buying or licensing the core is the better call, because building means owning the accounts, ledger, payments, AML/KYC, cards, and reporting forever, plus the platform engineering underneath. Building genuinely earns its place in one case: when the core itself is your edge and you can fund a permanent team to run it.
*As of July 2026, decided from a delivery and engineering standpoint.*
Tuesday Tech #3 - build vs buy core banking software: an engineering decision framework.
Building is the right call in one situation, and it is rarer than founders think: when the core itself is part of what makes you different, and you can fund the team to run it for years. I have seen that case work - a team whose whole product was a novel ledger no vendor could supply, where buying would have blunted the very thing that set them apart. But that is the exception, not the default. So before anyone writes a line of code, I run the decision through five questions - and a single "no" usually settles it.
Score "build" only if every one of these is a clear yes:
If any answer is no, you buy or license. I think of one payments startup - strong engineers, real ambition - that was set on building, until we walked these five questions together and it stuck on funding: it couldn't commit to a permanent platform team through the lean quarters. It bought, launched on time, and never looked back. That is the pattern across the 100+ launches we've delivered, and it is not a failure of ambition; it is the right read on where scarce engineering should go.
When a team says "we'll build the core," they are picturing the first release. The first release is the cheap part. The bill is the decade after it - because you do not ship a core banking system once, you run it forever.
A build means your team writes and operates accounts and the ledger, payments and reconciliation, onboarding, AML/KYC, card issuing, accounting, and reporting - and then keeps every one of them correct as PSD2, AML rules, and reporting standards move. That is not a project with an end date. It is a product with an indefinite roadmap and an on-call rotation.
This is the part the licensing-context view does not dwell on, so it is worth saying plainly: the customer-facing features are the visible 20%. The invisible 80% - double-entry correctness, idempotent payment processing, audit trails, reconciliation, safeguarding-ready accounting - is where the engineering years actually disappear, and it is exactly the part a mature platform already ships. *(The 20/80 split is Advapay's working estimate from delivery experience, not a published statistic.)*
Say you accept the maintenance. There is still a second system most build plans never scope: the modern platform layer that makes a core scale and stay observable. Founders budget the banking features and forget the engine room underneath them - and the engine room is where the surprise cost lives.
A useful yardstick is what a current platform actually contains. Macrobank 3.1 (2026) is built on .NET 10 with Apache Ignite distributed caching, RabbitMQ messaging, OpenTelemetry observability, and a Kubernetes-ready deployment model (release notes). To build a core that behaves the same way, you would have to design, integrate, and operate the equivalents of all of those - and keep them current.
Then add the moving parts that look like features but are platforms in their own right. Card issuing is the clearest: 3.1 ships a provider-agnostic Card Management Module, so you can switch card issuers without rebuilding. Replicating that abstraction in-house - plus crypto handling and AML screening - is months of work per integration. A build is not one system you finish; it is several systems you maintain in parallel.
When a team tells me they'll build the core, I ask who owns the ledger at 3 a.m. in year three. It is never a roadmap question for them yet - but that on-call reality, not the first release, is what build-versus-buy is really about.
The honest comparison is not build-price versus license-price. It is a permanent engineering payroll versus a predictable, scalable line item - and whoever owns the code owns the maintenance and compliance bill that comes with it. Buying converts an open-ended liability into a known cost.
On time, buying wins decisively. A configured platform can be demonstrable in weeks to months, while a credible in-house core typically takes multiple years of sustained engineering to reach production parity - a wide planning range that varies by scope and team, not a fixed figure. That gap is not just cost; it can delay the license, because EU EMI/PI authorization itself runs roughly 6-18 months and your platform has to be demonstrable inside that window.
On cost, a build front-loads senior salaries and never stops needing them - every framework upgrade, security patch, regulatory change, and integration is your team's job, indefinitely. SaaS, a license, or source code turns that into a line item and pushes most maintenance onto a vendor whose whole business is keeping the platform current. Control is the one axis where build genuinely wins, and it only pays off if you need something the market truly cannot supply.
The practical alternative to building is straightforward: Advapay delivers Macrobank as a production core in whichever model fits your stage - SaaS, a perpetual license, or a source-code purchase - so you get the modern stack, the regulated module set, and the maintenance handled, without standing up a platform team. And because Advapay covers the license and banking access too, the core arrives integrated with the launch, not as a separate project.
You take the core banking software configured to your model, cloud-hosted or on-premise, and - if owning the roadmap matters - you can buy the source code and keep the option to extend it yourself. Either way you skip the years of platform engineering and the permanent compliance treadmill. Advapay backs this with 100+ clients, 5 offices, and a team of around 50 people, with Macrobank already in production across multiple regulated markets. For the simpler "why buy a ready-made solution" case, Advapay's build-vs-buy explainer is already live.
For nearly every launch-stage fintech, buying is cheaper in total cost of ownership. Building front-loads senior engineering salaries and creates a permanent maintenance and compliance obligation; SaaS, a license, or source code converts that into a predictable, scalable cost.
A credible in-house core typically takes multiple years to reach production parity with a mature platform, and the timeline varies widely by scope and team. A configured platform can be demonstrable in weeks to months - which matters when authorization itself runs 6-18 months.
The modern platform layer (typed runtime, caching, messaging, observability, orchestration) and the unglamorous regulated parts (audit trails, reconciliation, safeguarding-ready accounting, reporting) - plus permanently maintaining all of it as rules change. These, not the customer-facing app, are where the engineering years go.
That guide weighs the decision in the context of getting licensed. This article is the engineering and delivery view - what building entails, the platform you'd have to replicate, and a go/no-go test. Read them together.
Build versus buy is not a measure of how serious your team is. It is a measure of where your scarce engineering belongs. Building a core means owning several systems forever: the banking features, the modern platform beneath them, and the compliance work that never ends. Reserve that for the rare case where the core is genuinely your edge and you can fund it indefinitely. For the overwhelming majority of payments, e-money, and neobank launches, the core is infrastructure - and for infrastructure, buying is the disciplined choice, not the lazy one.
If you want a straight read on which side your model falls, speak to our team - we can talk it through against your actual plan, not a generic one. Next week, Tuesday Tech goes inside the "buy" side - SaaS vs license vs source code - so you can pick the model, not just the decision.
