Operación digital, SPEI, onboarding, geolocalización y sistemas

Arquitectura de un transmisor digital sin efectivo

Punto de decisión

En un modelo sin efectivo, la clave es seguir la obligación desde el fondeo hasta la entrega. El mapa separa interfaz, ledger interno, cuenta bancaria y riel de liquidación, incluyendo rechazos y devoluciones. Cada instrucción necesita identificador común para conciliar monto, remitente, beneficiario, comisión y estado final.

Checklist

1. Definir ledger de obligaciones por instrucción.
2. Prohibir mezclas de fondos sin trazabilidad.
3. Conciliar banco, procesador y plataforma diariamente.

Patrón observado

En un manual anonimizado, la arquitectura se entendió sólo al superponer flujo de usuario, cuentas bancarias y ledger interno; cada diagrama aislado ocultaba una conciliación.

Cómo llevarlo a operación

Asigne un identificador de extremo a extremo antes de integrar el riel bancario. Ese valor debe unir consentimiento, fondeo, ledger, mensaje SPEI y comprobante. Modele estados intermedios, incluidos aceptada sin liquidar y liquidada sin confirmación. La conciliación distingue diferencia temporal de pérdida de integridad. Para devoluciones, defina quién actualiza saldo y comunica al usuario. La arquitectura es defendible si una muestra permite reconstruir todos los saltos y si ninguna cuenta bancaria se confunde con custodia jurídica de fondos.

Prueba de estrés

Someta la arquitectura a una instrucción aceptada que pierde conexión antes de recibir confirmación bancaria. El sistema debe consultar estado antes de reenviar, conservar una sola llave y reflejar correctamente saldo, comisión y mensaje al usuario. Al reconstruir el caso, consentimiento, ledger, cuenta concentradora, SPEI y recibo deben compartir referencias suficientes para distinguir retraso, devolución y duplicidad.

Base legal

• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — artículos 81-A Bis, 81-B, 81-D, 86 Bis y 95 Bis, según el tema.
• Circular 14/2017: disposiciones del SPEI, texto compilado — Circular 14/2017, texto compilado con modificaciones, incluida Circular 9/2026.

SPEI directo o indirecto: cómo repartir responsabilidades

Punto de decisión

La conexión directa o mediante un participante cambia contratos y operación, no la necesidad de asignar responsabilidades. Debe saberse quién valida la instrucción, genera el mensaje, conserva la clave de rastreo, concilia y atiende una devolución. Los layouts regulatorios deben poder reconstruirse sin depender de una explicación manual del proveedor.

Checklist

1. Mapear responsabilidades por estado de pago.
2. Conservar clave de rastreo y referencias.
3. Definir devoluciones, ventanas y escalamiento.

Patrón observado

En una revisión anonimizada, el proveedor ejecutaba el pago pero el transmisor conservaba la relación y los datos; el SLA inicial no asignaba la investigación de transferencias rechazadas.

Cómo llevarlo a operación

Construya un RACI por evento del pago y agréguelo al contrato con el participante. La clave de rastreo, la referencia y el estado deben viajar de regreso a la plataforma. Defina consultas para mensajes sin respuesta y ventanas de reintento. Los rechazos por dato inválido requieren dueño distinto de una caída del riel. Pruebe conciliación diaria y una devolución real o simulada. El usuario debe recibir información coherente aunque varias entidades intervengan en la ejecución.

Prueba de estrés

Compare dos incidentes: un rechazo por dato inválido y una indisponibilidad del participante. Aunque ambos impiden liquidar, cambian responsable, comunicación y posibilidad de reintento. El RACI contractual debe coincidir con permisos y bitácoras reales. Una muestra de devolución confirma además quién recibe el mensaje, quién ajusta el ledger y cuánto tarda en actualizarse el estado visible para el usuario.

Base legal

• Circular 14/2017: disposiciones del SPEI, texto compilado — Circular 14/2017, texto compilado con modificaciones, incluida Circular 9/2026.
• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — artículos 81-A Bis, 81-B, 81-D, 86 Bis y 95 Bis, según el tema.

Onboarding por API no equivale a identificación presencial

Punto de decisión

La API transporta datos o resultados; la identificación ocurre mediante reglas y evidencias concretas. El expediente debe ligar sesión, documento, validación, proveedor, versión y decisión final. Un resultado técnico inconcluso no puede presentarse en la interfaz como aprobación KYC.

Checklist

1. Versionar reglas de aceptación y rechazo.
2. Guardar respuesta, sello de tiempo y proveedor.
3. Bloquear altas ante validaciones inconclusas.

Patrón observado

En un expediente anonimizado, el front-end mostraba éxito aunque una fuente externa había respondido de forma inconclusa; separar estado técnico de decisión KYC corrigió el control.

Riesgo frecuente

Equiparar respuesta HTTP exitosa con identidad validada permite altas aunque la fuente externa no haya confirmado el atributo relevante.

Cómo llevarlo a operación

Documente cada servicio consultado por la API y el atributo que pretende validar. Una respuesta positiva debe tener significado funcional definido, no sólo código técnico. Guarde versión de reglas y proveedor para reproducir decisiones históricas. Cuando dos fuentes discrepen, el flujo debe detenerse o entrar a revisión manual. Pruebe documentos alterados, sesiones abandonadas y respuestas tardías. La pantalla de éxito sólo aparece cuando el expediente contiene todos los resultados obligatorios y el motor emitió una decisión explícita.

Prueba de estrés

Utilice un documento auténtico con respuesta tardía y otro alterado que un proveedor marque como válido. El primer caso prueba manejo de tiempo; el segundo, discrepancia y revisión manual. Conserve petición, respuesta, versión de la API y decisión del motor. Si el expediente sólo guarda una pantalla final, no será posible determinar qué atributos se verificaron ni reproducir el criterio histórico.

Base legal

• Disposiciones legales aplicables a transmisores de dinero — DCG derivadas del artículo 95 Bis y sus modificaciones.
• Ley Federal de Protección de Datos Personales en Posesión de los Particulares (texto vigente) — principios, aviso de privacidad, transferencias y medidas de seguridad.

Geolocalización: dato, consentimiento y evidencia

Punto de decisión

La geolocalización debe relacionarse con una sesión, un momento y una finalidad. Conviene guardar coordenadas, precisión, sello de tiempo, permiso, resultado y tratamiento de errores, respetando minimización y aviso de privacidad. La dirección declarada o la IP no deben sustituirla sin una regla expresa y defendible.

Checklist

1. Definir dato, precisión y sello de tiempo.
2. Registrar permiso, rechazo y contingencia.
3. Limitar uso y retención conforme al aviso de privacidad.

Patrón observado

En una prueba anonimizada, la aplicación pedía permiso, pero el backend no conservaba resultado ni causa de error; no era posible acreditar qué ocurrió en el alta.

Riesgo frecuente

Solicitar permiso en pantalla pero descartar el resultado en backend hace imposible probar qué ubicación se capturó.

Cómo llevarlo a operación

Registre la geolocalización junto con precisión y causa de cualquier degradación. Pruebe permiso negado, señal insuficiente y cambio de dispositivo. La política debe decidir si esos casos bloquean, permiten reintento o exigen otro canal. El aviso explica la finalidad sin ampliar usos comerciales por conveniencia. Limite acceso interno y defina retención. Una muestra debe ligar coordenada, sesión, identidad y aprobación; datos aislados en analítica móvil no demuestran el control regulatorio.

Prueba de estrés

Evalúe una sesión con permiso de ubicación negado y otra con coordenadas de baja precisión. La regla debe producir resultados previstos, registrar la causa y evitar que un analista complete manualmente un dato inexistente. Después verifique que retención y accesos correspondan a la finalidad informada. La coordenada adquiere valor probatorio únicamente cuando queda enlazada con dispositivo, identidad, instante y decisión de alta.

Base legal

• Disposiciones legales aplicables a transmisores de dinero — DCG derivadas del artículo 95 Bis y sus modificaciones.
• Ley Federal de Protección de Datos Personales en Posesión de los Particulares (texto vigente) — principios, aviso de privacidad, transferencias y medidas de seguridad.

Módulos mínimos del sistema automatizado PLD/FT

Punto de decisión

La demostración del sistema debe recorrer un caso completo: alta, perfil, lista, alerta, investigación, decisión, reporte y conservación. Además se prueban permisos, cambios de regla, interfaces y recuperación. La lista de módulos se vuelve una matriz requisito-función-evidencia para evitar que una licencia sin configuración se presente como control operativo.

Checklist

1. Mantener inventario de requisitos y módulo responsable.
2. Probar interfaces y calidad de datos.
3. Conservar versiones de reglas y bitácora de cambios.

Patrón observado

En un requerimiento anonimizado, se pidieron datos que existían en sistemas separados pero no podían relacionarse por un identificador común.

Riesgo frecuente

Una captura de dashboard acredita apariencia, no integridad de datos ni ejecución de la regla durante el periodo revisado.

Cómo llevarlo a operación

Prepare un guion de demo con entradas y resultados esperados antes de mostrar el sistema. Incluya usuario de alto riesgo, coincidencia falsa, alerta verdadera y corrección de datos. Verifique que permisos impidan al analista modificar la regla que evalúa. Exporte bitácoras y reporte desde el mismo caso. Documente interfaces y frecuencia de carga. El módulo existe para cumplimiento sólo cuando procesa el universo correspondiente, genera evidencia y permite explicar por qué un caso avanzó o fue detenido.

Prueba de estrés

Ejecute una alerta de principio a fin con un usuario que cambia de riesgo. Observe carga de listas, perfil, detección, asignación, dictamen y reporte, además de las bitácoras generadas. La demostración debe usar permisos ordinarios, no una cuenta administradora capaz de alterar resultados. Un módulo que produce pantallas convincentes pero omite parte del universo o no exporta evidencia sigue siendo insuficiente.

Base legal

• Disposiciones legales aplicables a transmisores de dinero — DCG derivadas del artículo 95 Bis y sus modificaciones.
• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — artículos 81-A Bis, 81-B, 81-D, 86 Bis y 95 Bis, según el tema.

Perfil transaccional y alertas en remesas digitales

Punto de decisión

El perfil combina información declarada y comportamiento esperado por corredor, frecuencia, monto, canal y contrapartes. Las alertas deben explicar qué desviación detectan y con qué datos; la calibración se mide por cobertura, falsos positivos y casos omitidos. Cada cambio de ponderación conserva hipótesis, aprobación y prueba.

Checklist

1. Documentar hipótesis de riesgo por regla.
2. Medir precisión, cobertura y backlog.
3. Aprobar calibraciones con evidencia.

Patrón observado

En una matriz anonimizada, las alertas más útiles combinaban corredor, frecuencia, contrapartes y desviación; las basadas sólo en monto acumulaban falsos positivos.

Riesgo frecuente

Subir umbrales para reducir volumen sin estudiar los casos cerrados puede ocultar riesgo en lugar de mejorar precisión.

Cómo llevarlo a operación

Seleccione un corredor y reconstruya cómo se calculó el nivel inicial. Compare expectativa declarada con frecuencia, monto y beneficiarios observados. Una alerta debe señalar la variable desviada y presentar datos suficientes al analista. Revise casos por debajo y por encima del umbral para medir frontera. Documente ajustes y efecto sobre volumen. La calibración se aprueba cuando mejora detección sin eliminar tipologías relevantes, no únicamente cuando reduce el número de casos abiertos.

Prueba de estrés

Calibre con operaciones situadas justo debajo y encima del umbral, y añada un patrón distribuido entre beneficiarios comunes. Compare sensibilidad, falsos positivos y casos perdidos antes de aprobar el cambio. La nota de calibración debe conservar población, periodo, versión y efecto esperado. Reducir inventario de alertas no es un objetivo válido si al mismo tiempo desaparece una tipología relevante del corredor analizado.

Base legal

• Disposiciones legales aplicables a transmisores de dinero — DCG derivadas del artículo 95 Bis y sus modificaciones.
• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — artículos 81-A Bis, 81-B, 81-D, 86 Bis y 95 Bis, según el tema.

Sistema espejo y conciliación: cómo probar integridad

Punto de decisión

La integridad se prueba siguiendo una instrucción entre sistema fuente, copia, motor PLD y reporte. No basta comparar totales: se revisan campos críticos, transformaciones, rechazos y diferencias. La bitácora debe mostrar cuándo se replicó el dato y cómo se corrigió una divergencia sin borrar el valor anterior.

Checklist

1. Conciliar registros y campos críticos.
2. Investigar diferencias con SLA.
3. Probar restauración y reconstrucción de una muestra.

Patrón observado

En una revisión anonimizada, dos bases contenían el mismo número de operaciones pero campos críticos distintos; la comparación por conteo había ocultado pérdidas de atributos.

Riesgo frecuente

Dos bases con igual número de filas pueden discrepar en remitente, cuenta o país, precisamente los atributos que cambian el análisis.

Cómo llevarlo a operación

Elija campos que cambian decisiones —rol, país, cuenta, monto y fecha— y concílielos individualmente. Registre transformación, formato y responsable entre cada sistema. Una diferencia debe abrir incidente y conservar ambos valores hasta resolverla. Pruebe reenvío, duplicado y llegada fuera de orden. La restauración también necesita muestra: recuperar un respaldo sin verificar relaciones no garantiza integridad. El sistema espejo sirve cuando permite reconstrucción independiente y detecta pérdidas que un simple conteo de filas no mostraría.

Prueba de estrés

Introduzca deliberadamente un duplicado y un registro fuera de orden entre el sistema principal y el espejo. La conciliación debe detectarlos sin borrar la evidencia original. Luego restaure una muestra desde respaldo y verifique relaciones, no sólo conteos. Identificadores, transformaciones y horarios permiten localizar el salto donde surgió la diferencia y asignar una corrección que no modifique silenciosamente la historia.

Base legal

• Disposiciones legales aplicables a transmisores de dinero — DCG derivadas del artículo 95 Bis y sus modificaciones.
• Circular 14/2017: disposiciones del SPEI, texto compilado — Circular 14/2017, texto compilado con modificaciones, incluida Circular 9/2026.

Cuentas de origen y destino: trazabilidad operativa

Punto de decisión

Las tablas de usuarios, operaciones y SPEI necesitan llaves estables y roles separados. La cuenta de fondeo, la cuenta operativa y el destino no son el mismo atributo; tampoco remitente y beneficiario. Un diccionario documenta formato, fuente, nulabilidad y transformación antes de generar el layout de supervisión.

Checklist

1. Crear campos separados por rol.
2. Validar titularidad cuando sea exigible.
3. Conservar identificadores bancarios y claves de rastreo.

Patrón observado

En una tabla anonimizada, el mismo campo se usaba para CLABE de origen y destino según el estado; normalizar roles permitió detectar pagos de terceros.

Riesgo frecuente

Reutilizar una columna de cuenta según el estado del pago vuelve ambiguo quién aportó y quién recibió los recursos.

Cómo llevarlo a operación

Defina una llave de operación que no cambie al pasar por proveedor o banco. Separe usuario, remitente, ordenante bancario y beneficiario en columnas distintas. Documente qué campo admite nulo y bajo qué supuesto. Pruebe caracteres, longitudes y múltiples cuentas. La tabla final debe conciliar con totales bancarios y conservar registros rechazados. Antes de enviarla, un analista reconstruye una fila hasta documentos y mensaje SPEI; así se comprueba semántica, no sólo formato.

Prueba de estrés

Pruebe una transferencia en la que el titular de la cuenta de origen no coincide con el remitente y el destinatario bancario difiere del beneficiario declarado. La tabla debe conservar los cuatro roles sin sobrescribirlos. Relacione excepción, autorización y resultado, y concilie el monto con el mensaje bancario. Esa separación evita inferir identidades a partir de un único campo técnico.

Base legal

• Disposiciones legales aplicables a transmisores de dinero — DCG derivadas del artículo 95 Bis y sus modificaciones.
• Circular 14/2017: disposiciones del SPEI, texto compilado — Circular 14/2017, texto compilado con modificaciones, incluida Circular 9/2026.

Recibo de operación, tipo de cambio y comisiones

Punto de decisión

El comprobante operativo debe permitir reconstruir monto recibido, comisión, tipo de cambio, monto de entrega, beneficiario, fecha y referencia. La factura fiscal tiene otra función y no debe usarse para ocultar el precio de la remesa. El disclosure previo y el recibo final conservan la regla cambiaria aplicada.

Checklist

1. Definir fuente y momento del tipo de cambio.
2. Mostrar todos los componentes antes de confirmar.
3. Conservar versión del disclosure aceptado.

Patrón observado

En una revisión contractual anonimizada, la comisión se mostraba pero la regla de tipo de cambio quedaba en un documento separado, generando discrepancias en soporte.

Riesgo frecuente

Mostrar la comisión pero dejar el margen cambiario en términos separados impide entender el costo total antes de confirmar.

Cómo llevarlo a operación

Compare el disclosure mostrado antes de confirmar con el recibo emitido al final. Deben coincidir monto, moneda, comisión y regla de conversión, salvo un evento explicado. Conserve la tasa, su fuente y el instante de fijación. Si el proveedor aporta el FX, el contrato debe permitir recuperar evidencia. Pruebe cancelación y devolución para decidir qué conceptos se reintegran. El usuario necesita una referencia única para reclamar sin depender de una factura que describe sólo efectos fiscales.

Prueba de estrés

Use una operación cuya tasa cambie entre cotización y confirmación. El expediente debe mostrar cuándo se fijó, qué fuente se usó y qué aceptó el usuario, además de explicar cualquier diferencia en el recibo. Después cancele la instrucción para verificar qué comisión y diferencial se restituyen. Factura fiscal, comprobante operativo y disclosure previo cumplen funciones distintas y deben poder reconciliarse.

Base legal

• Ley General de Organizaciones y Actividades Auxiliares del Crédito (texto vigente) — artículos 81-A Bis, 81-B, 81-D, 86 Bis y 95 Bis, según el tema.
• Requisitos para obtener registro como transmisor de dinero — portal RECC-TD y lista oficial de requisitos.

Continuidad ante incidentes de fondeo o pagos

Punto de decisión

La continuidad debe cubrir banco, API, motor PLD, proveedor de cumplimiento y conciliación. Para estados inciertos se define pausa, consulta, reintento idempotente y revisión manual. El plan también indica quién comunica al usuario y cómo se evita que la recuperación tecnológica duplique una entrega.

Checklist

1. Usar identificadores idempotentes.
2. Definir estados indeterminados y revisión manual.
3. Ejecutar simulacros con proveedores críticos.

Patrón observado

En una simulación anonimizada, reintentar automáticamente después de un timeout podía duplicar la entrega porque el proveedor había procesado sin responder.

Riesgo frecuente

Reintentar después de un timeout sin consultar el estado puede pagar dos veces una instrucción que sí se procesó.

Cómo llevarlo a operación

Catalogue dependencias por impacto y tiempo máximo tolerable. Para cada una defina señal de falla, decisión de pausa y responsable de recuperación. Los reintentos usan idempotencia y consulta previa del estado. Simule pérdida de conexión después de enviar una instrucción, pues es el escenario que más fácilmente duplica pagos. Conserve mensajes y conciliación posterior. El plan debe priorizar protección de recursos y comunicación exacta, incluso si eso exige detener temporalmente nuevas operaciones.

Prueba de estrés

Simule la caída después de enviar el pago, cuando aún no existe respuesta. Antes de reintentar, el sistema consulta al banco mediante la llave original y mantiene el saldo en estado intermedio. El equipo registra hora, alcance, decisiones y comunicación, y comprueba la conciliación al recuperar servicio. El éxito no es sólo restablecer conectividad: consiste en demostrar que ningún usuario quedó cobrado dos veces o informado con un estado falso.

Base legal

• Circular 14/2017: disposiciones del SPEI, texto compilado — Circular 14/2017, texto compilado con modificaciones, incluida Circular 9/2026.
• Disposiciones legales aplicables a transmisores de dinero — DCG derivadas del artículo 95 Bis y sus modificaciones.