The best companies to build a neobank with are engineering partners that have taken your chosen core banking platform live in production, under your regulator. Core banking platforms, banking-as-a-service providers and systems integrators solve different problems, so compare them by type first and by name second.
Key takeaways
- A neobank needs four layers: a core banking platform, integration engineering, a licensing path and the customer app. Few companies own all four well.
- The core platform is a software licence. The implementation partner decides whether the launch happens on time.
- A focused MVP on a licensed core usually takes 6–12 months; a fuller launch takes 12–24 months.
- Banking-as-a-service is cheaper upfront. A custom build on a licensed core is cheaper per customer at scale.
New to the topic? Start with what a neobank is and how it differs from a digital bank.
Search “best companies to build a neobank with” and you’ll get a dozen ranked lists, naming the same ten or so names reordered slightly, mixing core banking platforms, banking-as-a-service providers, and system integrators as if they were interchangeable options on a single shortlist. They aren’t.
A core banking platform and an engineering partner who implements it solve two completely different problems, and conflating them is exactly why so many neobank launches stall six months after the RFP is signed.
| Market context Aggregated 2024–25 reporting citing Simon-Kucher’s Global Neobanking Radar puts roughly three-quarters of neobanks still unprofitable, with average revenue per user around $45 against roughly $350 at a traditional retail bank. That’s a nearly an eightfold gap. At the same time, banking licensing requirements have tightened across major markets through 2026, raising the compliance bar for anyone launching new. The platform decision gets easier every year. The execution risks around integration, compliance, and time-to-market, has only gotten harder. |
|---|
Choosing the right development partner is at least as important as choosing the right core banking platform. This article is a practical framework for founders, CTOs, and Heads of Digital evaluating who should actually build the neobank.
Why “Best Companies” is the wrong framing
Ask what a neobank launch requires and most buyers can name the core banking platform they’re considering, Thought Machine, Mambu, SaaScada, within the first sentence. Far fewer can clearly say who is going to build the account opening flow, wire up the KYC provider, connect the card issuer, and get the whole thing through a regulator. That’s a different question, and it’s the one that actually determines whether the launch happens on time.
| The gap most rankings miss: A core banking platform defines how a ledger, account, and product logic work. It does not connect to your KYC provider, wire up your card issuer, migrate anything, or get you through a regulator’s sandbox review. That integration and delivery work is where neobank launches actually stall and it’s owned by the implementation partner, not the platform vendor. |
|---|
Rankings that put a core banking platform, a banking-as-a-service provider, and a systems integrator in the same numbered list obscure this problem. Before shortlisting anyone, it’s worth being explicit about which layer you’re actually shopping for.
Part of why this decision carries more weight than it used to: neobanks are winning share from incumbents largely on lower cost-to-serve and faster iteration, both of which come from the execution layer: how well the integration and product logic are built. Contrary to what it may seem it does not come from which core banking platform sits underneath. A well-chosen platform with a mediocre implementation partner still ships and scales slowly. That gap is where the partner decision actually pays for itself.
What a neobank build actually requires
A neobank launch is generally made up of four distinct layers, and rarely does one company genuinely own all four well:
- Core banking platform — the ledger and product engine (e.g. Thought Machine Vault Core, Mambu, SaaScada). This is a software license, not a delivery team.
- Integration and engineering — connecting the core to payments rails, card issuers, KYC/AML providers, and reporting. This is where the majority of launch delays originate.
- Licensing and compliance path — whether you’re pursuing your own charter, operating under a sponsor bank, or launching via a banking-as-a-service arrangement.
- Product and design — the actual customer-facing app and onboarding experience.
A development partner worth hiring should be candid about which of these layers they own directly and which they coordinate with third parties. A partner who claims to own all four end-to-end, with no named sub-processors or licensing partners, is usually oversimplifying.
Which types of companies build neobanks?
Five types of companies show up on most neobank shortlists. They aren’t alternatives to each other: most launches combine a core platform with a delivery partner.
| Company type | What they provide | Strengths | Risks | Best fit |
|---|---|---|---|---|
| Core banking platform vendor | The ledger and product engine as licensed software (e.g. Thought Machine Vault Core, Mambu, SaaScada) | Modern, configurable core; regular upgrades | Doesn’t build integrations, the app or the licensing path | Every neobank needs one, paired with a delivery partner |
| Banking-as-a-service provider | Licence, core and ready-made APIs as one package | Fastest route to market; low upfront cost | Per-account fees grow with you; limited control over the roadmap | Standard retail products in a well-served market |
| Specialist engineering partner | Core configuration, integrations, app and go-live by one engineering team | Hands-on platform experience; delivery ownership | Smaller bench than a large consultancy; check named references | Custom product logic on a licensed core |
| Large systems integrator or consultancy | Programme management, governance and large teams | Scale and board-level credibility | Senior pitch team, junior delivery team; slower to adapt | Very large, multi-country programmes |
| In-house team | Your own engineers build and run the stack | Full control and long-term ownership | Slow hiring, high fixed cost, regulatory learning curve | Banks with an existing platform engineering function |
How to evaluate a neobank development partner
The criteria below apply whether you’re a fintech founder launching greenfield or a bank spinning up a digital-first subsidiary. The weighting shifts by situation, but every criterion belongs on the list.
1. Platform-specific delivery experience, not just a partnership badge
A “certified partner” badge on a core banking platform’s website confirms a commercial relationship. It does not confirm the partner has taken that platform live in production. Ask for the number of completed launches on the specific platform you’ve chosen, and for reference contacts at institutions of comparable size and regulatory complexity. One size does not fit every customer on the same platform.
2. Engineering-led delivery over project coordination
Building a neobank is an engineering programme: account and ledger configuration, API integration work, KYC/AML orchestration, and testing under real transaction volumes. Ask a prospective partner to describe the actual composition of the delivery team. The ratio of engineers to project managers and business analysts is one of the best ways to tell who is serious.
3. Integration depth across the real stack
The core banking platform handles the ledger. Everything it touches like card issuing, payment rails, KYC/AML providers, fraud monitoring, reporting will be the partner’s responsibility. Ask a partner to walk through, specifically, how they’d design the integration architecture for your product. A generic answer isn’t a great sign.
KYC automation is a good stress test on its own. A strong partner won’t just name a KYC vendor, they’ll explain how they’ve evaluated one for onboarding conversion, false-rejection rates, and document coverage across the specific markets you’re launching in, and how that vendor’s decisioning integrates with your core platform’s account-opening flow. “We integrate with [vendor]” is a weaker answer than “here’s how we chose one and what it took to tune it
4. Regulatory and licensing fluency in your market
A partner who has taken a product through your specific jurisdiction’s licensing or sandbox process brings knowledge that’s hard to acquire any other way. They know from experience what documentation a regulator expects, what a sandbox review actually probes, how a compliance framework has been configured to satisfy it elsewhere. General fintech compliance familiarity is not the same thing. Verify jurisdiction-specific experience explicitly, and ask what the licensing path looked like on their last comparable engagement.
5. Realistic timeline and honest scoping
A partner who tells you a full-scope launch will take twelve months and explains why is more useful than one who promises six and revises it later. Ask what the hardest problem was on their last comparable launch and how they solved it. The specificity and honesty of that answer is better than any case study.
6. Post-launch independence instead of permanent dependency
The engagement should end with your own team able to configure products, manage integrations, and extend the platform without the partner in the room. If every post-launch change requires a change order back to the partner, the “partnership” has become a managed service. If that isn’t what you are looking for, ask what your team will be able to do independently by launch, and how that’s measured.
Evaluation, depending on your needs
| Criterion | What to ask | What good looks like |
|---|---|---|
| Platform delivery experience | How many live launches on this specific platform? Reference contacts? | Multiple completed launches; references in a comparable market and regulatory tier |
| Engineering-led delivery | What’s the team composition between engineers vs. PMs/BAs? | Engineering-heavy team; senior engineers on integration and configuration |
| Integration depth | Walk me through the integration design for our stack. | Specific, structured answer naming real components, not a generic diagram |
| Regulatory/licensing fluency | Have you taken a product through licensing or sandbox review in our market? | Named jurisdiction experience; specifics on what the process actually required |
| Timeline honesty | What’s the realistic timeline, and what could extend it? | Concrete range with named risk factors, not a single optimistic number |
| Post-launch independence | What will our team be able to do on their own after go-live? | Named capabilities and a measurable handover plan built into the programme |
Questions to ask before you commit
- Who specifically will be on the delivery team, and what have they individually shipped before?
- Is the cost estimate itemised, or is integration and compliance work bundled into a single line that hides where the risk actually sits?
- What does the licensing or sandbox timeline look like in our specific jurisdiction, and who owns that relationship?
- What happens if the launch date slips, is there a defined process, or does scope sneakily expand instead?
- What does the partner’s last comparable client say when you ask them directly what went wrong along the way?
A partner who answers all five specifically and honestly, without falling back to generic reassurance, is something you can trust more than some awards on a homepage.
What is a realistic timeline for launching a neobank?
A focused neobank MVP on a licensed core platform usually reaches production in 6–12 months. A fuller launch with custom product logic, several markets or its own banking licence takes 12–24 months. The licence route often sets the pace more than the technology does.
Most launches follow the same five milestones:
- Platform selection and solution design. Choose the core, define the first products and design the integration architecture.
- Licensing or sandbox submission. This runs in parallel with engineering, not after it.
- Core configuration and integrations. Connect payments, card issuing, KYC/AML and reporting to the core.
- Closed beta. Test with a limited group of real customers and real transactions.
- Phased public rollout. Open to the market product by product.
Vacuumlabs delivery examples:
| Project | What was built | Time to launch |
|---|---|---|
| Advance Intelligence | Full-service digital bank | Under 12 months |
| Mox by Standard Chartered | Virtual bank in Hong Kong on Thought Machine Vault Core | 18 months from licence to market |
| Galgal | Budgeting and banking app, India | 8 months |
How do you choose a core banking platform for a new digital bank?
Choose a core banking platform by testing it against your first products and markets, then checking who can take it live for you. A platform that looks right on paper still fails if no partner in your market has run it in production.
- Real-time, cloud-native architecture. Modern cores post transactions in real time and scale on demand.
- Product configurability. Your team should change interest, fees and limits without vendor change requests.
- APIs and integration fit. Check how the core connects to your payments, cards and KYC providers.
- References under your regulator. Ask for live banks in your jurisdiction, not only global logos.
- Implementation partner ecosystem. Confirm that certified partners have production deployments near you.
- Total cost of ownership. Compare licence, hosting, implementation and post-launch change, not only the licence fee.
For a deeper look at one cloud-native option, read our guide to Thought Machine Vault Core. To pick the team that implements it, see how to choose a core banking implementation partner.
Build vs buy: what does neobank technology cost?
It’s worth noting that not every launch needs a full engineering build. A retail-focused product entering a well-served market may be better served by a banking-as-a-service arrangement that trades some flexibility for speed. A product with unusual product logic, cross-border complexity, or ambitions to scale well beyond an initial market usually needs the deeper control that comes with a proper core banking implementation. Most launches land somewhere in between a licensed core platform, custom-built around it. The honest question to ask any partner isn’t “can you build this,” it’s “should this be fully custom, or would a lighter-weight path get us to market faster without boxing us in later.”
The total cost comparison rarely comes down to the platform license fee, that’s usually the smallest line item. A banking-as-a-service arrangement trades a lower upfront cost for ongoing per-account or per-transaction fees and less control over the product roadmap; a custom build on a licensed core platform carries higher upfront integration and compliance cost but lower marginal cost per customer at scale, and no dependency on a BaaS provider’s own roadmap or pricing changes. The break-even point depends on projected account volume and how differentiated the product needs to be a partner who can model that trade-off with your actual numbers, rather than defaulting to “build everything custom,” giving you a more honest answer than one who only sells one kind of engagement.
The platform licence is rarely the biggest cost in a neobank launch. Integration, compliance and running costs usually decide the total. Banking-as-a-service costs less upfront, while a custom build on a licensed core costs less per customer at scale.
| Cost driver | Banking-as-a-service | Licensed core + custom build | Fully in-house |
|---|---|---|---|
| Upfront cost | Low | Medium to high | Highest |
| Ongoing fees | Per account or per transaction, growing with volume | Licence and hosting, flatter as you grow | Salaries and infrastructure |
| Integration and compliance work | Mostly done by the provider | Largest line item; done by your partner | Entirely yours |
| Control over the product roadmap | Limited to the provider’s features | High | Full |
| Cost per customer at scale | Highest | Low | Low, after a long payback |
| Time to market | Fastest | 6–12 months for an MVP | Slowest |
Not every launch needs a full engineering build. A retail product in a well-served market may be better off with banking-as-a-service, trading some flexibility for speed. A product with unusual product logic, cross-border complexity or plans to scale beyond its first market usually needs the control of a proper core banking implementation. Most launches land in between: a licensed core platform, custom-built around it.
The break-even point depends on your projected account volume and how differentiated the product needs to be. Ask a prospective partner to model that trade-off with your own numbers. A partner who only sells one kind of engagement can’t give you an honest answer.
What are the risks and hidden costs of building a digital bank in-house?
Building a digital bank in-house gives you full control, but it moves every delivery and compliance risk onto your own team. The biggest risks are slow hiring, regulatory delays and the cost of running the platform after launch.
- Scarce skills. Engineers with production experience on modern cores are hard to hire, and the launch waits until they’re on board.
- Regulatory learning curve. A team that hasn’t been through your regulator’s licensing or sandbox process before tends to discover requirements late.
- Ledger correctness. Interest, fees and reconciliation errors are expensive to fix once real customer money is on the platform.
- Integration upkeep. Every payment scheme, card issuer and KYC provider changes its APIs, and someone has to keep up.
- Operational resilience. Rules such as DORA in the EU require tested incident, outsourcing and recovery processes from day one.
Hidden costs that often miss the first budget: security audits and penetration tests, card scheme certification, parallel testing, 24/7 operations and on-call, and the opportunity cost of a later launch.
How Vacuumlabs approaches neobank builds
Vacuumlabs is a banking software engineering firm with core banking implementations delivered across Europe and APAC, working as a certified implementation partner for Thought Machine Vault Core and SaaScada. For founders and banks building a neobank from the ground up, the delivery model is engineering-led: the same teams who design the integration architecture also configure the core platform, connect payments and KYC providers, and carry the product through to launch. We don’t slow down by handing off between separate design, build, and support teams, we work end-to-end as an opinionated development partner for you
| What we bring to greenfield neobank builds → Full-stack delivery ownership: solution design, core platform configuration, integration engineering, and go-live, coordinated by one team → Platform experience, such as Thought Machine Vault Core, matched to the product logic and scale a launch actually needs → Regulatory fluency in multiple jurisdictions: built into discovery, not retrofitted when there is an inquiry → Knowledge transfer as a deliverable, if needed: the goal is a bank team that can operate and extend the platform independently after launch or help you maintain it after |
|---|
For teams evaluating the platform layer itself alongside a delivery partner, our article on how to choose a core banking implementation partner covers the same evaluation logic in more depth for legacy modernisation and greenfield programmes alike.
Frequently Asked Questions About Neobank Builds
What’s the difference between a neobank platform and a neobank development company?
A neobank platform (such as Thought Machine, Mambu, or SaaScada) is the core banking software, also known as the ledger and product engine. A neobank development company is the team that configures that platform, integrates it with payments, cards, KYC, and reporting systems, and delivers a working product to launch. The platform is a license; the development company is the delivery team that makes it operational in your specific market.
How do I choose a neobank development company?
Evaluate platform-specific delivery experience (not just certification), the ratio of engineers to project managers on the proposed team, integration depth across your real technology stack, regulatory and licensing fluency in your specific jurisdiction, and whether the engagement ends with your team able to operate independently. Ask for reference contacts at institutions of comparable size and complexity, not just any past client.
How much does it cost to build a neobank from scratch?
Cost depends heavily on scope, jurisdiction, and how much of the stack is custom-built versus licensed through banking-as-a-service. A focused MVP built on a licensed core platform typically costs meaningfully less than a fully custom build with in-house licensing, but the larger cost driver is usually integration and compliance work, not the platform itself, which is why an itemised estimate matters more than a single headline number.
Is it cheaper to build a neobank or buy the technology through banking-as-a-service?
It depends on scale and timeline, not just sticker price. Banking-as-a-service has a lower upfront cost but ongoing per-account or per-transaction fees that grow with your customer base, plus less control over product roadmap. A custom build on a licensed core banking platform costs more upfront in integration and compliance work but has lower marginal cost per customer at scale. There’s no universal answer. It’s a break-even calculation based on projected volume and how differentiated the product needs to be, which is why it’s worth asking a prospective partner to model it against your actual numbers rather than accepting a default recommendation.
How long does it take to launch a neobank, and what are the key milestones?
A focused MVP on a licensed core platform can reach production in roughly 6–12 months; a fuller launch with custom product logic, multi-jurisdiction compliance or a from-scratch licensing path typically runs 12–24 months. The milestones are consistent regardless of timeline: platform selection and solution design, licensing or sandbox submission (in parallel with engineering), core integration and KYC/AML connection, a closed beta with a limited account cohort, then phased public rollout. The strongest predictor of staying on schedule is the delivery partner’s track record on comparable launches, not the platform choice itself.
Which is better for a neobank: Thought Machine or Mambu?
Neither is universally “better”, they’re suited to different product complexity and scale, and the platform choice matters less than most buyers assume. The bigger determinant of launch success is usually the implementation partner’s delivery track record on whichever platform you choose, not which platform you picked. A partner who insists one platform is simply superior in every scenario is oversimplifying; a partner who asks about your product logic, transaction volume, and target markets before recommending one is giving you a more useful answer.
Do I need a banking license to build a neobank, or can a partner help with that?
It depends on the model. Some neobanks operate under their own banking charter; many launch faster by operating under a sponsor bank’s license or a banking-as-a-service arrangement, then pursue their own charter later if it makes sense. A development partner with genuine licensing experience in your target jurisdiction can help you weigh that decision early, before it’s locked into the technical architecture.
How do I choose a KYC automation vendor for neobank onboarding?
Start by testing candidates against your actual onboarding funnel, not a feature list: ask for data on onboarding conversion, false-rejection rates, and document coverage across the specific markets you’re launching in. A strong vendor evaluation also looks at how the KYC provider’s decisioning integrates with your core banking platform’s account-opening flow, since a mismatch here is one of the most common sources of launch delay. Be wary of a partner who simply names a vendor they “integrate with” — the more useful answer explains how they evaluated and tuned that vendor for your specific product and markets, not just that a connection exists.
What does a neobank’s technology stack blueprint look like?
A neobank technology stack is generally made up of four layers: a core banking platform (the ledger and product engine — e.g. Thought Machine Vault Core, Mambu, SaaScada); integration and engineering connecting that core to payment rails, card issuers, and KYC/AML providers; a licensing and compliance path (own charter, sponsor bank, or banking-as-a-service); and the product and design layer — the customer-facing app and onboarding experience. Very few companies genuinely own all four layers well, which is why the blueprint is less about picking one vendor and more about deciding who owns each layer and how they connect.
What should a compliance checklist look like before launching a digital banking service?
At minimum, confirm your licensing path (own charter vs. sponsor bank vs. banking-as-a-service), and verify that your delivery partner has taken a product through your specific jurisdiction’s licensing or sandbox process before — general fintech compliance experience isn’t the same as jurisdiction-specific experience. Ask what documentation the regulator expects, what a sandbox review actually probes, and how the compliance framework has been configured to satisfy it on comparable launches. Treat regulatory fluency as something that should be built into discovery from day one, not something retrofitted once a regulator asks questions.
How do you evaluate vendors when buying a digital bank stack?
Evaluate each layer separately: the core platform on architecture and configurability, the KYC and payments vendors on conversion and market coverage, and the implementation partner on live launches under your regulator. Ask every vendor for references at a comparable bank, an itemised cost estimate and a clear split of who owns which integration.
This article was drafted with AI assistance and edited by our editorial team.
