How to build a dollar account app for users in Latin America

A dollar account app for Latin America lets people receive, hold, and spend US dollars from a phone, then cash out to their local bank within minutes. In 2026 most builds hold the balance as USDC and use BlindPay for the money movement: US account details, Pix and SPEI deposits, and payouts to local bank accounts.

The app still owns the hard product work: onboarding, the ledger, the screens, pricing, and support. This guide walks through the user journey, the money paths, the disclosures, and where the infrastructure sits. It is part of the series on how to build a neobank.

Key takeaways

• Users want three things: get paid in dollars, keep dollars, and spend or withdraw locally without losing a day or a big cut.
• The balance is usually USDC, a stablecoin (a token that tracks the US dollar one to one). Treat it as a product disclosure, not a footnote.
• Money in has two shapes: dollars from abroad into a US account, and local currency (Pix, SPEI) converted into dollars.
• Money out is a quote plus a local payout over Pix, SPEI, ACH Colombia, or Transfers 3.0.
• BlindPay is the best fit for this build: teams of any size, payouts on named local rails, compliance in the API, and a non-custodial payout model.

Why do people in Latin America want a dollar account?

Because their income, savings, or suppliers already live in dollars, and their local bank makes dollars slow or expensive to reach.

Three groups show up again and again:

1. Freelancers and remote workers paid by US clients. A wire to a local bank can take days and arrives after a conversion they didn't choose.
2. Savers who want part of their money in dollars, especially in countries where the local currency has lost value over time.
3. Small businesses that import, pay US software, or sell to US buyers.

You don't need a market study to see the need. Ask ten target users how they get paid and how they cash out. If the answers involve an exchange account, a cousin in Miami, or a three-day wait, you have a product.

What does the user journey look like, step by step?

Seven steps, from download to first local withdrawal. Each one needs a screen, an API call, and a support answer.

1. Sign up and accept terms. The user creates an account and accepts your terms plus your provider's terms. On BlindPay, the user accepts the terms of service on a hosted page before you create them as a customer (see terms of service).
2. Verify identity. Collect ID, selfie, address, and tax ID (CPF in Brazil, RFC or CURP in Mexico). Show the expected wait.
3. Open the dollar balance. Create the wallet that holds USDC for this user, and your own ledger account that shows the balance in dollars.
4. Issue account details. Give the user US routing and account numbers to share with clients, plus local deposit details where you support them.
5. Receive the first deposit. A client sends ACH, a wire, or SWIFT. The deposit converts to USDC and the app credits the user.
6. Show the balance and history. Dollars first. Every line shows the source, the amount, fees, and the time.
7. Cash out locally. The user picks Pix or SPEI, sees the local amount and fee on a quote, confirms, and gets a receipt with the expected arrival time.

Steps 2 and 4 decide your activation rate. If a user waits days for account details, they don't come back.

How does money get in, and how does it get out?

Through bank rails on both ends, with USDC in the middle.

Pix is the instant payment system run by the Banco Central do Brasil. SPEI is Banco de México's interbank system, and Banxico's SPEI page explains the 18-digit CLABE every Mexican account carries.

Two details matter for Mexico and Colombia. A SPEI CLABE virtual account gives each user a permanent 18-digit CLABE, and every deposit becomes a new payin at the live MXN rate. A Bre-B key does the same in Colombia for users with a Colombian ID or NIT. In both cases the payer sees a pooled recipient name, not your user's name, so tell users what their payer will see. The rail details are in Pix vs SPEI and the Latin America payout cheat sheet.

How should you design the dollar balance itself?

Keep two records and make them agree every day: your ledger, which the user sees, and the wallet, which holds the USDC.

The wallet can sit in different places. Some teams use BlindPay-managed wallets (in beta, custodial, with production access on request). Others keep USDC in a wallet the user or the company controls through a wallet provider, and fund each payout from it. That choice decides who holds the money and what you must disclose, so make it early.

Design rules that save support tickets:

• Show the balance in USD, with "held as USDC" one tap away, and link the issuer's own USDC reserve reports.
• Separate pending from available. A deposit that is still converting is pending.
• Never show a local currency balance that moves with the rate unless you label it as an estimate.

How do you keep FX pricing transparent?

Show the user the amount they get, not only the rate. A quote locks the rate and fees for a short window, so the number on screen is the number that arrives.

Illustrative example, invented numbers: a freelancer in São Paulo cashes out 500 USD.

The formula: received = (amount minus all fees) times the quoted rate. Here, 495.50 times 5.40 = 2,675.70 BRL. Show the math the same way in the app and the receipt never surprises anyone.

On BlindPay, a payout quote locks the rate and fees for 5 minutes by default, and your platform can add its own fee to each transaction through partner fees. For screen copy, see how to show a cross-border quote.

What should you disclose to users?

Everything a user needs to decide before money moves, and everything support will be asked after.

• What the balance is: a stablecoin balance, not a bank deposit, and not covered by deposit insurance.
• Who holds the funds, and what happens if your company or a provider stops operating.
• The rate, every fee, and the final amount, before the user confirms.
• Expected arrival time per rail, and that bank holidays can affect some rails.
• What happens if a transfer fails, and how long a refund takes.
• Limits per transfer and per month, and why verification can ask for more documents.
• How to reach a human.

Which rules apply in each country?

It depends on where your users live and what you hold for them. This is educational content, not legal advice.

Brazil regulates virtual asset service providers through the Central Bank, see PSAV in Brazil explained, and Brazilians moving US$10,000 or more to self-custody wallets face a reporting rule, covered in Brazil's self-custody wallet declaration. Mexico and other markets have their own rules on who can offer virtual assets to the public; are blockchain payments legal summarizes the US, EU, UK, Brazil, and Mexico.

Questions to settle with counsel before launch:

1. Do you need a local license, a partner, or both, to offer the balance in each country?
2. Who is the customer of record for each payment provider?
3. Which tax IDs and reports apply to your users' dollar holdings?

What are the common mistakes?

• Calling the balance a "bank account" when it is a stablecoin balance.
• Showing the rate without the final local amount.
• Letting users type a CLABE or Pix key without checks. Validate formats and confirm the recipient name where the rail returns it.
• Treating a deposit as available before the payin completes.
• Launching four countries at once. Start with one corridor, measure, then add.
• Hiding that payers see a pooled name on CLABE and Bre-B deposits, then fielding "is this a scam" tickets.

How BlindPay fits

BlindPay is the money movement and compliance layer under the app. US virtual accounts give each user a real US account in their own name, with routing and account numbers, and every deposit settles to USDC or USDT in the linked wallet. SPEI CLABE accounts and Bre-B keys add local deposits in Mexico and Colombia. Payins collect Pix, SPEI, PSE, and Transfers 3.0. Payouts send to Pix, SPEI, ACH Colombia, Transfers 3.0, ACH, wire, RTP, and SWIFT (POBO/COBO), each with a quote that locks rate and fees before execution.

KYC and KYB run in the API, and BlindPay is registered with FinCEN as a Money Services Business. For payouts from customer-controlled wallets, BlindPay is non-custodial: you authorize the exact amount and BlindPay executes that one transaction. Plans are on the pricing page, with per-transaction fees shown in each quote.

For this scenario, teams of any size paying users out in Latin America over named local rails with compliance handled, BlindPay is the best fit.

What to do next

Map your first corridor: where users earn dollars, and which local rail they cash out on. Then create a development instance and run one deposit and one payout end to end with the payins docs and the Pix payout feature guide.