Building a Neobank App: Pick the Licence Route First, Then the Features

A neobank app is a banking front end that runs on someone’s licence. So the first decision is whose licence holds your customers’ money: your own bank licence, an e-money or payment licence, or a partner bank that holds deposits for you. That choice sets your timeline, the shape of your first release and what you’re allowed to tell customers about their money. Once it’s made, a first release needs eight parts working, from identity checks to a complaints process. We haven’t built a bank, and this isn’t legal advice. Our payment and bookkeeping builds cover several of those parts, so we use them as examples where they fit.

Three routes to a neobank

Route	Who holds the money	What the regulator’s own page says	What it means for your first release
Your own bank licence	You	UK: the PRA authorises new banks with FCA consent. Euro area: the ECB decides, usually in six to twelve months	Longest road. You build the bank’s systems and its policies
E-money or payment licence	You, as e-money rather than deposits	UK: a small e-money institution stays under €5m of average outstanding e-money; above that it needs full authorisation	Faster than a bank licence. Customer money is e-money, not deposits, and the protection rules differ
Partner bank	The partner bank	US banks must manage the risk of third parties they work with, and that includes you	Fastest start. The partner’s review shapes your onboarding, limits and support

The bank route has a softer start in the UK. The New Bank Start-up Unit of the Bank of England describes authorisation with restrictions, called mobilisation. It usually lasts no longer than 12 months, and deposits are capped at £50,000 while the bank finishes its build. In the euro area, the ECB’s authorisation page says the same process and criteria apply to every bank, fintech or not. In the US, national bank charters go through the OCC’s chartering and licensing team.

The e-money route is covered by the FCA’s authorisation page in the UK. Its safeguarding rules for client money also changed: under policy statement PS25/12, new rules for e-money and payment institutions came into force on 7 May 2026, aimed at stronger reporting and monitoring and more consistent record keeping. Much of that lands in your ledger and back office, so read it before you design them. If you start on the third route, with a partner bank, the partner’s due diligence becomes your real launch gate. In 2023 the OCC, the Federal Reserve Board and the FDIC issued joint guidance on third-party relationships, which asks banks to manage partner risk in line with how risky and complex the partnership is. Expect questions about your onboarding, your controls and your support team before anyone opens an account.

What you may tell customers about their money

This part is copy, and it still belongs in the build plan. Customers will ask whether their money is protected, and the answer depends on the route. In the UK, the Financial Services Compensation Scheme protects deposits at authorised banks up to £120,000 per person per bank. The limit rose to that figure from December 2025, so check any wording written before then. The FSCS also says it can’t protect e-money or payment services firms.

So the sign-up screens, the FAQ and the app store listing need wording your compliance person has checked against the regulator’s text. Store that wording as content an admin can update, with a record of who approved each version. A rule change then means a content edit instead of a release.

The first release: eight parts that must work

Part	What it does	Usually bought or built
Sign-up and identity checks	Collects the data your partner requires and runs the checks	Checks bought from a provider, the flow built
Accounts and a ledger	Holds every balance and every movement as balanced entries	Built. It’s the part you can’t patch later
Money in and out	Transfers, top-ups and withdrawals on the partner’s rails	Rails bought, matching and status tracking built
Cards	Debit cards and card controls	Usually through the partner bank and a card issuing processor
History and statements	What came in, what went out, and a monthly statement	Built
Fraud and monitoring	Rules that flag odd activity and hand it to a person	Rules built, some tools bought
Support and complaints	A way to ask for help and a log of every complaint	Built, often with a help desk tool
Back office	Roles, approvals, limits and customer lookups for your team	Built

The ledger deserves the most care. On IPOPBOOKS, a bookkeeping platform for US small businesses, every approval posts a balanced double-entry record, and an hourly check makes sure the books still balance. A neobank ledger needs the same habit. If a balance is ever wrong, you should be able to rebuild it from the entries and find the one that broke it.

Money movement is the next hardest part. Koncierge, a payment platform we built for Japan, matches each incoming bank deposit to the right customer and holds anything that doesn’t match until a person assigns it. Withdrawals go out in batches of up to 1,000 as a file for the payment provider. AggloPay, a payment platform for merchants in Cameroon, takes payments in different currencies and schedules payouts, in English and French. Neither is a bank. They show how much of the work sits in matching and moving money, behind the screens.

Identity checks will keep changing, so build the sign-up flow to take a new check without a new release. In the EU, the new Anti-Money Laundering Authority started operations in Frankfurt in summer 2025 and plans to begin direct supervision of 40 selected firms in 2028. Your partner bank or provider decides which checks you run today, and those requirements can change.

Start narrow

The old pitch for neobanks was to serve groups the big banks overlook. That still works as a product decision, as long as the first release stays small. One customer group, one account type, one card and one way in and out is a product you can launch and support. Every extra country or currency brings its own set of rules, partners and support hours.

How we would estimate the first release

Price the narrow version before you talk to partners about the wide one. You can see what your first release would cost to build with our project estimate. It turns your brief into user stories, you confirm what is in scope, and every hour in the budget traces back to a story you kept. We check the hours the AI suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. The discovery option also suggests customer groups with a market size for each (TAM, SAM and SOM), which the estimate itself calls hypotheses, not verified demand.

Here is an example run of the estimate’s math with sample inputs, for a mobile payments app built on a licensed payment provider, with identity checks bought from a vendor. Every input is an assumption. Only the arithmetic is ours.

Input (assumption)	Value	Output	Value
Work items	10, in 7 phases	Budget	$8,700 to $18,000
Revenue a month per active user	$6	Timeline	4 weeks
Margin	60%	Customers who pay for the build ($13,350)	285
Months a customer stays active	18	First month that earns more than it spends	Month 7
Cost to win a customer	$25	Month the build is paid back	Month 13
New customers a month	400

The estimate covers the software. Licence, partner bank, compliance and legal costs come on top, so put them in the plan as separate lines.

What we would do

1. Write down the one customer group and the one job your app does better than their current bank.
2. Draw the money flow, then pick the licence route with a licensing lawyer. Shortlist two or three partner banks or providers.
3. Ask each partner for its onboarding, security, complaints and reporting requirements before you design screens.
4. Design the ledger and the data model first. Screens come last.
5. Buy identity checks, card issuing and payment rails. Build the ledger, the matching, the app and the back office.
6. Write the money-protection wording with your compliance person, from the regulator’s own text.
7. Launch to a small group with low limits, and raise the limits from the admin panel as monitoring proves itself.

Our fintech app development page shows our payment builds and the questions to ask a fintech software development company. The ledger and bank feed work is in the IPOPBOOKS case study. For the controls every payment product needs, from customer checks to an audit trail, see our guide to fintech regulatory compliance before launch.

FAQ

Do I need a banking licence to start a neobank?

Not necessarily. A neobank-style app can start on a partner bank that holds the deposits, or under an e-money licence. A full bank licence is the slowest route: the ECB says its decisions usually take six to twelve months. A licensing lawyer should confirm the route for each market.

Is customer money in a neobank app protected?

It depends on who holds it. In the UK, the FSCS protects deposits at authorised banks up to £120,000 per person per bank, and it says it can’t protect e-money or payment services firms. Your app’s wording has to match the route you use.

What should the first version of a neobank app include?

Sign-up with identity checks, accounts on a double-entry ledger, money in and out, a card if your partner supports it, history and statements, fraud alerts that reach a person, a support and complaints channel, and a back office for your team.

How much does it cost to build a neobank app?

The licence route and the partners drive the cost more than the screens do, so we quote after scoping. Our rate is $39-55 an hour, and the smallest build we take is $5,000. A fixed-price discovery sprint at $3,000 gives you a written scope, the main screens in a clickable prototype and a fixed price for the build.

Has Rocketech built a bank?

No. We build payment platforms, trading apps and fund systems, plus a bookkeeping platform with bank feeds and a double-entry ledger. Those builds cover parts of a neobank-style app, such as the ledger, payment matching and the back office.