How to build a remittance app to Latin America (API guide)

A remittance app to Latin America is software where a sender in the US or Europe pays and a recipient in Brazil, Mexico or Colombia gets local currency in a bank account. It needs verified senders, funding, a locked quote and a payout on a local rail such as Pix (Brazil's instant payment system, run by the Central Bank).

The app owns the sender relationship, the screens, the pricing and the licence question. The provider owns identity checks and accounts, and runs conversion on the payout rails. The conversion in the middle runs through a stablecoin: USD to USDC on the way in and USDC to BRL on the way out.

What does a remittance app need from an API?

Six jobs, split between app and API. The sender's phone is yours; anything touching a bank is the provider's.

The six jobs of a remittance app and who does each one

Each sender must be a customer of the provider in their own right, verified through KYC (know your customer, the verification of an individual). An app that pools every sender's money in one company account and pays recipients out of it is a nested structure, and the provider cannot accept it.

On Lumx, each sender is an individual customer with a custodial wallet in their name, the recipient is a destination registered under that sender, and the whole thing is a REST API with an OpenAPI spec. The stablecoin API explainer covers the model.

How does the sender fund the transfer?

By paying a local-currency account in the sender's name, which the provider converts to stablecoin and credits to the sender's wallet. The app creates the deposit for the exact amount.

Where the sender pays from

Two funding patterns work. A deposit per transfer fits an occasional sender. A standing balance fits one who sends every payday, but it is a stored balance, which is a licence question for counsel. Deposits also expire: a floating-rate deposit lapses after 1 day on Pix and SPEI (Mexico's interbank transfer system, run by Banxico) and after 7 days on the other rails. A deposit that lands after expiry is refunded on the same rail, and the expired screen should say so.

With Lumx as the provider, creating the sender with the currency in the accounts list provisions the account, and the account.active event says it can receive money. Each deposit has to match an on-ramp created in advance for the exact amount, and onramp.success is the moment the wallet is funded and the sender can confirm. A USD account can take up to one business day to activate after approval. The on-ramp explainer covers the conversion step, and named virtual accounts the account type.

Quote the amount the recipient gets

A sender cares about one number: what lands in the recipient's account. A locked rate fixes the conversion for 30 seconds, 1 minute or 5 minutes, and the 30-second lock has no fee while the longer ones include a fee for volatility risk. A locked rate accepts either a source amount or a target amount, which is how a sender promises exactly 2,000 reais and the app works out what to take. The rate comes back as an ID, which settles the payout at the quoted price and works once. If it expires first, request another. In the docs' sample (not a live rate), 500.00 USDC gives a finalTargetAmount of 2,581.81 BRL with an expiresAt for the countdown.

I recommend that the confirm screen shows the amount received as its largest number, lets the sender type the amount the recipient should get, and uses the 30-second lock with a fresh quote when it lapses. I would pick the 30-second lock over a longer one because the longer locks carry a fee, and a sender who hesitates is better served by a screen that says the rate moved and shows the old and new amounts side by side.

Your margin is a partner fee in basis points (hundredths of a percent), a flat dollar amount or both, set separately for funding and payout. On a locked rate the fee is part of the quote, so finalTargetAmount already includes it and the sender sees one total. The mechanics are in how stablecoin payout pricing works.

The Lumx call is a locked-rate request that names the sender as the customer, the rail, the currency pair and, when you want your fee in the quote, the partner fee. A sender who wants a fixed amount takes the per-transfer path: a locked rate, then the payout with its ID.

How does the recipient get paid?

Over the recipient country's own rail, from the sender's wallet to a bank account registered earlier. The app collects the details once and registers them as a destination, which is verified before it can receive a payout.

Payout by recipient country

The destination carries the rail: SPEI takes a CLABE (the 18-digit Mexican bank account number), and Colombia's rail is fixed at registration. A Bre-B (Colombia's instant payment system, run by the Banco de la República) payout above 1,000 UVB per operation (COP 12,110,000 in 2026), the cap in section 3.2 of the Banco de la República's Circular Reglamentaria Externa DSP-465 of March 31, 2026, is refused and never split. ACH Colombia is the rail for a larger transfer.

Every destination carries a holder relationship, RELATIVE for family or FRIEND for a friend, and it is a compliance field and not a label. The payout carries a purpose code: BILLS for a person-to-person transfer, or PERSONAL_ACCOUNT when the sender is paying their own account. Register the recipient when the sender saves them, not at confirm, because approval takes time. Rails are compared in Latin America payout rails compared, and the corridor explainer shows how a pair becomes a route.

The Lumx payout is an off-ramp that debits the sender's wallet, and the off-ramp explainer covers the conversion step. Lumx takes no fee out of the amount that reaches the recipient on a Pix, SPEI or Bre-B payout, and only the recipient's bank can charge them. On a Pix payout and a SPEI payout the recipient's statement shows the sender as the payer, because the sender is the customer (effective November 2026 for Pix, which the public docs still describe as paid in Lumx's name).

What the sender's screen shows when something goes wrong

A remittance fails in ten places, and each needs a sentence the sender can act on. Match on the code, never the message text.

Failure points, the signal behind each, and what the screen should say

A double tap is its own failure, so send an idempotency key, a UUID v4 stored before the request goes out, on every request that creates something: the same key with the same body returns the first response, a different body returns a 409, and keys expire after 24 hours. A retry that mints a new key pays twice.

The happy path runs offramp.transferring_stablecoin, offramp.trading, offramp.transferring_fiat and offramp.success. Hold the transfer in a pending state until offramp.success or offramp.failed arrives, and reconcile on the webhook rather than on a timer. Call the last one "Sent", not "Received": the docs' SLA page defines completion as funds leaving the banking partner, and the recipient's bank can still hold them for its own review.

When Lumx monitoring flags a transaction, it waits on an RFI (request for information, a compliance hold that asks for a document before a transaction clears), and a large transfer can add up to two business hours of risk review.

Limits per sender and what the app earns

Limits are per customer, so per sender, and enhanced verification lifts them to fit the capacity the sender documents.

Default limits by verification tier, in USD, read November 1, 2026

Funding is an on-ramp and the payout is an off-ramp, and each counts only against its own type of limit.

Reading the customer on Lumx with includeTransactionLimits=true returns the maximum and the used and remaining amounts per type, so the screen shows the room before the sender types. A request above a limit is rejected, not held, and higher limits come through a limit increase request, from the dashboard or the API, with a review target of one day. Pricing is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans (pricing compared).

Who verifies the sender and who holds the licence

Your app owns the licence question. Whether sending money abroad for consumers needs a licence or a licensed partner depends on the sender's country and on how you describe and charge for the service, so take it to counsel in each one.

Sender-facing disclosures stay with the app too, and in the United States they come from Regulation E, subpart B (12 CFR part 1005, Remittance Transfers), which implements section 1073 of the Dodd-Frank Act (Public Law 111-203, 2010). The US remittance rule explained covers it in detail. The docs list unlicensed remittance operators among the businesses the provider does not serve.

At onboarding, Lumx has each sender accept the terms on a hosted page and completes KYC, with a target of 1 business day for a standard individual review once the documents are in. A sender who already passed KYC elsewhere can reuse it through Sumsub token sharing. Your app is onboarded by Lumx as a business partner and discloses its money-services activity, which the docs class as high risk, so expect enhanced due diligence and a longer verification window. Each destination is verified before it can receive money. The app's own AML programme and the monitoring of its senders stay with the app. Lumx is not a bank, the sender's money sits in a custodial wallet in their name, and the sender's country has to be on the supported-countries list.

When a remittance app is the wrong build

• You have no licence and no licensed partner. The provider does not serve unlicensed remittance operators.

• Your model needs one pooled balance for all senders. Each sender has to be its own customer.

• Your senders are companies. A company paying suppliers needs business verification and invoice references, which is a payout flow. See marketplace payouts.

What this 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.

A sender in Texas sends 500 dollars to a mother in Belo Horizonte. The app creates the sender as an individual customer with a USD account, and once the sender passes KYC the account goes active. An on-ramp for 500.00 over ACH shows the routing and account numbers and waits for onramp.success. The mother's Pix key is registered as a RELATIVE destination, ready once destinations.approved arrives. At confirm, the app requests a 30-second locked rate, shows finalTargetAmount, and on the tap sends the off-ramp with the rate ID and BILLS.

Integration through the API takes 2 to 3 weeks to go-live, and your team uses the Lumx dashboard alongside it. The sandbox runs the whole loop without a bank transfer, and the last digit of the sender's tax ID picks the verification outcome, so the unhappy screens can be built before launch. The global payments page shows how collections and payouts compose, and the coverage page lists rails.

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

Cover photo: Big Dodzy on Unsplash.