Best stablecoin payment rails for PSPs: the license behind each

The best stablecoin payment rails for a PSP are the local bank rails that reach its merchants' accounts, one per market, because the stablecoin only moves the money between them. What separates the rails is the license each leg runs under and who answers for it, which is the first thing a merchant's compliance team asks.

Picture a PSP's support queue on a Tuesday. A merchant in Monterrey wants to know why a settlement has not landed, and the PSP's compliance lead, copied on the thread, asks a different question: under whose license did that payment run? A PSP that can answer in one line per corridor closes the thread the same day, and one that has to ask its provider loses a day. This guide is for a Head of Payments at a PSP that settles merchants across borders. It lists the rails, the license behind each leg and the risk under every rail, the stablecoin itself. For the product category first, start with the stablecoin payouts guide.

Which stablecoin rails does a PSP use?

A PSP uses the local rail of each market it serves: Pix (Brazil's instant payment system, run by the Central Bank), SPEI (Mexico's interbank transfer system, run by Banxico), Bre-B (Colombia's instant payment system) and the US, EU and UK rails. A stablecoin balance sits between them, and merchants never handle it. They see a deposit in their own currency, in their own bank.

Rails a PSP can use on Lumx, with settlement from the Lumx docs and the license behind each leg from the Lumx licenses page, both read on November 9, 2026.

The mechanics of two of them have their own guides: Pix for businesses and SPEI guide. Every rail in the table collects and pays out except ACH Colombia, which only pays out. A PSP collects into a named virtual account (a local account number issued in the customer's own name) in BRL, MXN, EUR, GBP or USD, and each deposit converts to stablecoin in the customer's wallet. The same wallet funds a payout. A COP account takes Bre-B and PSE (Colombia's online bank-transfer network) deposits and pays out over Bre-B or ACH Colombia.

Which license sits behind each leg?

Where Lumx holds no license, a licensed partner performs the regulated activity in its own name, and a PSP should tell merchants before they ask. When a merchant transacts, it also becomes a customer of the partner that performs that leg, under the partner's terms. That sentence belongs in the PSP's merchant contract.

Brazil, Pix. The Brazilian entity, Lumx Sociedade Prestadora de Serviços de Ativos Virtuais Ltda., filed for authorization as a virtual asset service provider (SPSAV) with the Central Bank of Brazil on October 27, 2026. It operates under the transition rules of Article 88 of BCB Resolution 520/2025 while the request is reviewed. A filing is not an authorization, so a PSP's merchant-facing copy should say "in transition", never "authorized". The entity deals only in BRL and stablecoin, so no USD leg runs through it.

Mexico, SPEI. MXN payments run through a licensed electronic payment funds institution (IFPE, the Institución de Fondos de Pago Electrónico), authorized under the Ley Fintech. Lumx holds no Mexican license. For a PSP the consequence is visible to the payer: SPEI deposits land in an account in the merchant's name, so the payer's statement shows the merchant, not the PSP. The model behind this is covered in own license versus partner license.

Colombia, Bre-B and ACH Colombia. COP runs through a sponsored program of a banking partner that is a financing company (compañía de financiamiento), supervised by the Superintendencia Financiera de Colombia. Accounts are opened in customers' names under the partner's license, and reporting of suspicious activity to Colombia's financial intelligence unit (UIAF) is the partner's job. Two things follow. The COP account is named only for Colombian customers, and for anyone else the receiver sees the partner as the sender. ACH Colombia has no per-payment limit, so it is the rail for an invoice above the central bank's Bre-B ceiling, and it settles in one business day.

United States, ACH and FEDWIRE. Lumx US OP LLC is registered with FinCEN as an MSB (money services business, the FinCEN registration category). A registration is not a state license: Lumx US OP LLC does not custody funds or transmit money. USD payments over ACH, FEDWIRE and SWIFT run through licensed money transmitters and banks under their own licenses, with a sponsor bank behind the USD account.

Europe and the United Kingdom, SEPA and Faster Payments. Lumx holds no license in the EU or the UK. EUR over SEPA and GBP over Faster Payments (the UK's real-time bank transfer network) run through a banking partner authorized as an electronic money institution by the UK Financial Conduct Authority and as a financial institution by the Malta Financial Services Authority. Customers in the United Kingdom are onboarded by reverse solicitation, meaning they approach Lumx and Lumx does no marketing there.

SWIFT, USD only. SWIFT on Lumx covers USD and nothing else. Euros go over SEPA and pounds over Faster Payments, and the on-behalf-of payments and collections that let a PSP pay and collect in its customers' names (POBO and COBO) run in USD, EUR and GBP over those local rails. SWIFT takes one to five business days, depends on intermediary bank hours and cuts off at 3:00 PM ET. Use it where no local rail exists, such as a payee in Asia. It runs under the same partners as the US legs.

The partner types and registrations are on the Lumx licenses page, updated November 2026. The sponsor bank, the UIAF reporting and the reverse solicitation notes are Lumx's own statements as of November 9, 2026.

The stablecoin carries its own risk

Every rail above sits behind a stablecoin, and a stablecoin can trade below one dollar. Circle and Tether issue USDC and USDT, and Lumx backs neither. The loss belongs to whoever holds the balance while the price is down: the merchant, for stablecoin sitting in its own wallet, and the PSP, if it prefunds a wallet of its own to pay out faster.

The reference case is the weekend after March 10, 2023, when Circle said it could not withdraw $3.3 billion of USDC reserves, about 8% of the total, from Silicon Valley Bank. At the trough, USDC traded at 86 cents to the dollar, according to the Federal Reserve FEDS Note of December 17, 2025. Redemptions fell to minimal levels while US banks were closed, and the price recovered after the joint Treasury, FDIC and Federal Reserve announcement that all depositors would be protected. A PSP cannot count on a backstop. It controls how many hours it holds a balance.

That is where the rails matter. A payout on Pix, SPEI, SEPA Instant or Faster Payments settles on a Saturday, so a balance funded for it leaves at once. A USD payout asked for on Friday night waits for Monday, so a PSP that funds it on Friday holds the balance all weekend. The exposure is the balance times the hours it is held, and stablecoin depeg risk for payment companies works through the arithmetic. Fund each run close to its payouts, not the whole week on Monday.

Every merchant stays the account holder

Lumx accounts cannot process payments for a party Lumx has not onboarded, and the nested payments rules apply to PSPs as they do to marketplaces: each merchant is onboarded as its own Lumx customer, with its own KYB (know your business, the verification of a company and its owners) and its own wallet. What does not work is every merchant's money landing in one PSP account, with the PSP distributing it off-platform.

Collections have a version of the same rule. A payer who is not the merchant is a third-party payer, and one that matches the flow the merchant declared at KYB passes, while one outside that pattern can trigger an RFI (request for information, a compliance hold that asks for a document before a transaction clears) and a return. See third-party payments in Brazil. A PSP that holds merchant funds under its own license, or runs a layered structure, should ask compliance@lumx.io for written approval before it builds.

On the supported rails the sender of record is the merchant's registered legal name, so the merchant's payee sees the merchant, not the PSP. The exception is COP for a merchant that is not Colombian, where the payee sees the banking partner.

Where a PSP's cross-border flow breaks

• A USD funding wire that lands after US banking hours, or on a US holiday, waits for the next business day. The Pix and SPEI payouts behind it run all night, and the dollar leg does not. Cut-offs by rail lists the times.

• A payout flagged by monitoring is held pending an RFI, usually for the relationship with the payee, the purpose of the payment and an invoice.

• A destination registered with a wrong tax ID or holder name should fail at registration, not on payday.

A PSP that runs one provider per country sees these in several formats, which is part of the case for payment orchestration with stablecoins.

What I would settle first

I recommend that a PSP choose its rails by the license behind each leg before it compares speed. A merchant's compliance team can accept a slower rail it understands, and it will not accept a fast one it cannot read. I would write the one-page answer for each corridor before the first merchant goes live.

When stablecoin rails are the wrong tool for a PSP

A PSP whose merchants all sit in one country, paid in its currency over a domestic rail, gains nothing from a stablecoin leg.

Stablecoin rails do not replace card acquiring either: they move funds between bank accounts, so a flow that needs card authorization or chargebacks stays on the card networks. And a corridor without a rail in the table, or with a counterparty in a restricted country, is a dead end: check the rails and countries covered and the supported countries list before promising one.

How to start with one corridor

1. Open the sandbox from the Lumx dashboard. It is self-serve, with all currencies available.

2. Create one merchant as a business customer, send it the terms and the verification link, and request its currencies, then confirm Bre-B is enabled before promising it to a Colombian payee. Lumx targets one business day for KYB.

3. Set each account to convert deposits to stablecoin automatically, and share the deposit details with a test payer.

4. Register a payee as a destination under the merchant, then quote and pay out.

5. Add the PSP's own fee as a partner fee, so its margin is on the transaction from the first payment.

6. Write the license page for that corridor from the table above, and show it to the merchant's compliance team before going live.

Lumx's typical API integration takes two to three weeks to go live. See how to integrate a stablecoin API, and for the market, the best stablecoin APIs in 2026.

What a PSP flow 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.

For a PSP, each merchant is a Lumx customer with its own accounts and wallet, plus its own verification, and the PSP orchestrates through one API. A merchant in São Paulo receives into a named BRL account, a deposit converts to stablecoin, and the PSP pays the merchant's supplier in the United States by FEDWIRE or a supplier in Bogotá over Bre-B. The PSP sees each payout's status as it moves from stablecoin to local currency. Lumx runs KYB on the merchant and verifies each destination. It screens and monitors transactions and does the conversion. The PSP owns the merchant relationship and the pricing.

Lumx is not a bank. The custodian of the stablecoin balances is BitGo, a third-party custodian, and the regulated payment activities listed above run under the partners' licenses. In Brazil the Lumx entity operates under its transition regime, and in the United States Lumx US OP LLC holds an MSB registration while the payments run under the partners' licenses. Support and complaints go to operations@lumx.io.

Methodology and sources

The licenses by market come from the Lumx licenses and registrations page, read on November 9, 2026. Settlement times and cut-offs come from the cut-off times page and the coverage page, the payer rules from the nested payments page, the POBO and COBO page and the sender of record page, all read on November 9, 2026. The USDC figures come from the Federal Reserve FEDS Note of December 17, 2025.

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

Cover photo: Scott Rodgerson on Unsplash.