I read the eight pages currently ranking for "crypto to fiat payments infrastructure". Together they run to roughly 25,000 words. Not one of them tells you what happens when the bank sends the money back.
That is the shape of this category. Six of the eight are published by companies selling an off-ramp, and the two most promotional name no competitors at all. The comparison tables are feature checkboxes. The failure modes, which are the only part of an integration that actually costs you money, are missing everywhere.
So this guide goes at the parts that break: quotes that are not quotes, payouts that return days later, a Travel Rule field that will freeze a customer's balance, and the reconciliation problem nobody writes down.
What Is Crypto-to-Fiat Payment Infrastructure?
Four moving parts, and only one of them is software.
Custody holds the crypto between the customer sending it and the conversion executing. Liquidity is whoever takes the other side of your sell order. The fiat payout rail is a real bank connection to Faster Payments, SEPA, ACH or a local scheme. Compliance is registration, the Travel Rule, and sanctions screening on both legs.When you integrate an off-ramp you are not buying an API. You are renting someone's banking relationship and their liquidity book. The API is the thin part, and it is the part everyone writes documentation about. The thick part is whether their bank will still be there in eighteen months and what their treasury desk does to your rate at 4pm on a Friday.
The EU wrote that separation into law. Under MiCA Article 70(4), a crypto-asset service provider may provide payment services related to its crypto-asset service only where it, or the third party doing it, is authorised under PSD2. A CASP licence does not carry a payments permission with it. The SEPA credit at the end of an off-ramp is a separate authorisation, held either by your provider or by someone standing behind them. Article 70(3) then requires client funds other than e-money tokens to be placed with a credit institution or a central bank by the end of the business day following receipt. Two provisions, and between them they describe the real architecture: a conversion business bolted to a payments business bolted to a bank.
That is also why the category keeps consolidating. Mastercard paying $1.8bn for BVNK, which I wrote about in March, was not an acquisition of clever endpoints.
How a Crypto-to-Fiat Off-Ramp Actually Settles
Abstract flow diagrams are useless here, so take a real one. Rail's published build guide runs on Layer2 Financial's API and documents the whole path:
| Step | Call | Notable fields |
|---|---|---|
| 1 | POST /api/v1/accounts/deposits | customer_id, account_to_open |
| 2 | POST /api/v1/deposits | deposit_type: "PUSH", returns deposit_instructions with address, blockchain, network |
| 3 | POST /api/v1/exchanges/market | source_account_id, destination_account_id, amount, action: "FIX_SOURCE" |
| 4 | POST /api/v1/exchanges/{id}/accept | executes the conversion |
| 5 | POST /api/v1/counterparties | counterparty_type: "FIAT_US", supported_rails: ["ACH"], account_number, routing_number |
| 6 | POST /api/v1/withdrawals then /accept | withdrawal_rail, destination_counterparty_id, memo |
Operation status moves through REQUESTED, ACCEPTED, PENDING, POSTED. Transactions are typed TRANSFER_IN or TRADE.
Both the exchange and the withdrawal are create-then-accept. That is six calls and four state machines to move one customer's USDC into one bank account, and each transition is somewhere a payout can be stranded in a state your reconciliation job has never seen.
Why Your Off-Ramp Quote Is Not a Quote
The most useful sentence in any off-ramp documentation I have read is in Rail's guide, in plain sight:
Given its a market order, the above is NOT a quote. It is merely the latest market price. When you accept the exchange, it will be sent to the liquidity partners to execute at the current market price, which may be different.
The create-then-accept pattern looks exactly like quote-then-confirm. Every engineer who has integrated a card processor or an FX API will read step 3 as a rate lock. It is not. You get price discovery and no price guarantee, and the amount your customer receives is decided after you have already told them a number.
My position, and it is a minority one: the market-order model is the honest design, and the locked quote is the one to interrogate. A 30-second rate lock is not free. The provider is writing you a short-dated option on the pair and pricing it into the spread, whether or not the fee schedule says so. On a liquid stablecoin pair you are paying real basis points to insure against thirty seconds of a move that is usually nothing. The two ranking pages that mention rate locks at all quote 30 to 120 seconds and treat the number as a feature. It is a cost.The practical consequence is the action parameter. FIX_SOURCE fixes the crypto you send, which means the fiat out is a variable. If you owe a customer exactly £500, that is the wrong way round. Fix the destination amount where the provider supports it, and if they do not, quote your customer a range or absorb the difference yourself.
What Happens When a Crypto-to-Fiat Payout Fails
Zero of the eight ranking pages cover this. It is the most expensive thing to discover in production.
For an ACH credit payout, the returns you will actually see are R02 (account closed), R03 (no account) and R04 (invalid account number), and the receiving bank has two banking days from the settlement date to send them back.
Worth separating from the number everyone repeats: the 60-calendar-day return window belongs to unauthorised consumer debits (R05, R07, R10) and requires a Written Statement of Unauthorized Debit. It does not apply to your outbound credit. This matters because it bounds how long a payout must stay reconcilable. Two banking days, not two months. Teams routinely build for the wrong one and hold reconciliation state for eight weeks they never needed.
Nacha's enforcement thresholds are worth knowing even as a credit-only sender, because they govern the provider you sit behind: unauthorised returns must stay under 0.5% and administrative returns under 3%, measured over a rolling 60 days.
In the UK the equivalent trap is Confirmation of Payee. It is a name check on the beneficiary account, mandated by the Payment Systems Regulator's Specific Direction 17 for Faster Payments and CHAPS, and over 320 PSPs now run it. It is advisory: nothing in SD17 obliges a bank to block on a no-match, so whether a mismatch stops your payout is your sending bank's policy, and you have to ask. And SD17 expressly exempts bulk payments and unattended payment routing, which describes most API-driven payout flows, so you may get no check at all and a mistyped account number is simply paid. If your KYC record holds a legal name and the customer's account is in a shortened or married name, one of those two outcomes recurs at a low rate forever. Know which.
The question no documentation answers, and the one to put in writing before you sign: when a payout is returned, does the money come back as fiat or is it re-converted to crypto? If it is re-converted, you have done a round trip at two different rates and somebody is short. Ask which of you it is.
Which Travel Rule Fields Are Required in the UK
Every ranking page names the Travel Rule. None lists the fields. They are in Part 7A of the Money Laundering Regulations 2017.
Regulation 64C(5), required on every transfer between cryptoasset businesses:
- name of the originator and the beneficiary
- registered or trading names where either is a firm
- account numbers, or a unique transaction identifier
- for firms: a customer identification number or registered office address
- for individuals: a customer identification number, address, identity document number, or date and place of birth
Then regulation 64G(1), covering unhosted wallets, which is the one that will show up as a support ticket. You may request the missing information from your customer, and if you do not receive it you "must not make the cryptoasset available to the beneficiary".
That is not an error condition. That is a held balance: money that exists, is owed to a named customer, and cannot move. If your ledger has no state for it, your support team will invent one in a spreadsheet. Model it explicitly, with an audit trail of what you asked for and when.
Custodial vs Non-Custodial Off-Ramp: The Trade-off
Banxa documents both models, which makes it a useful comparison against Rail's account-based design.
| Non-custodial (Banxa) | Custodial (Banxa) | Account-based (Rail) | |
|---|---|---|---|
| Who moves the crypto | Customer, via QR or manual send | Your platform, on their behalf | Customer deposits to an account you opened for them |
| Deposit certainty | Low. Underpayment and wrong-chain sends are yours to handle | High. You control chain and fee | High, but you carry per-customer account lifecycle |
| Regulatory surface | Smallest | You are holding customer crypto | Depends on account structure |
| Fits | Consumer wallets | Exchanges, custodial products | Platforms with a customer ledger already |
The trade-off in one line: non-custodial gives you a smaller permissions footprint and a worse failure surface. You cannot make a customer send the right amount on the right chain, and every one who does not becomes manual work.
Custodial removes that class of failure and replaces it with an obligation. Holding customer assets changes what permissions you need and what you must do with client money, and the UK safeguarding regime tightened under CASS 15. Do not pick custodial for the engineering convenience without pricing the compliance work.
Banxa's documented payout rails are PayID for AUD, SEPA for EUR and PIX for BRL. Rail's worked example is FIAT_US over ACH. Neither is GBP into a UK bank account out of the box. If Faster Payments is what you need, ask specifically and get the answer before the pilot, not during it.
Reconciling On-Chain Transactions to Bank Statements
The trap is assuming one chain transaction maps to one bank statement line. It does not, as soon as your provider nets or batches settlements. Three customer payouts can arrive as one credit with a reference field truncated to something unhelpful.
What works: treat the provider's own identifiers as the reconciliation key at every stage, deposit id to exchange id to withdrawal id, and treat the chain txid as a leaf. The txid proves the customer sent what they claim. It is evidence, not a join key.
On idempotency, the finding is the absence. Rail's build guide walks through six calls without mentioning an idempotency key, and Banxa's off-ramp overview never raises it. If your provider does not offer one on the payout endpoint, your retry policy is the control. The two-phase pattern helps more than it first appears: creating a withdrawal is safe to retry, accepting one is not. Single-flight the accept, persist the id before you call it, and never retry an accept on a timeout without reading state back first.
I covered the neighbouring problems, confirmation counts and webhook durability, in the stablecoin tooling guide.
What This Means for Payment Engineers
Six things to do before you sign anything:
1. Get the return path in writing. Fiat or re-converted, and who absorbs the round-trip FX. 2. Ask for the idempotency story on the payout endpoint. If there is none, single-flight your accept calls and persist ids before you make them. 3. Model a held state for Travel Rule shortfalls, triggered at £800, with the request audit trail attached. 4. Fix the destination amount, not the source, wherever you owe an exact figure. 5. Bound ACH credit reconciliation at two banking days, and stop holding state for the 60-day debit window that does not apply to you. 6. Confirm the GBP rail explicitly. Faster Payments support is not implied by "we support fiat payouts".
Key Takeaways
- Six of the eight ranking pages are written by off-ramp sellers; the failure modes are absent from all eight.
- A create-then-accept exchange is usually a market order, not a rate lock. Read the docs for the word "quote" and check whether it means one.
- UK Travel Rule enhanced fields trigger at £800, and an unhosted-wallet shortfall legally requires you to hold the asset rather than release it.
- Confirmation of Payee is advisory, and API payouts are often exempt from it entirely. Find out which applies to yours.
- Reconcile on provider identifiers. The chain txid is evidence, not a key.