Stablecoin payouts for business banking platforms are payments a platform sends for its business customers to suppliers abroad, in the supplier's own currency, funded from the customer's own balance. The platform keeps the interface and the customer relationship; a provider supplies the accounts and wallets, plus conversion and delivery over local rails.
A business banking or spend-management platform sells control: who can pay, how much, to whom, with which approval. The money movement under that control is where international payments hurt. A customer in São Paulo with an invoice from a supplier in Texas can wait one to five business days on a SWIFT payment, and the platform's support team gets the ticket. This guide covers how the flow works on stablecoin and local rails, what the platform has to design on its own side, and where it breaks. For the whole product category first, start with the stablecoin payouts guide.
How does a business banking platform pay suppliers abroad with stablecoin?
The business customer is the payer, and the platform orchestrates. Each step has an owner.
Who does what in one outbound supplier payment.
Step | What the platform does | What the provider does |
1. Onboard | Collects the customer's company data and shares the verification link | Runs KYB on the customer |
2. Open accounts | Requests the currencies the customer will use | Provisions a named virtual account (a local account number issued in the customer's own name) per currency |
3. Fund | Shows the customer where to deposit, or lets the customer move stablecoin in | Converts each deposit to stablecoin and credits the customer's wallet |
4. Register the payee | Saves the supplier's bank details with the relationship "supplier" | Validates the destination and ties it to the customer |
5. Quote and pay | Shows the customer the rate and fee, then the amount the supplier receives, and submits | Converts stablecoin to local currency and sends it over the local rail |
6. Track | Updates the customer's ledger from status notifications (webhooks) | Reports each status change and the rail reference |
The customer holds the wallet and the account, not the platform. And the payee is registered under that customer with a declared relationship, which is what lets compliance connect a payout to the customer's own obligation.
The build order is in how to integrate a stablecoin API.
Why the business customer has to be the account holder
The design to avoid is one pooled account for the whole platform. The platform collects from many customers, pays many suppliers and keeps its own sub-ledger. It looks efficient, but provider compliance rules treat it as nesting, meaning payments for parties the provider has not onboarded.
The test a provider applies is whether the money and the business behind the payment both belong to an onboarded customer. If either belongs to an entity the provider has not seen, the payment is nested and does not fit. A sub-ledger or a contract with its customers does not change the answer. The model that works is the one the named virtual account versus pooled account comparison describes: each business customer is onboarded, holds its own accounts and wallet, and pays from them.
Onboarding becomes part of the platform's own onboarding flow, with the customer accepting the provider's terms and clearing KYB (know your business, the verification of a company and its owners) before the first payment. Lumx targets one business day for KYB, and an RFI (request for information, a compliance hold that asks for a document before a transaction clears) can stretch it. A platform that already verifies its customers with Sumsub can reuse that work, because Lumx accepts an existing Sumsub verification through its verification reuse process. When the customer is the account holder, the platform can pay and collect for the customer in the customer's own name without opening accounts abroad for anyone. That capability is POBO and COBO, payments and collections on behalf of your customers.
What the supplier sees and what the platform sees
What lands on the supplier's statement matters to the customer, because the supplier will call the customer.
On a Lumx payout the sender of record is the customer: the legal name registered during KYB. That holds on Pix (Brazil's instant payment system, run by the Central Bank), SPEI (Mexico's interbank transfer system, run by Banxico), ACH, FEDWIRE (the Federal Reserve's same-day wire system), SEPA, Faster Payments (the UK's real-time bank transfer network) and SWIFT. The supplier sees the name of the company that owes the invoice, as sender of record on every rail the docs list, instead of a provider it has never heard of.
The reference works the same way. The platform passes the customer's invoice number as the memo on the payout. On SWIFT the memo maps to the one field the supplier's bank shows as the payment reference, and only the first 30 characters reach the supplier, so the invoice number goes first. After settlement, each transaction carries an identifier for tracing: the UETR on SWIFT (a unique end-to-end reference for the payment), the IMAD on FEDWIRE (the wire message's Federal Reserve identifier), and the bank's booking reference on ACH when one is available.
Collecting for customers: COBO and autoconversion
Business banking customers also get paid, on the same accounts. Each currency account has deposit details in the customer's name. A standing autoconversion rule on the account turns every deposit into stablecoin in the customer's wallet, with no request per deposit, and the wallet is where the outbound payment starts. One wallet can serve a customer paid by a US client over ACH and paying a Brazilian supplier over Pix.
This is where reconciliation gets simpler than in a pooled model. A deposit arrives at an account that belongs to one customer, so nobody matches a lump sum against twenty customers' invoices. Named virtual accounts for B2B collections covers matching and holds on the inbound side, and what a named virtual account is is the short version.
Which rails a payout takes, by destination
The platform's customers pay suppliers where the suppliers are. The rail follows the destination.
Payout rails on Lumx for the most used destinations, read from the Lumx cut-off times page on November 9, 2026. GBP over Faster Payments and EUR over SEPA are in the full table in the stablecoin payouts guide.
Currency | Rail | Cut-off | Settlement |
BRL | Pix | None | Instant, 24/7/365 |
MXN | SPEI | None | Instant, 24/7/365 |
USD | ACH | 2:00 PM ET | 1 to 2 business days |
USD | FEDWIRE | 3:00 PM ET | Same business day, typically within hours |
USD | SWIFT | 3:00 PM ET | 1 to 5 business days |
A supplier in a country without a local rail on the list gets USD by SWIFT, or stablecoin to a wallet if the supplier can receive it. The coverage page carries the current list of rails and pairs, and the corridor behind each pair is explained in what a stablecoin corridor is.
The cut-offs matter more for a banking platform than for most buyers, because a customer who approves a dollar payment after the US cut-off has already missed it for the day. The product should say "arrives tomorrow" before the customer taps approve. The São Paulo customer paying that Texas supplier funds in BRL, which converts to USDC and is paid out in USD over FEDWIRE before 3:00 PM ET: same business day, not one to five days by SWIFT.
Where payouts break, and what the platform should build for it
Payouts stop in four places the platform can design for.
An empty wallet. A payout larger than the wallet balance fails with an insufficient-balance error, and a customer who approved a payment and sees it fail has a supplier waiting. The platform needs to show the funded balance next to the payment form, and to decide whether it lets the customer queue a payment before the deposit lands.
A wrong holder relationship. Every payout goes to a destination registered under the customer, with the relationship to the payee declared: supplier, employee or subsidiary. Lumx does not ask for a document on every third-party payout. If transaction monitoring flags one, it goes on hold and compliance asks for the relationship, the purpose and a supporting document such as an invoice. A platform that collects the invoice at payment time already has the document on file, so answering the RFI means resending it. One that does not has to chase its customer first.
Every payout also carries a purpose code, such as trade transactions or professional services. Banking partners use it for screening and reporting, and a mismatch can hold the payment. Confirm with Lumx compliance how the platform's spend categories map to purpose codes, and have the customer attest the purpose of each payment instead of letting the product choose it silently.
A customer may also ask for something that is nesting: paying vendors of another entity, or running payments for its own clients through its account. Those parties have to be onboarded too, or approved in writing first, so say so at design time.
Questions I would ask a provider before signing
<!-- OPERATOR PARAGRAPH --> I recommend that a business banking platform settle one question with a provider before it settles price: who is the account holder on the payment the supplier receives. If the answer is the platform or the provider, the platform has bought a pooled account with an API on top, and the compliance rules will catch up with it. If the answer is the platform's customer, the product can be built around the customer's own accounts, and every other question gets easier, from reconciliation to what the supplier sees. I would ask it in the first call and ask for the answer per rail.
Then four more. What does the customer see when a payout is held, and can the platform read the reason through the API? Can the platform add its own fee on a payout, and is it charged on top of what the customer funds, so the quote the customer sees is final? Does the provider hold the stablecoin, and with whom? Which rails exist for the corridors the platform's customers actually use, as opposed to the ones on a marketing page? The best stablecoin APIs in 2026 compares providers on these points.
When stablecoin payouts are the wrong tool for a banking platform
A conversion layer earns nothing for a platform whose customers pay mostly at home; a local payments API or a direct bank integration does the job.
A consumer-style dollar app is a different build, covered in launching a dollar account app. A customer that wants deposit protection, interest on idle balances or a checkbook needs a bank. The balance in the customer's wallet is stablecoin held in custody, not a deposit. A platform that markets a "business account" should not call this balance a deposit, should not imply deposit insurance, and should say in its own terms and screens that the balance is stablecoin held with a custodian. The primer on what stablecoin banking is draws the line in detail.
A platform that wants to pool its customers' funds and pay on their behalf under one account needs each party onboarded, or the structure approved in writing, so plan it with compliance before building. Payroll platforms meet the same rule, as stablecoin payouts for payroll platforms explains.
What this looks like on Lumx for a business banking platform
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 banking platform, SWIFT payouts run in USD only; the on-behalf-of payments and collections are what run in USD, EUR and GBP.
For a banking or spend-management platform, the sequence is the one in the table above. The platform creates each business customer through the API with the currencies it needs. Each currency becomes a named virtual account in the customer's name, which activates right after approval for BRL, MXN, EUR and GBP, and within one business day for USD. A standing rule converts deposits into USDC or USDT in the customer's wallet. Wallets are custodial (wallet documentation), held with BitGo, and each customer's balance is segregated from every other customer's and from Lumx's own. Payouts run from that wallet to registered destinations on the rails in the table, with the customer as sender of record. A partner fee set by the platform is added on top of what the customer funds when its identifier is on the request, and there is no default fee. The platform does not need to open accounts abroad.
To start, open the sandbox from the Lumx dashboard, which is self-serve, create one business customer with a BRL and a USD account, and pay one supplier in each. An integration typically takes two to three weeks to go live.
The named virtual accounts page shows the account side, and global payments the payout side.
On regulation, as of November 2026: Lumx is not a bank, and the balance in a customer's wallet sits outside deposit-protection schemes such as the FGC (Brazil's deposit protection fund). EUR and GBP accounts come through a banking partner, because Lumx has no license in the EU or the UK, and customers in the United Kingdom are onboarded by reverse solicitation, without Lumx marketing there. Stablecoins can also lose their dollar peg, which Lumx does not back, so the customer carries that exposure for as long as it holds a balance. In the United States, Lumx US OP LLC is a FinCEN-registered Money Services Business. What the platform may call its own product is a question for the platform's counsel.
Methodology and sources
Account behavior comes from the Lumx accounts and POBO and COBO pages, the payer rule from the nested payments page, the sender of record from the sender of record page, and rails and cut-offs from the cut-off times page, all read on November 9, 2026. The custody and entity statements are on lumx.io.
Verified on November 9, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Marcin Jozwiak on Unsplash.
How do stablecoin payouts work for business banking platforms?
The platform onboards each business customer, which gives the customer named accounts and a wallet. The customer funds the wallet in local currency or in stablecoin, and the platform submits a payout to a registered supplier. The provider converts the stablecoin and pays the supplier over a local rail, with the customer as sender. On Lumx, this runs through one API: customers, accounts, wallets, destinations and status notifications together.
Can a spend-management platform pay suppliers abroad for its customers?
Yes, when each customer is onboarded and pays its own suppliers from its own account. On Lumx, the payout is registered under the customer with the supplier relationship declared, and the supplier sees the customer's name. This is POBO, payment on behalf of the customer, and it works because the provider can see every party. It does not extend to paying vendors of entities that were never onboarded.
Is a named virtual account the same as a bank account?
No. Lumx is not a bank: its wallets are custodial, held with BitGo, with each customer's balance segregated. The balance is stablecoin held in custody, not a deposit. A named virtual account is an account number issued by a Lumx banking partner in the customer's own name; the customer, not the platform, is the account holder.
Which payout rails can a business banking platform use?
Lumx lists its rails and pairs on its coverage page. The rail follows the destination: Brazil is paid over Pix, Mexico over SPEI, the UK over Faster Payments, Europe over SEPA, and the United States over ACH, FEDWIRE or SWIFT. Suppliers elsewhere receive USD by SWIFT.
What happens when a payout is held for compliance?
The payout pauses and compliance sends a request for information, usually about the supplier relationship, the purpose and an invoice. The platform answers through the API and the payout continues. On Lumx this happens only when monitoring flags the payout, and a platform that already holds the invoice can answer by resending it.
