Exchange the platform's API credentials for a short-lived Bearer token (~20 minutes). Reuse the same token string in every later call in this demo.

Provision the omnibus MXN Cobre Balance on provider pr_mex_cobre3 — the provider that supports layering many player Virtual CLABEs on a single balance. Create it once, before onboarding any player; every player's Virtual CLABE (from the next step onward) is issued against this same account.

One stream feeds several systems in parallel: the compliance transaction-monitoring engine, the platform's ledger, and treasury. Include accounts.balance.credit (Virtual CLABE deposit, no Money Movement is created), the withdrawal's Money Movement statuses, and returned for SPEI returns. Verify deliveries with HMAC-SHA256.

At sign-up, every player on the platform receives their own permanent, exclusive CLABE over the MXN Cobre Balance. The player saves it once as a frequent payee in their bank. From then on, funding does not require opening the platform: they transfer straight from their banking app. Attribution is deterministic — the CLABE is the player; there is no numeric reference the user has to type.

Account Verification is the backbone of the "register your bank account" flow. The player declares their CLABE; Cobre confirms it exists and cross-checks the holder's data against the RFC/CURP already verified in the platform's identity stack. Creation returns processing — do not treat processing as authorization. Continue only once the later GET returns matched.

Poll GET until status.state is completed. Enable the account only if verification_response.verification_result is matched. Unmatched or failed go to review — funding and withdrawal are not enabled. This turns the same-holder principle from a process control into a system control.

Only after matched: register the player's CLABE as a SPEI counterparty. This is the only account enabled to receive withdrawals. Normalize accents in counterparty_fullname — special characters are not allowed.

The player transfers MXN 2,500.00 via SPEI to their platform CLABE (703013052111000038). Cobre credits the Cobre Balance with spei_credit — no Money Movement is created. metadata.account_reference attributes the credit to player 10042. metadata.sender_clabe is the source control: the platform accepts the deposit only if it matches the player's registered, verified CLABE. A third-party deposit is identified at the moment and flagged or rejected. Because every CLABE is tied to one player, caps (amount, daily/monthly accumulated, transaction count) are enforced at the moment of credit.

Match the accounts.balance.credit webhook against the platform's ledger. Attribution: account_reference → player. Source control: sender_clabe must be the registered CLABE. If it does not match, flag or reject the deposit (third party). Apply funding caps by profile (per operation, daily, monthly, transaction count) at this moment — not afterward.

Mapping the webhook payload from an earlier step onto Platform ledger / Compliance. No API call is made — this step closes the loop in your own system.

System rule: the withdrawal can only go to the CLABE that originated the deposit (cp_PlayerBank01 = 012180001234567890). The platform does not let the player type in another account. Amount in cents (180000 = MXN 1,800.00). metadata.reference is numeric, 1–7 digits. Reuse the idempotency header on retries — valid for 24h. Subscribe to returned for SPEI returns.

Match the completion webhook against the platform's ledger by external_id and mm_id. Confirm destination_id is the same counterparty that funded. The platform, Cobre, and the bank reconcile against the same identifier — the gray zone between "the player says they deposited/withdrew" and "the system doesn't see it" disappears.

Mapping the webhook payload from an earlier step onto Platform ledger / Compliance. No API call is made — this step closes the loop in your own system.