Crypto on/off-ramp
Crypto on/off-ramp infrastructure for controlled fiat and crypto flows
Design the route as a controlled money-movement workflow: confirm the corridor, collect or fund, track the asynchronous state, convert only through supported pairs, and reconcile the final destination.
Bank-to-crypto funding
Use enabled Open Banking or onramp configurations to start from bank rails and settle into a supported crypto balance.
SEPA funding instructions
Radom's current public standalone onramp API creates SEPA funding instructions for the enabled flow documented publicly.
Asynchronous onramp events
Use the onramp webhook and related status surfaces to distinguish processing from a completed state in your customer and operations systems.
Overview
What are crypto on-ramps and off-ramps?
A crypto on-ramp moves value from fiat or bank rails into crypto; an off-ramp moves crypto towards fiat through an enabled payout route. Radom connects enabled bank-to-crypto funding with supported conversion, balance, webhook, and payout workflows. The public standalone onramp API currently creates SEPA funding instructions; a crypto-to-fiat route is assembled from the conversion and payout capabilities enabled for your organisation, not a promise of one universal off-ramp endpoint. Markets, currencies, assets, networks, destinations, timing, and permissions remain route-specific.
Who it is for
Who this is for—and when it is not the right route
Good fit
Fintech funding journeys
Connect an enabled bank funding route to a supported crypto balance while keeping the customer or merchant state visible throughout the asynchronous flow.
Platforms and payment processors
Add selected fiat and crypto movement behind an existing product with explicit route controls, internal references, and event-driven status handling.
Treasury and settlement teams
Combine supported balance conversion and fiat or crypto payouts when the business needs to move operational funds between rails.
Use another route when
A universal one-call corridor
The public product surface is component-based. Do not assume one endpoint covers every bank-to-crypto and crypto-to-bank route.
Crypto-to-crypto conversion only
Use Crypto Convert when the requirement is a quoted conversion between supported assets and networks without a bank collection or payout leg.
Unverified instant cash-out
Rail speed, conversion acceptance, payout processing, banking cut-offs, and operational review can all affect the end-to-end timeline.
Capabilities
A connected operating workflow
Bank-to-crypto funding
Use enabled Open Banking or onramp configurations to start from bank rails and settle into a supported crypto balance.
SEPA funding instructions
Radom's current public standalone onramp API creates SEPA funding instructions for the enabled flow documented publicly.
Asynchronous onramp events
Use the onramp webhook and related status surfaces to distinguish processing from a completed state in your customer and operations systems.
Supported asset conversion
List currently supported pairs, check minimum source amounts, request a quote, and accept it before initiating conversion.
Fiat or crypto disbursement
Use enabled payout routes for the destination leg after confirming the funding balance, beneficiary data, corridor, and permissions.
End-to-end reconciliation
Link the originating customer or treasury instruction to the funding object, conversion quote, balance movement, and payout record.
Implementation
From requirements to reconciled operation
- 01
Map the direction and parties
Define whether the route starts with bank funding or an existing crypto balance, who owns each balance, and who receives the destination funds.
Control: Document the customer, merchant, beneficiary, contracting, disclosure, and support model before choosing endpoints.
- 02
Confirm route availability
Check the market, source currency, bank rail, source asset, destination asset or currency, network, payout corridor, and organisation permissions.
Control: Reject any route that has not been enabled and tested for the intended organisation and customer journey.
- 03
Choose the Radom components
Select Open Banking or the enabled funding method for inbound fiat, Convert when asset movement is required, and Payouts for the destination leg.
Control: Do not insert a conversion or payout step when it adds cost and complexity without solving the operating requirement.
- 04
Create and reference the flow
Attach your internal customer, order, treasury, or beneficiary identifier to each Radom object and retain the relationship between legs.
Control: Use server-side identifiers and permissions; do not trust a browser return or customer-supplied state as final.
- 05
Wait for dependable states
Show processing honestly while bank funding, conversion acceptance, or payout completion remains unresolved and react to the relevant events.
Control: Make handlers idempotent and separate submitted, processing, accepted, initiated, and completed states in the ledger.
- 06
Reconcile the destination
Compare source and destination amounts, currencies or assets, fees when supplied, references, timestamps, network, beneficiary, and final state.
Control: Route mismatches, timeouts, failed payouts, unsupported routes, and duplicate instructions to accountable exception queues.
Decision guide
Choose the route by operating requirement
| Route | Use when | Plan for |
|---|---|---|
| Open Banking or onramp funding | The journey begins with a bank payment and should result in an enabled crypto operating balance. | The public standalone onramp API currently creates SEPA funding instructions; other experiences and rails depend on configuration. |
| Virtual accounts | Repeat bank deposits need reusable account details and attribution by customer, merchant, or treasury workflow. | Account type, region, currency, settlement asset, and network must be confirmed before use. |
| Crypto Convert | An existing supported balance needs to move between assets or networks through a quoted conversion. | Supported pairs and minimum amounts are dynamic and should come from the API rather than a static list. |
| Payouts | An enabled balance should be disbursed to a supported fiat account or crypto destination. | Beneficiary data, corridor, funding source, approval controls, timing, and destination support govern the route. |
Operations
Reconciliation and controls
A state model for every leg
Represent funding, conversion, and payout states separately so processing in one system cannot be mistaken for completed end-to-end settlement.
One linked reference chain
Persist your instruction ID alongside the relevant Radom funding, quote, conversion, balance, payout, and event identifiers.
Idempotent event handling
Deduplicate webhook messages and make balance posting, customer notification, and fulfilment safe to retry.
Route and beneficiary validation
Allow only enabled currencies, assets, networks, account types, corridors, and verified destination details for the organisation.
Risks and limitations
Know the boundaries before launch
There is no universal ramp route
The exact combination of funding, conversion, balance, and payout capabilities varies by market, organisation, and intended use.
End-to-end timing has several parts
Bank processing, status confirmation, quote acceptance, internal controls, blockchain finality, and payout processing can all affect completion.
Conversion and payout are separate controls
A successful funding event does not prove conversion or payout completion. Reconcile each leg and its exceptions independently.
This page is not legal advice
Technology does not grant permissions or remove obligations. Assess the business model, customer journey, jurisdictions, disclosures, and responsibilities separately.
Frequently asked questions
Practical answers
What is Radom's crypto on/off-ramp infrastructure?
It is a configurable operating route that can connect enabled bank-to-crypto funding with supported balances, conversion, webhooks, and fiat or crypto payouts. Exact components and coverage depend on your organisation.
What does Radom's public standalone onramp API support?
Radom's public Open Banking documentation says the standalone onramp API currently creates SEPA funding instructions. Confirm the market, currency, settlement asset, and flow enabled for your organisation.
Does Radom offer one universal crypto-to-fiat off-ramp endpoint?
This page does not claim that. A supported crypto-to-fiat operating route can combine an enabled balance, conversion where needed, and a supported payout destination. The exact corridor and product configuration must be confirmed.
Are on/off-ramp transactions instant?
Do not assume they are. Bank rails, status confirmation, conversion, blockchain finality, payout processing, cut-off times, and operational controls can affect the full timeline.
How should an on/off-ramp flow be reconciled?
Keep one reference chain across the source instruction, funding event, conversion quote and acceptance, balance movement, payout, beneficiary, fees when supplied, and final destination state.
Which currencies, assets, networks, and countries are supported?
Coverage is route- and organisation-specific. Use current API responses and an onboarding or coverage check rather than publishing a static assumption that every currency, asset, network, or country is available.
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.
Bank-to-crypto funding, SEPA instructions, statuses, and settlement.
Primary public documentation for the enabled inbound bank and onramp behaviour described here.Processing and processed onramp event payloads.
Primary public documentation for event-driven onramp state handling.Supported pairs, minimum amounts, quotes, and acceptance.
Primary public documentation for the optional conversion leg.Funding models, destination types, corridors, and operations.
Primary public documentation for enabled fiat and crypto disbursement routes.Plan the route
