A Latin America neobank launch checklist is a plan that takes a team from scope to its first live customers in 90 days: 30 days to fix the licensing route, the vendors and one country, 30 to build and test every money flow, and 30 to pilot against written launch criteria. It assumes a licensed partner holds the regulated parts.
The 30, 60 and 90 split is a planning template we wrote, not a Lumx service level, and buys a pilot in one country. The economics are in how Latin American neobanks make money.
Four decisions that set the 90 days
Four decisions decide whether the calendar holds, and none is engineering speed.
The licensing route. A launch on a licensed partner fits in 90 days, an assumption of our planning template: the regulated parts sit with the partner, so the calendar is engineering and verification time. A launch that waits for its own authorization does not. The partner and the scope of what it holds are chosen with counsel, and Lumx is not that partner. The Brazilian version of this decision is in the neobank license guide, and whether you need a local entity at all is in the local entity guide. Both belong to counsel, and the answer is due on day 30. For a US launch, see the US version of this checklist.
One country first. Every added country adds a rail, a set of identity documents and a support script.
One money loop. Money in, a balance, money out. Dollar balances are covered in launching a dollar account app.
One named owner for compliance, a person and not a committee.
A rail found unavailable on day 70 restarts days 31 to 60.
What does it cost? On Lumx the pricing model is monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, and no published plans. The standard agreement has no setup fee and has a monthly minimum. There is no pre-funding: no capital sits in settlement accounts before a transaction, because conversion and settlement happen when it starts.
Days 1 to 30: decide the route, the corridor and the vendors
Days 1 to 30, with an owner and a test for each task
# | Task | Owner | Done when |
1 | Pick one user type, one country, one money loop | Product | Founders signed a one-page scope |
2 | Choose the licensing route | Counsel, Compliance | A written route is on file, with the stablecoin regulation and Mexico CNBV pages read for your country |
3 | Map every money flow | Product, Engineering | Every arrow names a rail and an owner |
4 | Check the rails against coverage | Engineering | Each rail matches the coverage page read that week |
5 | Pick vendors and open the sandbox | Product, Engineering | A sandbox customer is created end to end |
6 | Draft the compliance program | Compliance | Counsel signed the AML and verification policies, read with AML for stablecoin fintechs |
7 | Design onboarding, add money and withdraw screens | Product | Target users finish each flow without help |
8 | Write the launch criteria | Product, Compliance | The pass or fail list below is signed before the build starts |
Choose vendors on stablecoin corridor coverage, verification model and who holds the funds.
On Lumx, sandbox and production are separate environments with the same API, new accounts start in the sandbox, and the sandbox is open and self-serve. Sandbox runs on test stablecoins with mock banking partners, so no real money moves.
Which rails should the first launch run on?
The ones already live in your first country, tested in both directions. A rail a vendor lists as planned is not a launch rail.
Pix (Brazil's instant payment system) and SPEI (Mexico's interbank transfer system) run every day, and SPEI pays to a CLABE (the 18-digit Mexican bank account number). Colombia collects by Bre-B (its instant payment system) or PSE (its online bank-transfer network) and pays by Bre-B or ACH Colombia.
Rails by country for a first launch, as of November 1, 2026
Country | Money in | Money out | Timing | Test before launch |
Brazil | Pix to a BRL account | Pix | 24/7/365, no cut-off | A deposit and a payout on a Sunday |
Mexico | SPEI to a CLABE | SPEI | 24/7/365, no cut-off | A deposit and a payout on a bank holiday in the Banxico calendar |
Colombia | Bre-B key of the COP account, or PSE | Bre-B or ACH Colombia | Bre-B cap applies per payout | A payout above the Bre-B cap is refused, so route it to ACH Colombia |
United States | ACH, FEDWIRE or SWIFT into a USD account | ACH, FEDWIRE or SWIFT | USD account up to 1 business day to open; cut-offs 2:00 PM ET for ACH, 3:00 PM ET for FEDWIRE and SWIFT | A request after the cut-off goes out the next business day |
The Bre-B cap is 1,000 UVB per operation, set in section 3.2 of the Banco de la República's Circular Reglamentaria Externa DSP-465 of March 31, 2026. Its "Conozca Bre-B" page puts that at COP 12,110,000 for 2026 and describes Bre-B as instant. PSE is a pull rail, so it collects but does not pay out. SPEI has no cut-off, but holiday handling follows the Banxico calendar in the Lumx docs, where a request on a recognised holiday is queued to the next business day, so test it.
On Lumx, BRL, MXN and COP accounts open right after the customer is approved, and a USD account takes up to one business day. The account type that carries the deposit details is a named virtual account (a local account number issued in the customer's own name), and a foreign company holds one in BRL or MXN without a local entity, as multi-currency accounts without a local entity explains.
Days 31 to 60: build and test every money flow, including the ugly ones
Each row is finished when its failure path is tested.
Days 31 to 60, with an owner and a test for each task
# | Task | Owner | Done when |
9 | Onboarding with KYC and KYB | Engineering | Approved, RFI and final rejection paths each tested |
10 | Terms acceptance | Engineering | The hosted terms page opens as a redirect, not an iframe |
11 | Accounts and deposit details | Engineering | An |
12 | Ledger and balances | Engineering | Pending and available balances reconcile daily with no breaks |
13 | Money in | Engineering | A late, a duplicate and an expired deposit each behave as designed |
14 | Money out | Engineering | The destination is approved before the first payout, and a failed payout shows its reason |
15 | Limits | Engineering, Compliance | Remaining headroom is read before each withdrawal |
16 | Pricing and partner fee | Product | The amount on the quote screen equals the amount received |
17 | Support playbooks for the top ten tickets and vendor escalation contacts | Operations | Compliance and Product signed them |
18 | Terms, fee schedule and balance disclosure | Counsel | Live in the app, with the balance described as a balance and not a bank deposit |
Verification is the long pole. KYC (know your customer, the verification of an individual) for people, and KYB (know your business, the verification of a company and its owners) for companies. An RFI (request for information, a compliance hold that asks for a document before a transaction clears) resets the review clock when you resubmit, so build the screen that names the missing document. The KYB onboarding flow and what KYB is cover the business side.
On Lumx, each user is a customer who accepts the terms on a hosted page, then goes through verification: KYC targets one business day and KYB targets one business day (effective November 2026), as targets and not guarantees, with an enhanced review taking longer. In the sandbox the last digit of the tax ID drives the outcome, so a 2 forces an RFI and a 3 forces a final rejection. Standard KYC limits default to USD 7,500 per transaction and USD 15,000 a day, and passing includeTransactionLimits=true when reading a customer returns the headroom left. A request above the limit is rejected.
Days 61 to 90: pilot with real users against the written criteria
Days 61 to 90, with an owner and a test for each task
# | Task | Owner | Done when |
19 | Production keys and server IP allowlist | Engineering | The first production call comes from an allowlisted address |
20 | Employee test | Everyone | One real deposit and one real payout per rail, with receipts matching balances |
21 | Pilot cohort | Product | Invited users are onboarded, in one country |
22 | Weekly metrics review | Product | The four numbers below are discussed every week |
23 | Incident drill | Operations, Engineering | A failed payout, a stuck deposit and an RFI are each resolved inside the target time |
24 | Compliance review of pilot activity | Compliance | No alert is open longer than a week |
25 | Go or no-go memo | Product, Compliance | Every criterion in the next table passes |
On Lumx, the production API accepts calls only from allowlisted server IPs, with the docs giving September 21, 2026 as the date enforcement starts, and sandbox accepts any IP.
I recommend giving the compliance owner the only veto on the go decision, and I would not widen the pilot until a full week of reconciliation has closed with no breaks. A product lead who owns both the date and the verdict will rarely say no to the date.
What belongs on the go-live criteria?
Ten pass or fail tests. Launch when all ten pass, not on day 90.
Go-live criteria, each with its evidence
# | Criterion | Evidence |
1 | Licensing route confirmed in writing | Counsel memo and signed partner agreements on file |
2 | Verification works on every path | Approved, RFI and final rejection each reached in the sandbox, then once in production |
3 | Every requested account is live |
|
4 | A deposit credits exactly once |
|
5 | A payout reaches the destination |
|
6 | Failures are shown with a reason |
|
7 | Limits are visible to the user | Remaining headroom shown before the withdrawal is confirmed |
8 | Reconciliation runs daily | Ledger, bank statement and wallet balance agree for a full week |
9 | Support can answer the top ten tickets | Playbooks signed, escalation contact per vendor |
10 | Disclosures are live | Terms, fee schedule and balance description in the app |
On Lumx, each event above arrives as a webhook event with a unique eventId, so deduplicating is a lookup.
Which metrics matter in the first 90 days?
Four numbers, measured weekly from the first pilot user.
The four launch metrics, how to compute them and what they tell you
Metric | Formula | What it tells you |
Activation rate | Users with a first deposit divided by verified users | Whether the product is worth funding |
Time to first deposit | Median time from verified to first deposit | Where onboarding stalls |
Payout success rate | Completed payouts divided by payouts started | Destination data quality and rail health |
Tickets per 100 active users | Tickets divided by active users, times 100 | Where the app confuses people |
Many users verifying and few funding points at the deposit instructions, not at the next feature. That is our rule of thumb, not a benchmark.
When a 90-day plan is the wrong plan
Your own authorization has to come first. Then the calendar is the regulator's.
Three countries on day one. A second country restarts days 31 to 60 for its rail.
Cards are the product. Cards are a separate workstream with their own providers. On Lumx, the card comes from your own issuing stack, and Lumx carries the funding: a Pix, SPEI or PSE deposit that becomes stablecoin in the wallet, and an off-ramp for the cash-out.
A pooled balance for many people. Each user has to be a customer of their own, because under the nested payments rules one account does not move money for parties Lumx has not onboarded, unless Lumx has approved the structure in writing.
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.
Lumx is not a bank and does not replace your licensing route. In Brazil, services are provided by Lumx's SPSAV (Sociedade Prestadora de Serviços de Ativos Virtuais, the company type that holds an authorization for virtual asset services), which filed its application and operates under the Article 88 transition regime of Central Bank of Brazil Resolution 520/2025. Lumx is not your licensed partner.
The integration is a REST API with an OpenAPI specification and a docs MCP server, and takes two to three weeks to go-live. The integration guide walks the calls, named virtual accounts describes the account type, and supported countries lists where customers can be onboarded. See also what stablecoin banking is.
Methodology and sources
Product facts come from the Lumx documentation, read on November 1, 2026, and from Lumx's current product decisions on the Colombian rails and the one business day KYB target. Pages read: Coverage, payment rail cut-off times, Accounts, Identity Verification, Transaction Limits, Webhooks, Idempotency, Authentication, Environments and Nested Payments. The 1,000 UVB Bre-B cap is from the Banco de la República's Circular Reglamentaria Externa DSP-465, and the COP 12,110,000 value from its Conozca Bre-B page.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Tim Mossholder on Unsplash.
What should a Latin America neobank launch checklist include?
One country and one money loop, a written licensing route, a named compliance owner, vendors chosen in month one, every money flow tested including failures, a real-user pilot, and go-live criteria written before the build. On Lumx, the sandbox tests verification, deposits, payouts and webhooks before any real money moves.
Can a neobank launch in Latin America in 90 days?
Yes, as a pilot in one country, when a licensed partner holds the regulated parts and vendors are chosen in month one. Waiting for your own authorization takes longer. On Lumx, an API integration takes two to three weeks to go-live, and the Lumx dashboard is available beside the API.
Which countries and rails should a neobank launch with first?
Start where your first users live, on a rail that runs every day such as Pix or SPEI, then add the next country after a clean month of reconciliations. On Lumx, Pix and SPEI have no cut-off and run 24/7/365, and Colombia collects by Bre-B or PSE and pays by Bre-B or ACH Colombia.
How long does it take to verify a neobank's customers?
Plan for about one business day on a standard review, longer on an enhanced one and again after each RFI. On Lumx, KYC targets one business day, KYB targets one business day, and the customer events tell your app when each user is approved or needs a document.
When should a neobank add cards?
After money in and out work and users ask to spend the balance, since a card program is a separate workstream. On Lumx, card funding works as a local-currency top-up that becomes stablecoin in the wallet, and the cash-out is an off-ramp, while the card itself comes from your own issuing stack.
