Fiat-to-stablecoin settlement
Collect fiat, reconcile the source, and settle through supported stablecoin routes
Treat bank collection, payment confirmation, conversion, and stablecoin settlement as connected but independently controlled legs.
Operating model
- 01Choose the routeMatch the product to the payment intent.
- 02Confirm final stateKeep initiated and completed states separate.
- 03ReconcilePreserve internal and Radom references.
- 04Operate exceptionsMake retries, returns, and failures actionable.
Overview
How does fiat-to-stablecoin settlement work?
An enabled fiat-to-stablecoin workflow starts with a bank-led collection such as Open Banking checkout or a virtual account, waits for the appropriate final payment state, attributes the source funds, and connects them to a supported crypto balance or quoted conversion route. The exact fiat currencies, markets, settlement assets, networks, timing, and operating model depend on onboarding and the capabilities enabled for the organisation.
Before implementation
Define the operating requirement
A defined collection route
Choose a checkout-led bank payment for a specific order or a virtual account for repeat attributable transfers.
A finality policy
Specify the bank or platform state that releases the fiat collection into downstream settlement processing.
A settlement instruction
Define the supported destination asset, network, balance, ownership, and permitted downstream use.
A two-leg reconciliation model
Reconcile the fiat source and stablecoin destination independently, including conversion and fee records when present.
Operating model
From requirement to reconciled operation
- 01
Confirm market and configuration
Validate the collection market, source currency, bank route, customer model, settlement asset, network, and organisation permissions.
Control: Published examples are not a commitment that every currency or asset combination is available.
- 02
Create attributable collection
Attach your customer, invoice, order, or treasury reference to the Open Banking checkout or virtual account record.
Control: Prevent unsupported currencies and account purposes from entering the flow.
- 03
Wait for confirmation
Use final checkout or deposit events to move the source leg from pending to confirmed.
Control: Do not settle or fulfil from a browser redirect, bank authorisation, or unconfirmed transfer.
- 04
Post settlement and reconcile
Record source amount, destination amount, asset, network, quote or transaction reference, fees when supplied, and timestamps.
Control: Escalate unmatched, delayed, rejected, returned, or materially different settlement outcomes.
Product routing
Choose the product by the job it needs to do
| Product route | Use when | Plan for |
|---|---|---|
| Open Banking | The customer should initiate a bank payment inside a specific checkout or funding journey. | Radom documents EUR and GBP use cases; actual bank, rail, and market coverage is configuration-specific. |
| Virtual accounts | Customers or treasury entities need reusable collection details for repeat bank transfers. | Public documentation describes enabled USD, EUR, MXN, and BRL account formats, subject to coverage and onboarding. |
| Crypto conversion | A confirmed balance needs a quoted move into another supported asset or network route. | Use the current pair catalogue, minimum, and quote response rather than publishing a permanent pair matrix. |
| Stablecoin settlement | The full collection, balance, conversion, payout, and controls model needs to be designed together. | Stablecoin settlement is an operational payment leg, not a promise of yield or investment return. |
Operations
Controls that make the workflow durable
Store source and destination amounts
Keep both fiat and stablecoin quantities, identifiers, timestamps, fees when supplied, and conversion context.
Name the settlement owner
Record which customer, merchant, programme, or treasury ledger owns the resulting balance movement.
Separate pending from available
Do not make downstream balances spendable until the source and required settlement checks have completed.
Reconcile residuals
Define how rounding, minimums, fees, rejected quotes, returns, and small residual balances are handled.
Practical answers
Frequently asked questions
Can Radom collect EUR or GBP through Open Banking?
Radom's public product and implementation material describes enabled EUR and GBP Open Banking flows. Availability varies by bank, rail, market, onboarding, and organisation configuration, so it must be confirmed before launch.
Which virtual-account currencies are documented?
Radom's public virtual-account material describes enabled USD, EUR, MXN, and BRL account formats. That is not a guarantee that every format, region, or settlement route is available to every organisation.
Which stablecoins and networks are supported?
Use the currently enabled payment methods, balance configuration, and conversion routes for the organisation. Radom should not publish a static universal promise because asset and network support can vary by product and configuration.
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.
- Open Banking guidePublic implementation source for enabled bank-led payment flows.
- Virtual accounts guidePublic source for documented account formats and settlement models.
- Conversion API guidePublic source for dynamic pair, minimum, quote, and acceptance handling.
Plan the workflow
