Banking-as-a-Service · Use case

Launch a neobank or wallet on Banking-as-a-Service

Short answer

A BaaS provider supplies the licence, accounts, IBANs, payment rails and ledger; you build the app, the brand and the customer relationship. The decisions that matter most are whose licence you run under, whether customers hold e-money or deposits, and how much of compliance you take in-house.

What this use case is

A consumer or SME banking product — accounts, everyday payments, usually a card — offered under your brand. Without your own licence, a BaaS provider carries the regulated parts.

Who builds this

Consumer neobanks
SME banking apps
Community and diaspora banking
Brands launching a wallet

What your customer sees

  1. 1Downloads the app
  2. 2Verifies identity
  3. 3Receives an IBAN
  4. 4Funds the account
  5. 5Pays and gets paid
  6. 6Adds a card to a mobile wallet

How Banking-as-a-Service solves it

1

Onboarding

your app collects data; KYC runs through the provider or your own vendor

2

Account creation

an account and IBAN are opened under the licence holder

3

Incoming funds

credited to the ledger and safeguarded or held as deposits

4

Outgoing payments

submitted to SEPA, Faster Payments or other rails through the provider

5

Events

every balance change reaches your app through webhooks

6

Statements and reporting

produced by the provider; regulatory reporting stays with the licence holder

Want to have

  1. Accounts and IBANs in your target markets
  2. SEPA and SEPA Instant or Faster Payments
  3. KYC integration
  4. Webhooks for every balance event
  5. Statements
  6. Transaction monitoring
  7. A card programme or card-issuing partner integration

Optional

  1. Savings or interest
  2. Multi-currency
  3. Direct debits
  4. Payee verification in the app
  5. Open banking connectivity

Design decisions

E-money wallet or deposit account

E-money
Deposits

speed and provider choice versus deposit protection, interest and how you may describe the product

Named or virtual IBANs

Named per customer
Virtual on pooled accounts

customer clarity and payee verification versus cost and flexibility

Your role

Provider's customer
Agent or distributor
Own licence later

launch speed versus control and margin

What to put in your RFP

Licensing and markets

  • licence holder and regulator
  • target countries
  • consumer and/or SME customers

Accounts

  • IBAN countries
  • named or virtual
  • account limits
  • savings options

Payments

  • rails required
  • instant payments
  • direct debits
  • payee verification

Onboarding and compliance

  • KYC approach
  • compliance split
  • transaction monitoring

Cards

  • native card issuing or partner integration

Technical

  • sandbox, webhooks, SDKs, uptime commitments

Commercials

  • setup, minimums, per-account and per-transaction pricing, at your volume

Exit

  • data export, IBAN portability, migration support
Add these to an RFP

How to evaluate providers for this use case

  1. 1Risk appetite for retail or SME customers in your segment
  2. 2IBAN countries matching your market
  3. 3API maturity for a mobile-first product
  4. 4A realistic path to your own licence later
  5. 5Stability of the licence holder

Pitfalls

  • Calling the product a bank when customers hold e-money
  • Underestimating customer support and complaints volume
  • Choosing a provider whose risk appetite excludes your segment after you have integrated
  • No plan for migrating to your own licence

What providers will ask you

  1. Target segment and markets
  2. Projected accounts and balances
  3. Compliance lead
  4. Funding and runway
  5. Launch timeline

Other Finlane categories that cover parts of this

This use case is solved mainly with Banking-as-a-Service. These categories cover specific parts of it and can be tendered alongside it.

Frequently asked questions

See the full cross-category stack for this use case

Other Banking-as-a-Service use cases

Scope launch a neobank or wallet with Banking-as-a-Service providers

Scope this use case