KYC — Mexico (MXN)

KYC requirements for enabling MXN rails for Mexican users. Identity review reuses the documents already uploaded through the standard KYC wizard.

LifecycleUserWalletKYCRailFundMove money

Mexican users get an MXN smart wallet and move money over SPEI/CLABE through the MXN on/offramp. Identity review is handled by BMONI’s Mexico KYC provider, reusing the documents the user already uploaded through the standard KYC wizard — there is no separate Mexican document flow. A CLABE is provisioned and the bank account is registered automatically during activation; there is no separate bank-account call.

---

How it works (the flow)

1. Run the standard KYC wizard, through Sumsub approval — PATCH /kyc with personal info, the Mexican address, and an identificationNumbers entry for the RFC; upload the ID document (/kyc/documents/identification), proof of address (/kyc/documents/proof-of-address), and selfie (/kyc/documents/biometric); then POST /kyc/activate and get it to approved. Mexico activation requires this to already be approved — it imports identity data from it rather than taking its own.
2. POST /onboarding/start-mexico — Registers the smart wallet’s mxnWalletAddress + mxnWalletIndex for the MXN rail, the same “one call per currency” step every other region does (see Integration flow).
3. POST /latam/mx/kyc/activate — Takes no body. Starts the Mexico KYC workflow from the already-approved Sumsub profile. A CLABE is provisioned in the background.
4. GET /latam/mx/kyc/launch/agreements — Send the user to the provider’s hosted verification page. Completing it is required for approval — without it the review never completes.
5. GET /latam/mx/kyc/status — Poll until approved.

A Mexican user who also wants a USD account follows the Rest of world flow in addition to this one — the two are independent activations over the same KYC profile.

---

The RFC is a hard prerequisite

Mexico activation reads the RFC (the Mexican tax id) straight off the KYC profile and submits it to the provider as taxId. Sumsub does not always carry it, so it has to be on the profile before you activate:

PATCH /v1/users/{userId}/kyc
{
  "identificationNumbers": [
    { "type": "rfc", "number": "GALA900101AB1", "issuingCountryCode": "MEX" }
  ]
}

issuingCountryCode is ISO 3166-1 alpha-3. The response carries canActivate and, when it is false, a missing array — check it before calling activate rather than reading the 400 back.

CURP is not required. It was only used by the per-user bank-account registration, which was removed when ramps moved to a shared business account. Sending one is harmless; omitting it does not block activation.

---

Activation

POST /v1/users/{userId}/latam/mx/kyc/activate

Takes no body — identity data is imported from the user’s already-approved standard KYC (Sumsub) profile, not resubmitted here. Fails with a 400 if that profile isn’t approved yet, or if the RFC is missing from it.

Returns the review status:

{
  "status": "proposed"
}

---

Hosted verification (required for approval)

GET /v1/users/{userId}/latam/mx/kyc/launch/agreements

Returns a browser form-POST payload that sends the user to the provider’s hosted verification page — it covers agreements, email confirmation, selfie/liveness, and any remaining region document in one flow. Call it after activation, and any time kyc/status is still proposed.

GET .../kyc/launch/idv is a deprecated alias that returns this same payload — kept only for integrations built before the provider consolidated its separate agreements and bank-verification launches into one flow. Use launch/agreements going forward.

{
  "url": "https://…/auth/launch",
  "method": "POST",
  "fields": {
    "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
    "assertion": "<signed user JWT>",
    "target": "/agreements"
  },
  "html": "<form …>…</form>",
  "expiresAt": "2026-06-02T12:05:00.000Z"
}

The assertion JWT expires roughly 5 minutes after you fetch it. Fetch this payload at the moment you are ready to send the user to the page — never at the start of a session, and never cached in your own store. An expired launch fails at the provider rather than at BMONI, so you get no error from this API to tell you what went wrong.

Read expiresAt and treat it as a hard deadline. If the user abandons the page, or you are still on your own screens when it passes, call this endpoint again for a fresh payload. There is no cost or limit to re-calling it.

Load html into a WebView or browser as-is (it auto-submits), or build the form-POST yourself from url + fields.

---

Status values

GET /v1/users/{userId}/latam/mx/kyc/status

status
not_started	Activation not yet submitted
in_progress	Review underway
proposed	Submitted, not yet decided — still needs hosted verification if not yet completed
approved	KYC approved — gate showing the MXN deposit account on this
rejected	Review rejected

Ramps route through BMONI’s shared business account, so there is no per-user bank-account compliance gate — approved is the terminal success state.

---

Next step

Once status is approved, move money with Mexico — MXN on/offramp — depositing MXN to the user’s CLABE onramps automatically, and offramps are a quote followed by an order. Users who onboarded before the MXNe → MEXe token migration should also be checked for a legacy balance — see MXNe → MEXe migration.