The short answer
You add 35 currencies without 35 licences by not holding the money yourself. A technology layer connects your product to licensed institutions that already hold the relevant permissions; you integrate once, they cover the jurisdictions. The currency count becomes a configuration, not a procurement programme.
Why owned rails cap at 2–3 currencies
If you settle in a currency, you take on what that currency requires: a local licence or a partner who holds one, liquidity you source, redemption you stand behind. Do that for two currencies and it's a serious programme. Do it for 35 and the regulatory edges never all line up at once. This is why the most licensed providers in a market still settle in two or three — owning rails and counting currencies move in opposite directions.
| Model | Currencies you can hold | What it costs |
|---|---|---|
| Own the rail | 2–3 (deep, yours) | Licence + capital per currency |
| Layer | 35+ (rented) | One integration |
How the layer reaches 35
The layer doesn't need a licence per currency because it doesn't custody the funds — regulated partners do, in the markets where they're authorised. You rent their permissions through one API. Adding a currency is a string, not a banking relationship. See the shape in White-Label Payment Infrastructure.
Nobody has ever offered 35 currencies and owned the rail underneath all of them. The arithmetic doesn't allow it — so the 35-currency answer is always a layer.
The bottom line
Add currencies by connecting to licensed rails, not by collecting licences. One integration, 35 currencies, none of them your regulatory burden.