Stellar anchors vs payout API for BRL: what each covers

A Stellar anchor is a business that turns bank money into assets on the Stellar network and back, using open standards called SEPs. A payout API does the same job behind one REST integration, with its own customer verification. For BRL, the choice comes down to who verifies the user, who quotes the rate, and how many counterparties you integrate.

This post compares the two routes for Brazilian reais over Pix (Brazil's instant payment system, run by the Central Bank) on the questions that decide the pick: who owns the user, who verifies it, how a quote is held, and when the reais land. If the open question is which network to hold on, the network comparison comes first.

What a Stellar anchor does

Stellar's developer documentation defines anchors as the network's on- and off-ramps to traditional financial rails, typically operated by financial institutions or fintech companies. An anchor accepts a deposit of bank currency over an existing rail and sends the user the equivalent tokens on Stellar. In the other direction it takes tokens back and pays out bank currency. The Stellar Development Foundation (SDF) lists operating anchors in its Anchor Directory.

An anchor is standardized: it publishes its services in a stellar.toml file and authenticates clients with Stellar's web authentication (SEP-10). A wallet written against the standards can talk to any anchor that implements them. SEP stands for Stellar Ecosystem Proposal, and each one is a public specification on GitHub.

Coverage belongs to each anchor, not to Stellar. Whether an anchor serves BRL, and which bank sits behind it, are questions for that anchor, so check its directory entry before designing around it.

On Lumx the BRL leg on Stellar is a call to the REST API: you request an on-ramp from BRL with the network set to Stellar, and USDC arrives in the customer's wallet on that network. On Lumx, Stellar carries only this BRL to USDC on-ramp. The call is plain REST, and the docs describe no SEP flow.

The four flows an anchor can offer

The SDF's documentation names SEP-6, SEP-24 and SEP-31 as the most important for anchors, with SEP-38 beside them for quotes. The difference between them is mostly about who talks to the user.

The four anchor flows, with the status and version read in each specification's header on November 1, 2026.

Two details matter for a business. SEP-31 needs a bilateral agreement: the specification says the two anchors "must create bi-lateral agreements to interoperate with each other", and it expects each to hold the licenses of its own jurisdiction. And SEP-38 is still a Draft, so two anchors can implement quotes differently.

A Lumx customer never chooses among these four: the API offers on-ramp, off-ramp and transfer, and one verified customer and wallet serve all three.

What a payout API does

A payout API puts the whole route behind one contract. You are the provider's customer: it verifies you once, gives you a wallet, quotes the conversion and credits the recipient on a local rail.

What a BRL withdrawal asks of your engineering team on each route (steps counted from the SEP-24 specification and the Lumx docs).

On Lumx the off-ramp pays a registered destination from a wallet on Ethereum, Polygon or Base, since Stellar is on-ramp only, and the status moves from the stablecoin transfer to the trade to the fiat transfer and then to success.

How do anchors and a payout API compare for BRL?

The sharpest differences are structural, not a question of which route is cheaper: an anchor sets its own fees, and a provider sets its own pricing.

Anchor route and payout API route on the questions that decide a BRL flow, as of November 1, 2026.

The open standard is the real advantage of the anchor route. A wallet that speaks SEP-24 works with any compliant anchor, and no provider can lock it in. The cost is that every anchor still brings its own verification form, its own bank and its own quote server.

Who verifies the user, and how a quote is held

On SEP-24 the anchor collects KYC (know your customer, the verification of an individual) on its own hosted page, so the user answers a different form for each anchor. On SEP-6 your client collects it and sends it through SEP-12, so you must know what each anchor wants. On SEP-31 the receiving anchor asks for SEP-12 data when it needs it. In Brazil the identifier is the CPF (the Brazilian individual taxpayer ID) for a person and the CNPJ (the Brazilian company taxpayer ID) for a company, and a BRL leg on either route will ask for it. The difference is where the answer is kept: in each anchor's records, or in one verification record under your company.

Lumx verifies a company through KYB (know your business, the verification of a company and its owners), and it targets one business day for that. A wallet is usable only once the customer is approved. Each destination is verified before it can receive a payout, and every payment declares its purpose. A mismatched purpose can hold a transaction and open an RFI (request for information, a compliance hold that asks for a document before a transaction clears). Lumx needs to see every payer and payee, so you onboard the parties as customers instead of pooling their funds.

Quotes follow the same split. SEP-38 separates two kinds of price. Indicative prices come from GET /prices, and the specification says the actual price is calculated once the anchor receives the funds. A firm quote comes from POST /quote: the anchor must hold the quoted amount in reserve until expires_at, the time by which it must receive the funds. That suits BRL, since the real can move between quote and funds. Ask each anchor whether it implements SEP-38, which is optional, and how long its firm quotes last.

Lumx has the same two kinds of price. A floating rate is a live reference with no lock and no fee, used to show an estimate. A locked rate fixes the conversion for 30 seconds, 1 minute or 5 minutes, and only the 30-second lock is free. You pass the returned rate id on the transaction, and an expired id means a new request. A standing autoconversion rule always converts at market. The spread under either rate is explained in how stablecoin payout pricing works.

How BRL settles, and what Pix changes

Pix runs every day of the year with no cut-off, so the BRL leg is rarely the delay. What can be slow is what surrounds it: the anchor's bank, its review, and the time it takes to see your Stellar payment. The SEP-24 specification defines statuses, from pending_user_transfer_start to completed, but not how long the bank leg takes, so ask each anchor for its cut-off table.

The cut-off table lists Pix as instant, 24/7/365, and Lumx treats an off-ramp as complete once the funds leave its banking partner, so the recipient's own bank can still take time to show them. On a Pix payout the recipient sees the customer's name as the payer, and Lumx takes no fee out of the amount that reaches the recipient. A Pix deposit that lands after an on-ramp has expired is refunded to the sender over Pix. Conversion runs on Lumx's own liquidity and that of institutional counterparties, among them BTG Pactual. The live rates are on BRL to USDC and USDC to BRL.

Which route fits which product

A consumer wallet fits SEP-24: the user picks a local anchor and verifies on its page. A remittance business with bilateral relationships in its corridors fits SEP-31. A business that pays or collects in BRL for its own customers, and holds one verification record for each, fits a payout API. The routes mix: a wallet can offer SEP-24 to its users and still run its own BRL treasury payouts through an API.

I recommend deciding by who has to answer the compliance question for each end user. If a bank partner or a regulator will ask you who your user is, you want one verification record that you hold and can show, not one form hosted by each anchor, and that points to the API. If you build a wallet where the user is the counterparty to the anchor, hosted SEP-24 is the better fit and I would not rebuild its forms. Before choosing on price, I recommend running one test transfer on each route and timing it against the bank leg's cut-off, because the spread is the part both routes let you compare last.

When an anchor or a payout API is the wrong tool

An anchor is the wrong tool when you need one verification record under your own control, when a BRL flow has to settle on a schedule you can check against a rail's cut-off, or when no anchor holds the asset you need. A payout API is the wrong tool when the product is a wallet in which each user chooses their own anchor, or when an open standard is itself a requirement, for example when you must swap counterparties without changing code.

What the BRL to USDC corridor looks like with 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.

The BRL to USDC corridor on Stellar is live, and the launch announcement describes its start. On Stellar it is an on-ramp only. Coverage lists Stellar for USDC with BRL as the supported fiat, and every customer gets a wallet on each supported network, Stellar included. The customer is created with a BRL account, the payer sends a Pix, the on-ramp converts the reais, and USDC is credited to the wallet on Stellar. The status moves from awaiting funds through the fiat transfer, the trade and the stablecoin transfer to success, with a webhook on each change. The corridor explainer shows how the legs join.

A BRL payout goes the other way: the wallet holds USDC on Ethereum, Polygon or Base, and an off-ramp pays a registered Pix destination, as the off-ramp explainer and the step by step guide to sending USDC to Brazil describe. The rails and pairs are listed on the coverage page, and the API sits on the global payments page.

On regulation, Lumx has applied for the SPSAV (Sociedade Prestadora de Serviços de Ativos Virtuais, Brazil's virtual asset service provider authorization) and operates under the transition regime of Central Bank of Brazil (BCB) Resolution 520 of 2025, Article 88. It does not hold the authorization today. SEP-31 expects each anchor to hold the licenses of its own jurisdiction, so ask any anchor which entity and which regime stand behind its BRL leg.

Methodology and sources

Anchor definitions and the list of SEPs are from the Stellar developer documentation on Anchors, read on November 1, 2026. Versions, status, dates and quoted requirements are from the specifications on GitHub, read the same day: SEP-6, SEP-24, SEP-31, SEP-38 and SEP-12.

Product behavior was read on docs.lumx.io on November 1, 2026: Coverage, Stablecoin Wallets, Transactions, Exchange Rates, Destinations and Payment rail cut-off times. BCB Resolution 520 of 2025 links to the Central Bank's official page, which loads only through a script, so the text was not read there.

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

Cover photo: Suganth on Unsplash.