Give each payer, customer or business unit its own account number, so incoming money identifies itself without reading the payment reference.
Here is what the term actually means, and how IBANs work on the NGPES platform, which is a related but distinct thing.
A virtual IBAN is an account number that routes to an underlying account rather than being an account in its own right.
One per customer, per entity or per flow, so the account number itself carries the information.
Money arriving on a given IBAN identifies its sender by definition, without depending on a reference field.
The funds land in the underlying account. The IBAN is a label on the door, not a room.
It is worth being precise, because the benefit is often described vaguely.
In an ordinary setup, hundreds of payers send money to one account. Matching each receipt to an invoice depends on the payer typing a reference correctly, which a meaningful proportion of them will not do. Somebody then spends the first week of every month working out who paid what.
With a virtual IBAN per payer, the account number the money arrived on identifies the payer. The reference becomes a convenience rather than a dependency. That is the whole trick, and at volume it removes a large amount of manual work.
The corollary is that a virtual IBAN is worth very little if you have five customers. The benefit scales with the number of payers you cannot control.
| Standard IBAN | Virtual IBAN | |
|---|---|---|
| What it is | The identifier of an actual account | An identifier routing to an underlying account |
| How many you get | One per account | Many, typically one per payer, entity or flow |
| Where funds land | In that account | In the underlying account |
| Main benefit | It is the account | Automatic attribution of incoming payments |
| Best suited to | General operation | Businesses with many payers and heavy reconciliation |
This is the part specific to NGPES, and it is different from the generic concept above.
If your project depends specifically on issuing many virtual IBANs to your own customers, ask the team directly rather than inferring it. The documented structure is a dedicated IBAN linked to a wallet, with subaccounts underneath, and that is a different shape from a virtual IBAN issuing programme.
The platform runs on a stablecoin settlement layer. Fiat is not held inside it. It moves in and out through a linked IBAN, and converts on the way through.
Most of the operational risk in cross-border payments comes from paying the wrong party, or taking money from a source you cannot account for. NGPES makes both a deliberate step.
This is what the platform supports today.
| Position today | |
|---|---|
| Stablecoins | Selected MiCA-compliant stablecoins only. Assets outside that set are not held on the platform. |
| Non-compliant assets | Funds arriving in an asset that is not MiCA-compliant can be converted into a MiCA-compliant one, as a case-by-case exception, not a standing service. |
| Fiat | Moves in and out through the linked IBAN via on-ramp and off-ramp. Fiat balances are not held on the platform. |
| Swap | Between supported MiCA-compliant stablecoins only. |
| External accounts | You can register your own external bank accounts and wallet addresses. They are verified before use, and only for flows involving the same organisation. |
| Team management | Announced as coming soon. Not available yet. |
If a particular asset, currency or corridor matters to your business, ask us before you build around it.
Where NGPES is authorised today.
NGPES is based in France and the platform supports selected MiCA-compliant stablecoins only, by design. Services will become available only upon obtaining the relevant CASP and EMI authorisations.
What NGPES states today.
| What NGPES states | |
|---|---|
| Reach | Funds move across 150+ countries via SEPA, SWIFT and local rails. |
| Stablecoin settlement | T+0. |
| Fiat settlement | T+1. |
| Processing | 24/7/365, with no end-of-day batch. Everything is processed in real time. |
| Conversion | Instant conversion between fiat, in USD, EUR and GBP, and stablecoins. |
| Exchange | 24/7 fiat to stablecoin exchange, with OTC support. |
For a per-country arrival time, a fee, or the supported asset and network list, talk to the team.
An account number that routes to an underlying account rather than being a separate account itself. Businesses issue one per payer or per business unit so that incoming money is attributed automatically by the number it arrived on.
A standard IBAN identifies an actual account. A virtual IBAN is an identifier pointing at an underlying account, and you can have many of them.
Attribution. When each payer has their own IBAN, you know who paid without depending on them typing a reference correctly. The benefit scales with the number of payers.
The documented structure is a dedicated IBAN linked to each wallet, with subaccounts providing separation beneath the organisation account. If you need to issue many IBANs to your own customers, confirm that specifically with the team.
No. Fiat is not held on the platform. Funds arriving through the IBAN are processed through the on-ramp and converted into a supported stablecoin before being credited to the wallet.
Through subaccounts, each with its own balances and transaction history, under central organisational control.
No. Sources are whitelisted in advance, and funds from an unrecognised source are held while the support team contacts you.
That number decides whether the structure you need is subaccounts or something else.
NGPES, Next Generation Payment EcoSystem, is a B2B payment infrastructure that enables businesses to send, receive, hold and move money efficiently across borders. Both fiat currencies and regulated stablecoins are integrated, for faster settlements, lower costs, and enhanced transparency. NGPES is based at 35 avenue de Friedland, 75008 Paris, and was ranked 83 in the Finance Innovation Fintech100 2025.
Interested in our solution? Talk to our team, or email sales@ngpes.com.
.avif)
.avif)
