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.
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.
Build vs. License vs. Hybrid
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.
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.
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 inside that window are fairly consistent regardless of timeline length: platform selection and solution design, licensing or sandbox submission (which can run in parallel with engineering), core integration and KYC/AML connection, closed beta with a limited account cohort, then phased public rollout. The strongest predictor of whether a programme actually stays on schedule is the delivery partner’s track record hitting those specific milestones on comparable launches, not the platform choice itself.
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?
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 strongest predictor of whether a programme stays on that timeline 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.
This article was drafted with AI assistance and edited by our editorial team.
