---
title: "What is a virtual account? A plain-English guide for fintech teams"
seoTitle: "What is a virtual account? Meaning and how it works"
description: "A virtual account is a unique set of bank details that routes incoming payments to one customer or purpose. How it works, who uses it, and where it fits."
date: "2026-07-29"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "Is a virtual account a real bank account?"
    a: "It depends on how the provider structures it. A virtual account always routes into an account held at a regulated bank, and the payer's bank treats its details like any other account number. Some providers issue it under a pooled account in the provider's name; others issue a named account titled to your customer. Ask which one you are getting before you promise it to users."
  - q: "Can a virtual account hold money?"
    a: "Usually not on its own. A virtual account is an identifier that routes funds into a master or settlement account, and the provider's ledger records which balance belongs to which customer. Some providers show a per-account balance; others sweep every deposit onward, for example converting it to a stablecoin and sending it to a linked wallet, so nothing sits in the account."
  - q: "Are virtual accounts legal?"
    a: "Yes. Banks and licensed payment companies issue virtual accounts in the US, Europe, and elsewhere, and they are a standard tool for collections and reconciliation. What regulators care about is who the funds belong to and whether that party was verified. Using one customer's accounts to move money for third parties who were never onboarded is where it becomes a compliance problem."
  - q: "How fast can a virtual account be created?"
    a: "Technically in seconds, since issuance is an API call. In practice it depends on review. Some providers issue pooled accounts instantly. Named accounts titled to your customer usually need compliance and bank approval first. At BlindPay, production accounts go through both reviews, with SLAs from 24 hours to 5 business days depending on the account type."
  - q: "Can one customer have several virtual accounts?"
    a: "Often, yes. Separate accounts let a customer split funds by purpose, such as payroll collections versus client invoices, and keep each flow reconciled on its own. BlindPay supports multiple virtual accounts per customer, each settling to one wallet, with a limit of one active account per banking partner for most partners."
---

A virtual account is a unique set of bank details, an account number and routing number or an IBAN, that routes incoming payments into a master account while identifying exactly who they belong to. The payer sends a normal bank transfer. The provider sees which virtual account received it and credits the right customer, invoice, or purpose automatically.

No memo field to get wrong. The account number does the matching.

## Key takeaways

- A virtual account is an identifier that routes money, not a separate pot of money at a separate bank.
- Its main job is attribution: every deposit arrives already labeled with the customer or purpose it belongs to.
- Providers can issue virtual accounts through an API in seconds, at a scale where opening real bank accounts is out of reach.
- Whose name is on the account (yours, the provider's, or your customer's) changes what the payer sees and what compliance requires.
- Stablecoin providers use virtual accounts as an on-ramp: fiat comes in over bank rails and leaves as USDC or USDT in a wallet.

## What is a virtual account?

A virtual account is a set of bank details linked to a master account or settlement flow, used to identify and attribute incoming payments. Payers see a normal account number. Behind it, many virtual accounts can point at the same underlying bank account.

Think of it like extension numbers on a phone system. One office line, hundreds of extensions, and every call rings the right desk.

The term covers a few different products depending on the provider and the country: virtual account numbers in the US, virtual IBANs in Europe, collection accounts, or "sub-accounts" on a bank's cash management platform. The mechanics are the same. A unique identifier routes funds and tells the receiver who they are for.

## How does a virtual account work?

A virtual account works by giving each customer or purpose its own unique receiving details, then reading those details off every incoming payment to credit the right ledger entry. Three pieces make it work:

1. **A master account at a bank.** This is where the money physically lands. It can be in the provider's name (pooled) or set up so each virtual account is titled to the end customer (named).
2. **A range of account identifiers.** The bank lets the provider issue account numbers, or IBANs, that route into the master account.
3. **A ledger.** The provider's system maps each identifier to a customer and records every deposit against it.

Here's how one payment moves through that setup:

1. **Issue the account.** Your platform calls the provider's API for a customer. The provider returns account and routing details (or an IBAN) for that customer.
2. **Share the details.** Your customer gives them to whoever pays them: a client, an employer, a marketplace buyer.
3. **The payer sends a transfer.** ACH, wire, SWIFT, SEPA, whatever rail the account supports. From the payer's side it's an ordinary bank payment.
4. **The deposit is detected.** The bank credits the master account and reports the receiving account number to the provider.
5. **The deposit is matched.** The provider looks up which customer owns that number. No reference parsing, no guessing.
6. **The balance or settlement updates.** The provider credits the customer's ledger balance, or sends the funds onward (to another account, or converted to a stablecoin and sent to a wallet).
7. **A webhook fires.** Your system gets an event with the deposit, the account, and the amount, and updates your UI.

Step 5 is the whole point. Everything before it is plumbing.

## How is a virtual account different from a traditional bank account?

A traditional bank account is opened by a bank for one account holder, holds its own balance, and takes days of paperwork. A virtual account is issued by a provider on top of an existing bank relationship, routes into a master account, and is created through an API.

| | Traditional bank account | Virtual account |
| --- | --- | --- |
| Who holds the funds | The bank, in an account for one holder | The bank, in a master account; the provider's ledger tracks each customer's share |
| Name on the account | The account holder | The provider (pooled) or the end customer (named), depending on the setup |
| How it's opened | Branch or online application, one at a time | API call, often in bulk |
| Speed of issuance | Days to weeks | Seconds to a few business days, depending on review |
| Scale | A handful per business | Thousands or millions per platform |
| Reconciliation | Match each deposit by reference or amount | The receiving account number identifies the deposit |
| Payer can send to it? | Yes | Yes, it looks like any account number to the payer's bank |
| Typical use | Operating account, treasury | Collections, customer deposits, payouts attribution |

One thing a virtual account usually can't do: act like a full retail account. No debit card, no checks, no online banking login for your customer. It exists to receive money and attribute it.

## What is a virtual account number?

A virtual account number is the account number issued for a virtual account. In the US it comes with a routing number (ABA), and the payer's bank sends ACH or wire transfers to it exactly as it would to any checking account. In Europe the equivalent is a virtual IBAN.

The number is real in the sense that matters to the payer: the payment rails route money to it. It's "virtual" only because it points into a shared master account instead of standing alone. The payer's bank can't tell the difference, and doesn't need to.

## Is a sub-account the same as a virtual account?

Not quite. A sub-account is usually a ledger split inside one bank account, with no external details of its own. A virtual account has its own external account number that payers can send to. Some banks use the words interchangeably, so check whether the "sub-account" you're being offered can actually receive transfers from outside.

| | Sub-account (ledger only) | Virtual account |
| --- | --- | --- |
| Own external account number | No | Yes |
| Can receive transfers directly | No, funds arrive at the parent and are allocated internally | Yes |
| Where the split lives | Your ledger or the bank's cash platform | The account number itself |

## Who uses virtual accounts?

Virtual accounts are used by any business that receives many payments from many payers and needs to know instantly who paid. Common examples:

- **Marketplaces** give each seller receiving details so buyer payments land already attributed.
- **Payment service providers (PSPs)** issue accounts to merchants so every merchant's collections stay separate.
- **Payroll and contractor platforms** give each contractor or client company an account to fund or receive payroll.
- **Remittance apps** give each sender or recipient a dedicated account for incoming transfers.
- **SaaS and B2B billing** assigns one account per customer, so invoices get paid without "which company sent this?" emails.

**Illustrative example.** A payroll platform has 400 client companies that fund payroll by wire each month. With one shared account, finance matches 400 wires a month by reading free-text references, and the ones with a missing reference sit in a suspense queue until someone calls the client. With one virtual account per client company, each wire arrives on that client's own account number. The match happens at the bank, and the suspense queue is gone. (Numbers are illustrative.)

## How do virtual accounts connect to stablecoins?

A stablecoin virtual account receives fiat over bank rails and converts every deposit into a stablecoin, like USDC or USDT, which it sends to a linked blockchain wallet. The payer sends dollars to an account number. The customer ends up with a stablecoin balance they can hold or pay out elsewhere.

That makes the virtual account an on-ramp that needs no checkout page. At BlindPay, each [virtual account](/virtual-accounts) belongs to one customer, receives ACH, wire, and SWIFT transfers into a US account in that customer's name, and settles to one wallet. Each deposit is tracked as its own payin, so the stablecoin that lands can always be traced back to the bank transfer that funded it. A customer can hold several accounts to separate funds by purpose.

The full flow, from approval to wallet balance, is in [stablecoin virtual accounts explained](/resources/more/stablecoin-virtual-accounts-explained). For what happens after the stablecoin lands, see [how a stablecoin payment works](/resources/more/how-a-stablecoin-payment-works).

## What should you watch out for?

Four things catch teams the first time they launch virtual accounts:

- **Pooled vs named.** If the account is in the provider's name, the payer sees the provider as the beneficiary. Some payers, and some compliance teams, won't accept that. Ask which you get.
- **Review time.** Named accounts usually need compliance and bank approval. Build onboarding around the real SLA, not the API response time.
- **Whose money it is.** A virtual account should hold money that belongs to the customer it was issued to. Using one customer's accounts to collect for *their* clients, who the provider never verified, is called nesting, and providers shut it down. BlindPay's rule is in [nested payments](/docs/kb/nested-payments).
- **Rails.** Not every virtual account receives every rail. A US account might take ACH and wire but not SWIFT, or the reverse. Confirm before you tell a foreign client how to pay.

If you're weighing whether to build this on your own bank relationships, [build vs buy](/resources/more/build-vs-buy-stablecoin-payments) covers what that takes.

## Where does BlindPay fit?

[BlindPay](/virtual-accounts) issues US virtual accounts in your customer's own name through one API. Deposits over ACH, wire, and SWIFT convert automatically to USDC or USDT and settle to the customer's wallet, with the same API paying out over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO) to 100+ countries with no pre-funding.

## What to do next

Spin up a free development instance and create one virtual account. It's approved instantly with a test routing number (`110000000`), so you can watch the `virtualAccount.complete` and `payin.complete` webhooks fire before any bank is involved. Start with [create a virtual account](/docs/virtual-accounts-create).

*This article is for general information only and is not legal, tax, or financial advice.*