> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rheon.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Virtual accounts

> Issue permanent bank details per user. Money that arrives is converted and settled to a wallet automatically.

A virtual account is a set of real bank details - IBAN, SWIFT, or local rails -
issued to one of your users and kept for good. Your user pays it from their own
bank, like any other transfer. What arrives is converted and settled as stablecoin
to the wallet and chain you attached to that account, with no reconciliation on
your side.

## What it is for

Each account behaves as a programmable collection point:

* **Collection** - one payer, one permanent set of details, any number of transfers.
* **Conversion** - fiat that lands is converted to the output asset you set on the
  account.
* **Settlement** - the converted amount is delivered to the wallet you attached, on
  the chain you named.
* **Attribution** - funds arrive already tied to one user, so you are not matching
  names on statements.

Typical uses: a fintech giving every customer their own deposit IBAN; a marketplace
giving each merchant a collection account that settles on-chain; a platform
collecting EUR and holding balances in USDC.

## How it works

<Steps>
  <Step title="Verify the user once">
    Identity is checked once and reused across rails - see [Rheon ID](/rheon-id).
    The user consents to sharing the result with the banking partner; a returning
    user is not asked again.
  </Step>

  <Step title="Open the account">
    You name the destination wallet, the chain, and the output asset. You get back
    the bank details to display and the fee that applies.
  </Step>

  <Step title="Show the details">
    Display the account details and the reference exactly as returned. A transfer
    that arrives without the reference has to be attributed by hand.
  </Step>

  <Step title="Money arrives and settles">
    The user sends a normal bank transfer. Conversion and settlement happen without
    another call from you. Bank transfers clear in hours or days, not seconds - do
    not build a UI that expects the user to wait on screen.
  </Step>

  <Step title="Track it">
    Poll for funding status until the transfer is delivered, then credit the user.
  </Step>
</Steps>

## What an account carries

| Setting                    | What it does                                                                             |
| -------------------------- | ---------------------------------------------------------------------------------------- |
| Destination wallet         | The address the settled stablecoin is delivered to. Attached when the account is opened. |
| Chain                      | The network settlement happens on.                                                       |
| Output asset               | What the incoming fiat is converted into.                                                |
| Incoming rail and currency | Which bank rail and currency the account accepts, e.g. EUR over SEPA.                    |
| Fee                        | Your fee, in basis points, applied to money arriving on that account.                    |
| Reference                  | The string the payer must include, so the transfer is attributed automatically.          |

## Fees

Your fee is set in basis points on the account and taken from the incoming amount.
The banking partner charges its own fee on top of that, so what the user receives is
smaller than the amount minus your fee alone. If you show a "you send / you receive"
figure before the transfer, quote it - do not compute it from your own fee only.

## API

Two ways in, depending on who drives:

* **The buyer-facing flow** - onboard the user, open the account, poll for funding.
  Three calls, in order: the
  [Bank transfers reference](/api-reference/bank-transfer).
* **Direct management** - create, read, update, and list virtual accounts from your
  backend, starting at
  [Create a virtual account](/api-reference/virtual-account-create). Creating
  accounts needs the virtual-accounts permission on your API key - see
  [Authentication](/api-reference/authentication).

## Currencies, rails, and limits

EUR, GBP, USD (ACH, wire, RTP, and SWIFT), AED, AUD, BRL, MXN, NGN, and COP, plus
stablecoin collection accounts on eight networks. Per-currency rails, who is allowed
to pay in, and the settlement ceilings are on [Coverage](/coverage); pricing is on
[Fees](/fees).

Two operational details worth building for:

* **Some accounts provision asynchronously** (USD, AED, COP). The details come back
  empty and populate moments later - poll rather than showing your user a blank
  screen.
* **Not every rail accepts a third-party payer.** GBP and AUD accept money only from
  the account holder. A transfer from someone else's account is not a payment you can
  credit.