Virtual accounts
Virtual accounts for clearer payment operations
Give customer, merchant, or treasury collections distinct bank details, then connect each inbound transfer to the right ledger record and supported settlement route.
Named inbound collection
Use enabled virtual account details for repeat or operationally structured fiat deposits rather than treating every inbound transfer as an anonymous shared-account event.
Multiple account formats
Public documentation describes USD account and routing details, EUR IBAN and SEPA details, MXN CLABE details, and BRL Pix collection details, subject to coverage.
Customer and workflow attribution
Map each issued account to the customer, merchant, legal entity, or treasury workflow represented in your own system of record.
Overview
What is a virtual account?
A virtual account provides reusable fiat collection details assigned to a customer, merchant, entity, or operating workflow so inbound transfers can be attributed. Radom connects enabled virtual accounts to reconciliation and supported crypto settlement. Public documentation describes enabled USD account and routing details, EUR IBAN and SEPA details, MXN CLABE details, and BRL Pix details. The account type, region, settlement asset, destination network, and operating model depend on onboarding and the capabilities enabled for your organisation.
Who it is for
Who this is for—and when it is not the right route
Good fit
Platforms with repeat collections
Assign inbound bank details to a customer, merchant entity, or operational workflow so transfers can be attributed without a shared-reference guessing game.
Crypto and fintech treasury teams
Connect supported fiat collection to enabled crypto balances while retaining the account, currency, settlement asset, and network in the operating record.
Finance and reconciliation teams
Maintain a durable mapping from the assigned collection account to the internal customer or ledger entity that owns the resulting balance movement.
Use another route when
A checkout-led bank payment
Use Open Banking when the payer should choose a bank and initiate a transfer for a specific order inside a checkout journey.
Direct on-chain collection
Use dedicated crypto deposit addresses when the sender already holds a supported digital asset and the collection should start on-chain.
Universal account coverage
Do not design around every account type, country, currency, settlement asset, or network being available. Coverage is specific to your organisation and route.
Capabilities
A connected operating workflow
Named inbound collection
Use enabled virtual account details for repeat or operationally structured fiat deposits rather than treating every inbound transfer as an anonymous shared-account event.
Multiple account formats
Public documentation describes USD account and routing details, EUR IBAN and SEPA details, MXN CLABE details, and BRL Pix collection details, subject to coverage.
Customer and workflow attribution
Map each issued account to the customer, merchant, legal entity, or treasury workflow represented in your own system of record.
Supported crypto settlement
Connect eligible fiat deposits to an enabled crypto balance, with the settlement asset and destination network confirmed before launch.
Webhook-led operations
Use Radom event delivery or related operational tooling to drive deposit processing, reconciliation, notifications, and exception queues.
Connected treasury routes
Where enabled, use conversion and payout workflows after collection rather than moving funds through an unrelated, difficult-to-reconcile stack.
Implementation
From requirements to reconciled operation
- 01
Define the attribution model
Choose whether each virtual account represents a customer, merchant, business entity, treasury purpose, or another durable ledger dimension.
Control: Do not issue accounts before deciding which internal record owns every resulting deposit and exception.
- 02
Confirm the enabled route
Agree the account type, currency, region, expected payer profile, settlement asset, destination network, and intended downstream use with Radom.
Control: Treat public coverage as a product description, not organisation-specific approval or availability.
- 03
Store the account mapping
Persist the Radom account identifier and supplied bank details against the correct internal entity before exposing them to a payer.
Control: Restrict changes to account ownership and settlement destinations through appropriate permissions and review.
- 04
Present precise payment instructions
Show the enabled account details, supported currency, beneficiary information, and any payer instructions exactly as configured.
Control: Prevent customers from substituting unsupported currencies, account fields, or payment methods.
- 05
Process inbound activity
Receive the relevant operational event, match the account to your internal entity, and keep processing pending until the deposit reaches the final state used by your workflow.
Control: Make event handling idempotent and route unmatched, duplicated, delayed, or returned transfers to an exception queue.
- 06
Reconcile settlement
Record the source account, fiat amount and currency, Radom identifiers, settlement asset and network, timestamps, fees when supplied, and resulting balance movement.
Control: Reconcile source and destination legs independently so a collection is not mistaken for completed downstream treasury movement.
Decision guide
Choose the route by operating requirement
| Route | Use when | Plan for |
|---|---|---|
| Virtual accounts | A customer, merchant, or treasury workflow needs repeatable bank collection details and durable inbound attribution. | Account type, region, currency, payer instructions, settlement asset, and destination network are configuration-specific. |
| Open Banking checkout | A payer should choose a bank and initiate a transfer as part of a particular checkout or funding session. | The journey is asynchronous; a redirect or bank authorisation is not final proof of payment. |
| Crypto deposit address | The sender already holds a supported digital asset and the inbound flow should be attributed on-chain. | Network selection, deposit minimums, confirmation state, and address ownership need explicit controls. |
| Payouts | The operating need is to disburse an existing balance rather than collect an inbound bank transfer. | Beneficiary data, funding balance, corridor, destination type, and permissions govern the payout route. |
Operations
Reconciliation and controls
Durable account ownership
Keep one authoritative mapping between the Radom virtual account, the internal customer or entity, and the ledger account that receives the collection.
Separate collection from settlement
Record the inbound fiat event and the resulting crypto balance movement as linked but distinct operational legs.
Idempotent event processing
Deduplicate webhook messages, record state transitions, and make ledger posting and customer notification safe to retry.
Exception ownership
Assign teams and response rules for unmatched transfers, unsupported currencies, delayed settlement, returns, duplicates, and account-detail changes.
Risks and limitations
Know the boundaries before launch
Coverage is organisation-specific
Supported account types and corridors depend on region, onboarding, enabled capabilities, and the exact operating model.
Settlement is not identical across currencies
Public documentation describes different settlement assets and network choices by account type. Confirm the production route rather than generalising one setup.
An account number is not reconciliation
The operational value comes from a reliable ownership map, event processing, ledger posting, and exception process around the account details.
This is not legal or accounting advice
Your legal, compliance, tax, and finance teams should determine how accounts, payer relationships, funds flows, and settlement are treated for the business.
Frequently asked questions
Practical answers
What is a Radom virtual account?
It is a named fiat collection account used to receive bank-led deposits into Radom while keeping attribution clearer than a shared-account model. Availability and the exact account details depend on your organisation and region.
Which virtual account types does Radom describe publicly?
Radom's public documentation describes enabled USD accounts with account and routing details, EUR accounts with IBAN and SEPA details, MXN accounts with CLABE details, and BRL accounts with Pix details. Confirm the account types enabled for your organisation.
How do virtual account deposits settle?
Public documentation says virtual account deposits generally settle into supported crypto balances. The settlement asset and destination network differ by account type and configuration and must be confirmed before launch.
Are virtual accounts available to every business and country?
No universal availability is promised. Region, onboarding status, organisation permissions, required account type, currency, settlement model, and intended use all affect coverage.
When should we use Open Banking instead?
Use Open Banking when a payer should initiate a bank transfer for a particular checkout or funding session. Use a virtual account when the business needs reusable collection details and repeat attribution.
How should virtual account deposits be reconciled?
Store the virtual account and Radom identifiers against your internal customer or ledger entity, process events idempotently, and record the fiat source leg separately from the resulting settlement balance movement.
Documentation
Product and implementation references
Reference material for the product capabilities and implementation notes on this page. Confirm the exact route and availability for your organisation before launch.
Account types, use cases, settlement models, networks, and rollout.
Primary public documentation for the account coverage and settlement behaviour described on this page.Event verification, retry behaviour, and idempotent processing.
Primary public documentation for event-driven reconciliation and operational handling.Supported pairs, minimum amounts, quotes, and quote acceptance.
Primary public documentation for optional downstream conversion after collection.Plan the route
