Virtual IBANs and named accounts: what they are and when you need them

A virtual IBAN and a named account solve different payment problems. A virtual IBAN primarily routes incoming transfers to the correct customer, entity or ledger. A named account identifies your company as the beneficiary or account holder. A virtual IBAN can be named, but it is not named automatically; a named account can also use a conventional IBAN rather than a virtual one.

What is a virtual IBAN?

A virtual IBAN, or vIBAN, is an IBAN assigned to a business, customer or payment stream that routes transfers into an underlying payment account or ledger. It looks like a standard IBAN to the sender, but it does not necessarily represent a separate bank account with its own balance.

When a payment reaches the provider’s infrastructure, the virtual IBAN tells the provider where to allocate it. A business can therefore issue different receiving details for subsidiaries, customers, contracts or collection channels without opening a conventional bank account for every flow.

A typical receipt follows this sequence:

1. The business gives the payer a virtual IBAN, beneficiary name and payment instructions.
2. The payer sends a transfer through a supported rail, such as SEPA or SEPA Instant.
3. The provider receives the transfer through its underlying account infrastructure.
4. The virtual IBAN maps the payment to the correct business ledger or collection stream.
5. The transaction record shows available details such as payer name, amount, currency, reference, timestamp and status.
6. Subject to the provider’s controls and product availability, the business can hold the fiat, pay it onward or convert it into USDC or USDT.

An IBAN identifies a payment route; it does not determine payment speed. Timing depends on the rail, sending and receiving institutions, operating windows, screening, currency and whether the transfer requires manual review. An eligible SEPA Instant payment may arrive within seconds, while a standard SEPA transfer generally follows banking-business-day processing.

What is a named account?

A named account generally means that payment instructions or banking records display the company’s registered legal name as beneficiary or account holder. This matters when a customer, marketplace, bank or exchange checks whether the account name matches the entity named in a contract or platform profile.

Named account is not a universally standardised legal category. Providers may use the term for materially different arrangements, including:

• An account opened directly in the company’s legal name.
• A payment account supplied through a regulated banking or payment partner.
• A virtual IBAN mapped to the company, with its legal name included in the payment instructions.
• A ledger balance within a broader safeguarding or custodial structure.

The displayed beneficiary name does not, by itself, explain who legally provides the service, where funds are held, whether the IBAN is dedicated, or what protections apply. Finance teams should request the account terms and legal structure rather than relying on the word “named.”

Name matching also has limits. Banks may apply different formatting, truncate long names or omit punctuation and corporate suffixes. A named account can reduce avoidable mismatches, but it does not guarantee that every bank or beneficiary-verification system will accept a transfer.

Virtual IBAN vs named account

How collection accounts improve reconciliation

Collection accounts receive customer payments before the funds are retained, converted or paid onward. Virtual IBANs are useful when free-text references are too inconsistent to serve as the main reconciliation key.

For example, a finance team might assign one virtual IBAN to each subsidiary, major customer or marketplace merchant. The receiving IBAN then provides a persistent allocation key even if the payer omits an invoice number or enters it incorrectly.

This helps with three common workflows:

• High invoice volumes: Payments can be associated with a customer or contract before reference-level matching.
• Multiple legal entities: Separate receiving details reduce the risk of recording one subsidiary’s funds against another.
• Fiat-to-stablecoin flows: Treasury can identify the payer and purpose before converting collected fiat into USDC or USDT.

A vIBAN does not eliminate exceptions. Finance teams still need procedures for duplicate transfers, partial payments, refunds, unexpected third-party senders, unsupported currencies and payments sent after an identifier has been closed.

Transaction data should preserve the payer name, amount, currency, value date, timestamp, reference, receiving IBAN, status and bank transaction identifier where available. Retaining the original data matters because a general-ledger summary may not contain enough evidence to investigate a disputed or unmatched receipt.

How this differs from a multi-currency account

A multi-currency account allows a company to hold or transact in more than one currency within one provider relationship or interface. It is a balance capability, not a synonym for a virtual IBAN or named account.

A company might use a euro virtual IBAN for SEPA collections, local GBP details for UK receipts and separate USD instructions for ACH or wire transfers. The corresponding balances may appear in one multi-currency account even though each currency uses different payment details and rails.

Do not assume one IBAN accepts every currency. Sending an unsupported currency can cause rejection, return, automatic conversion or correspondent charges. Before distributing instructions, confirm:

• The currency accepted by each set of account details.
• Whether the transfer is local, regional or cross-border.
• Who bears intermediary and correspondent fees.
• Whether unsupported currencies are rejected or converted.
• The relevant cutoffs, limits, value dates and return process.

When does a company need each option?

Use a virtual IBAN when payment volume or organisational complexity makes reference-only reconciliation unreliable. Common cases include recurring European invoices, marketplace collections, separate subsidiary receipts and repeatable fiat funding of a stablecoin treasury.

Prioritise a named account when a customer, bank, exchange or regulated counterparty requires the beneficiary or originating account to match your company’s legal name. Some platforms restrict deposits and withdrawals involving third-party accounts, even when related entities share an owner. Confirm the platform’s rule before moving funds; economic ownership alone may not satisfy its controls.

A company receiving only a few predictable transfers may need neither multiple vIBANs nor a complex collection structure. Additional identifiers create maintenance work: payment templates must be updated, unused details closed, customers notified and stale instructions monitored.

Jurisdiction, eligibility and account structure

Availability depends on factors including incorporation country, operating locations, ownership, business model, industry, expected volumes and transaction corridors. The country code at the start of an IBAN does not necessarily show where the company is incorporated or establish the legal location of its funds.

Onboarding commonly requires incorporation records, registered address, directors, beneficial owners, business activity, source of funds and expected payment patterns. Stablecoin companies may also be asked to explain wallet ownership, transaction counterparties, supported assets and how fiat and onchain records are reconciled.

Before relying on receiving details, ask the provider to confirm:

1. Which legal entity provides the payment service.
2. Whether the details display your exact registered company name.
3. Whether the IBAN is virtual, dedicated or linked to an underlying pooled account.
4. How funds are held and what safeguarding or custodial arrangement applies.
5. Which currencies, countries, sender types and transaction purposes are supported.
6. What limits, fees, cutoffs and return procedures apply.
7. How transaction records and audit evidence can be exported.
8. What happens to incoming payments if the details are suspended or closed.

Using receiving accounts with a stablecoin treasury

Receiving fiat is only the first stage of a stablecoin treasury workflow. Finance must also approve conversion, select the correct blockchain network and destination wallet, document the exchange rate and fees, and reconcile the fiat debit against the onchain transaction.

Controls should distinguish the beneficiary account from the wallet destination. A correctly named fiat account does not validate a blockchain address, and an approved wallet does not establish the source of incoming fiat. Before sending USDC or USDT, verify the token, network, address, amount and signing authority; screen the destination under the company’s compliance process; and retain both fiat and onchain evidence.

Stablerail provides one business account for USDC and USDT treasury, including approvals and signing quorum, sanctions and address screening before send, corporate cards, global payouts, fiat off-ramp and exportable audit evidence. Availability of account details, currencies and rails remains subject to the company’s jurisdiction and KYB outcome.

The practical choice is therefore not “virtual IBAN or named account” in every case. A finance team may need a named virtual IBAN: a dedicated routing identifier for reconciliation that also displays the legal entity expected by counterparties. The provider should confirm both features explicitly in writing before the business publishes payment instructions or depends on the route for treasury funding.