ComplianceShield · los cambios
La ley cambió el 16 de julio de 2025. La pregunta no es si su sistema lo sabe. Es cuánto le costó enterarse.
Umbrales, plazos, formatos oficiales, obligaciones nuevas y una autoridad distinta. En el modelo con el que se le vendió su sistema, cada una de esas cosas es una orden de cambio con su cotización. Aquí es una edición con su bitácora.
El 16 de julio de 2025, y lo que ese día le hizo a su sistema
Empecemos por el caso real, porque en este dominio no hace falta inventar un escenario. El decreto de reforma a la ley de la materia se publicó en el Diario Oficial de la Federación el 16 de julio de 2025 y entró en vigor al día siguiente. No fue un ajuste de redacción: cambió obligaciones que viven dentro de un sistema, campo por campo.
Un sistema de cumplimiento que no absorbió esos cambios no está «un poco desactualizado». Está calculando plazos de conservación equivocados, dejando fuera un dato que ahora es obligatorio y omitiendo obligaciones que la autoridad ya puede verificar. Y todo eso se mide en multas, que la propia ley fija en veces el valor diario de la unidad de medida y actualización.
Lo que la reforma del 16 de julio de 2025 obliga a mover dentro del sistema
| Qué cambió | Artículo | Qué toca dentro del sistema |
|---|---|---|
| La conservación del soporte sube de cinco a al menos diez años, y el plazo se interrumpe si hay recurso o juicio | 18, fracción IV | La política de retención por tipo de documento, el cálculo de la fecha de purga y el estado de litigio por expediente |
| Obligación expresa de identificar al beneficiario controlador de personas morales, fideicomisos y otras figuras; y declaración del cliente persona física | 18, fracción III | Entidades nuevas de cadena de propiedad y declaración, y una condición más para poder abrir la relación |
| Evaluación con enfoque basado en riesgos, para identificar y mitigar los riesgos propios y los de la contraparte | 18, fracción VII | La matriz de riesgo, su periodicidad y el score por contraparte |
| Manual de políticas internas obligatorio, con seguimiento a personas políticamente expuestas y aplicación a sucursales y filiales del grupo | 18, fracción VIII | El repositorio de políticas con versión, su distribución y su acuse |
| Programas de capacitación anuales para órgano de administración, directivos, representante de cumplimiento y personal de trato directo | 18, fracción IX | El plan anual, la constancia por persona y el vencimiento que dispara alerta |
| Mecanismos automatizados de monitoreo permanente, con seguimiento intensificado a personas políticamente expuestas y de alto riesgo | 18, fracción X | El motor de reglas, el perfil transaccional y el umbral de cada alerta |
| Revisión de auditoría interna o de auditor externo independiente, con dictamen en un año calendario | 18, fracción XI | El plan de auditoría, el hallazgo con su acción correctiva y su estado de resolución |
| Alta, modificación y baja en el padrón por el portal oficial, en el formato publicado en el Diario Oficial | 18, fracción IV Bis | El calendario de obligaciones del padrón y el formato de envío |
| La supervisión, verificación y vigilancia queda a cargo de la Secretaría | 22 Bis (nuevo) | El expediente de la visita de verificación y a quién se le responde |
| Facultad de ordenar la suspensión temporal de operaciones con determinadas personas clientes o usuarias | 54 Bis (nuevo) | Un estado nuevo de la contraparte, y el bloqueo de la operación en el punto de captura |
Fuente: texto vigente de la LFPIORPI, decreto de reforma publicado en el Diario Oficial de la Federación el 16 de julio de 2025 · verificado al 27 de septiembre de 2026
Diez cambios obligatorios de un solo decreto. En un modelo de órdenes de cambio, eso son diez cotizaciones para seguir cumpliendo lo mismo que ya cumplía.
Y la ley no es lo único que se mueve
La reforma de la ley de la materia es el caso grande, pero no es el único. El 20 de marzo de 2025 se publicó la nueva ley de protección de datos personales en posesión de los particulares, con reforma posterior del 14 de noviembre de 2025, y con ella cambió la autoridad competente: dejó de ser el instituto anterior. Eso obliga a rehacer cada aviso de privacidad que nombre a la autoridad vieja.
Hay además un tipo de cambio que en este dominio ocurre por diseño y no por excepción: el formato oficial. La ley dice que los avisos e informes se presentan por medios electrónicos y en los formatos oficiales publicados en el Diario Oficial de la Federación, «así como sus modificaciones» (artículo 24). Dicho de otro modo: la propia ley anticipa que el formato va a cambiar, y le traslada a usted la obligación de seguirlo.
Un sistema cuyo formato de salida está clavado en el código, y cuyo cambio cuesta una orden de cambio, está en desventaja estructural frente a una obligación que por definición se actualiza. Y no es culpa de su gente: es el modelo con el que se le vendió.
La única constante verificable de este dominio es que el umbral, el plazo y el formato van a cambiar otra vez.
Por qué existe la orden de cambio, y de qué es síntoma
La orden de cambio no es un trámite administrativo: es la consecuencia lógica de un modelo de contratación. Cuando el sistema se le licenció cerrado, cualquier diferencia entre su operación y el producto se convierte en trabajo de alguien que no es usted. Ese trabajo hay que cotizarlo, aprobarlo, calendarizarlo, probarlo y facturarlo. La orden de cambio es la factura de esa distancia.
El efecto secundario sale más caro que la factura. Con el tiempo, su empresa aprende a no pedir. El umbral se ajusta en una hoja de cálculo paralela, el formato nuevo se llena a mano, la matriz de riesgo vive en un archivo que nadie versiona, y el sistema que costó una fortuna termina sirviendo para archivar.
En cumplimiento eso tiene un nombre concreto: evidencia fuera del sistema. Y la evidencia fuera del sistema es exactamente la que no tiene bitácora, no tiene autor y no tiene hora, que es lo que la autoridad va a pedir.
Cuando pedir un cambio cuesta, el cumplimiento se muda a una hoja de cálculo. Y una hoja de cálculo no prueba nada.
Los cuatro niveles de impacto, decididos antes de que usted edite
El motor de cambios de la plataforma no pregunta después qué tan grave fue lo que usted tocó. Lo sabe antes. Cada campo editable está clasificado en una tabla de reglas que vive en el código, y la clasificación se resuelve en tiempo de compilación, sin inferencia al momento.
Son 662 reglas de clasificación, contadas en el código: 2 en nivel bloqueado, 199 en nivel directo, 315 en nivel con efecto en cascada y 146 en nivel con aprobación. Un campo sin regla explícita cae al nivel directo por omisión, no a un limbo.
Nivel de impacto · qué hace el sistema
| Nivel | Nombre | Qué ocurre cuando alguien lo edita | Reglas |
|---|---|---|---|
| 0 | Bloqueado | El campo está deshabilitado en pantalla y no genera solicitud. Es el caso de lo que no se toca sin rehacer el expediente | 2 |
| 1 | Directo | Se aprueba solo y el cambio se aplica. Queda solicitud registrada y aplicada, sin tarea posterior | 199 |
| 2 | Directo con efecto en cascada | Se aplica de inmediato y encola la tarea que propaga el efecto al resto del sistema | 315 |
| 3 | Con aprobación | La solicitud queda pendiente y el campo se bloquea con un indicador en pantalla hasta que el responsable aprueba o rechaza | 146 |
Fuente: niveles declarados; conteo por nivel verificado · 27 de septiembre de 2026
Las tres reglas que gobiernan el comportamiento están escritas y son verificables. Bloqueo visual: si un campo tiene una solicitud pendiente, el control queda deshabilitado con su indicador de espera, de modo que dos personas no pidan lo contrario sobre el mismo umbral. Detección automática: el nivel de impacto se determina en compilación. Reversión incorporada: la escritura sobre la tabla de origen lleva el valor original y es el motor el que aplica el valor nuevo cuando corresponde, por eso un cambio pendiente no deja el expediente a medias.
Los tipos de cambio: quién lo pide, qué hace el sistema, qué registro queda
Esta es la tabla que sostiene el titular. Cada fila es un tipo de cambio que el sistema trata de manera distinta, con la tarea del motor que lo ejecuta cuando hay efecto en cascada y el registro que queda al terminar. Los ejemplos son de este dominio, no genéricos.
Tipo de cambio · quién lo pide · qué hace el sistema · qué registro queda
| Tipo de cambio | Ejemplo en su operación | Quién lo pide | Qué hace el sistema | Qué registro queda |
|---|---|---|---|---|
| Dato de configuración de nivel directo | El umbral de identificación y el de aviso de su actividad vulnerable, cuando cambia el valor de la unidad de medida; el plazo de conservación que pasa de cinco a diez años | El responsable de cumplimiento, en su propia pantalla | Clasifica, aprueba solo y aplica el valor | Solicitud registrada y marcada como aplicada, con usuario y hora |
| Cambio de configuración con propagación | El catálogo de actividades vulnerables que su empresa realiza; el calendario de obligaciones del padrón | El responsable de cumplimiento | Aplica el valor y encola la tarea de configuración incremental, que ajusta el proyecto sin regenerarlo | Solicitud aplicada, tarea de cambio encolada y notificación informativa al proyecto |
| Alta de un artefacto nuevo | La entidad de cadena de propiedad que el beneficiario controlador exige; la pantalla del dictamen anual de auditoría | El responsable de cumplimiento, con la aprobación del responsable del sistema | Inserta el artefacto —pantalla, entidad o relación— en el proyecto existente | Solicitud, artefacto dado de alta con su identificador y notificación |
| Renombrado con propagación | El rol «Representante encargado del cumplimiento» pasa a llamarse como lo llama su organización | El responsable del sistema | Propaga el nombre nuevo a todos los textos del proyecto que lo referencian, sin intervención de un modelo de lenguaje | Solicitud aplicada y registro de los campos alcanzados |
| Baja en cascada | Se retira una actividad vulnerable que su empresa dejó de realizar, o un rol que desapareció del organigrama | El responsable del sistema | Elimina en cascada el artefacto aprobado y lo que dependía de él | Solicitud aplicada y notificación informativa |
| Cambio con aprobación | El umbral que dispara una alerta de monitoreo; el criterio con el que se cierra un dictamen; el score a partir del cual una contraparte es de alto riesgo | Lo pide quien opera; lo aprueba quien responde por el cumplimiento | Deja la solicitud pendiente y bloquea el campo en pantalla hasta la decisión | Solicitud con comentario obligatorio del aprobador, y su estado: aprobada o rechazada |
| Cambio bloqueado | La llave del expediente de una operación ya avisada, y el acuse que la autoridad devolvió | Nadie: el campo no es editable | El control está deshabilitado en pantalla y no genera solicitud | No hay cambio, y por eso no hay duda sobre el expediente |
| Cambio con efecto en el código | El formato oficial del aviso publicado con modificaciones en el Diario Oficial; un campo nuevo que la autoridad agrega al expediente de identificación | El responsable de cumplimiento | Ejecuta comprobación previa, respaldo, el cambio y el posproceso; y donde toca, regenera la capa de datos, los servicios y la pantalla | Instantánea de versión de la pantalla, con número de versión consultable |
Fuente: tareas de gestión de cambios del motor y recorrido completo de un cambio; los ejemplos de operación provienen del brochure de ComplianceShield y del texto de la ley · 27 de septiembre de 2026
Ocho tipos de cambio, ocho registros distintos. Ninguno de los ocho se cotiza.
Qué pasa, paso por paso, cuando alguien cambia algo
El recorrido está documentado y es el mismo para todos los niveles; lo que cambia es dónde se detiene. Se describe lo que ocurre, en orden, sin decir cuánto tarda.
Nadie abrió un ticket. Nadie cotizó. Y aun así hay expediente: solicitud, decisión, comentario, respaldo, versión y notificación.
- La pantalla pregunta antes de dibujarse. Al abrir, consulta qué campos tienen solicitud pendiente y los deshabilita con su indicador.
- Al guardar, el cambio se intercepta. La operación registra el cambio como tal, y la escritura sobre la tabla de origen lleva el valor original.
- El motor clasifica. Devuelve nivel de impacto, tarea de cambio asociada y tipo de operación.
- Se crea la solicitud. Auto-aprobada en los niveles directos, pendiente en el nivel con aprobación.
- Se decide. En los niveles directos, el propio sistema. En el nivel con aprobación, el responsable desde la pantalla de gestión de cambios, que aprueba o rechaza.
- El procedimiento aplica el cambio. Lee la solicitud, escribe sobre la tabla correspondiente, pasa la solicitud a aprobada, si el cambio tiene efecto en cascada, encola la tarea que lo propaga.
- Se ejecutan los efectos. Comprobación previa, respaldo, cambio, posproceso y —cuando el cambio lo exige— regeneración de la base, de los servicios y de las pantallas afectadas.
- Queda la versión. Se calcula el número de versión nuevo y se guarda la instantánea, consultable después por pantalla.
La matriz de estados de una solicitud de cambio
Una solicitud de cambio es una entidad con estados, no un correo. El catálogo de estados está en la plataforma de la casa y tiene ocho entradas, transcritas aquí tal como están.
Un detalle que conviene decir porque circula al contrario: no existe un estado «revertido» en el catálogo del motor. Aparece mencionado en material interno de trabajo y no está en la base. La reversión se sostiene con el respaldo del artefacto y la instantánea de versión, que sí existen y se citan más arriba, no con un estado de la solicitud.
Los ocho estados de una solicitud de cambio, transcritos del motor
| # | Estado | Qué significa en la práctica |
|---|---|---|
| 1 | Por analizar | La solicitud existe y espera clasificación |
| 2 | Analizando | El motor está resolviendo nivel de impacto y efectos |
| 3 | Por aprobar | Espera la decisión del responsable; el campo está bloqueado en pantalla |
| 4 | Aprobada | La decisión está tomada y el cambio va a escribirse |
| 5 | Rechazada | La decisión fue no, con su comentario |
| 6 | Por aplicar cambios | Aprobada y en cola de aplicación |
| 7 | En proceso de aplicación de cambios | Hay una tarea de propagación corriendo |
| 8 | Cambios aplicados | El cambio está en el sistema, con su instantánea de versión |
Transcrito del motor de la casa, tabla cat_estado_cambio, consultada el 27 de septiembre de 2026. El recorrido documentado del caso frecuente es 1 → 3 → 4 → 7 → 8, con 5 como salida de la decisión.
Qué se verificó, con su fecha
La afirmación «los cambios se hacen en la sesión» sólo vale si alguien la probó campo por campo. La verificación de cobertura del motor de cambios existe, está fechada, y dice lo siguiente.
Verificación de cobertura del motor de cambios
| Qué se verificó | Resultado | Fecha y origen |
|---|---|---|
| Campos editables recorridos de extremo a extremo | 229 campos en 63 entidades, con cero errores | 31 de mayo de 2026 |
| Reparto de esos campos por comportamiento | 175 se aprueban solos · 52 quedan pendientes de aprobación · 2 están bloqueados | 31 de mayo de 2026 |
| Corrida anterior, para comparar | 174 campos, cero errores | 30 de mayo de 2026 |
| Reglas de clasificación en el código | 662 reglas: 2 bloqueadas, 199 directas, 315 con cascada, 146 con aprobación | Conteo en código |
| Pantallas del portal con el motor integrado y pantallas sin él | Inventario con sus huecos nombrados: dos pantallas con regla declarada y sin integración de pantalla, y 31 pantallas fuera del motor por diseño | Verificación interna de cobertura |
Fuente: verificación interna de cobertura del motor de cambios de la plataforma, con las fechas indicadas
Se publica también el hueco, porque un inventario que sólo lista lo que funciona no es un inventario. Hay pantallas del portal cuya regla de clasificación existe en el código sin la integración correspondiente en la pantalla, y hay pantallas que quedan fuera del motor por decisión de diseño. Están nombradas una por una en el inventario interno, con su fecha.
229 campos probados, cero errores, y los huecos con nombre. Eso es una verificación; lo demás es una promesa.
Por qué no hay orden de cambio
La respuesta no es comercial, es estructural. La orden de cambio existe para resolver cuatro incógnitas: qué tan grave es el cambio, quién tiene que autorizarlo, qué más se rompe y cuánto cuesta el trabajo de aplicarlo. En este sistema las cuatro están resueltas antes de que usted abra la pantalla.
Lo único que queda del ciclo tradicional es la parte que sí es suya: la decisión de negocio sobre si el cambio debe hacerse, y quién responde por ella.
- La gravedad no se estima: está clasificada. 662 reglas en el código dicen el nivel de impacto de cada campo, decidido en compilación. No hay una junta que lo dictamine.
- La autorización no es un comité: es un estado. Los 146 campos de nivel con aprobación la piden dentro del sistema, a quien responde por el cumplimiento, con comentario obligatorio. Los otros no la necesitan porque su efecto ya está acotado.
- Lo que se rompe no se investiga: se propaga. Las tareas de configuración incremental, alta de artefacto, renombrado con propagación y baja en cascada existen precisamente para eso, y son parte del motor, no de un proyecto aparte.
- El trabajo de aplicarlo no se cotiza porque no se hace a mano. Donde el cambio toca el código, el propio motor regenera la capa de datos, los servicios y la pantalla, y guarda la versión. No hay horas de consultoría que facturar porque no hay horas de consultoría.
Dicho al revés, que es como se entiende mejor: no es que se haya decidido no cobrar por los cambios. Es que el cambio dejó de ser un entregable. Y cuando el cambio no es un entregable, no hay nada que facturar por entregarlo — por eso el trato es cobrar por resultados.
El contraste, en términos del modelo de contratación
La comparación que sigue no habla de la calidad de ningún producto ajeno. Habla del modelo con el que se contrata, que es lo que determina qué le pasa a usted el día que la ley de la materia se reforma otra vez.
El mismo cambio regulatorio, dos modelos de contratación
| Cuando cambia un umbral, un plazo o un formato oficial | En un sistema licenciado, con órdenes de cambio | En ComplianceShield |
|---|---|---|
| Quién decide si se puede hacer | El proveedor, tras un análisis de viabilidad que se contrata | Está decidido: el campo tiene su nivel de impacto en el código |
| Quién autoriza | Un comité de control de cambios, con acta | Quien responde por el cumplimiento, dentro del sistema, con comentario obligatorio |
| Qué se firma antes de empezar | Cotización, alcance y calendario | Nada. La solicitud es el registro, y la genera el propio sistema |
| Quién ejecuta | Consultoría, propia o de un socio implementador | El motor, con sus tareas de propagación y regeneración |
| Qué pasa con los demás módulos | Se investiga el impacto y se cotiza aparte | La propagación es parte del tipo de cambio: renombrado, alta, baja en cascada |
| Cómo se prueba | Un ciclo de pruebas contratado | Comprobación previa y posproceso dentro del recorrido; el sistema deja la versión |
| Qué queda documentado | El acta del comité y la orden firmada | Solicitud, estado, comentario, respaldo, instantánea de versión y notificación |
| Qué pasa si sale mal | Una orden de cambio nueva | El respaldo del artefacto y la instantánea de versión anterior existen desde antes de aplicar |
| Qué pasa mientras tanto con su obligación | Sigue corriendo. El plazo del día 17 no espera a que la orden de cambio se apruebe | Sigue corriendo, y el sistema ya cambió |
| Qué aprende su empresa | A no pedir | A pedir, porque pedir no cuesta |
Comparación sobre el modelo de contratación, no sobre la calidad de ningún producto ajeno · 27 de septiembre de 2026
El que cobra por cada cambio tiene un incentivo que usted no comparte: que su operación no se parezca al producto.
Lo que esta página no le promete
Aquí no aparece ningún número de días, de horas ni de milisegundos, y la razón se dice completa: en el material técnico de la plataforma existen cifras de latencia del motor de cambios, y al revisarlas resultaron ser estimaciones escritas en un diagrama, sin instrumentación, sin entorno de medición, sin percentil y sin fecha. Una cifra así no se publica.
Tampoco se publica un porcentaje de cobertura que circula en el mismo material, porque su aritmética no cuadra con el universo de campos verificado. Lo que sí se publica es lo que se contó: 662 reglas en el código, 229 campos recorridos con cero errores el 31 de mayo de 2026, y el reparto entre los que se aprueban solos, los que esperan aprobación y los que están bloqueados.
Y queda una distinción que conviene no perder. «En la sesión» describe dónde ocurre el cambio —dentro del sistema, en la pantalla donde se trabaja, sin salir a un proceso paralelo—, no cuánto tarda el reloj. Lo que se compromete es que no hay una orden de cambio entre su decisión y el sistema. El resto lo comprobará usted mismo cuando lo tenga enfrente.
Se describe lo que ocurre. No se compromete un número de días.
Preguntas frecuentes
¿De verdad no hay órdenes de cambio, o es una forma de hablar?
No las hay porque el cambio no es un entregable que alguien tenga que producir a mano. Cada campo editable está clasificado en uno de cuatro niveles de impacto por una tabla de 662 reglas en el código; la autorización, cuando hace falta, es un estado de la solicitud dentro del propio sistema; y la propagación la ejecuta el motor con sus tareas de configuración incremental, alta de artefacto, renombrado y baja en cascada.
Cambió la ley. ¿Qué tengo que hacer para que el sistema lo refleje?
Depende del tipo de cambio, y por eso existe la tabla de arriba. Un umbral o un plazo —de cinco a diez años de conservación, por ejemplo— es un dato de configuración que el responsable de cumplimiento edita en su pantalla. Una obligación nueva que exige una entidad o una pantalla es un alta de artefacto. Un formato oficial que cambia toca la capa de datos y los servicios, y el motor los regenera dejando instantánea de versión. Ninguno de los tres pasa por una cotización.
¿Entonces cualquiera puede cambiar cualquier cosa?
No. Dos campos están en nivel bloqueado y no son editables por nadie; 146 exigen aprobación del responsable, con comentario obligatorio, y mientras esperan, el campo queda deshabilitado en pantalla con su indicador. El control no desapareció: dejó de ser un trámite externo para ser una decisión registrada dentro del sistema.
¿En cuánto tiempo queda aplicado un cambio?
No publicamos un plazo, y decimos por qué: las cifras de tiempo que existen en el material técnico interno son estimaciones escritas en un diagrama, sin instrumentación ni entorno de medición. Lo que sí está verificado es el recorrido —solicitud, clasificación, decisión, aplicación, propagación, versión— y que 229 campos se recorrieron de extremo a extremo con cero errores el 31 de mayo de 2026.
¿Qué pasa si el cambio sale mal?
El respaldo del artefacto y la instantánea de versión se producen dentro del propio recorrido, antes y después de aplicar, no como un trámite aparte. Lo que no existe es un estado «revertido» de la solicitud: el catálogo de estados del motor tiene ocho entradas y ninguna es ésa (cat_estado_cambio, consultada el 27 de septiembre de 2026). La reversión se sostiene con el respaldo y la versión, no con un estado.
¿Cuándo sí tengo que hablar con alguien de la casa?
Cuando el cambio no es de configuración sino de criterio: una actividad vulnerable que su empresa empieza a realizar y no estaba en el alcance, un régimen distinto al de actividades vulnerables, un proceso que su organización decide operar de otra manera. Esa conversación es sobre el negocio y no se factura como orden de cambio: el trato es cobrar por resultados, no por entregables.
Referencias
- Ley Federal para la Prevención e Identificación de Operaciones con Recursos de Procedencia Ilícita. Texto vigente, última reforma publicada en el Diario Oficial de la Federación el 16 de julio de 2025, en vigor el 17 de julio de 2025. Artículos 17, 18 (fracciones III, IV, IV Bis, VII a XI), 22 Bis, 23, 24, 53, 54 y 54 Bis. Consultada el 27 de septiembre de 2026. ↗
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares, publicada en el Diario Oficial de la Federación el 20 de marzo de 2025, con reforma del 14 de noviembre de 2025: cambia la autoridad competente respecto de la ley de 2010. Consultada el 27 de septiembre de 2026. ↗
- Evidencia de plataforma: motor de cambios del motor de la casa — 662 reglas de clasificación y su reparto por nivel; niveles de impacto, recorrido y estados de la solicitud; verificación de cobertura, 30 y 31 de mayo de 2026; y inventario y huecos. Recogidas con cita de archivo y línea en el expediente interno. Verificado el 27 de septiembre de 2026.
- Motor del motor de la casa · base del motor de la casa, tabla cat_estado_cambio: ocho estados de una solicitud de cambio, sin estado de reversión. Consultada el 27 de septiembre de 2026.
El modelo
Primero ve su sistema funcionando, sin costo y sin compromiso. Después decide si lo compra o lo renta.
No es un demo: es ComplianceShield con sus procesos, sus áreas y su operación dentro. Entra, lo recorre y lo usa. Verlo no cuesta nada y no lo compromete a nada. Cuando decida, cobramos por resultados, no por entregables.