Crypto Payment Rails: How Off-Ramps Work - Inside the 'Cash Out to Bank' Pipeline

Part 2 of the Crypto Payment Rails series. Read Part 1: How Crypto On-Ramps Work for the inbound side.

TL;DR - A crypto off-ramp is a five-layer system: on-chain receipt, custody, FX and liquidity, compliance, and fiat payout. The user only sees a button labeled "Cash Out to Bank." Behind that button, you need to detect the deposit on chain, decide when it is final, sweep the funds into treasury without leaking keys, sell the asset for fiat, screen the transaction against sanctions and Travel Rule rules, and push fiat through the right local rail (ACH, SEPA, RTP, PIX, SPEI, UPI, or wire). Custody is the layer that decides whether all of this is profitable or a slow-motion exit fraud incident. This post walks through every layer, the four ways an off-ramp dies, and why most teams underestimate the receiving side until a banking partner freezes their account.

Building an off-ramp? Talk to Fystack - we provide the MPC custody and indexer layer so you can ship in weeks, not quarters.

What is a crypto off-ramp?

A crypto off-ramp is the path that converts on-chain value back into fiat sitting in a user's bank account. Stablecoin in, USD out. ETH in, EUR out. USDC on Solana in, BRL via PIX out.

It is the mirror image of an on-ramp, but the failure surface is completely different. On-ramps fight chargebacks, card fraud, and float risk. Off-ramps fight tainted deposits, chain reorgs, frozen banking partners, and Travel Rule compliance. The skill set required to operate one well is closer to a fintech AML team running a remittance corridor than a crypto exchange running a trading book.

If on-ramps are how money enters the crypto economy, off-ramps are how it leaves. And whoever controls the exit controls the gravity of the entire system.

The off-ramp gold rush in numbers

The numbers most people quote about stablecoins are misleading. Total on-chain stablecoin volume in 2025 was around $33 trillion, but the vast majority of that is internal crypto trading and treasury rebalancing - dollars moving between exchanges, market makers, and DeFi protocols. The number that matters for off-ramp builders is the slice that actually leaves the chain.

Real-world stablecoin payment volume roughly doubled in 2025 to about $400 billion, with around 60% B2B. Forecasts point toward $1 trillion in monthly stablecoin flows by end of 2026. Visa, Stripe, Mastercard, and Circle have all shipped stablecoin settlement products in the last 18 months. Every neobank with cross-border ambitions is now evaluating a stablecoin off-ramp.

The opportunity is concrete: every dollar of stablecoin volume that wants to become a salary, an invoice payment, or a vendor payout has to pass through an off-ramp. Today, most of that value flows through a tiny number of regulated providers, and those providers are not infrastructure-friendly to the next generation of fintechs.

A new crop of off-ramps is being built right now. Most of them will fail not because they cannot acquire users, but because they cannot keep their banking partners.

What happens when a user clicks "Cash Out to Bank"

From the user's perspective, the off-ramp is a single button. Behind it, five layers run in sequence. Skipping or under-engineering any one of them is how you end up with stuck withdrawals, frozen accounts, or worse.

Layer 1: On-chain receipt

The off-ramp starts the moment the user broadcasts a transaction to your deposit address. You need three things working in concert:

• Indexers that watch every chain you support and surface incoming transactions to your backend within seconds. A naive eth_getLogs poll loop falls over above ~50 deposits per minute. Production systems use a fan-out indexer like our open source multichain-indexer or roll their own with reorg-aware block followers.
• Confirmation policy per chain and per asset. Crediting too early loses you money on reorgs. Crediting too late loses you customers. The right depth depends on the chain and the amount.
• Dust and spoof filtering. Attackers send 0.000001 USDC from sanctioned wallets to your hot deposit addresses to taint your address graph. Treat unsolicited dust as a known attack pattern, not a free deposit.

Confirmation thresholds engineers actually use in production:

The mistake most teams make is picking one number per chain and stopping there. Mature off-ramps tier confirmations by amount and risk score. A $50 USDT withdrawal from a wallet with a year of history can clear at one confirmation. A $250,000 withdrawal from a brand-new wallet sits until full finality.

Layer 2: Custody

Once the deposit is confirmed, the funds are yours to move. This is where the off-ramp diverges sharply from the on-ramp.

On the on-ramp side, custody is mostly about pushing crypto out. On the off-ramp side, custody is about receiving, sweeping, and rebalancing. You need to:

1. Receive deposits into per-user (or per-invoice) addresses without exposing the master key.
2. Sweep accumulated balances from those deposit addresses into a treasury wallet on a schedule.
3. Maintain a hot working balance for FX and immediate operations.
4. Move excess balance into warm and cold storage.
5. Sign every sweep and rebalance without a human approving each transaction.

This is the part where teams either commit to an MPC or HSM-backed architecture or quietly run a single-key hot wallet that holds far more value than they would ever admit on a sales call. We will come back to this.

Layer 3: FX and liquidity

The crypto needs to become fiat. There are three dominant patterns.

Inventory-based. You hold fiat reserves in your operating bank account and crypto reserves in your treasury. When a user withdraws, you debit the fiat account and the crypto enters your treasury at a known rate. You then rebalance over time on the open market. This minimizes user-facing latency but requires real working capital and exposes you to inventory risk.

Pass-through. You pipe the crypto straight to a market maker or OTC desk that immediately quotes a fiat amount. You take their quote, the user gets the fiat, and the crypto leaves your books. Lower capital, more counterparty exposure, and you are exposed to the desk's quote latency.

Hybrid. You hold inventory inside a band (say, +/- $500K of expected daily flow) and route anything outside the band to a desk. This is what production off-ramps look like once they cross meaningful volume.

Whichever model you pick, slippage and quote management become a real engineering problem. A 30 basis point miss on a million-dollar daily volume is $30,000 a month in margin you do not get to keep.

Layer 4: Compliance

This is the layer that quietly kills off-ramps. The on-ramp side has card networks doing some of the AML work for you. On the off-ramp side, you are the one accountable for what enters your system, and your banking partner will offboard you if you let the wrong dollars out the other end.

Production off-ramps run every deposit through:

• Chain analysis screening (Chainalysis, TRM, Elliptic) - is the source address tagged sanctioned, mixer-adjacent, stolen, or ransomware?
• Sanctions and PEP screening on the receiving fiat account.
• Travel Rule data exchange for transfers above the local threshold ($1,000 in many jurisdictions). The originating VASP must transmit beneficiary information; if your counterparty is non-compliant, you cannot legally receive their funds.
• Behavioral velocity checks - dormant accounts suddenly active, abnormal volume jumps, structuring across multiple wallets.

The hardest part is reconciliation. The on-chain identity (a wallet address) and the off-chain identity (a KYC'd user) have to be linked. If a user's wallet receives a deposit from a flagged source, you have to decide in real time whether to refund, freeze, or escalate. That decision needs evidence and an audit trail your bank can read in plain English.

EU TFR and the FATF Travel Rule turned this from a nice-to-have into a precondition for keeping a bank account in 2025-2026. Every serious banking partner asks for your Travel Rule provider, your transaction monitoring vendor, and your offboarding policy before they sign.

Layer 5: Fiat payout

Once the funds clear compliance, you push fiat to the user. The rail you use determines the user experience and your unit economics.

A user-facing detail that matters: instant rails are irrevocable. If your compliance layer flags a payout after the fiat has cleared, you cannot claw it back the way you can with ACH. That makes Layer 4 binding before Layer 5 even more important when you support RTP, FedNow, SEPA Instant, PIX, SPEI, and UPI.

The competitive surface among off-ramps in 2026 is which local rails they support and how clean their settlement is. A Brazilian off-ramp without PIX is dead on arrival. A US neobank without RTP is leaving table stakes on the table. A European fintech without SEPA Instant is, charitably, a 2018 product.

Why custody is the silent failure mode of every off-ramp

There are four ways an off-ramp dies. Three of them are custody problems.

The pattern in all four: the receiving custody architecture decides whether the off-ramp survives the failure. Tainted deposits are caught only if your indexer hands every incoming transaction to a screening pipeline before the funds are swept. Hot wallet drains only happen if the signing key exists in one place. Reorg credits only happen if your confirmation policy is naive. Travel Rule mismatches only matter if you cannot prove which originating VASP belongs to which deposit.

Most off-ramp teams know this in theory. In practice, they ship version one with a single-key hot wallet, a polling indexer, and a confirmation threshold copied from a Reddit thread. Then they spend the next 18 months rebuilding the custody layer in production while their banking partner gets steadily more nervous.

How MPC custody automates incoming flow at scale

The custody pattern that works for off-ramps in 2026 is multi-party computation (MPC) signing combined with a programmatic sweep policy. The idea is simple: the private key never exists in one place. Instead, the key is split into shares held by independent signing nodes, and a transaction is signed only when a threshold of those nodes approves it.

For an off-ramp, this matters in three ways:

No single point of compromise. A leaked operator laptop or a misconfigured server does not drain the treasury. An attacker has to compromise a threshold of independent nodes simultaneously, which is a different and much harder problem.

Programmatic policies, not human approvals. A sweep happens because rules say so: deposit confirmed, source clean, amount under cap, destination is the canonical treasury wallet. The policy is code, not a human in Slack approving every transaction.

Per-user or per-invoice deposit addresses without per-user keys. A single MPC key can derive an unlimited number of receiving addresses. You do not need to provision a key per user, and you do not need to expose the master.

The auto-sign payout flow looks like this:

User clicks "Cash Out"
 |
 v
Backend issues quote, locks rate, creates withdrawal record
 |
 v
Compliance pre-check (sanctions, velocity, Travel Rule data ready)
 |
 v
Custody policy engine validates: amount cap, destination, daily limit
 |
 v
MPC nodes (n-of-m threshold) co-sign the on-chain sweep or the fiat payout instruction
 |
 v
Indexer confirms on-chain settlement; payout rail acknowledges fiat
 |
 v
Withdrawal marked complete, ledger reconciled

Every step is observable, every signature is bound to a policy, every policy is auditable. This is what the custody section of a banking partner due-diligence questionnaire wants to see.

If you are building an off-ramp, the receiving and sweep flow is exactly what Fystack's MPC engine, mpcium, is designed for. Open source, self-hostable, supports the chains an off-ramp actually needs. Book a 30-minute architecture review if you want to walk through the integration.

Build vs buy: the real economics of crypto off-ramp custody

A non-trivial fraction of off-ramp founders we talk to are quietly building their own custody. Six months in, they have an MVP. Twelve months in, they realize the MVP does not pass a SOC 2 audit. Eighteen months in, they have rebuilt twice and lost their first banking partner over a hot wallet incident.

The honest version: if you are a fintech CTO weighing whether to build custody for an off-ramp, the only reason to build is regulatory or sovereignty constraint. Every other reason is sunk-cost optimism. The economics on the off-ramp side are tighter than on-ramps because your margin is thinner (FX spread, not card processing markup), and the time you spend rebuilding custody is time your competitors spend acquiring banking partners.

What to look for in modern custody infrastructure

If you are evaluating custody for an off-ramp, the questionnaire you should run a vendor through:

• Threshold signing, not just multisig. Multisig is on-chain and chain-specific. MPC threshold signatures are off-chain and work uniformly across every chain. This matters because off-ramps support a long tail of chains.
• Per-user / per-invoice deposit addresses without per-user keys. Address derivation must be cheap and deterministic.
• Indexer integration. Custody is useless without knowing what landed in which address. Look for vendors that ship the indexer alongside the custody, or test their integration with whatever indexer you already run.
• Programmatic sweep and rebalance policies. Time-based, balance-based, risk-score-based.
• Auditability. Every signature bound to a policy, every policy versioned, every action exported to your SIEM.
• Open source option. Closed-source custody is a non-starter for any team that wants the option to self-host or audit. The vendors who refuse to show you the code are the vendors you want to avoid.
• Banking-partner readiness. Vendor docs, SOC 2, key ceremony documentation, incident response playbook. This is what your banking partner's risk team will read before they sign.

You should expect to ship the off-ramp custody layer in weeks, not months. If a vendor's onboarding timeline is longer than that, they are selling you a Fireblocks-class product, not infrastructure.

SaaS vs self-hosted custody: which makes sense for your stack

The same dimensions that apply to on-ramps apply here, but the off-ramp side has one additional consideration: data sovereignty for compliance evidence.

The pragmatic split we see in production: small-to-mid teams ship on Fystack Cloud, hit product-market fit, then migrate to self-hosted mpcium once they cross volumes where data sovereignty becomes a board-level requirement. Both products use the same protocol, so the migration is straightforward.

The window is closing

Stablecoin off-ramps are at the same stage on-ramps were in 2022: a fragmented landscape, a handful of well-funded incumbents, and a long tail of fintechs starting to ship. The difference is that the regulatory and banking environment for off-ramps in 2026 is far stricter than the on-ramp environment was in 2022. EU TFR, FATF Travel Rule enforcement, US OCC interpretive guidance, and the willingness of banking partners to offboard at the first sign of weak custody all mean that the off-ramps that win the next two years will be the ones that ship custody and compliance correctly the first time.

The teams shipping in late 2026 and 2027 will not be able to copy the 2022 playbook. They will need MPC custody on day one, programmatic policies wired into their compliance stack, and a banking partner story that does not rely on a single relationship.

Talk to Fystack

If you are building a crypto off-ramp, payout product, or stablecoin payments platform, we provide the custody and indexer layer so you can focus on the rest:

• Fystack Cloud - managed MPC custody SaaS, ready in days
• mpcium - open source MPC wallet engine you can self-host in 10 minutes
• multichain-indexer - production indexer for 12+ chains, deposit detection ready
• Fystack Self-Hosted - supported on-premise deployment for teams with sovereignty requirements

Book an architecture review - 30 minutes, technical, no slides. We will walk through your off-ramp stack and tell you honestly which parts you should build and which parts you should not.

Not ready yet? Join our Telegram for product updates and architecture discussions, or star mpcium on GitHub.

Frequently asked questions