A stablecoin on-ramp is the service that turns ordinary money into a dollar stablecoin: a company sends reais over Pix (Brazil's instant payment system, run by the Central Bank) or pesos over SPEI (Mexico's interbank transfer system, run by Banxico), and USDC or USDT appears in a wallet it controls or that a provider holds for it. The money arrives as a bank credit and leaves as a token balance, at a rate the provider quoted before the transfer.
The stablecoin off-ramp is the same road in the other direction, and most businesses end up running both. This post covers the steps, what actually decides the timing, the failure modes that have nothing to do with blockchains, who is allowed to operate one, and the cases where an on-ramp is the wrong tool. If the token itself is new, start with what a stablecoin is.
The four steps between a bank transfer and a token balance
Quote. The business asks what a given amount of local currency will buy. The answer carries a rate, a fee and an expiry: a floating quote priced at execution, or a locked one held for a stated window. A provider that prices only after the money lands is charging a spread the client cannot audit.
Deposit. The business sends the local transfer. Where it sends it is the part that matters most, and the two models are genuinely different. A pooled account means everyone pays into one account belonging to the provider, with a reference code to identify who sent what. A named virtual account means the business, or each of its customers, gets an account number in its own name, so the credit is identified by the account it landed in rather than by a code someone had to type correctly.
Conversion. The provider buys the stablecoin at the quoted rate, from inventory or through a liquidity partner, and the local currency joins its treasury.
Credit. The token balance appears. Either in a wallet the provider custodies for the client, or by transfer to an address the client owns on a supported network.
Nothing in that sequence needs a block explorer. The client sees a transfer go out and a balance go up.
What actually decides the timing
On Pix and SPEI the bank leg settles in seconds, at any hour. The conversion is a book entry. So an on-ramp that takes two hours is not slow because of the blockchain, and saying so is usually a provider covering for something else.
Three things genuinely add time. The first is identification of the deposit: a pooled account with a mistyped reference sits unallocated until somebody reconciles it by hand, which is the strongest practical argument for named accounts. The second is compliance, where a first deposit, an amount out of pattern or a new payer triggers an RFI (request for information, a compliance hold that asks for a document before a transaction clears). The third is the destination transfer, if the client wants tokens moved to its own address on a congested network.
Ramps built on slower rails inherit those rails. An ACH deposit in the United States is a business day. A SEPA credit transfer is same day or next. SWIFT is one to three business days, and at that point the settlement speed of the token is decoration.
Why the deposit account decides the experience
Brazil is the clearest illustration, because the identity layer is public infrastructure. As of August 31, 2026, the Central Bank's directory of Pix keys held 186.3 million registered users, of which 18.6 million were companies, according to the Bank's own open data service. A Pix key resolves to a named account holder, and a payout or a deposit can be checked against the CPF (the Brazilian individual taxpayer ID) or CNPJ (the Brazilian company taxpayer ID) behind it before anything moves.
That is why a named virtual account changes the operational picture rather than just the branding. The deposit carries the payer's identity from the rail itself, the provider can refuse a credit whose payer does not match the onboarded customer, and reconciliation stops depending on a human typing a code. Mexico works the same way through the CLABE (the 18-digit Mexican bank account number), which is tied to a named holder at a named institution.
Where a stablecoin on-ramp breaks
Third-party deposits. A customer pays from an account that is not theirs: a relative, a business partner, another company. Most providers must return it, because accepting money from an unverified payer breaks the customer due diligence they are required to perform. This is the single most common reason a first on-ramp fails, and it is almost never malice.
Amount mismatch. The client sends a different amount than the quote covered, usually because their bank deducted a fee. Whether the provider executes at the old rate, requotes, or returns the difference should be written down before the first transfer, not discovered on it.
Expired quote. A locked rate has a window. Money that arrives after it gets the current rate, which is fine when the market has not moved and a support ticket when it has.
Wrong network on the way out. The client asks for delivery to an address on a network the provider does not support for that token. USDC and USDT do not live on the same set of networks, and neither does any provider's coverage.
Unallocated deposit. The pooled-account failure: the money is in the provider's bank, and nobody can prove whose it is yet.
The first time we ran a serious on-ramp volume in Mexico I underestimated exactly one thing, and it was not the rail. A client onboarded a few hundred of its own customers in a week, and roughly one deposit in six came from an account with a different name on it, usually a spouse or the family business. Our flow returned every one of them, correctly and silently, and the client's support queue filled with people who had done nothing wrong and had no idea why their money came back. We changed two things: the return now carries a plain reason the client can forward, and the deposit details show the customer the account name we expect before they pay. The compliance rule did not move. What moved was how long it took someone to understand it.
Who is licensed to run an on-ramp
Taking local currency from the public and returning a virtual asset is a regulated activity, and the licence sits with the provider. In Brazil, Law 14.478 of December 21, 2022 defines a virtual asset service provider as a company that performs, on behalf of third parties, at least one of five services, the first being exchange between virtual assets and national or foreign currency. That is an on-ramp, described in law. Central Bank Resolutions 519, 520 and 521 of 2025 supply the authorization and conduct requirements around it.
In the United States the baseline is a money services business registration with FinCEN. In the European Union it is authorization as a crypto-asset service provider under MiCA, Regulation (EU) 2023/1114. A provider that cannot name the entity and the authorization per country is asking the client to carry that risk without pricing it.
When an on-ramp is not the answer
When the business already holds dollars. Buying USDC with reais to pay a supplier in dollars, when the company has a US account with dollars in it, adds a conversion for nothing.
When the flow is domestic. A Brazilian company paying a Brazilian supplier should send Pix. Local currency in, token, local currency out, is two spreads to end where it started.
When the counterparty wants local currency anyway. Then the right product is a cross-border payout, and the token stays invisible inside it.
When the amounts are small and rare. Onboarding, a KYB (know your business, the verification of a company and its owners) review and an integration cost real time. A handful of transfers a year does not repay it.
What an on-ramp looks 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.
An on-ramp with us starts with a named virtual account issued to the client or to each of its customers, so the deposit arrives identified. An auto-conversion rule can turn the credit into USDC or USDT on arrival, or the client can hold the local balance and convert against a quote later. Every state change emits an event: deposit received with the payer's details, conversion executed at the quoted rate, compliance cleared or held with a reason, tokens credited. The BRL to USDC and MXN to USDC pages show the live rate and the networks available for each pair.
Methodology and sources
Pix directory figures come from the Central Bank of Brazil's open data service (olinda.bcb.gov.br, Pix_DadosAbertos), queried on September 21, 2026, for the most recent month published, which was August 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. The United States registration requirement follows FinCEN's money services business registration page; the European framework is Regulation (EU) 2023/1114. Rates, pairs and networks change, so the corridor pages above are the live reference and the stablecoin glossary holds the stable definitions.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Jerry Kavan on Unsplash.
How long does a stablecoin on-ramp take?
On Pix or SPEI, minutes from the bank transfer to the token balance, at any hour, when the deposit is identified and compliance is clear. On ACH it is a business day, and on SEPA the same day or the next. Delays almost always come from an unidentified deposit or a compliance hold, not from the blockchain.
Can I pay into an on-ramp from someone else's bank account?
Usually no. Providers are required to verify who the money came from, so a deposit whose payer does not match the onboarded customer is normally returned. Some providers support explicitly declared third-party payers under stricter checks, which is worth asking about before the first transfer.
What is the difference between a pooled account and a named virtual account?
A pooled account receives everyone's deposits into one account belonging to the provider, and a reference code says who sent what. A named virtual account gives each customer an account number in their own name, so the rail itself carries the identity and reconciliation does not depend on a typed code.
Do I need my own crypto wallet to use an on-ramp?
No. In a custodial model the provider holds the tokens and the client sees a balance, which is what most payment flows need. A business that wants the tokens in its own wallet can have them delivered to an address it controls on a supported network.
