Why Most Digital Banks Get It Wrong Before They Write a Single Line of Code

The global neobank market is expanding at a pace that would have seemed implausible a decade ago. The race to launch digital banking products has never been more competitive. Or more consequential. Yet for every Monzo, Revolut, or Chime that made it to market cleanly and quickly, there are a dozen banking ventures that burned through the runway, missed regulatory windows, and watched their competitive advantage erode while still in pre-launch.

But, why? The business case can seem sound. The team is qualified. The funding was secured. So what can go that wrong?

More often than not, the answer lives somewhere in the earliest technical and architectural decisions.

Decisions that need to be made wisely before a single customer ever opens an account. There are many nuances to the decision, but it comes down to knowing which problems have been solved and what differentiates you.

The nuances of build vs buy

There’s a seductive logic to building everything in-house. It feels like ownership, like control, like differentiation. But in practice, teams that insist on building every component from scratch are making a strategic error they’ll spend years paying for.

A useful principle: if it doesn’t differentiate you in year three, don’t build it in year zero. Buy it.

Compliance infrastructure is the most common place teams fall into this trap. AML and KYC tooling, fraud detection, sanctions screening — these are solved problems. The vendor ecosystem is mature, well-regulated, and deeply integrated into how financial institutions operate globally. Global financial institutions spend billions on financial crime compliance and the cost only continues to rise with the advent of AI cybersecurity threats. 

Luckily, there is no shortage of proven solutions. Building a proprietary alternative from scratch isn’t innovation; it’s reinvention of the wheel, usually at the cost of your timeline. 

Regulatory reporting presents an even more dangerous blind spot. Many teams defer it, assuming they can just assemble the data and buy a vendor solution later. But reporting tooling can only be procured effectively if the underlying data architecture (which must be built) is designed with reporting in mind from day one.

Regulatory bodies don’t wait for data architectures to mature, and retrofitting reporting capabilities onto a live system is a brutal engineering challenge, especially if you are migration from legacy core banking safely. You can buy the reporting engine, but you have to build the foundation. Reserve your engineering talent for the problems only your team can solve.

What actually deserves to be built

So what should a digital bank own entirely? 

Two categories stand out.

The first is integration and orchestration logic. This is the connective tissue of a digital bank, how account opening flows end-to-end, how payment instructions are routed across rails and retried on failure, how limits are enforced across product types, how exceptions surface and resolve. These workflows sit at the intersection of your product logic, your third-party relationships, and your core banking system.

No vendor will build this for you in a way that reflects your specific proposition. You must maintain control and flexibility where it matters most. That means, build the orchestration layer internally for specific needs of the bank to maintain control and flexibility where it matters the most. The right core banking implementation partner can help you construct these custom workflows without sacrificing that critical ownership.

Data architecture falls into the same category. While it might not directly differentiate your product to a customer, data is the heart of every integration and enables you to build those differentiating features the right way. Because of that, you must maintain complete control internally. It is not glamorous, but it is foundational. Banks that underinvest here consistently find themselves optimising for the wrong things, building features in response to surface level signals because the underlying data fails to give them a clear picture of what is actually happening. In the 2024 Global Banking Annual Review, experts at McKinsey found that financial institutions with mature data capabilities outperformed peers on customer acquisition cost by up to 30%. That gap doesn’t emerge from better marketing. It emerges from better infrastructure.

The second category is customer experience. The mobile interface your customers will see as your first touchpoint and interact with daily. In a market where switching costs are low and alternatives are abundant, the app is often the first and most lasting impression a customer forms. Digital-native challengers have understood this from the beginning; many incumbent banks are still catching up. User experience is one of the few genuine differentiators visible at first contact, and it compounds: J.D. Power’s 2024 U.S. Banking Mobile App Satisfaction Study found that customers who rate their mobile banking experience highly are significantly more likely to expand their product relationship with that institution. The front end is not a polish exercise. It is a retention mechanism.

Rethinking where core banking falls in the decision

Core banking sits in a category of its own because it is simultaneously something you should buy and something you must configure deeply.

The mistake teams make is treating the core as a black box. Just selecting a platform and then working around its constraints rather than through its capabilities. Modern core banking platforms, from vendors like Thought Machine, Mambu, and 10x Banking, are built on the assumption that product teams will configure them extensively. For example, the best partner for Thought Machine implementation and others would know that: defining product parameters, composing propositions, and orchestrating workflows around the ledger logic the platform provides.  Because this configuration is a huge effort itself, banks should not save money on a proper implementation partner. A vendor with a track record will not only configure the products properly but will also advise on exactly which logic should go into the core and which should go into the orchestration layer.

What you should never be building is the ledger itself — the posting engine, the transaction processing layer, the financial audit trail. That infrastructure exists, it is robust, and rebuilding it serves no one. What you should be building is everything that sits above it: the logic that makes your current account different from a competitor’s, the rules that govern how your credit product behaves, the orchestration that ties your core to your payment rails to your third-party services.

The banks that launch cleanly tend to have internalized this distinction early. They treat the core as infrastructure and build their differentiation on top of it, rather than treating the entire stack as a construction project.

Launching fast, but without the added risk

There is a persistent assumption in the industry that launching fast requires compromising on product integrity or regulatory robustness. The evidence doesn’t support this. Fast launches and and well-built launches are not in opposition, they are the product of the same discipline: knowing which problems have already been solved and refusing to solve them again. However, going live quickly also requires ruthless prioritization. You have to look at your features through the lens of time. If an annual regulatory report is not due until six months after your launch, do not build it for day one. If customer offboarding can be handled manually by your back office initially, leave it out of your launch scope.

The digital banking sector added over 400 million users globally between 2021 and 2024. That growth reflects genuine consumer demand for better products. The opportunity is real. The question for any team preparing to enter the market is not whether to move quickly, but how to move quickly in a way that doesn’t require undoing half of what was built once the first customers arrive.

Build the things that make you different. Buy the things that don’t. And be honest, very early, about which is which. We have a banking team of experts and core banking migration consultants that have seen several fully digital banking projects launch in 18 months, not 36. Reach out to us and chat with them about all the nuances in build vs buy decisions.

Digital Bank Launch: Your Questions, Answered

Launching cleanly comes down to knowing which problems are already solved. Here are answers to the questions founders ask most often when planning a digital bank.

Step-by-step guide to launch a digital bank

Launching a digital bank generally follows a clear sequence:

• validate the business case and target segment;
• secure funding;
• engage with the regulator and apply for the right licence;
• design the technology architecture and decide what to build versus buy;
• select and configure a core banking platform;
• integrate compliance, payments, and KYC/AML providers;
• build the orchestration layer and customer-facing app;
• complete regulatory testing and security audits;
• then run a controlled launch before scaling.

The biggest determinant of speed isn’t funding or team size — it’s the early architectural decisions about what to build and what to buy. Vacuumlabs has helped fully digital banks go live in 18 months rather than 36 by getting those calls right from day zero. Talk to our banking team.

What licences are required to start a digital bank?

The licence required depends on what the bank intends to do and where it operates. To hold customer deposits and lend, a venture typically needs a full banking licence (a credit institution authorisation) from its national regulator. Lighter models may instead use an e-money institution (EMI) or payment institution licence, or partner with an already-licensed bank under a Banking-as-a-Service arrangement. Requirements, capital thresholds, and timelines vary significantly by jurisdiction, so early engagement with the relevant regulator is essential.

How to choose core banking for new digital bank?

Choosing a core for a new digital bank comes down to a few factors:

• cloud-native architecture,
• real-time processing,
• API-first design,
• configurability,
• and a vendor track record in your target market.

Modern platforms like Thought Machine Vault Core, Mambu, and 10x Banking are built on the assumption that product teams will configure them deeply — defining product parameters and composing propositions around the platform’s ledger logic. The mistake teams make is treating the core as a black box and working around its constraints instead of through its capabilities. The right implementation partner advises on exactly which logic belongs in the core versus the orchestration layer. See how Vacuumlabs approaches core banking.

Compliance checklist for launching a digital banking service

A practical compliance checklist for a digital bank launch covers:

• the correct banking, EMI, or payment licence for your model;
• AML and KYC onboarding workflows;
• sanctions and PEP screening; fraud detection and transaction monitoring;
• data protection compliance (such as GDPR);
• and regulatory reporting.

A critical, often-missed point: reporting tooling can only be procured effectively if the underlying data architecture is designed with reporting in mind from day one. Compliance infrastructure like AML, KYC, and sanctions screening are solved problems with a mature vendor ecosystem — these should generally be bought, not built. Vacuumlabs helps banks integrate these providers into a stable, well-architected core. Explore our fintech engineering services.

Technology stack blueprint for new digital banking venture

A modern digital banking stack has clear layers:

• a cloud-native core banking platform (the ledger and posting engine) that you buy and configure;
• an orchestration and integration layer that you build, tying the core to payment rails and third-party services;
• bought compliance tooling for KYC, AML, fraud, and sanctions;
• a data architecture you own and control;
• and customer-facing mobile and web apps.

The guiding principle: buy the ledger and solved compliance problems, build the orchestration logic and customer experience that actually differentiate you. Vacuumlabs designs and builds these stacks end-to-end for new banks and regulated fintechs. Explore our greenfield solutions.

Digital bank business plan template for new founders

A digital bank business plan typically covers:

• the target customer segment and the specific problem you solve;
• your product proposition and how it differentiates from incumbents and challengers;
• the regulatory and licensing strategy; a technology and build-vs-buy plan;
• a financial model covering capital requirements, funding rounds, and the path to profitability;
• a go-to-market and customer acquisition plan;
• a risk and compliance framework;
• and a realistic launch timeline with milestones.

The strongest plans are honest very early about which capabilities genuinely differentiate the venture and which are commodity problems already solved by the vendor ecosystem.

Marketing launch strategy for new digital-only bank

A digital-only bank’s launch marketing usually combines a clear value proposition aimed at an underserved segment, a waitlist or early-access programme to build pre-launch demand, referral mechanics that turn early users into advocates, and content that builds trust around security and regulation. Because switching costs are low and alternatives are abundant, the product experience itself — especially the mobile app — is often the most powerful marketing asset. Acquisition is most efficient when the underlying data infrastructure gives a clear picture of customer behaviour, which is why mature data capabilities correlate with markedly lower customer acquisition costs.

Capital requirements to set up a digital bank

Capital requirements depend on the licence type and jurisdiction. A full banking (credit institution) licence carries the highest minimum initial capital and ongoing regulatory capital obligations, set by the relevant regulator and scaled to the bank’s risk profile. E-money and payment institution licences require substantially less initial capital. Beyond the regulatory minimum, founders need significant operating runway to cover technology build, compliance, and staffing through to launch and early scaling — which is typically the larger figure. Exact thresholds vary by country, so confirm with your target regulator.

Timeline and milestones for launching a neobank successfully

A neobank launch is often assumed to take three years or more, but disciplined teams reach market faster.

Key milestones include:

• business case and funding secured;
• regulator engagement and licence application submitted;
• core banking platform selected and configured;
• compliance, payments, and KYC integrations completed;
• orchestration layer and app built;
• regulatory and security testing passed;
• and a controlled go-live before scaling.

Fast and well-built launches aren’t in opposition — they come from the same discipline of refusing to rebuild solved problems and ruthlessly prioritising what’s needed for day one. Vacuumlabs has supported fully digital banks, including Mox by Standard Chartered, in launching in 18 months rather than 36. See the Mox case study.

Key hiring plan for early-stage digital bank teams

An early-stage digital bank needs a focused core team before scaling:

• a regulatory and compliance lead to manage licensing and supervision;
• a head of product to define the proposition;
• engineering talent concentrated on the orchestration layer, data architecture, and customer experience (the components that differentiate the bank);
• a risk and financial crime function; and finance and operations.

A useful principle is to reserve in-house engineering talent for the problems only your team can solve, and rely on proven vendors and an experienced implementation partner for commodity infrastructure — which keeps the early team lean and the timeline short.