Wallet for end users

What you'll build

A system where each of your end users has their own balance, their own CLABE to receive money, and a clean movements history. The building block for neobanks, marketplaces that hold seller balances, gig-worker apps, and anything where "user balance" is a first-class concept.

When to use it

• Neobanks and fintech apps.
• B2B platforms holding client funds.
• Marketplaces or gig platforms where sellers accumulate earnings before cashing out.

Three patterns — pick one

You have three ways to model "user wallet" on top of Fintoc, from cheapest to richest. Start with the simplest that fits.

Pattern A — One Account Number per user (virtual CLABEs)

• Structure: one Fintoc Account (yours) with many Account Numbers, one per user.
• Per-user balance: you track it in your own database. Fintoc holds the aggregate.
• KYB: none per user — only your Root Entity is onboarded.

flowchart LR
    S1[Sender for user 1] -->|SPEI| C1[CLABE 1]
    S2[Sender for user 2] -->|SPEI| C2[CLABE 2]
    C1 --> A[Your Account<br/>single total balance]
    C2 --> A
    A -.webhook.-> DB[(Your DB<br/>balance_user1 += amount)]

Set up:

1. Use your Root Account.
2. Create one Account Number per user with metadata.user_id.
3. On transfer.inbound.succeeded, credit the user's balance in your DB.
4. For withdrawals, create an outbound Transfer from your Root Account and debit the user's balance in your DB.

Good for: lightweight wallets, earnings, simple deposit/withdraw.

Pattern B — One Account per user under your Entity (sub-accounts)

• Structure: many Accounts, all under your Entity. Each has its own balance and its own root CLABE.
• Per-user balance: Fintoc tracks it at the Account level. Visible in Dashboard and statements.
• KYB: none per user.

flowchart LR
    S1[Sender for user 1] -->|SPEI| A1[Account: user 1<br/>own CLABE + balance]
    S2[Sender for user 2] -->|SPEI| A2[Account: user 2<br/>own CLABE + balance]
    A1 -.webhook.-> You[(Your backend)]
    A2 -.webhook.-> You

Set up:

1. POST /v2/accounts with your Entity's ID. Account is created instantly with a root CLABE.
2. On transfer.inbound.succeeded, use data.account_id to identify the user.
3. Withdrawals use that account_id as the source of funds.

Good for: wallets where you want Fintoc to ledger balances per user. Works in both MX and CL.

Pattern C — One Account per user under their own Entity

• Structure: many Entities (one per client), each with its own Account and root CLABE.
• Per-user balance: Fintoc tracks at the Account level.
• KYB: required per Entity (≈1 business day per client).

flowchart LR
    S1[Customer of A] -->|SPEI| A1[Account A<br/>Client A Entity]
    S2[Customer of B] -->|SPEI| A2[Account B<br/>Client B Entity]
    A1 -->|Withdrawal<br/>CEP: Client A name| O1[Client A bank]
    A2 -->|Withdrawal<br/>CEP: Client B name| O2[Client B bank]

Set up:

1. Create an Entity in the Dashboard for the client.
2. Fintoc runs KYB; you get notified when it's approved.
3. Once approved, create an Account under that Entity. Outbound transfers from that Account show the client's legal name on the CEP.

Good for: flows where receipts must show the client's name (e.g., a food delivery platform paying each restaurant under that restaurant's RFC).

Choosing between them