Banxico Circular 9/2026: An Engineer's Deadline-Prep Guide to Homologating Your SPEI/DiMo/CoDi Transfer UX by Dec 14, 2026

What does Banxico’s Circular 9/2026 actually require?

Banxico’s Circular 9/2026 modifies Circular 14/2017 and adds user-experience Guías that homologate the mobile transfer experience for SPEI, DiMo, CoDi and QR. Direct participants, contractually-linked indirect participants, and IFPEs offering SPEI must comply by December 14, 2026. The binding, screen-by-screen spec lives in those Guías — not in the press coverage.

If you build a mobile app that moves money in Mexico, this is your work now, not a bank’s memo — audit your current flow against the Guías, not against a headline. The circular reaches into how you present, confirm and document a transfer, on a fixed deadline. Below I translate the mandate into engineering areas to audit, and I’m deliberate about where I stop: the exact pixel-level requirements are Banxico’s to define, not mine to invent. I’m an engineer who ships payments in Mexico, not a compliance vendor — confirm every obligation against the official texts and your compliance team before you ship.

Why Banxico is homologating the transfer UX

The stated objective is plain: mobile transfers should be intuitive, easy and fast. Today, moving money feels different in every app — different screens, different navigation routes, different fields captured in a different order. A user who learned to send a transfer in one bank’s app has to relearn it in the next. That app-to-app friction is exactly what the circular targets.

Banxico’s fix is homologation: a standardized experience so the flow feels the same regardless of which institution’s app you open. The mandate spans the rails users actually touch on a phone — SPEI for account-to-account transfers, DiMo for phone-number/alias sends, CoDi for request-to-pay, and QR for scan-to-pay. The goal is not to make every app identical in branding; it’s to make the transfer mechanics predictable so the friction of relearning disappears.

For a builder, the mental model is: Banxico is standardizing the grammar of a transfer — the steps, the confirmation, the field capture — while leaving your product’s voice intact. Your job is to find where your current grammar diverges from the Guías and reconcile it before the deadline. For where these rails sit in the broader market, see my overview of payment gateways in Mexico.

Who must comply, and by when

The obligation is not narrow. It reaches direct participants in SPEI and contractually-linked indirect participants — the institutions that plug into a direct participant to reach the system. And for non-bank players, the framing is sharper: for IFPEs (Instituciones de Fondos de Pago Electrónico) that offer SPEI, complying with the Guías becomes a condition to remain in the system. This is not an optional polish pass you can defer to next year’s roadmap.

The date is fixed: December 14, 2026. That’s the wall. Everything below — the audit, the gap analysis, the UI and confirmation-screen work, the testing — has to land before it.

Two practical notes for planning. First, if you’re an indirect participant riding on a direct participant’s connection, confirm with that partner how the Guías flow down to you contractually — the obligation is real, but the exact division of responsibility is for your compliance and partner-integration teams to nail down. Second, “comply” here means your user-facing app, not just your backend — the Guías are about experience, so the work is disproportionately front-end and product, which is often the slowest thing to change safely. Start now.

The app-work areas to audit against the Guías

Here is where I have to be careful, and where I’ll ask you to be careful too. What follows are the areas a team must audit against the Guías. These are not invented pixel specs, exact copy, or field lengths — those are Banxico’s to define in the official text. Treat this as your gap-analysis checklist, and resolve every item against the Guías themselves.

• A standardized transfer flow. The circular homologates the transfer experience across apps. Audit the sequence of screens from start to sent, and check it against the flow the Guías describe. Where your flow diverges — extra interstitials, a different order — you have a gap to close.
• How you present, confirm and document a payment. The publicly known scope covers how apps present, confirm and document the transfer, including a beneficiary-confirmation step. Audit your confirmation screen: what you show the user before they commit, and how you record and display what happened after. Verify the specifics against the Guías.
• Homogenized field capture. Different apps capture the same data in different orders and formats today; the objective is to reduce exactly that. Audit which fields you collect, in what order, and how they’re labeled — then reconcile with the Guías.
• Inline CoDi and QR handling. Apps must allow CoDi operations and process CoDi collection messages while respecting the UX homogenization. Audit how your app initiates and responds to a CoDi request and how QR scan-to-pay is handled inline, without breaking the standardized flow.
• DiMo alias and phone. DiMo sends money by alias or phone number. Audit how your app captures and confirms a DiMo alias/phone, and check that presentation against the Guías.

None of these are exotic engineering problems. Most are friction you already built and now need to reconcile with a standard. For the technical side of accepting these rails, my walkthrough on accepting CoDi and DiMo payments covers the plumbing; this circular is about the experience layer on top of it.

The honest pointer: the binding spec is in the Guías

I want to be explicit about the limits of this guide, because a payments post that pretends to know Banxico’s exact screen spec would be doing you a disservice. The authoritative, screen-by-screen requirements — exact field standards, the precise beneficiary-confirmation screen, alias/DiMo handling details, and any MFA or biometric rules — live in Banxico’s official Circular 9/2026 and its Guías. That is the binding source. Public reporting tells you the objective and the scope; it does not give you the pixels.

So the single most important engineering action in this whole post is unglamorous: go read the Guías. Pull the official text, put it next to your app, and gap-analyze against the document itself. Anything I or anyone else summarizes is a starting map, not the territory. If a requirement hinges on an exact field order, a specific confirmation-screen element, or an authentication rule, that decision must come from the Guías and your compliance team — never from a blog, including this one.

# Deadline-prep starting point — not a substitute for reading the Guías
# 1. Get the binding text
open "https://www.banxico.org.mx/"   # Circular 9/2026, its Guías, and Circular 14/2017

# 2. Gap-analyze your app against the Guías, area by area
#    - standardized transfer flow (screen sequence)
#    - present / confirm / document (beneficiary-confirmation step)
#    - homogenized field capture (fields, order, labels)
#    - inline CoDi / QR handling
#    - DiMo alias / phone capture

# 3. File each divergence as a ticket with an owner and a date before 2026-12-14

Your deadline-prep checklist

Here’s the plan I’d run if this landed on my desk. Nothing here is legal advice — it’s project sequencing.

1. Audit the current flow. Screen-record your live transfer flow for SPEI, DiMo, CoDi and QR. Count the screens, note the field order, capture the confirmation and receipt screens. You can’t close a gap you haven’t measured.
2. Run a gap analysis against the Guías. Put the recording next to the official text and mark every divergence: missing beneficiary-confirmation element, field captured out of the standardized order, a CoDi or QR path that breaks the homogenized flow.
3. Budget the changes. Scope the UI refactor, the confirmation-screen work, and the alias/CoDi/QR handling. Front-end and product changes carry the most schedule risk, so budget conservatively and assign owners now.
4. Test before December 14, 2026. QA the homologated flow end to end across all four rails, on real devices, and confirm nothing regressed. Leave buffer before the wall — a compliance deadline is a bad time to discover an edge case.

For the reconciliation and record-keeping side of running multiple rails cleanly, my guide to multi-rail payment reconciliation in Mexico pairs well with the “document the payment” area above.

The counter-tension: homologating UX must not weaken your risk controls

Here’s the part a naive reading of “make it fast and frictionless” gets wrong. Homologating the experience is not a license to strip your fraud controls. A standardized, four-rail transfer flow that removed adaptive authentication, device signals, or step-up challenges would be a lower-friction way to lose your users’ money. You still own the risk.

Your adaptive auth and fraud logic have to live within the homologated flow, not as extra interstitials that break it. That usually means moving risk decisions off the critical path where you can — device fingerprinting, behavioral signals, velocity checks in the background — and reserving visible friction (a step-up challenge, a hold) for genuinely risky transfers rather than every one. A beneficiary-confirmation step, done well, is itself a fraud control: it’s the moment a user catches a wrong or spoofed recipient. So don’t treat confirmation as a box to minimize; treat it as risk surface to get right.

If you accept cards alongside these rails, the same principle governs authentication there — my post on 3DS2 in Mexico walks through keeping strong auth without wrecking conversion. The through-line: homologate the flow, keep the guardrails.

Engineer, not lawyer

Everything above is an engineering planning guide, not legal advice. I ship payments in Mexico; I don’t certify compliance. Confirm every obligation against Banxico’s official texts — Circular 9/2026, its Guías, and Circular 14/2017 — and validate your reading with your compliance team before you ship anything against them. Where the Guías and my summary disagree, the Guías win, every time.

Net: Circular 9/2026 gives you until December 14, 2026 to homologate the mobile transfer experience for SPEI, DiMo, CoDi and QR. Audit your current flow, gap-analyze it against the official Guías, budget the UI, confirmation and alias changes, and test before the wall — all without weakening the fraud controls you still own. For the account-tier changes in the same regulatory wave (a distinct mandate), see my post on Banxico’s Nivel 2 Bis account, and for the broader picture, my LATAM payments hub.