An on-ramp turns local currency into a stablecoin and an off-ramp turns a stablecoin back into local currency, and which one a fintech product needs is decided by where its users' money starts and where it has to end, not by which direction sounds more complete. Most products that ask for both on day one use one of them, and the other sits idle until a real flow appears.
That is the argument of this post. It compares the two directions on what each one requires from the product, what each one costs to operate, where each one fails, and what the user actually experiences. It then works through the common fintech shapes, says which direction each one needs, and closes with the recommendation and with the products that should build neither. The on-ramp explainer and the off-ramp explainer cover each direction on its own.
The two directions on one table
On-ramp and off-ramp compared on what each one asks of a fintech product.
Question | On-ramp (local currency to stablecoin) | Off-ramp (stablecoin to local currency) |
Where the money starts | A user's bank account, over a local rail | A stablecoin balance, held by the provider or in the user's own wallet |
Where it ends | A stablecoin balance, custodied or delivered to an address | A bank account, validated against its holder's tax ID |
What the product must collect from the user | Enough to verify the payer and issue a deposit address or account | Enough to verify the recipient and register a destination |
The step that decides timing | Identifying the deposit, then compliance | Compliance, then the payout rail's hours |
Where it usually fails | Third-party deposits, amount mismatches, expired quotes, unallocated deposits | Name and tax-ID mismatches, closed accounts, compliance holds, wrong-network deposits on the way in |
What the user sees | A transfer leaves and a dollar balance appears | A dollar balance shrinks and local currency lands |
The finance question | Whose deposit is this | Whose account is this, and does the name match |
Where the cost sits | FX spread on the conversion, sometimes a deposit fee | FX spread on the conversion, plus the payout rail's fee and the network fee on the way in |
The rows that matter most are the fourth and the fifth. Each direction has its own failure family, and a product that builds both inherits both families whether or not it has traffic in both.
What an on-ramp asks of the product
A product with an on-ramp has users who hold local currency and want a dollar balance: a savings app in Brazil offering a dollar account, a treasury tool converting reais at month end, a platform that lets Mexican freelancers keep earnings in dollars. The user pays in over Pix (Brazil's instant payment system, run by the Central Bank) or SPEI (Mexico's interbank transfer system, run by Banxico), and USDC or USDT appears.
The product's job is to make the deposit identifiable. A named virtual account per user does that by construction, because the credit lands in an account that belongs to the user, and a standing rule can convert it on arrival. The product's second job is to set expectations about who may pay: a deposit from a spouse's account or the family business will be returned, because the provider must know the payer, and a user who was not told that will open a ticket.
What the product does not need is a payout path, a destination registry or a tax-ID match on bank accounts. Building those for an on-ramp product is building for a flow that has no users yet.
What an off-ramp asks of the product
A product with an off-ramp has users who hold a stablecoin balance and need local currency to arrive somewhere: a payroll platform paying contractors in Brazil, a marketplace paying sellers in Mexico, a company paying suppliers from a dollar treasury. The balance is debited, converted at a quoted rate, and paid out over the local rail to a bank account whose holder has been validated against the recipient's CPF (the Brazilian individual taxpayer ID), CNPJ (the Brazilian company taxpayer ID) or CLABE (the 18-digit Mexican bank account number).
The product's job here is the destination. Every recipient is a bank account with a name, a tax ID and a relationship to the payer, and the product must collect those before the first payout rather than during it. Its second job is to surface the reason a payout stopped, because a held payout with no reason becomes a support ticket blaming the product, and the reason is usually a mismatch the recipient can fix in a minute.
What the product does not need is deposit accounts per user or an inbound reconciliation job. The balance it pays from was funded once, by the business, and the USDC to BRL page shows what that single funding buys on the way out.
When a product genuinely needs both
Both directions belong in one product when the same user's money goes in and comes out in local currency, with time in between. A remittance app collects reais over Pix, holds a dollar balance for hours or days, and pays pesos over SPEI: on-ramp in Brazil, off-ramp in Mexico, same product. A dollar account for Latin American users takes deposits over local rails and lets the user withdraw over local rails: both directions, same country. A marketplace that collects from buyers in one currency and pays sellers in another has both by definition.
The tell is the balance. If the product's user holds a stablecoin balance that came from local currency and will return to local currency, the product needs both. If the balance came from somewhere else, or never returns, it needs one.
Building both also means running both failure families and both reconciliation jobs, and it is worth sequencing: launch the direction with users, watch the tickets, then open the other. The BRL to USDC and USDC to BRL pages show the two directions of the same corridor priced separately, which is a reminder that the provider treats them as two flows too.
The common fintech shapes and what each one needs
Product shapes and the direction each one usually needs, before a second flow appears.
Product | Direction needed first | Why |
Dollar savings account for users in Brazil or Mexico | On-ramp | Users deposit local currency; withdrawals come later and are usually smaller |
Payroll or contractor payouts across LATAM | Off-ramp | The employer funds a balance once; every user event is a payout |
Marketplace with local buyers and cross-border sellers | Both | Collect in the buyer's currency, pay in the seller's |
Corporate treasury converting reais to dollars | On-ramp | The company holds the dollars; payments out are a separate decision |
Supplier payments from a dollar treasury | Off-ramp | The balance exists; every event is a payout |
Remittance app between two LATAM countries | Both | Local currency in one country, local currency in another |
Exchange or wallet where users bring their own tokens | Off-ramp, and often neither | Users already hold tokens; the question is whether local currency ever has to arrive |
Five of the seven start with one direction. That is not an argument against the second; it is an argument for building it when the flow exists.
I push back when a prospect asks for both directions on day one, and the pushback is not about our integration time. It is that a product with no users in one direction has no way to find out what breaks there, and everything that breaks in a ramp breaks at the edges, in the third-party deposit or the mismatched name, where only traffic teaches you. The position I hold is that a fintech should ship the direction its users are already asking for, read the rejection reasons for a month, and then open the other direction with what it learned. A product that builds both in silence launches two flows it has never seen fail.
What each direction costs to run
The visible cost is the same on both sides: the FX spread on the conversion, shown on the quote before execution when the provider is any good. The invisible costs differ.
On the on-ramp, the cost is operational: identifying deposits, returning the ones from unverified payers, and answering the users whose money came back. Named accounts remove most of the first and none of the second.
On the off-ramp, the cost is the payout rail's fee, the network fee on the token deposit that funded the balance, and the destination data quality. A batch of payouts to recipients whose names were collected in a free-text field will bounce at a rate that surprises the finance team, and each bounce is a refund of a conversion that already happened.
Neither direction is expensive. Both are expensive when built for a flow that does not exist, because the fixed cost of onboarding and integration is paid against zero volume.
When a ramp is the wrong product
When the flow is domestic. A Brazilian company paying Brazilian suppliers should send Pix. Local currency in, token, local currency out, is two spreads to end where it started.
When the business already holds the currency it needs. Buying USDC with reais to pay a dollar invoice, when the company has a dollar account, adds a conversion for nothing; the off-ramp it needs is a plain payout from that account.
When the counterparty wants local currency anyway and the sender has local currency. That is a cross-border payment with the token invisible inside it, and the product should buy the payment, not the ramp.
When the regulator in the user's market has not defined the activity. Taking currency from the public and returning a virtual asset is a licensed service in Brazil under Law 14.478 of December 21, 2022, whose Article 5 lists exchange between virtual assets and currency as the first of five services that make a company a virtual asset service provider, with Central Bank Resolutions 519, 520 and 521 of 2025 setting the regime. Where the user's market has no such frame, the ramp is a legal question before it is a product.
What on-ramp and off-ramp look like on 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, 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.
The two directions are two transaction types on the same customer. An on-ramp starts with a named virtual account in the customer's name and, for BRL, MXN and USD accounts, a standing autoconversion rule that turns each deposit into USDC or USDT on the network the client chose; the deposit details the client shares embed the reference that matches a deposit to the rule, and each conversion runs as an on-ramp with its own events, from the fiat arriving to the tokens credited. An off-ramp debits the customer's custodial wallet to a destination registered under that customer, with the holder relationship declared, at a floating rate or one locked for 30 seconds without a fee, and pays out through global payments over the local rail; a held payout arrives as an event with its reason. A product that needs one direction integrates one transaction type and one set of events, and adds the other when the flow appears, on the same customer and the same wallet, which is the sequencing this post argues for.
Methodology and sources
Direction definitions and the failure families follow the on-ramp and off-ramp explainers on this blog, verified on September 21, 2026, and the behaviour of transactions and accounts, and of autoconversion rules, is from the Lumx documentation at docs.lumx.io, read on September 24, 2026. The definition of a virtual asset service provider and the five services follow Article 5 of Law 14.478/2022 as published by the Presidency of the Republic, read on September 24, 2026. Rates and pairs change, so the corridor pages linked above are the live reference.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Ben Garratt on Unsplash.
Does a fintech need both an on-ramp and an off-ramp?
Only when the same user's money enters as local currency and leaves as local currency, with a stablecoin balance in between. A payouts product needs the off-ramp; a dollar savings product needs the on-ramp first. Build the direction with users, then add the other when the flow exists.
Which is harder to build, the on-ramp or the off-ramp?
They are hard in different places. The on-ramp's difficulty is identifying deposits and handling the ones from payers the provider cannot accept. The off-ramp's difficulty is destination data: names, tax IDs and relationships collected correctly before the first payout.
Can a product start with one direction and add the other later?
Yes, and it usually should. On a provider that models both as transaction types on the same customer, the second direction is a new call and a new set of events, not a new integration. The user's balance and verification carry over.
Is running an on-ramp a regulated activity?
Yes, and the licence sits with the provider. In Brazil, exchanging virtual assets for currency is the first of the five services listed in Law 14.478/2022, and the Central Bank's 2025 resolutions set the authorization regime. A fintech using a provider's ramp should ask which entity holds that authorization in each country.
