Key points
- The dividing line is whether you hold client funds, and in what form
- Payment initiation, money remittance and e-money issuance are three different permissions
- Safeguarding client funds is the obligation most applicants underestimate
- Many crypto businesses need a payments permission as well as a crypto one
- Scope is defined per activity — a licence is not a general permission to operate
Fintech licensing covers payments, remittance and e-money rather than crypto-asset services, and the dividing line is usually whether you hold client funds and in what form. We handle Latvian API and EMI, Singapore's Major Payment Institution licence, New Zealand FSP registration, Canadian MSB including RPAA registration, UK API and EMI, and Hong Kong MSO.
Fintech licensing sits next to crypto licensing and is frequently confused with it. The distinction matters because the two answer different questions: a crypto permission concerns virtual-asset activity, while a payments permission concerns the movement and holding of money. A great many businesses need both.
Which fintech licence do you need?
Which permission matches which activity
| What you actually do | The usual category | Where we work on it |
|---|---|---|
| Move money between third parties without holding it | Payment institution / payment services | Latvia · UK · Singapore · Canada |
| Hold customer balances that can be spent later | Electronic money institution | Latvia · UK |
| Cross-border remittance for retail customers | Money service / remittance | Canada · Hong Kong · New Zealand |
| Issue or operate a card programme | E-money plus a card scheme relationship | Singapore · Hong Kong |
| Operate a wallet holding both fiat and tokens | Payments permission plus a crypto permission | Case by case, and usually both |
Start from what actually happens to funds. If money moves between two third parties and never rests with you, you are likely in payment services. If customers hold a balance with you that they can spend later, that is usually electronic money, and the obligations rise sharply because you are holding other people's funds. If you are moving money across borders for retail customers, remittance regimes apply. If you are issuing a card, you need an e-money footing and a relationship with a scheme.
We work on Latvian API and EMI authorisations, Singapore's Major Payment Institution licence under the framework administered by the Monetary Authority of Singapore, New Zealand financial service provider registration overseen by the Financial Markets Authority, Canadian money services business registration including RPAA, UK API and EMI, and Hong Kong money service operator licensing.
What does the application require?
What a payments regulator will want to see
- A precise description of the payment flow — who holds funds, at which moment, and in whose name
- Safeguarding arrangements for client money, with the mechanism named and evidenced
- Capital that meets the category's threshold, and evidence of where it came from
- AML and CFT procedures matched to the actual payment corridors and customer geography
- Governance: named individuals with defined responsibilities, and fit-and-proper material for each
- Operational resilience — what happens to client funds and access if a critical supplier fails
- Financial projections consistent with the volumes the rest of the application describes
Payments regulators ask a narrower and more forensic set of questions than crypto regimes do, because the risk they are managing is concrete: client money going missing. Safeguarding is the item applicants consistently underestimate. It is not enough to say client funds are held separately — the regulator wants the mechanism named, the account structure evidenced, and the reconciliation process described in a way that could be audited.
The second recurring gap is a payment flow description that does not survive a careful reading. If the narrative says funds are never held but the technical architecture shows a pooled account with a settlement delay, the application has answered its own question the wrong way.
The overlap with crypto licensing
This is the most consequential thing on the page. A wallet that holds both fiat balances and tokens, a payment processor that settles in stablecoin, an exchange that lets customers leave money on account — each of these is very likely conducting two regulated activities at once. Scope is defined per activity, not per company, and a permission granted for one does not stretch to cover the other.
Where your customers are in the EU, the Markets in Crypto-Assets Regulation now governs the crypto side, and its transitional period ended on 1 July 2026 — a payments licence does not substitute for CASP authorisation. Sorting out which combination you need is the subject of choosing a licence, and it is worth doing before any application is started rather than after one is granted.
What we do
The same seven stages as any other engagement, described on how we work: classification first, then jurisdiction, then entity and the personnel the regime requires, then the full document set drafted against your real payment flow, then submission and the question rounds. Payments applications tend to involve more iterations on the safeguarding and financial-projection sections than crypto files do, and we budget for that rather than treating it as a surprise.
After approval, payments permissions carry heavier ongoing reporting than most crypto regimes — covered on post-licence compliance. The bank account and card relationships the licence assumes you will have are on banking and card issuing.
No approval can be guaranteed; regulators retain full discretion. This page is general information, not legal advice, and reflects the position as at August 2026. CryptoLicense is an advisory firm, not a regulator and not a law firm.
