EMI License Wallet: Build for UK & EU Rules in 2026
AI Summary: An EMI license wallet in the UK or EU is an electronic-money product, not a bank deposit account. Teams must identify the issuer and distinguish their own authorisation from an agent or partner arrangement. Safeguarding, issuance and redemption, customer onboarding, ledgering, payment integrations and reporting shape the wallet's architecture and operations. |
A wallet that holds customer balance in the UK or EU is usually an e-money product. The customer pays in funds, you issue electronic money that represents a claim on you, and the customer spends or redeems it. That is not the same as taking deposits as a bank. It is also not the same as building a payments UI on top of someone else's balance without understanding who is legally issuing the money.
This guide is for founders and product teams building an EMI-backed wallet for the UK, the EU, or both. It covers the licensing routes, what safeguarding and conduct rules turn into software, a reference architecture, key APIs, compliance features, and the drivers that move cost and timeline. For India prepaid wallets see our PPI wallet guide; for US wallet architecture see our US digital wallet guide. For licences across markets, see our Fintech Licensing Requirements 2026 guide.
EMI license wallet: What an EMI-backed wallet is
Under the UK Electronic Money Regulations 2011, electronic money is electronically (including magnetically) stored monetary value, represented by a claim on the issuer, issued on receipt of funds for making payment transactions, and accepted by a person other than the issuer. In product terms your wallet:
Accepts customer funds and issues a balance (e-money)
Lets the customer pay merchants, peers or billers, or redeem back to a bank account
Keeps those customer funds protected through safeguarding, not through bank deposit insurance
Many EMI wallets also provide payment services (transfers, card acquiring, account information). In the UK those sit under the Payment Services Regulations 2017 as well as the EMRs. The FCA's EMI applicant page is the practical starting point for what authorisation or registration requires.
Three routes compared
Route | Who issues e-money | What you need | Best for | Trade-offs |
Authorised EMI (AEMI) | Your firm | FCA authorisation, initial capital, safeguarding, governance, MLR controls | Full product control, scale, cards and multi-rail wallets | Long application; ongoing capital and safeguarding audit burden |
Small EMI (SEMI) | Your firm (capped) | FCA registration as SEMI; volume and service limits | Early UK launch with limited outstanding e-money | Caps on outstanding e-money and unrelated payment volume; no AIS/PIS |
Partner EMI / distributor | A licensed EMI | Commercial agreement, distributor or agent arrangements, your brand on their rails | Faster market entry while you learn the product | Partner concentration; permissioning and change control sit with the EMI |
The EMRs Schedule 2 set initial capital for an authorised EMI at at least €350,000. For a small EMI, capital of 2% of average outstanding e-money applies when that average is €500,000 or more. The FCA also states SEMI limits: average outstanding e-money must not exceed €5m, unrelated payment transactions must stay within the stated monthly average threshold, and SEMIs cannot provide account information or payment initiation services.
Partnering is not "licence shopping". If you act as an agent providing payment services, the EMI remains responsible and must register agents and oversee them. If you only distribute e-money without providing payment services yourself, document the split carefully so your software does not accidentally perform regulated activities your agreement does not cover.
UK vs EU: two authorisations, not one passport
A UK FCA EMI authorisation does not give you an EU passport after Brexit. If you want customers in both the UK and the EU, plan for:
UK: authorisation or registration with the FCA under the EMRs/PSRs
EU: authorisation in a home Member State under that state's implementation of the e-money and payment services framework, then passporting within the EEA if your licence allows it
Building one multi-tenant wallet platform that can serve both regimes is common. Collapsing two legal entities into one licence is not. Your rules engine should tag every wallet, rail and customer journey by jurisdiction so safeguarding banks, complaint handling and regulatory reports stay clean.
For the wider UK fintech landscape, see our note on top fintech companies in the UK. If you are exploring licence-as-a-service partnerships more broadly, our licence as a service guide covers the pattern without treating it as a shortcut around substance.
What the application turns into software
The FCA expects a programme of operations, business plan, governance, safeguarding measures, MLR controls, capital evidence, security policy, incident reporting, wind-down planning and more. In our experience building wallet stacks, these map directly to product requirements:
Application / rule area | What you build |
Programme of operations | Product catalogue with clear permissions (issue, redeem, P2P, merchant pay, cards) |
Safeguarding | Double-entry ledger, segregated safeguarding accounts, daily internal and external reconciliations, evidence packs |
MLRs | KYC/KYB onboarding, ongoing monitoring, sanctions screening, case management and escalation |
Governance and wind-down | Role-based access, maker-checker on high-risk actions, exportable customer and balance data for resolution |
Security and incidents | Strong authentication, encryption, audit logs, incident playbooks and customer notification workflows |
Agents / distributors | Partner onboarding, activity limits, monitoring dashboards if you use or become an agent |
Safeguarding is not a treasury spreadsheet. The FCA's safeguarding page explains that relevant firms must protect customer funds on insolvency by segregation or by an insurance policy or comparable guarantee, and that APIs, AEMIs and SEMIs face mandatory safeguarding. Firms also face monthly safeguarding reporting and daily reconciliation expectations under the Client Assets and Supervision rules referenced there. Design the ledger so every customer balance can be tied to safeguarded funds on a reconciliation day.
Reference architecture
Layer | Components | Notes |
Channels | Mobile and web wallet, merchant APIs, ops console | Jurisdiction and product flags on every session |
Identity | KYC/KYB, liveness, sanctions and PEP screening | Re-KYC triggers on risk and periodic review |
Ledger | Double-entry accounts for customer e-money, fees, safeguarding control accounts | Idempotent posting; reverse rather than edit |
Funding rails | UK Faster Payments / account-to-account; SEPA for EU; cards as funding where offered | Clear cut-off and return handling |
Spend rails | P2P, merchant pay-by-bank, card issuing | Permission checks before every debit |
Cards (optional) | BIN sponsor / card processor, 3-D Secure, controls | Only if your licence and partner stack allow issuing |
Open banking | AIS/PIS where your permissions allow | SEMIs cannot provide AIS/PIS |
Compliance | Transaction monitoring, limits, freezes, complaints, regulatory reporting extracts | Export formats aligned to FCA returns |
Ops | Reconciliation, dispute management, customer support with full balance timeline | Resolution-pack data ready |
Event-driven posting between rails and the ledger matters. A Faster Payments credit that updates the bank account but not the customer wallet, or the reverse, is how safeguarding breaks.
For a product-feature view of wallets outside the EMI lens, see our digital wallet app development guide and how to develop a digital wallet app.
Key APIs and integrations
Identity and AML: document and database KYC, company registry checks for business wallets, ongoing screening
Bank rails: UK account-to-account providers or direct bank connectivity; SEPA for euro; webhook-based credit/debit notifications with idempotency keys
Card issuing and processing: if you offer a spend card, integrate BIN sponsor, processor and 3DS
Open banking: account information or payment initiation only if your authorisation covers them
Notifications: email, push and SMS with consent records
Finance ops: bank statement ingestion for safeguarding accounts, automated matching to ledger control accounts
Support and disputes: tools that show immutable transaction history to agents without allowing silent balance edits
Cross-border remittance features may pull you into additional regimes; our money transmitter / remittance guide covers the US angle when that corridor matters.
Compliance features to build
Safeguarding evidence: daily reconciliations, break management, resolution pack, insurance/guarantee contingency if you use that method
Redeemability: customers must be able to redeem e-money at par in line with the EMRs; build clear redeem flows and timelines
Strong customer authentication: where payment services rules require SCA, do not ship password-only high-risk payments
Limits and controls: velocity limits, merchant category controls, freeze and unblock with dual control
Complaints and incidents: logged complaints with deadlines; security incident reporting workflows aligned to your regulatory notifications
Record keeping: retain onboarding, transactions, reconciliations and customer communications so an FCA or home-state review can reconstruct history
Agent oversight: if you use agents, fitness checks, activity monitoring and the ability to cut them off quickly
Cost and timeline drivers
We do not quote generic build prices. These factors move cost and time most:
Driver | Why it matters |
Own licence vs partner | Authorisation work and capital run in parallel with build; partner routes shift effort into integration and contract compliance |
UK only vs UK+EU | Two legal entities, two safeguarding banks, two reporting packs |
Rails and cards | Each rail and card programme adds certification, reconciliation and dispute flows |
Business vs consumer | KYB, multi-user permissions and invoice payouts add complexity |
Safeguarding design | Segregation vs insurance/guarantee changes banking setup and operational controls |
Build vs buy for ledger | A proven ledger shortens launch; a custom ledger needs careful dual-control and audit design |
Build plan
Define the product and jurisdiction: consumer or business, UK and/or EU, rails and card scope
Choose the route: AEMI, SEMI or partner EMI, with counsel on whether your activities need agent registration
Design safeguarding first: ledger chart of accounts, banking setup, reconciliation jobs and evidence storage
Build core wallet flows: onboarding, fund, spend, redeem, statements and support tools
Compliance testing: SCA journeys, monitoring rules, redeemability, reconciliation break drills
Pilot: limited volume, daily recon with finance, then expand rails and markets
Operational tip: treat every new rail as a mini go-live — update safeguarding mapping, monitoring rules and customer disclosures before the first live payment, not after the first break appears in reconciliation.
FAQs
Do I need an EMI licence to launch a wallet in the UK?
If you issue e-money yourself, yes — as an authorised or small EMI (unless an exclusion applies). Many startups launch as a distributor or under a partner EMI while they prepare their own application. Get counsel on which activities you perform.
What is the difference between an EMI and a payment institution?
An EMI issues e-money (stored monetary value representing a claim on the issuer). A payment institution provides payment services without issuing e-money. Many wallets need EMI status because they hold a customer balance.
Can a UK EMI passport into the EU?
No. Treat the UK and EU as separate authorisations. EU passporting requires a licence from an EEA home-state regulator.
What is safeguarding in practice?
It is the set of measures that protect customer funds if your firm fails — typically segregation in designated accounts or an eligible insurance/guarantee — plus records, reconciliations and reporting so those funds can be returned.
Is a SEMI enough to start?
It can be for a limited UK product. Watch the outstanding e-money and payment volume caps, and remember SEMIs cannot provide AIS or PIS. Plan the upgrade path to authorised EMI before you hit the ceiling.
How long does launch take?
It depends on route, rails and whether you already have a partner EMI. Authorisation and banking setup are often the longest poles; build the ledger and reconciliation early so technology is not the blocker when permission arrives.
Build your EMI wallet with Fintegration
Fintegration builds regulated wallet and payments platforms: double-entry ledgers, safeguarding reconciliations, KYC/AML workflows, UK and EU rail integrations and the reporting operations teams need. We help founders choose own-licence vs partner routes without painting over the compliance work. Talk to our team to scope your EMI-backed wallet.
