What a banking product actually contains
From the outside a neobank looks like an app. Inside, it is a set of tightly coupled systems that each have to be correct, auditable and available. Before comparing build and buy, it helps to be honest about the full inventory.
The core banking ledger
The ledger is the source of truth for every balance and every movement of value. It has to be double-entry, idempotent under retries, correct across currencies, and reconcilable against every external provider you touch. This is the component teams most often underestimate: the first version takes a quarter, and the version you can safely run a business on takes considerably longer, because the hard part is not posting transactions — it is what happens when a rail times out, a settlement file arrives late, or a chargeback reverses a posting that has already been swept.
Multi-currency accounts and dedicated IBANs
Customers expect an account number they can share. That means dedicated IBANs rather than a shared pooled account with reference-based allocation, and it means holding several currencies per customer without inventing your own FX bookkeeping. Multi-currency accounts with dedicated IBANs is a module on our platform for exactly this reason: the wiring between IBAN issuance, the ledger and the payment rails is where most in-house projects stall.
Card issuance
Virtual and physical card issuance brings its own supply chain: a card processor, a scheme relationship through your issuer, BIN sponsorship, authorisation handling in real time, 3-D Secure, disputes and card lifecycle management. Authorisation is a latency-bound, always-on service — it does not tolerate the deployment habits of a normal product team.
KYC/KYB, screening and monitoring
Onboarding a consumer and onboarding a company are different products. You need document capture and liveness, sanctions and PEP screening, ongoing monitoring, case management for your compliance officers, and audit trails that show who decided what and when. Our KYC/KYB compliance workflows include those audit trails because a control you cannot evidence is a control your partner will not accept.
Crypto and FX
If your proposition touches conversion — and in most markets it does — you need pricing, spread management, exposure control and settlement against liquidity providers, all posting cleanly back into the ledger.
Apps and API
Finally the visible layer: white-labeled iOS, Android and web applications, plus full API access so your own product team can build what makes you different rather than rebuilding what makes you the same as everyone else.
The true cost of building
Build estimates usually price the first release. The cost that determines whether a programme survives is the second and third year. Each module above needs an owner. Rails change their message formats. Providers deprecate endpoints, get acquired, or exit a market and have to be replaced. Reconciliation breaks quietly and is discovered by finance rather than by monitoring. Back-office tooling — refunds, limits, freezes, manual postings — grows with every product you add, and it is never on the roadmap that got funded.
There is also a sequencing cost. Building means your regulatory conversations, your commercial partnerships and your engineering all sit on the critical path at once. Any one of them slipping moves the launch. Teams that license infrastructure move the engineering risk off that path and spend their attention on licensing and distribution, which are the parts nobody can do for them.
Building is the right answer in one situation: when the ledger or the rail integration is your product and your differentiation, and you have the balance sheet and the specialist hiring pipeline to run it as a permanent engineering function.
What buying actually gets you
White-label infrastructure means the seven modules already exist, already talk to each other, and already connect to a set of pre-integrated providers. You configure rather than construct: currencies, products, fees, limits, onboarding flows, card designs, app branding. Where you need something bespoke, the API is open, so bespoke work is additive instead of foundational.
This is what compresses go-live to weeks. A four-week go-live is achievable because the engineering that normally consumes the calendar has already happened; what remains is configuration, integration decisions, testing and the licensing work that runs in parallel. For a deeper comparison of delivery models, read BaaS vs white-label banking, and if you are launching into MENA or the EU/EEA, see launching a digital bank in MENA and Europe.
A practical way to decide
- Write down every module in the inventory above and mark the ones your customers would notice if they were merely competent rather than exceptional. Those are candidates to buy.
- Mark the one or two where being better than the market is the reason customers choose you. Those are candidates to build — usually in the product layer, on top of the API.
- Cost the buy option as an operating expense over three years and the build option including the second team you will need for operations, reconciliation and compliance tooling.
- Test the sequencing: if licensing lands in month six, does your engineering plan still allow you to launch in month seven?
Where to go next
If you already know what you are launching — an SME neobank, a consumer product, a crypto or OTC desk, a payment hub, or banking inside an existing app — the fastest next step is to map the modules against it with someone who has done it before. Our team works from Dubai, Belgrade, Tallinn and London and focuses on MENA and EU/EEA programmes.
Book a demo and we will walk through the modules, the providers and a realistic sequence for your launch. You can also start from the guides index or the reference page on core banking software.