---
title: "How to build a dollar account app for users in Latin America"
seoTitle: "How to build a dollar account app for Latin America"
description: "Build a dollar account app for Brazil, Mexico, and Colombia: a 7-step user journey, money in and money out paths, disclosures, and where BlindPay fits."
date: "2026-10-22"
updated: "2026-10-22"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "How do I build a dollar account app for Latin America?"
    a: "Give each user verified onboarding, a dollar balance, ways to fund it in dollars and in local currency, and a fast way to cash out to a local bank. Most 2026 builds hold the balance as USDC and use an API such as BlindPay for US account details, Pix and SPEI deposits, and local payouts, while the app owns the ledger, the screens, and the user relationship."
  - q: "Is a USDC balance the same as a US bank deposit?"
    a: "No. A USDC balance is a claim on a stablecoin that its issuer says is fully backed and redeemable one to one with US dollars. It is not a bank deposit and is not covered by deposit insurance. Say this plainly in your terms and on the balance screen, so users understand what they hold before they move savings into the app."
  - q: "How do users in Latin America receive US dollars from abroad?"
    a: "The cleanest path is a US virtual account in the user's own name. A US client or employer sends ACH, a domestic wire, or SWIFT to the routing and account number, and each deposit converts to USDC or USDT in the linked wallet. BlindPay US virtual accounts cost $1.50 per month per account and go through a compliance and bank review."
  - q: "How do users cash out dollars to a local bank account?"
    a: "With a payout from the dollar balance to a local rail: Pix in Brazil, SPEI in Mexico, ACH Colombia in Colombia, or Transfers 3.0 in Argentina. The app requests a quote that locks the rate and fees for 5 minutes, shows the local amount, and executes on confirmation. The money lands in the user's own bank account in local currency."
  - q: "Which users need extra verification in a dollar account app?"
    a: "Everyone needs identity verification before moving money. On BlindPay, KYC Standard is automated and typically completes in about 60 seconds, while users from high-risk countries go through KYC Enhanced, which adds documents and a manual compliance review. Plan the screens for both paths and tell users how long each one takes."
  - q: "What should a dollar account app disclose to users?"
    a: "Disclose what the balance is (a stablecoin, not a bank deposit), who holds it, the exchange rate and every fee before confirmation, the expected arrival time per rail, what happens if a transfer fails, and how to contact support. Show the final amount the recipient gets, not only the rate, and keep a receipt for every movement."
---

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](/resources/more/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](/docs/learn/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.

| Direction | Path | What the user does | Lands as |
| --- | --- | --- | --- |
| In, from abroad | US virtual account (ACH, Wire, SWIFT) | Shares routing and account number with a client | USDC or USDT in the linked wallet |
| In, local Brazil | Pix payin | Pays a Pix code from their bank app | USDC at a quoted rate |
| In, local Mexico | SPEI payin, or a permanent SPEI CLABE | Sends SPEI from their bank | USDC at the live MXN rate |
| In, local Colombia | PSE payin, or a Bre-B key | Pays from their Colombian bank | USDC at the COP rate |
| Out, Brazil | Pix payout | Picks a saved Pix account, confirms a quote | BRL in their bank account |
| Out, Mexico | SPEI payout | Enters a CLABE, confirms a quote | MXN in their bank account |
| Out, Colombia | ACH Colombia payout | Picks a saved account | COP, about 1 business day |
| Out, Argentina | Transfers 3.0 payout | Enters the CBU of their account | ARS in their bank account |
| Out, US | ACH, Wire, or RTP | Pays a US account, theirs or a supplier's | USD |

Pix is the instant payment system run by the [Banco Central do Brasil](https://www.bcb.gov.br/en/financialstability/pix_en). SPEI is Banco de México's interbank system, and [Banxico's SPEI page](https://www.banxico.org.mx/services/interbanking-electronic-payme.html) 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](/resources/more/pix-vs-spei) and the [Latin America payout cheat sheet](/resources/more/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](https://www.circle.com/transparency).
- 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.

| Line | Value |
| --- | --- |
| You send | 500.00 USD (held as USDC) |
| Exchange rate on the quote | 5.40 BRL per USD |
| Fees on the quote | 2.50 USD |
| Your app's fee | 2.00 USD |
| They receive | 2,675.70 BRL |
| Arrives | Usually within minutes over Pix |

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](/docs/learn/partner-fees). For screen copy, see [how to show a cross-border quote](/resources/more/cross-border-quote-screen-fee-disclosure).

## 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](/resources/more/psav-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](/resources/more/brazil-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](/resources/more/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](/pricing), 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](/docs/payins) and the [Pix payout feature guide](/resources/more/neobank-pix-transfer-feature).