What Is an Off-Ramp Wallet? Deposit Address to Bank Account

An off-ramp wallet is a blockchain wallet address whose stablecoin balance ends up as fiat in a bank account. The address either holds the balance until an off-ramp call sends it to a registered bank account, or pays out on each deposit. The payer needs only the address and the supported network.

We covered the concept behind it in what a stablecoin off-ramp is, and the wallet itself in what a custodial wallet is.

Two designs behind the same name, and what to ask

The phrase can describe two mechanics. They share a deposit address and a bank account at the end, and they differ on who decides when the money leaves. The first question to any provider is whether the address pays out on deposit or holds a balance until you call.

The two patterns the phrase can mean. Which one a provider runs is stated in that provider's own documentation.

Lumx works the second way. Every customer gets a custodial wallet on each supported network, and the payout is an explicit off-ramp call from that wallet to a registered destination, so your application picks the amount, the destination and the quote.

Whatever the design, five items can be checked against a provider's documentation:

• Networks and stablecoins accepted, and whether the off-ramp runs on each one.

• Rails and cut-offs for the currencies you pay out in.

• Quote lock: whether you can fix the rate before the money moves, for how long, and at what cost.

• Behaviour on a wrong-network deposit, as the documentation states it.

• Screening: what is checked on the deposit before a payout is created.

How the deposit becomes a bank transfer

Four things happen, in this order, in both designs. Only the trigger differs.

1. The wallet exists. A provider creates the address, usually on a specific network, and ties it to a customer that has passed KYB (know your business, the verification of a company and its owners) or KYC (know your customer, the verification of an individual).

2. The deposit lands. Someone sends USDC or USDT to the address. This is a plain blockchain transfer, so the sender needs no account with the provider. Plain does not mean unscreened, as the screening section below explains.

3. The stablecoin is converted. The provider sells it for local currency at a market rate, or at a locked rate if the design allows one.

4. Fiat leaves on a local rail. The provider sends the money to the bank account over Pix (Brazil's instant payment system, run by the Central Bank), SPEI (Mexico's interbank transfer system, run by Banxico), ACH or another rail, and the status moves to a final state.

On Lumx, step 1 happens when the customer is created: the wallet is provisioned with the customer and enabled once the customer reaches APPROVED. Step 2 is a normal transfer to that address, and the balance reads on the customer record; there is no webhook yet for a deposit sent from an external address, so read the balance. Steps 3 and 4 start when your application calls the off-ramp with a registered destination, a source currency, an amount and a purpose code. The transaction then moves through TRANSFERRING_STABLECOIN, TRADING, TRANSFERRING_FIAT and SUCCESS, with an offramp.* webhook at each change.

Which networks and stablecoins can a wallet accept?

The network is part of the address. USDC sent on a network the wallet does not support is a different asset in the wrong place, which is why every deposit instruction should name the network next to the address.

Networks where a Lumx wallet holds USDC or USDT, and whether the off-ramp to local currency runs on each, from the Lumx docs (wallets and coverage) read on November 1, 2026.

A provider's list will differ, so read what its documentation says about a deposit on an unsupported network.

On Lumx, each wallet record carries its blockchain, its address and a blockExplorerUrl, and one wallet is marked isDefault. The off-ramp call takes an optional blockchain, and when it is omitted Lumx uses the default wallet. Stellar is only for the BRL to USDC on-ramp, so show the sender only Ethereum, Polygon, Base and Tron, with the stablecoin each one carries.

How long until the bank account is credited?

The chain is the fast part. A deposit confirms in seconds to minutes, depending on the network. The wait that matters is the last rail, and it varies by a factor of days.

Payout rails on Lumx, with cut-off and settlement as published in the Lumx docs and facts on November 1, 2026. The table lists the published rails, not every corridor. Targets, not guarantees.

Three things add time on any rail: a compliance hold, a bank holiday, and the receiving bank's internal review. A request after the cut-off or on a holiday waits for the next business day. If an address pays out on deposit, the deposit time sets the clock, so a deposit that lands late on a Friday waits for Monday on ACH. The same logic applies to USDC to a US bank account and to USDC to euros by SEPA.

On Lumx, the EUR request always sends the rail as SEPA and Lumx picks the scheme from the amount and the time. An off-ramp counts as complete when the funds leave the banking partner, and the receiving bank can still hold them for its own review. A payout your application triggers at 6:00 PM in São Paulo lands after the FEDWIRE cut-off and goes out the next business day.

What can go wrong with a deposit

Four failures are worth planning for.

• Wrong network. The sender used a chain the address does not support. Nothing arrives that the off-ramp can use, so check what the provider's documentation says before you publish deposit instructions.

• Compliance hold. The deposit, the sender's wallet or the destination triggers a review. The payout waits for a document, which Lumx calls an RFI (request for information, a compliance hold that asks for a document before a transaction clears).

• Balance too low. In the explicit design, the call asks for more than the wallet holds.

• Deposit that triggers nothing. If an address pays out on deposit, no call fired, so no error appears when a payout does not happen.

With an explicit call, a bad state is an error your application can read. With an automatic payout, it is a missing bank transfer hours later.

On Lumx, a payout larger than the wallet balance fails with an INSUFFICIENT_BALANCE error, so the application finds out in the response and not from the recipient. A transaction that monitoring flags is held until the requested document arrives. An off-ramp also needs a destination that has passed verification, and the application reads that status from the destination record rather than from webhooks alone.

Is a deposit to an off-ramp wallet anonymous?

No. A plain transfer is not an anonymous one. The deposit has a source address, and the compliance question is whose money it is. Screening of that address is covered in wallet screening for stablecoin payouts, and the proof of where the funds came from in source of funds for crypto off-ramps.

On Lumx, transaction monitoring (KYT through Chainalysis) can hold a flagged transaction as an RFI (request for information). The funds must also belong to the onboarded customer, as the nested payments rules require, so the wallet is not a collection point for third parties Lumx has not onboarded.

What stacks up in the cost

Three layers sit between the deposit and the bank account: a network fee for the transfer itself, which the sender pays on an external deposit, the conversion from stablecoin to local currency, and the fee of the payout rail. An explicit call lets you see the conversion rate before you commit, if the provider offers a locked quote.

On Lumx, the customer needs no ETH or TRX, because Lumx covers the network fee on its own legs. An off-ramp prices at execution on a floating rate, or against a locked quote that you request first and that returns an id and an expiry. A lock lasts 30s, 1m or 5m, and only the 30s lock is free. On a payout by Pix (Brazil's instant payment system) or SPEI (Mexico's interbank transfer system), Lumx deducts no fee from the amount that reaches the recipient, and only the recipient's own bank can charge them. SEPA carries a flat Lumx fee, as any rail does. Lumx's own pricing is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans.

Who decides when the money leaves

I recommend keeping the payout as an explicit decision unless the payer truly cannot do anything but send a plain transfer. A payout is the moment money becomes hard to pull back, and I would want an amount, a destination and a screened sender in front of that moment rather than a side effect of someone else's transfer. The automatic design earns its place in one case: a client or an exchange withdrawal that can only send to an address and will not follow instructions.

When an off-ramp wallet is the wrong tool

An off-ramp wallet that pays out on its own is the wrong tool when the amount has to be known before the money moves, because the rate is whatever the market gives at arrival. It is also the wrong tool when the payee changes from payment to payment, because the bank account is fixed.

Separately, one address that several third parties send to, paying one account, is nested payment activity when Lumx cannot see who owns the funds, and it needs written approval from compliance.

On Lumx, the wallet belongs to an onboarded customer and pays out to that customer's registered destinations, so it fits repeated payouts once onboarding is done.

How is it different from a virtual account, and who holds the keys?

A virtual account receives fiat and is named to a customer, while an off-ramp wallet address receives stablecoin. What a named virtual account is covers that side. On keys, a custodial provider holds them and a self-custody wallet leaves them with you, as what a custodial wallet is explains.

On Lumx, the wallet is custodial, held by BitGo with insurance and fully segregated per customer, with no omnibus.

What this looks like with Lumx

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

For this pattern, the sequence is concrete. You create the customer, and the wallets arrive with it. You register the recipient's bank account as a destination, with a holder relationship that says whose account it is: SELF for the customer's own account, or a value such as SUPPLIER or EMPLOYEE for a third party. When the destination is approved and the wallet holds a balance, you call the off-ramp with a source currency and an amount, or with the id of a locked quote, plus the purpose code. Every payout debits the wallet of an onboarded customer and goes to a destination registered under that same customer, with the account holder and the relationship disclosed.

Money can reach the wallet two ways. An on-ramp turns a local-currency deposit into stablecoin credited to the wallet, and a direct transfer from any external address funds it with no on-ramp. For the country-level picture of where a payout can land, see Lumx coverage, and for the BRL leg specifically, USDC to BRL. The wallet is the same product described on custodial wallets, and the payout side sits under global payments. If you are deciding between on- and off-ramp roles for your own product, on-ramp vs off-ramp covers the split, and how to structure institutional custodial wallets covers the account layout.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Guillaume Bolduc on Unsplash.