Digital operation, SPEI, onboarding, geolocation and systems

Architecture of a cashless digital transmitter

Decision point

In a cashless model, the key is to follow the obligation from funding to delivery. The map separates interface, internal ledger, bank account and settlement rail, including rejections and returns. Each instruction needs a common identifier to reconcile amount, sender, beneficiary, fee and final status.

Checklist

1. Define a ledger of obligations by instruction.
2. Prohibit commingling of funds without traceability.
3. Reconcile bank, processor and platform daily.

Observed pattern

In an anonymized manual, the architecture was understood only by overlaying user flow, bank accounts and internal ledger; each isolated diagram concealed a reconciliation.

How to put it into practice

Assign an end-to-end identifier before integrating the banking rail. That value must link consent, funding, ledger, SPEI message and receipt. Model intermediate states, including accepted-not-settled and settled-without-confirmation. Reconciliation distinguishes a timing difference from a loss of integrity. For returns, define who updates the balance and communicates to the user. The architecture is defensible if a sample allows reconstructing all the hops and if no bank account is confused with legal custody of funds.

Stress test

Subject the architecture to an accepted instruction that loses connection before receiving bank confirmation. The system must query the status before resending, keep a single key, and correctly reflect the balance, fee and message to the user. When reconstructing the case, consent, ledger, concentration account, SPEI and receipt must share enough references to distinguish delay, return and duplication.

Legal basis

• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — articles 81-A Bis, 81-B, 81-D, 86 Bis and 95 Bis, depending on the topic.
• Circular 14/2017: SPEI provisions, compiled text — Circular 14/2017, compiled text with amendments, including Circular 9/2026.

Direct or indirect SPEI: how to allocate responsibilities

Decision point

Direct connection or connection through a participant changes contracts and operation, not the need to assign responsibilities. It must be known who validates the instruction, generates the message, keeps the tracking key, reconciles and handles a return. The regulatory layouts must be reconstructable without depending on a manual explanation from the provider.

Checklist

1. Map responsibilities by payment status.
2. Preserve the tracking key and references.
3. Define returns, windows and escalation.

Observed pattern

In an anonymized review, the provider executed the payment but the transmitter kept the relationship and the data; the initial SLA did not assign the investigation of rejected transfers.

How to put it into practice

Build a RACI by payment event and add it to the contract with the participant. The tracking key, the reference and the status must travel back to the platform. Define queries for messages without a response and retry windows. Rejections due to invalid data require a different owner than a rail outage. Test daily reconciliation and a real or simulated return. The user must receive coherent information even though several entities are involved in the execution.

Stress test

Compare two incidents: a rejection due to invalid data and an unavailability of the participant. Although both prevent settlement, they change the owner, the communication and the possibility of retry. The contractual RACI must match real permissions and logs. A return sample also confirms who receives the message, who adjusts the ledger and how long it takes for the status visible to the user to update.

Legal basis

• Circular 14/2017: SPEI provisions, compiled text — Circular 14/2017, compiled text with amendments, including Circular 9/2026.
• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — articles 81-A Bis, 81-B, 81-D, 86 Bis and 95 Bis, depending on the topic.

API onboarding is not the same as in-person identification

Decision point

The API transports data or results; identification occurs through concrete rules and evidence. The file must link session, document, validation, provider, version and final decision. An inconclusive technical result cannot be presented in the interface as a KYC approval.

Checklist

1. Version the acceptance and rejection rules.
2. Save the response, timestamp and provider.
3. Block onboardings with inconclusive validations.

Observed pattern

In an anonymized file, the front-end showed success even though an external source had responded inconclusively; separating technical status from the KYC decision corrected the control.

Frequent risk

Equating a successful HTTP response with validated identity allows onboardings even though the external source has not confirmed the relevant attribute.

How to put it into practice

Document each service queried by the API and the attribute it is meant to validate. A positive response must have a defined functional meaning, not just a technical code. Save the version of the rules and the provider to reproduce historical decisions. When two sources disagree, the flow must stop or enter manual review. Test altered documents, abandoned sessions and late responses. The success screen only appears when the file contains all the mandatory results and the engine issued an explicit decision.

Stress test

Use an authentic document with a late response and another altered one that a provider marks as valid. The first case tests time handling; the second, discrepancy and manual review. Preserve the request, the response, the API version and the engine's decision. If the file only keeps a final screen, it will not be possible to determine which attributes were verified nor reproduce the historical criterion.

Legal basis

• Legal provisions applicable to money transmitters — DCG derived from article 95 Bis and its amendments.
• Ley Federal de Protección de Datos Personales en Posesión de los Particulares (texto vigente) — principles, privacy notice, transfers and security measures.

Geolocation: data, consent and evidence

Decision point

Geolocation must be tied to a session, a moment and a purpose. It is advisable to save coordinates, precision, timestamp, permission, result and error handling, respecting minimization and the privacy notice. The declared address or the IP must not replace it without an express and defensible rule.

Checklist

1. Define data, precision and timestamp.
2. Record permission, refusal and contingency.
3. Limit use and retention in accordance with the privacy notice.

Observed pattern

In an anonymized test, the application requested permission, but the backend did not keep the result or the cause of the error; it was not possible to evidence what happened during onboarding.

Frequent risk

Requesting permission on screen but discarding the result in the backend makes it impossible to prove what location was captured.

How to put it into practice

Record the geolocation together with the precision and the cause of any degradation. Test denied permission, insufficient signal and change of device. The policy must decide whether those cases block, allow a retry or require another channel. The notice explains the purpose without expanding commercial uses for convenience. Limit internal access and define retention. A sample must link coordinate, session, identity and approval; isolated data in mobile analytics does not demonstrate the regulatory control.

Stress test

Evaluate a session with location permission denied and another with low-precision coordinates. The rule must produce the foreseen results, record the cause and prevent an analyst from manually completing a nonexistent data point. Then verify that retention and access correspond to the informed purpose. The coordinate acquires evidentiary value only when it remains linked to device, identity, moment and onboarding decision.

Legal basis

• Legal provisions applicable to money transmitters — DCG derived from article 95 Bis and its amendments.
• Ley Federal de Protección de Datos Personales en Posesión de los Particulares (texto vigente) — principles, privacy notice, transfers and security measures.

Minimum modules of the automated PLD/FT system

Decision point

The demonstration of the system must run through a complete case: onboarding, profile, list, alert, investigation, decision, report and retention. In addition, permissions, rule changes, interfaces and recovery are tested. The list of modules becomes a requirement-function-evidence matrix to prevent a license without configuration from being presented as an operational control.

Checklist

1. Maintain an inventory of requirements and responsible module.
2. Test interfaces and data quality.
3. Preserve rule versions and a change log.

Observed pattern

In an anonymized requirement, data were requested that existed in separate systems but could not be related through a common identifier.

Frequent risk

A dashboard screenshot evidences appearance, not data integrity nor execution of the rule during the reviewed period.

How to put it into practice

Prepare a demo script with inputs and expected results before showing the system. Include a high-risk user, a false match, a true alert and a data correction. Verify that permissions prevent the analyst from modifying the rule being evaluated. Export logs and a report from the same case. Document interfaces and load frequency. The module exists for compliance only when it processes the corresponding universe, generates evidence and allows explaining why a case advanced or was stopped.

Stress test

Run an alert from start to finish with a user who changes risk. Observe list loading, profile, detection, assignment, ruling and report, in addition to the logs generated. The demonstration must use ordinary permissions, not an administrator account capable of altering results. A module that produces convincing screens but omits part of the universe or does not export evidence remains insufficient.

Legal basis

• Legal provisions applicable to money transmitters — DCG derived from article 95 Bis and its amendments.
• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — articles 81-A Bis, 81-B, 81-D, 86 Bis and 95 Bis, depending on the topic.

Transactional profile and alerts in digital remittances

Decision point

The profile combines declared information and expected behavior by corridor, frequency, amount, channel and counterparties. Alerts must explain what deviation they detect and with what data; calibration is measured by coverage, false positives and omitted cases. Each change of weighting preserves the hypothesis, the approval and the test.

Checklist

1. Document the risk hypothesis per rule.
2. Measure precision, coverage and backlog.
3. Approve calibrations with evidence.

Observed pattern

In an anonymized matrix, the most useful alerts combined corridor, frequency, counterparties and deviation; those based only on amount accumulated false positives.

Frequent risk

Raising thresholds to reduce volume without studying the closed cases can hide risk rather than improve precision.

How to put it into practice

Select a corridor and reconstruct how the initial level was calculated. Compare the declared expectation with the observed frequency, amount and beneficiaries. An alert must point to the deviated variable and present enough data to the analyst. Review cases below and above the threshold to measure the boundary. Document adjustments and their effect on volume. The calibration is approved when it improves detection without eliminating relevant typologies, not only when it reduces the number of open cases.

Stress test

Calibrate with transactions located just below and above the threshold, and add a pattern distributed among common beneficiaries. Compare sensitivity, false positives and missed cases before approving the change. The calibration note must preserve population, period, version and expected effect. Reducing the alert inventory is not a valid objective if a relevant typology of the analyzed corridor disappears at the same time.

Legal basis

• Legal provisions applicable to money transmitters — DCG derived from article 95 Bis and its amendments.
• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — articles 81-A Bis, 81-B, 81-D, 86 Bis and 95 Bis, depending on the topic.

Mirror system and reconciliation: how to prove integrity

Decision point

Integrity is proven by following an instruction between the source system, the copy, the AML engine and the report. Comparing totals is not enough: critical fields, transformations, rejections and differences are reviewed. The log must show when the data was replicated and how a divergence was corrected without erasing the previous value.

Checklist

1. Reconcile records and critical fields.
2. Investigate differences with an SLA.
3. Test restoration and reconstruction of a sample.

Observed pattern

In an anonymized review, two databases contained the same number of transactions but different critical fields; the count-based comparison had concealed losses of attributes.

Frequent risk

Two databases with the same number of rows may differ in sender, account or country, precisely the attributes that change the analysis.

How to put it into practice

Choose fields that change decisions —role, country, account, amount and date— and reconcile them individually. Record the transformation, format and responsible party between each system. A difference must open an incident and preserve both values until it is resolved. Test resending, duplication and out-of-order arrival. Restoration also needs a sample: recovering a backup without verifying relationships does not guarantee integrity. The mirror system is useful when it allows independent reconstruction and detects losses that a simple row count would not show.

Stress test

Deliberately introduce a duplicate and an out-of-order record between the main system and the mirror. The reconciliation must detect them without erasing the original evidence. Then restore a sample from backup and verify relationships, not just counts. Identifiers, transformations and timestamps make it possible to locate the hop where the difference arose and assign a correction that does not silently modify the history.

Legal basis

• Legal provisions applicable to money transmitters — DCG derived from article 95 Bis and its amendments.
• Circular 14/2017: SPEI provisions, compiled text — Circular 14/2017, compiled text with amendments, including Circular 9/2026.

Source and destination accounts: operational traceability

Decision point

The user, transaction and SPEI tables need stable keys and separate roles. The funding account, the operating account and the destination are not the same attribute; nor are sender and beneficiary. A dictionary documents format, source, nullability and transformation before generating the supervision layout.

Checklist

1. Create separate fields by role.
2. Validate ownership when required.
3. Preserve bank identifiers and tracking keys.

Observed pattern

In an anonymized table, the same field was used for the source and destination CLABE depending on the status; normalizing roles made it possible to detect third-party payments.

Frequent risk

Reusing an account column depending on the payment status makes it ambiguous who contributed and who received the resources.

How to put it into practice

Define a transaction key that does not change when passing through a provider or bank. Separate user, sender, bank originator and beneficiary into distinct columns. Document which field admits a null and under what assumption. Test characters, lengths and multiple accounts. The final table must reconcile with bank totals and preserve rejected records. Before sending it, an analyst reconstructs a row down to documents and SPEI message; this verifies semantics, not just format.

Stress test

Test a transfer in which the holder of the source account does not match the sender and the bank recipient differs from the declared beneficiary. The table must preserve the four roles without overwriting them. Relate exception, authorization and result, and reconcile the amount with the bank message. That separation avoids inferring identities from a single technical field.

Legal basis

• Legal provisions applicable to money transmitters — DCG derived from article 95 Bis and its amendments.
• Circular 14/2017: SPEI provisions, compiled text — Circular 14/2017, compiled text with amendments, including Circular 9/2026.

Transaction receipt, exchange rate and fees

Decision point

The operational receipt must allow reconstructing the amount received, the fee, the exchange rate, the delivery amount, the beneficiary, the date and the reference. The tax invoice has another function and must not be used to hide the price of the remittance. The prior disclosure and the final receipt preserve the applied exchange rule.

Checklist

1. Define the source and timing of the exchange rate.
2. Show all components before confirming.
3. Preserve the version of the accepted disclosure.

Observed pattern

In an anonymized contractual review, the fee was shown but the exchange rate rule remained in a separate document, generating discrepancies in support.

Frequent risk

Showing the fee but leaving the exchange margin in separate terms prevents understanding the total cost before confirming.

How to put it into practice

Compare the disclosure shown before confirming with the receipt issued at the end. The amount, currency, fee and conversion rule must match, except for an explained event. Preserve the rate, its source and the moment it was fixed. If the provider supplies the FX, the contract must allow recovering evidence. Test cancellation and return to decide which items are refunded. The user needs a unique reference to file a claim without depending on an invoice that describes only tax effects.

Stress test

Use a transaction whose rate changes between quote and confirmation. The file must show when it was fixed, what source was used and what the user accepted, in addition to explaining any difference in the receipt. Then cancel the instruction to verify which fee and spread are refunded. Tax invoice, operational receipt and prior disclosure serve different functions and must be reconcilable.

Legal basis

• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — articles 81-A Bis, 81-B, 81-D, 86 Bis and 95 Bis, depending on the topic.
• Requirements to obtain registration as a money transmitter — RECC-TD portal and official list of requirements.

Continuity in the face of funding or payment incidents

Decision point

Continuity must cover the bank, API, AML engine, compliance provider and reconciliation. For uncertain states, a pause, a query, an idempotent retry and a manual review are defined. The plan also indicates who communicates to the user and how the technological recovery is prevented from duplicating a delivery.

Checklist

1. Use idempotent identifiers.
2. Define indeterminate states and manual review.
3. Run drills with critical providers.

Observed pattern

In an anonymized simulation, automatically retrying after a timeout could duplicate the delivery because the provider had processed it without responding.

Frequent risk

Retrying after a timeout without querying the status can pay twice for an instruction that was indeed processed.

How to put it into practice

Catalog dependencies by impact and maximum tolerable time. For each one, define the failure signal, the pause decision and the recovery owner. Retries use idempotency and a prior query of the status. Simulate loss of connection after sending an instruction, since it is the scenario that most easily duplicates payments. Preserve messages and subsequent reconciliation. The plan must prioritize protection of resources and exact communication, even if that requires temporarily stopping new transactions.

Stress test

Simulate the outage after sending the payment, when there is still no response. Before retrying, the system queries the bank using the original key and keeps the balance in an intermediate state. The team records the time, scope, decisions and communication, and verifies the reconciliation when service is recovered. Success is not just restoring connectivity: it consists of demonstrating that no user was charged twice or informed with a false status.

Legal basis

• Circular 14/2017: SPEI provisions, compiled text — Circular 14/2017, compiled text with amendments, including Circular 9/2026.
• Legal provisions applicable to money transmitters — DCG derived from article 95 Bis and its amendments.