Do you need a banking license to launch a fintech app?

"Do you need a banking license to launch a fintech app?" is really three questions wearing one coat. Are you holding customer money? Are you moving it? And whose regulatory permission covers that movement — yours, or someone else's? Answer those and the licensing question mostly answers itself. The short version that surprises most teams: the majority of fintech apps never hold a banking licence, because the majority of fintech apps never do the one thing a banking licence is actually for. What follows is a map of the spectrum, not legal advice — the goal is to know which questions to ask before anyone quotes you a timeline or a price.

What a banking licence is actually for

A full banking licence — in EU terms, a credit institution authorisation — permits one specific, heavily guarded activity: taking deposits from the public and lending that money back out. That maturity mismatch, funding long loans with balances customers can withdraw on demand, is the reason banks carry heavy capital requirements, deposit-guarantee obligations, and a supervisor reading their balance sheet line by line. If your app does not take deposits and lend against them, you are almost certainly not looking at a banking licence at all. You are looking at something lighter, further down the spectrum — and the spectrum is the whole story.

The permission spectrum, heaviest to lightest

Financial permissions come in tiers. At the top sits the credit institution — the bank — that can hold deposits and lend. Below it, an electronic money institution (EMI) may issue e-money: it can store customer value and put it on cards or in wallets, but the float it holds must be safeguarded — kept apart and untouched, never lent out. Below that, a payment institution (PI) may execute payments — initiate transfers, collect, remit, acquire card transactions — but is not built to store value over time; money passes through, it does not sit. And at the bottom, an agent or distributor holds no licence of its own at all, operating instead under the authorisation of a licensed entity that has registered it.

The pattern is that each rung down sheds a capability and, with it, a slice of capital and obligation. Holding deposits is the heaviest thing you can be permitted to do; being the agent of someone who can is the lightest. Most consumer fintech apps — wallets, cards, transfers, payment links — live in the EMI and payment-institution range, or on top of a partner that holds one of those permissions. Very few need to be a bank, and knowing that early saves a great deal of misdirected effort.

A quick way to place yourself: if your customers will hold a balance in the app — a wallet they top up, a card they preload — you are in e-money territory, because storing value is the permission that defines an EMI. If money only moves through — you initiate a transfer, collect a bill, hand a payout straight on — a payment-institution permission is the natural fit, held by you or by a partner. If you never touch the funds at all and only present information about accounts held elsewhere, even that has its own lighter registration. The heavier you sit, the more capital and supervision come attached; the design goal is to sit no heavier than the product actually requires.

Renting the permission: partner models

You do not have to hold the permission yourself to build on it. The common route is to rent it. Under a sponsor-bank or Banking-as-a-Service arrangement, a licensed bank or EMI holds the accounts, issues the IBANs and cards, and safeguards the float; you build the app against their API and ship the experience. Under an agent model, you register as the agent of a payment institution — or as a distributor of an e-money issuer — and their licence covers your activity, with the regulator aware of you through them. Different contracts, same underlying fact: somewhere in the stack, someone holds the permission. The only question is whether that someone is you or a partner.

Who carries which liability

Renting a licence does not rent away the responsibility. The licensed entity is the one answerable to the regulator — for safeguarding customer funds, for anti-money-laundering monitoring, for the conduct of the whole programme. But those obligations flow downhill by contract. Ride on a partner's licence and you will still run KYC and onboarding, still watch transactions for AML, still honour the limits and reporting the partner is bound to. Liability is not so much outsourced as apportioned: the partner owns it to the regulator and owns you to a contract that pushes much of the day-to-day duty back onto your side. Read that contract as carefully as you would read the licence you chose not to get.

A licence is permission to hold or move other people's money. Software is how that money is instructed, reconciled, and shown back to the customer. You can buy them from one vendor or from two — but you are always buying both.

— Protocore · Payments engineering

The software and the licence are separate purchases

This is the insight that reorders the whole project. A payment app looks like a single thing to the customer, but it is two things fused: the regulated permission to hold or move money, and the software that instructs the movement, keeps the ledger, reconciles the credits, and renders a balance on a screen. Those two are sourced separately. You might hold your own licence and buy the software; hold a licence and build the software in-house; rent the permission through a partner and buy software on top; or take both from a single vendor who has bundled them. All four are normal. What is not normal — and what quietly costs projects months — is confusing the two: shopping for a "banking licence" when what you needed was a BaaS partner plus an app, or shopping for an app on the assumption that the permission comes welded to it.

Seeing them as separate purchases is clarifying because it lets you price and schedule them independently. The software can be judged on its merits — does the onboarding flow work, is the ledger correct, can operators actually run the thing — while the permission is judged on jurisdiction, safeguarding, and terms. Protocore Pay (/products/pay) is an example of the software layer on its own: a whitelabel app platform and operator console that runs on top of whatever regulated rails you bring to it. It is not a licence, and no software is one — which is precisely why the licence stays a separate line in the plan.

Questions to ask any platform vendor

Whoever is pitching you a "launch your fintech" platform, the same short list cuts through most of the ambiguity. Does your product include a regulated permission, or do I bring my own? If it includes one, whose licence is it, in which countries, and am I a direct customer of that entity or its agent? Who safeguards customer funds, and where are they held? Who is named to the regulator for anti-money-laundering — you, the partner, or me? Which obligations land on me by contract even though the licence is not mine? And if the partnership ends, what happens to my customers' money and their data? The answers sort vendors quickly into those selling software, those reselling a partner's permission, and those who have genuinely bundled both — and tell you which of the three you are actually talking to.

The reassuring shape of all this: most apps launch as software plus a partner's permission, and graduate to their own licence only when volume, margin, or strategy makes the capital and the compliance headcount worth it. Knowing which rung you truly need — and that the software and the permission are bought on separate lines — is most of the battle. The rest is asking the questions above and reading the answers closely. None of this is legal advice, and the thresholds and category names vary by jurisdiction; treat it as the map you bring to the conversation with a regulator or an adviser, not a substitute for one.