Money Transmitters and Payments

Money Transmitters and Payments in Mexico

In brief

A money transmitter is not merely an application that moves payments. It is an entity whose perimeter, registration, governance, PLD/FT, systems, third parties and contracts must all describe and control the same flow of funds. This guide brings together 70 operational answers, organized into seven dossiers, to move from the regulatory question to defensible evidence.

By Héctor CamachoLegal cutoff: July 9, 2026

Seven-layer map from perimeter and registration through to payment alliances; the illustration is indicative and the regulatory content remains in the reviewed text.

Quick answer: where to start?

If you are still designing the product, map out who receives funds in Mexico, for what consideration, under whose instruction and who delivers them. Start with dossier 1.
If you are acquiring or reorganizing an entity, freeze critical changes and map notices, governance, the CO, SITI and continuity. Go to dossier 2.
If the model is digital, a cashless experience still requires identity, geolocation, profiling, alerts, reconciliation and evidence. Review dossiers 3 and 4.
If you are investigating an alert or an LPB match, preserve data, fix the timeline and distinguish analysis, decision and reporting. Consult dossier 5.
If you use affiliates, agents or providers, classify them by actual function, access to funds, data and decisions. Consult dossier 6.
If you connect to an IFPE, API, POS or card program, assign responsibilities by event and align contract, interface, data, brand and fraud. Consult dossier 7.

The seven dossiers

1. Registration, technical opinion and perimeter

The starting point is not the product's commercial name but the legal flow of funds: who receives, where they receive them, with what regularity, for what consideration and under whose instruction they deliver or transfer them. Once the perimeter is confirmed, the registration and the technical opinion must be prepared as a single, consistent file. Includes topics 81 to 90.

2. Corporate changes, control, governance and Compliance Officer

In a registered entity, a corporate closing does not end with the share ledger. The transfer, the change in practical control, the composition of the governing body, the continuity of the Compliance Officer and the regulatory credentials form a single critical path. Includes topics 91 to 100.

3. Digital operation, SPEI, onboarding, geolocation and systems

Digitizing the experience does not eliminate controls: it converts them into data, events and logs. The architecture must distinguish money transmission from the banking or IFPE infrastructure that moves the funds and preserve evidence of identity, geolocation, profiling, alerts and reconciliation. Includes topics 101 to 110.

4. KYC of senders, beneficiaries, legal entities and cross-border

The file must represent the actual transaction, not merely the person who opened the account. In remittances and cross-border payments the sender, user, beneficiary, beneficial owner, source account, destination account and, at times, a third-party payer all coexist. Includes topics 111 to 120.

5. LPB, alerts, ROI, 24 hours, SITI and audit

An alert is not a report, and a match is not always a confirmed identity. A defensible control separates detection, analysis, decision, escalation, submission and preservation of the acknowledgment, with distinct clocks and owners. Includes topics 121 to 130.

6. Agents, correspondents, intercompany and contracts

The contractual label does not determine the regime. What matters is whether the third party receives or delivers funds, interacts with the user, makes compliance decisions or merely provides technology and support. The entity retains regulatory responsibility even when it outsources execution. Includes topics 131 to 140.

7. IFPE, API, POS, cards, promoters, data, brand and fraud

Payment alliances combine several regulated and commercial layers. The contract must reflect who is the entity vis-à-vis the customer, who executes payments, who promotes, who processes data, who licenses the brand and who absorbs fraud, chargebacks and incidents. Includes topics 141 to 150.

How to use this guide

Defensible control model

Defensible control model. Columns: Layer, Question and Expected evidence.
Layer	Question	Expected evidence
Perimeter	What activity does each participant legally carry out?	Funds diagram, memo and contracts
Governance	Who decides, supervises and answers?	Minutes, appointments, RACI and calendar
Data and system	What does the platform capture, transform, alert and preserve?	Dictionary, rules, logs, tests and reconciliation
Operation	What happens in a normal instruction and in an exception?	Samples, tickets, receipts and decisions
Reporting	How is it investigated, approved, submitted and evidenced?	File, final record, hash and acknowledgment
Third parties	What is delegated and how is it supervised?	Contract, SLA, audit, continuity and exit

How to determine the perimeter without relying on the product's name

The first question is not whether the company presents itself as a fintech, platform, processor, aggregator or technology provider. The analysis begins with the legal journey of the funds. It must be identified who receives money or rights within national territory, from whom they receive them, under whose instruction, whether a consideration is charged and who makes the final delivery or transfer. The commercial diagram, the contract, the bank accounts and the system events must all describe the same journey.

That functional examination avoids two opposing errors. The first is to assume that every platform involved in a payment is a money transmitter. The second is to believe that a label such as “mandate,” “collection” or “software” eliminates the activity even though the actual operation shows habitual receipt and transfer instructions. Where several participants exist, it is advisable to prepare a matrix by event: instruction, acceptance, funding, conversion, settlement, delivery, refund and claim. For each event, title, control, account, source data, receipt and owner are recorded.

The perimeter conclusion must preserve explicit assumptions. If the product adds stored balance, payments to third parties, cross-border operation, cash, virtual assets or a new group entity, the analysis reopens before launch. A memo that only describes the initial version does not serve as permanent authorization for future functionalities.

Regulatory path by company stage

Design and feasibility

Before incorporating a company or acquiring an entity, the minimum product, the countries, currencies, channels, participants, accounts and revenue model are defined. With that information, the perimeter of transmitter, IFPE, acquiring, correspondent banking, commercial commission agency and technology services is tested. The useful output is not an isolated label, but a map of permitted, reserved, conditioned and out-of-scope activities, with decisions that require additional confirmation.

Registration and operational preparation

Once the regime is confirmed, the corporate file, the technical opinion and the registration application must be built on a master source. Shareholders, beneficial owners, representative, domicile, corporate purpose, control structure and representations cannot vary between annexes. In parallel, the manual, methodology, Compliance Officer, system, contracts and access rights are prepared. Obtaining an opinion or registration does not by itself correct a product whose operation contradicts the submitted documents.

Controlled launch

Going to production requires a comprehensive test with normal cases and exceptions. The team must be able to reconstruct an instruction from onboarding and geolocation through to delivery, reconciliation, profiling, alerts, receipt and preservation. Rejection, refund, attempted fraud, watchlist match, provider interruption and recovery are also tested. Discrepancies are closed before increasing volume; they are not deferred indefinitely to an ownerless backlog.

Operation, change and supervision

Once operational, the entity manages periodic and event-driven obligations. Changes of shareholders, control, governance, Compliance Officer, domicile, agents, systems, accounts, products or providers may trigger notices and coordinated adjustments. The evidence must make it possible to compare what was approved, what was configured and what was executed. Faced with a request, the strongest response is not a lengthy narrative, but a matrix that links each item to a fact, legal basis, file, owner, date and acknowledgment.

Differences worth resolving early

Differences worth resolving early. Columns: Question, Why it matters and Documentable decision.
Question	Why it matters	Documentable decision
Does the user deliver funds to the transmitter or to a third party?	It changes the perimeter, the reconciliation and the evidence of receipt.	Account title, mandate, instruction and contractual reflection.
Does the entity hold a balance or merely execute an instruction?	It may raise additional questions about electronic payment funds.	Balance states, availability, redemption and role of each participant.
Who identifies the sender and the beneficiary?	Integration does not eliminate regulatory responsibility.	Fields, validations, exceptions, updating and access to evidence.
Who investigates an alert and who decides to report?	A technical SLA does not assign a compliance decision.	RACI, clock, file, approval, submission and acknowledgment.
Can a third party modify rules or data?	It affects supervision, traceability and continuity.	Permissions, change control, testing, audit and rollback.
What happens when the contract ends?	Without an orderly exit, data, balances or operational capacity may be lost.	Export, transition, revocation, destruction and assistance.

These differences must be resolved together. A contract may state that the entity does not receive funds, while the account statement and the system show otherwise. A manual may require geolocation, but the API may not store the original data. A policy may assign the investigation to the Compliance Officer, while the provider closes alerts without leaving inputs. The control consists of identifying and reconciling those contradictions before they become a finding, incident or claim.

Governance of the compliance program

The board or administrator needs an executive view that does not confuse activity with effectiveness. Reporting that alerts were reviewed or that training was delivered is insufficient if it does not explain coverage, exception, cause and closure. A useful dashboard distinguishes overdue, upcoming, event-driven and change-conditioned obligations. Each indicator must lead to recoverable evidence and show who can approve an exception.

The Compliance Officer requires practical independence, access to information and continuity. The appointment, acceptance, certification where applicable, notice and access to SITI must form a single sequence. Where a Communication and Control Committee exists, the minutes must reflect inputs, discussion, decision, owner and follow-up; a repeated format with no connection to files does not demonstrate real supervision.

Product and technology are also part of regulatory governance. Any functionality that changes receipt, delivery, identity, limits, data, alerts or third parties must undergo a prior assessment. The approval records version, assumptions, tests, residual risk and deployment condition. After launch, the actual result is compared with what was approved and deviations are corrected.

What to review in alliances, APIs and providers

Payment alliances often distribute the user experience among several entities. To avoid gaps, the contract and the design must assign each event: who presents the service, receives the instruction, authenticates, identifies, monitors, moves funds, handles claims and preserves logs. The phrase “each party will comply with the regulation applicable to it” does not replace that assignment.

An API must preserve the actor, purpose, authorization, date, relevant payload, response and change of state. Server credentials should not erase which user or process originated the instruction. There must be controls of least privilege, idempotency, rotation, abuse detection and revocation. When personal data is processed from another country, the map must include remote access, transfers, subprocessors and deletion.

The critical provider needs service levels that measure more than availability. Timeliness and quality of KYC, delivery of evidence, accuracy of rules, preservation of logs, incident handling and regulatory cooperation also matter. The audit right must be exercisable in ordinary operation and in the face of incidents. The exit is designed from the outset: export format, temporary continuity, knowledge transfer, revocation of access and certified destruction.

Frequently asked guidance questions

Is a money transmitter the same as an IFPE?

No. They are distinct regimes and the analysis depends on specific functions. A transmitter habitually receives funds or rights in order to transfer or deliver them in accordance with an instruction within the framework of the LGOAAC. An IFPE operates electronic payment funds under the Ley Fintech and a specific authorization. A product may connect entities of both types, but it must separate their roles and not attribute to one the powers of the other.

Does using SPEI eliminate the money transmission regime?

No. SPEI is payment infrastructure and its direct or indirect use does not replace the examination of the company's activity. The model must identify the participant that sends the order to the system, the accounts used, the control of instructions, the reconciliation and the evidence that each party preserves. The rules and contracts applicable to the access used must also be reviewed.

Can compliance be outsourced?

Tools and services may be contracted, but the entity must retain direction, access, supervision and the ability to demonstrate control. It is not advisable to delegate decisions without an approved framework, nor to depend on a single person or provider to recover the sole copy of the evidence. The contract must set roles, SLA, confidentiality, security, audit, continuity and exit.

Which document should be prepared first?

The diagram of funds and roles. From it, the perimeter memo, regulatory matrix, contracts, manual, data architecture, tests and calendar are built. If those documents are produced before agreeing on the actual flow, each team will fill the gaps with different assumptions and the inconsistency will surface during integration or supervision.

When should legal review be requested?

Before incorporating or acquiring the entity, filing a procedure, changing control or governance, launching a product, integrating a critical third party or responding to an incident or request. The review must not halt the preservation of evidence or the regulatory clocks. Its function is to fix assumptions, applicable provision, alternatives and concrete actions.

Privacy principle

The examples do not reproduce files or identify customers. Only abstract patterns and generalizable controls are published. Names, RFC, contact data, accounts, amounts, transaction dates and combinable facts are excluded; the complete evidence remains in a restricted editorial file.

Legal basis

Regulatory cutoff: 2026-07-09. Formats, catalogs and operational criteria must be verified again before filing or launching.

Next step

SVA.LAW can review the flow of funds, perimeter, registration file, governance, manual, automated system, KYC, reports, third parties and payment contracts with a single matrix of findings and evidence.

Editorial path

Registration and regulatory perimeter