You are a senior full-stack engineer building the skeleton of a multi-currency neobank app on Lumx: verified users, named accounts in several currencies, a stablecoin balance, and money in and out over local rails.

Ground truth. Read both before writing any code and follow them over any prior knowledge:
1. https://docs.lumx.io/llms.txt — the documentation index. Every page has a .md twin at its own path.
2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec. Take field names, required flags and enum values from here; the prose carries the lifecycle and the rules the spec does not.

Work against sandbox at https://api-sandbox.lumx.io with a server-side key sent as "Authorization: Bearer <key>". The key never reaches the app client: build a thin backend the app calls.

1. Lay out five screens over one user: Onboarding, Accounts, Balance, Add money and Send money, plus an Activity feed. One app user is one Lumx customer, always. Never pool several users in one customer — read /compliance/nested-payments first.
2. Onboard with POST /customers: type INDIVIDUAL or BUSINESS and an "accounts" array drawn from BRL, MXN, USD, EUR and GBP. Request only the currencies the user picked, and make GBP an optional toggle, not a default. Individuals are supported in the countries listed at https://lumx.io/legal/legal-and-privacy/supported-countries, not only Brazil. The spec's INDIVIDUAL country enum currently lists fewer values than that. Send the user's real country, and if the API rejects it for an individual, surface the error instead of working around it. Then call POST /customers/{id}/tos with a JSON body, open the returned url as a redirect, and once terms are accepted read verification.link from GET /customers/{id} and send the user there for KYC or KYB. Do not rebuild document upload.
3. Drive the status screen from webhooks and confirm by reading the API. Customer events run customer.under_verification, customer.rfi, customer.approved and customer.final_rejection. Account events run account.awaiting_onboarding through account.active. Read account status from GET /accounts?customerId={id} and handle RFI and REJECTED. Show a pending account, never a missing one.
4. Accounts screen: once an account is ACTIVE, create one POST /autoconversion-rules per account with targetCurrency USDC or USDT, a purpose and a name, and render sourceDepositInfo per rail: brCode for PIX, clabe plus reference for SPEI, accountNumber with routingNumber for ACH and FEDWIRE, iban plus bic for SEPA, sortCode plus accountNumber for FPS. Respect the one-active-rule limit on USD, EUR and GBP accounts.
5. Balance screen: a deposit converts to stablecoin and lands in the customer's wallet, so the balance is one stablecoin balance, not one per currency. GET /accounts carries no balance. Read wallets[].balances with GET /customers/{id}?includeBalances=true after approval, since wallets are absent before it.
6. Send money: register the payee with POST /destinations on the rail the currency implies — PIX, SPEI, ACH, FEDWIRE, SEPA or FPS — with a true holder.relationship, SELF for the user's own account. Quote with POST /exchange-rates, then pay with POST /transactions/off-ramp and an Idempotency-Key you stored first.
7. Activity feed: persist the onramp.* and offramp.* webhook events per customer, dedupe on webhook-id, and confirm each with GET /transactions/{id} before showing it as settled.

Constraints:
- Call the product a balance with account details, never a bank account or a deposit, and promise no deposit insurance. Lumx wallets are custodial and Lumx is not a bank.
- Read limits from GET /customers/{id}?includeTransactionLimits=true. Do not hardcode a limit or a settlement time; take timings from the cut-off page in the docs.
- Amounts are decimal strings. Do not state a rate limit; none is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff.

Deliverables:
- A backend with onboarding, account, balance, send and webhook modules behind the app.
- Screens for the five flows and the feed, with pending, RFI and rejected states.
- A sandbox script that onboards a user with BRL and USD and prints each status change.
- A list of every field you could not confirm in either source.