Virtual IBANs route incoming payments to the right client, entity or balance, so money is identified the moment it arrives instead of being matched by hand at the end of the month.
A single account collecting every incoming payment looks simple until the volume arrives. Then the work is no longer receiving money — it is working out whose money it was. This is the problem virtual IBAN arrangements exist to solve.
Payments land on one set of details with a free-text reference the payer filled in, so somebody reads each line and decides which customer it belongs to.
The same payer appears under two spellings, a beneficiary name is abbreviated differently each time, and two teams keep their own version of who has paid.
Attribution is deferred to month end, so the close becomes an assembly job rather than a review of figures that were already correct.
Handing out different account details per client without a system behind it multiplies the confusion rather than resolving it — more IBANs, no more clarity. A virtual IBAN structure is what turns that sprawl into a system.
An incoming payment that has not appeared yet cannot be distinguished from one that was never sent, so the answer to the client is a guess.
A virtual IBAN is a set of payment details that routes an incoming payment to an underlying account rather than holding a balance of its own. To the payer it looks and behaves like any other IBAN: they send an ordinary bank transfer to the details they were given. On the receiving side, the virtual IBAN carries the meaning — it tells the provider which client, entity or balance that payment belongs to, before anyone reads a reference field.
That is the difference from a dedicated IBAN account. A dedicated IBAN is attached to an account that holds funds in its own right; a virtual IBAN is an address that resolves to one. Providers also distinguish named IBANs, issued in the beneficiary name of the company or its client, from pooled arrangements where several parties share underlying details. Which model applies changes who is shown as the beneficiary name on a payment, and it is worth asking any provider directly.
One consequence is worth stating plainly, because it is where most misunderstandings about virtual IBAN accounts begin: a virtual IBAN does not create a separate pot of money. Ten virtual IBANs pointing at one balance are ten ways of labelling arrivals into that balance, not ten balances. Companies that need genuinely segregated funds are describing dedicated accounts, not virtual ones, and the two are worth separating before a provider is chosen.
How a virtual IBAN arrangement is structured: several sets of details, one account behind them.
| Virtual IBAN | Dedicated IBAN account | |
|---|---|---|
| Holds a balance | No — a virtual IBAN routes to an underlying account | Yes — funds rest on the account itself |
| Main purpose | Identifying and attributing incoming payments | Receiving and holding funds for the company |
| Typical count | Many virtual IBANs, often one per client or entity | One per company, or one per currency |
| Beneficiary name | Depends on whether the virtual IBAN is issued as a named or pooled arrangement | The company holding the account |
| Payer experience | Identical — an ordinary transfer to an IBAN | Identical — an ordinary transfer to an IBAN |
Fenryx provides business IBAN accounts designed for receiving third-party payments. That is the honest shape of it: details a company can publish to its clients, platforms and processors, sitting on the same platform as the balances those funds land in, the statuses attached to each payment, and the exports the finance team reconciles from.
Whether a given account is issued as a dedicated, named, pooled or virtual IBAN depends on the setup agreed for that account, and it is confirmed during onboarding rather than promised here. If your use case depends specifically on virtual IBAN behaviour — many sets of details resolving to one balance — say so in the first conversation and we will tell you plainly what is available for your business and in which collection currencies. We would rather answer that question in a conversation than publish a virtual IBAN claim the product has not confirmed.
What is consistent across the board is what happens once funds arrive: a payment carries its detail and reference into the platform, holds a status you can look up, and reaches an export that has not lost the context. The receiving side pairs with the outgoing side described under cross-border payments, so collection and payment run from one seat rather than two.
The company applies online and sends documents remotely. Every account opens through KYB review, and screening continues once the account is live.
Details the company can publish so third parties pay in directly, rather than routing collections through a personal or unrelated account. See IBAN account.
Funds held in the major currencies the business collects in, so a euro payment does not have to be converted on arrival. See multi-currency account.
Payments arrive over the rail the sender's institution uses, whether that is a euro transfer inside the SEPA area or a SWIFT payment from further afield.
Incoming payments carry a status on the platform, so an expected payment that has not landed is distinguishable from one that has.
Payment detail, comments and references survive into the export, and periods can be exported for the accounting side without losing that context.
A platform collecting from a long list of customers, where the value of a virtual IBAN arrangement is that attribution happens at arrival rather than in a spreadsheet afterwards.
A company invoicing across the SEPA area, receiving in the currency the client already works in and holding it rather than converting on arrival. Pairs with international business accounts.
Identified incoming payments mean the month closes on figures that were already attributed, so reconciliation is a review rather than an assembly job across statements.
A group running several companies, keeping each entity's collections distinguishable instead of unpicking one commingled stream at the end of every period — the classic case for a virtual IBAN per entity.
Tell us how your business collects — how many payers, in which currencies, and whether flows need to be separated by client or entity. We will confirm what is available for your account before you commit.
Check availability for your businessRelated reading: IBAN accounts and multi-currency accounts.
Tell us who pays your business and in which currencies.
The company, owners and collection profile are verified.
Account details are issued and confirmed in the model agreed for your account.
Publish the details to your payers and funds start arriving.
Follow incoming payments by status and export the period for reconciliation.
| Account fee | Quoted per account at onboarding |
| Incoming payment fee | Quoted per rail, shown before the account goes live |
| Currency conversion | Rate and cost shown side by side, not folded into the rate |
| Collection currencies | Agreed per account, aligned to who pays you |
| Limits | Set at onboarding, reviewed against real activity |
Terms depend on the business profile and the way the company collects, so pricing is set at onboarding rather than published as one price list.
Registered legal entities only. We do not open personal accounts, and collections run to a company account rather than to an individual.
Eligibility depends on business type and jurisdiction, on who the company receives funds from, and on the outcome of KYB review. No account or IBAN model is guaranteed before that review is complete, and screening applies throughout the life of the account.
A summary. See our AML Policy.
A virtual IBAN is a set of payment details that routes an incoming payment to an underlying account rather than holding a balance of its own. The payer sees an ordinary IBAN and pays it in the ordinary way; on the receiving side, the virtual IBAN tells the provider which client, entity or balance that payment belongs to.
Most often to identify incoming payments automatically. A company issues a different virtual IBAN per client, per entity or per product line, so a payment arriving on that IBAN is already attributed when it lands, instead of being matched by hand against a reference the payer may have typed incorrectly.
No. An IBAN is a standardised way of addressing an account, not the account itself, and a virtual IBAN in particular is a routing reference rather than a place funds rest. Fenryx is a payment account provider and money services business rather than a bank, and what is described here are business payment accounts — see IBAN accounts for the receiving side and international business accounts for the full stack.
That is the main reason companies ask for them. When each payer or entity has its own IBAN, attribution happens at the moment funds arrive rather than at the end of the month, which shortens period close and removes a class of manual matching errors. A virtual IBAN does not make the accounting easier by itself; it makes the attribution unambiguous, and the accounting follows from that. The same logic applies on the outgoing side, where references survive into the export for cross-border payments.
Registered legal entities, subject to KYB review. Eligibility depends on business type, jurisdiction and where the company receives funds from, and no account is guaranteed before that review is complete. Personal accounts are not offered. Which IBAN model applies to your account is confirmed during onboarding.
Tell us who pays your company, in which currencies, and how those flows need to be separated.
Fenryx is operated by Globally United Tech Corporation, a money services business registered with FINTRAC in Canada, Vancouver, BC. Account availability, the IBAN model issued, collection currencies and limits depend on business type, jurisdiction and KYB review. Settlement timing depends on the rail and the sending institution.