Virtual accounts explained: receiving details, names, and ownership

A client asks for your bank details. Your payment provider gives you an account number, a beneficiary name, and a routing code. The instructions look familiar, but the provider calls them a virtual account.

What have you actually received?

Virtual accounts are payment-identification arrangements whose underlying structure depends on the provider. They can make incoming transfers easier to allocate to a customer or invoice. They do not, by themselves, establish that the customer has opened a conventional deposit account at the named bank.

That distinction matters when you explain the details to clients, connect a marketplace payout destination, or decide where to keep business funds. This guide separates the identifiers you share from the service and legal relationship behind them.

What does a virtual account do?

Imagine a payment provider serving three businesses. All three receive transfers, sometimes for identical amounts on the same day. The provider needs to know which payment belongs to which business.

One arrangement gives each business a distinct receiving identifier. Another uses shared instructions with a customer-specific reference. Other structures combine multiple identifiers and internal records.

The receiving instruction is a routing and allocation tool. The provider’s records connect the incoming transfer with a particular customer, balance, invoice, or transaction.

For a concrete industry example, Stripe describes using virtual bank account numbers to identify customer bank transfers and help reconcile them. That describes Stripe’s implementation, not a universal specification or an Ostro feature claim. Stripe: Bank transfer payments.

Separate four layers of the arrangement

Layer	What to establish	Why it matters
Receiving identifier	Account number, IBAN, or other instructions	Tells the payer where to direct the payment
Allocation mechanism	Unique details, required reference, or another method	Connects the transfer to the right customer
Service relationship	Your contracting provider and applicable terms	Explains your rights, obligations, and support route
Funds and settlement arrangement	Institutions involved and applicable protections	Explains how funds are handled behind the interface

A bank name in the instructions answers only part of this exercise. It might identify the institution participating in a receiving arrangement. It does not automatically make you a direct retail or business banking customer of that institution.

Ask the provider to explain the structure in plain language. A clear answer should describe your product, rather than merely repeat that the infrastructure is regulated.

Virtual account, virtual IBAN, and reference-based payment

A virtual IBAN uses an IBAN-format identifier within a virtual-account arrangement. Other currencies may use account and routing numbers or different local identifiers. The word “virtual” does not determine the currency or payment rail.

With reference-based instructions, the payer may need to send to a shared destination and include an exact code. That code can be essential to allocation. An invoice number invented by the sender may not substitute for it.

With unique receiving details, a reference may still be required for compliance, reconciliation, or transaction identification. Never remove a reference just because the account number appears unique.

The practical rule is simple: copy the complete current instruction set. Preserve the beneficiary name, currency, transfer method, and reference rules together. Our guide to payment references explains why those fields perform different jobs.

Does a named account mean a traditional bank account?

Not necessarily. “Named” can describe how the beneficiary or receiving details are presented. “Bank account” describes a legal and product relationship that needs its own explanation.

A product can display receiving details in a customer’s name while operating through financial infrastructure supplied by other institutions. The actual relationship depends on the agreement and jurisdiction.

Conversely, some receiving arrangements require the payer to use a provider or other designated beneficiary name. Replacing it with your trading name can make the instructions incorrect, even if the invoice legitimately belongs to your business.

For Ostro, the appropriate description is “Account details in your name, where available and approved.” Use the beneficiary information actually shown in your workspace. Do not describe conditional receiving access as a traditional bank account available to everyone.

Why account ownership checks can cause confusion

A marketplace may require a payout destination in the seller’s legal name. A client may need to complete vendor verification. A bank may display a name-check warning.

These checks are about the receiving arrangement’s compatibility with the sender’s rules. Having a valid account number does not prove that a particular marketplace or payroll system will accept it.

Before changing a payout destination, ask both sides:

• Does the sender accept this account type and destination country?
• Does the receiving provider accept payments from this sender and for this purpose?
• What beneficiary name must appear?
• Is an account-confirmation document available through the approved process?
• Are third-party payments, marketplace payouts, and first-party funding treated differently?

If the two sets of requirements conflict, use another supported arrangement. Altering the beneficiary name to bypass a mismatch creates a new problem rather than resolving the original one.

The KYC and KYB guide explains why identity verification, business eligibility, and approval of a particular payment are separate checks.

What can you receive through virtual details?

The answer depends on the specific product. Currency, payment rail, payer type, customer eligibility, and transaction purpose can all matter.

USD details might accept a supported ACH credit or domestic wire without accepting every international wire service. EUR instructions may be intended for a particular SEPA route. An account supporting client payments may have different rules for transfers from an account you own.

Also distinguish receiving money from authorising a debit. Details that accept incoming bank transfers do not necessarily support a company pulling money from the account to collect a subscription or verify a payment method.

Use the USD receiving guide and EUR receiving guide to understand those local systems. Then verify the actual capabilities of your account with the provider.

A worked example: allocating three identical payments

Consider a fictional agency with three clients, each owing USD 1,000.

Under one arrangement, each client receives a different customer-specific account identifier. The provider uses the destination identifier to help distinguish the payments.

Under another, all three clients use the same destination but must include separate references: one for each client’s allocation. If two clients omit the reference, matching only on amount is unreliable.

The agency still needs its commercial ledger in either case. Receiving USD 1,000 from a client does not establish whether it pays this month’s invoice, an overdue invoice, or a project deposit.

A useful reconciliation record therefore includes the provider transaction ID, sender information, receiving identifier or reference, currency, amount, and the invoice allocation chosen by the agency. Virtual details can reduce ambiguity, but they do not replace commercial records.

What happens after the payment arrives?

Receipt, allocation, availability, and payout are separate events.

A transfer can arrive at a receiving institution before it is allocated to your profile. It can be allocated but awaiting review. It can be available for an eligible payout that has not yet been requested or completed.

This is why the word “received” needs context. Read the provider’s status explanation before promising that the money is ready to spend elsewhere.

If a client has sent the payment but you cannot see it, gather the route-appropriate transaction evidence. Provide the amount, currency, sending date, sender name, and transfer identifier through a secure support channel. Avoid asking the client to pay again while the first transfer is being investigated.

For the accounting side, see cross-border payment reconciliation.

How should you assess protection and provider risk?

Start with the product’s legal terms and the relevant regulator’s explanation of that product type. Do not infer insurance, safeguarding, or deposit protection from an account-number format.

For example, the UK’s Financial Conduct Authority explains that funds with certain payment and electronic-money providers are subject to safeguarding arrangements rather than the same protection as eligible bank deposits under the Financial Services Compensation Scheme. That is a UK-specific distinction, not a rule for every country or provider. FCA: Using payment service providers.

Ask who your contracting entity is, who handles the funds, how any protection applies, what happens if a provider becomes insolvent, and how complaints are handled. Obtain answers for your jurisdiction and account type.

The practical aim is not to choose a product based on a reassuring label. It is to understand the actual arrangement before relying on it for important receipts.

Share instructions without sharing account access

Receiving details are intended to be shared with legitimate payers through an appropriate channel. Login credentials, recovery codes, authentication codes, and private keys are not payment instructions.

Keep a controlled copy of the approved details and the date they were confirmed. If the provider changes them, update invoices and notify recurring payers through an established contact route.

Treat unexpected requests to change receiving details carefully. A convincing email thread can still be compromised. Verify changes using a previously known contact method before the next payment. Our business payment-fraud guide explains a proportionate process for small teams.

Questions to ask before choosing a receiving arrangement

Request specific answers about your expected transactions:

1. Which customer types and countries are eligible?
2. Which currencies and incoming transfer methods are supported?
3. Which payer types and payment purposes are permitted?
4. What beneficiary name and reference must the payer use?
5. Can the details change, expire, or be disabled?
6. How are reviews, returns, and missing payments handled?
7. What fees apply before and after receipt?
8. Which payout destinations are available?
9. What records can you access for reconciliation?
10. What legal relationship and funds protections apply?

Compare those answers against a sample client payment and a sample marketplace payout. A product can be suitable for one and unsuitable for the other.

Frequently asked questions

Is a virtual account the same as a virtual card?

No. A virtual card is a card payment credential. Virtual receiving details are instructions or identifiers for receiving and allocating payments. One does not imply access to the other.

Can I use virtual receiving details on an invoice?

Only when the provider permits that payer, purpose, currency, and route. Include the exact required instructions and confirm that the client can use them.

Can I receive a different currency into the same details?

Do not assume so. Follow the currency-specific instructions and ask the provider how unsupported currency payments are handled before anyone sends one.

Does “virtual” mean anonymous?

No. The word does not remove onboarding, identity verification, eligibility checks, monitoring, or other applicable requirements.

What should I call the details when speaking to a client?

Use the provider’s accurate product description and the specified transfer method. “Here are the receiving details for this USD payment” is clearer than making an unsupported claim about owning a particular bank account.