How to fund a stablecoin on-ramp: Pix, SPEI, PSE, ACH or wire

Funding a stablecoin on-ramp means paying fiat into the account the on-ramp converts from, over a rail the payer's bank offers. The rail sets the speed and the risk. Local real-time rails clear in seconds, ACH takes one to two business days, and wires follow bank hours and cut-offs. Choose the rail first, then the account type.

The on-ramp itself is covered in what a stablecoin on-ramp is. This guide covers the payment that starts it and assumes the customer is already verified.

How does a payer fund an on-ramp, rail by rail?

Each currency has its own rails, and each rail asks the payer for different details. The table follows the Lumx docs read on November 2, 2026.

Rails that pay into an on-ramp account on Lumx, with what the payer needs and when the money lands

Pix (Brazil's instant payment system) and SPEI (Mexico's interbank transfer system) never close. The Mexican payer uses a CLABE (the 18-digit Mexican bank account number), and the memo ties the deposit to the customer. PSE (Colombia's online bank-transfer network) and Bre-B (Colombia's instant payment system) behave differently, as the next section explains. BRL is Pix only: boleto (a Brazilian bank slip payable at any bank or app) and TED (Brazil's same-day bank transfer, business hours only) are not funding rails. Faster Payments (the UK's real-time bank transfer network) and SEPA are open around the clock, except that SEPA routes a payment of €100k or more sent between 4:30 PM and 2:30 AM UK time to SEPA Credit Transfer, which settles the same or next business day.

On Lumx, one account per currency receives all of these rails: a USD account takes ACH, FEDWIRE and SWIFT on the same account details, and a customer can hold several currencies at once. Rails by country sit on the coverage page, and the pairs have their own pages, such as BRL to USDC and MXN to USDC.

Push and pull: who starts the payment

A push is a credit the payer sends from their own bank. A pull is a debit the receiver starts after the payer has authorized it. Pix, SPEI, Bre-B, SEPA, Faster Payments, wires and an ACH credit are pushes. An ACH debit is a pull, and so is PSE, where the payer approves a debit from their own bank.

The difference matters because a pull can come back. Nacha, the body that sets the ACH rules, changed this in 2020 and 2021: its rule on differentiating unauthorized return reasons re-purposed return code R11, used when a consumer says a debit did not match the terms they authorized, and moved its return timeframe from two days to 60 days (Nacha). So a business that credits a customer on a debit it started carries a window of up to two months in which the money can be reclaimed, and a push does not carry that window because the payer sent the money themselves.

The cost of a push is that the payer decides when to send, how much, and whether to include the reference, and a missing reference leaves a deposit someone has to match by hand.

On Lumx, a USD account is funded by the payer sending an ACH credit, a wire or SWIFT to the account details, so the payer starts the payment. Lumx supports ACH credit (push) only, with no ACH debit. In Colombia, PSE is the pull rail: the payer authorizes the debit from their own bank, and PSE only brings money in.

Which rail should a payer use for USD?

For USD the choice is between ACH, FEDWIRE and SWIFT, and it comes down to how much time and how much cost the payer will accept. The cut-offs and settlement come from the Lumx cut-off page.

USD rails compared on the same Lumx account

FEDWIRE (the Federal Reserve's same-day wire system) is the rail for money that has to arrive today, and the cut-off decides whether today is possible: a request after it, on a weekend or on a bank holiday is processed the next business day. SWIFT is the rail for a payer outside the US with no US account, and it runs through correspondent banks the receiving platform does not control.

On Lumx, SWIFT is a USD rail, so a payer in another currency sends USD. The docs give the timezone trap: a transfer triggered at 4:00 PM in São Paulo misses the 3:00 PM ET FEDWIRE cut-off.

Standing account details or a payment per top-up

A payer can pay the same account details every time, or pay a new instruction created for each deposit. The first suits a payer who tops up often, the second a payer who wants the price before paying.

Standing details work like a named virtual account (a local account number issued in the customer's own name, explained in what a named virtual account is): the payer saves them once, and each deposit converts at the market rate when it arrives. A payment per top-up fixes the amount and the rate first and expires if the payer is slow. Named accounts vs pooled accounts covers why one shared account for many payers breaks matching.

On Lumx, an autoconversion rule is the standing option: creating it returns the deposit details, a Pix brCode for BRL or a CLABE and memo for MXN, and every matching deposit converts to USDC or USDT. Each deposit must be worth at least 50 USD in the account's currency or it is not converted. The per-top-up option is an on-ramp transaction, which waits in AWAITING_FUNDS and expires after 1 day for Pix and SPEI or 7 days on other rails when the rate is floating. A deposit that lands after expiry is refunded to the sender on the same rail. For USD, EUR and GBP a customer can hold one active rule per account, because those deposits are matched to the account and not to a reference.

How long funding takes, and what delays it

The rail sets the floor, and the cut-off, the calendar, account activation and compliance review set the rest. Pix, SPEI, Bre-B and Faster Payments land the same minute on any day. ACH lands one to two business days later, and only if the request beat the 2:00 PM ET cut-off on a business day.

Calendars differ: ACH, FEDWIRE and SWIFT stop on US federal holidays, SEPA Credit Transfer on TARGET closing days, and SPEI on Banxico non-business days. A deposit under review is held until the review ends, and a large transfer can add up to two business hours.

The first deposit also waits on the account. A new customer goes through KYC (know your customer, the verification of an individual) or KYB (know your business, the verification of a company) before any account can receive money. BRL, MXN, EUR and GBP accounts activate right after approval, and a USD account takes up to one business day because the banking partner reviews it first. Limits and cut-offs by rail has the full calendar.

I recommend that a platform shows each payer one rail per currency by default and offers a second only when the first cannot work, such as a wire for a payer who must land funds today. A payer handed six rails picks by habit and not by cut-off, and the ticket arrives on Friday after the 2:00 PM ET ACH cut-off. I would also credit the payer in the app only when the success webhook arrives, never when the deposit instruction is shown, because an instruction is a promise to pay and not a payment.

On Lumx, the app learns of each stage by webhook: account.active when an account can receive funds, and the onramp.* events as a deposit moves through TRANSFERRING_FIAT, TRADING and TRANSFERRING_STABLECOIN to onramp.success.

Minimums and limits that cap a deposit

Three caps apply to a deposit: a minimum, the customer's verification level, and the rail's own ceiling.

Default Lumx limits by verification level, in USD, from the Lumx docs read on November 1, 2026

The rail ceiling matters for Colombia. Bre-B carries a regulatory cap of 1,000 UVB per transaction, set by the Banco de la República in Circular Reglamentaria Externa DSP-465, which is COP 12,110,000 for 2026 and about USD 2,870. The 2026 figure comes from the Banco de la República "Conozca Bre-B" page as read on November 1, 2026.

On Lumx, an on-ramp counts only against its own limit, so a deposit never uses up off-ramp or transfer headroom. Pass includeTransactionLimits=true when reading the customer to see the used and remaining amounts. A deposit that would pass a limit is rejected with a 422 and the code TRANSACTION_LIMIT_EXCEEDED, and a higher limit comes from an Enhanced KYC or KYB review, which the docs target at one business day.

Fees and failed deposits, in one place each

Fees come from three places: the rail's own charges, the conversion rate, and any fee the platform adds. A deposit that does not show up is almost always a missing reference, a wrong amount, a cut-off or a compliance hold, and the order to check is reference first, then amount, then the cut-off, then whether a review is open.

On Lumx, a platform adds its own fee by sending a partnerFeeId with the request. That fee sits on top of what the payer funds, so a BRL payer sends more reais for the same USDC credited.

When funding an on-ramp this way is the wrong tool

Funding from a bank account is the wrong tool when the payer already holds a stablecoin: USDC on a supported network should go straight to the wallet, with no conversion and no delay. It is also wrong for a payer who needs the money in minutes and only has ACH, because the answer there is a wire. And it is the wrong tool when one account collects for many payers who have not been onboarded, because that is a pooled account and the money cannot be tied to a person.

What funding 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, 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.

Funding follows a short path: create the customer with the currencies it needs, wait for account.active, then give the payer the deposit details. The details carry the reference that matches a payment to the customer, so nobody matches by hand. Funds are delivered as USDC on Ethereum, Polygon or Base, or as USDT on Ethereum, Polygon or Tron, and BRL on-ramps can also deliver USDC on Stellar. A foreign company can hold a named account in BRL and MXN without a local entity in Brazil or Mexico, as set out in named virtual accounts, and the countries where Lumx onboards are on the supported countries page. For USD, the USD to USDC page covers the pair. Funding a payout comes next.

Methodology and sources

We read the Lumx docs on November 2, 2026 and the Nacha rules page on November 1, 2026.

• Lumx docs: Coverage, Payment rail cut-off times, Accounts, Autoconversion rules, Transactions, Transaction limits

• Nacha: Differentiating Unauthorized Return Reasons, effective April 1, 2020 and April 1, 2021

• Banco de la República, Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2, cited by name and number, with the 2026 figure from its "Conozca Bre-B" page

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

Cover photo: Miha Meglic on Unsplash.