Precios
Idioma

Guía · Actualizada el 10 de septiembre de 2026 · 15 min de lectura

Cambiar de software de cribado de sanciones: plan de control para la migración

Plan práctico para controlar el cambio de proveedor de cribado de sanciones, incluidos datos, configuración, decisiones, monitorización, pruebas, transición y documentación.

Compartir

Esta guía se dirige a organizaciones que ya utilizan software de cribado de sanciones y van a sustituirlo o modificarlo de forma sustancial. Si la cuestión es qué producto adquirir, empiece por cómo elegir software de cribado de sanciones.

La pregunta de la migración es distinta:

¿Podemos pasar del control actual al estado objetivo aprobado sin perder cobertura de cribado, continuidad de la monitorización, contexto de las investigaciones ni documentación?

Las conclusiones supervisoras de la FCA aportan ejemplos para entidades reguladas en el Reino Unido que muestran por qué es importante: puede mantenerse la configuración histórica de un proveedor sin un análisis suficiente, las transferencias entre sistemas pueden introducir errores en los datos y los fallos en integraciones antiguas pueden dejar actividad sin cribar.1 Son conclusiones supervisoras, no un método universal de migración.

Trate la sustitución como un cambio del control

Una nueva plataforma puede superar una prueba de concepto durante la compra y fallar después de su implantación porque la organización asignó campos incorrectos, omitió una población, cambió sin querer el comportamiento del cotejo, perdió registros de monitorización o dejó de poder reconstruir decisiones anteriores. Por tanto, la migración debe abarcar el control de cumplimiento, los datos y la configuración, las operaciones y la documentación, además de la continuidad técnica; no solo el despliegue de la aplicación.

Para las entidades incluidas en el ámbito de SYSC 8 de la FCA, las normas de externalización mantienen la responsabilidad en la entidad y abordan la supervisión, el acceso, la continuidad y la terminación.2 Es un ejemplo regulatorio británico de alcance limitado, no una regla aplicable a todas las organizaciones del mundo.

Documente el estado actual aprobado

Documente lo que hace realmente el sistema actual antes de diseñar la transferencia. No deduzca su funcionamiento del contrato ni de una descripción genérica del proveedor.

Registre:

  • el perímetro de cribado aplicable y las fuentes oficiales aprobadas;
  • los clientes, empresas, titulares, contrapartes u otras partes que entran en el control;
  • los eventos de alta, pago, cambio y nueva comprobación;
  • los identificadores persistentes de las personas o entidades y los sistemas responsables de ellos;
  • los campos enviados al cribado y las transformaciones aplicadas antes del cotejo;
  • la configuración del cotejo, las exclusiones y los estados de decisión;
  • las dependencias de API, lotes, portal, colas y monitorización; y
  • la documentación conservada sobre las ejecuciones de cribado y las investigaciones.

Utilice la guía práctica del cribado de sanciones si también debe reevaluarse el alcance subyacente. Esta guía de migración presupone que la organización cuenta con un responsable del perímetro jurídico y operativo.

Cree un mapa del control actual al control objetivo

Asigne a cada elemento del estado actual un tratamiento aprobado en el estado objetivo. Que «ambos proveedores lo admitan» no basta: unas etiquetas o cifras de umbral equivalentes pueden producir comportamientos distintos.

Elemento del controlDecisión de migraciónDocumentación necesaria antes del cambio
Fuentes y programasAsignar los registros y procesos de actualización actuales a las fuentes vigentes del sistema objetivoInventario de fuentes, identificadores, versiones y prueba de actualización
Registros de personas y entidadesConservar los identificadores internos estables y definir las transformaciones de los camposRecuentos de exportación, registros rechazados y conciliación por campos
Configuración del cotejoAprobar configuraciones que no sean equivalentes, en vez de copiar cifrasReferencia inicial, configuración objetivo y comparación representativa
Decisiones anteriores de no coincidenciaVolver a validarlas, migrarlas cuando sea posible, archivarlas o retirarlas de forma deliberadaRegla de decisión, responsable, revisión de una muestra y registro de excepciones
Alertas y casos abiertosCompletarlos en el sistema actual, recrearlos en el objetivo o conservarlos con acceso controladoInventario de casos, conciliación de estados y prueba de recuperación
Registros de monitorizaciónContabilizar todas las personas y entidades y las fuentes pertinentes en el sistema objetivoConciliación de las partes incluidas y las fuentes antes y después del cambio
Interfaces y colasAsignar productores, consumidores, errores, reintentos y conciliaciónPrueba integral y responsable designado de los fallos
Documentación históricaConservar o exportar suficiente contexto para reconstruir la actividad anteriorPrueba de recuperación, fundamento de conservación y plan de acceso tras la terminación

Los identificadores internos estables son importantes. Un nombre modificable no es una clave de enlace segura para conectar una persona o entidad exportada con su estado de monitorización, decisiones anteriores e historial de casos.

No copie decisiones anteriores sin validarlas

Una decisión anterior sobre un falso positivo o una exclusión se adoptó con datos de fuentes, identificadores, comportamiento del cotejo y documentación del analista concretos. Un motor nuevo puede agrupar los registros de otra forma, mostrar identificadores distintos o utilizar otro modelo de decisión.

Elija un tratamiento aprobado para cada clase de decisión: volver a validarla, migrarla cuando el destino permita un estado controlado equivalente, conservarla como documentación histórica o retirarla con un motivo documentado. El diseño detallado de las exclusiones y los umbrales se explica en la guía para reducir falsos positivos en el cribado de sanciones.

Las investigaciones abiertas necesitan un responsable expreso. No permita que un caso desaparezca porque el sistema actual deje de aceptar trabajo antes de que el nuevo esté preparado. Decida si cada caso se completará en el sistema anterior, se recreará en el nuevo proceso o se conservará en modo de solo lectura conforme al plan de documentación aprobado por la organización.

Proteja la monitorización continua durante la transición

Concilie la población monitorizada, los identificadores persistentes, las fuentes activas y el último punto de cribado satisfactorio. Registre el último evento correcto del sistema actual y el primero del sistema objetivo, contabilice los cambios en las fuentes que se produzcan entre ambos, defina cómo se conciliarán los registros fallidos o duplicados e identifique quién puede detener la transición si los recuentos no coinciden.

La monitorización continua es una capacidad del estado objetivo, no una prueba de que la transición se haya completado.

Pruebe la aceptación de la migración y las diferencias no explicadas

Utilice datos representativos de producción y casos conocidos con resultados esperados para probar las fuentes, la asignación, el cotejo, la distribución, los registros de monitorización, la gestión de errores y la documentación conservada. La sección sobre pruebas del control en producción explica el trabajo de pruebas más amplio; el plan de migración debe centrarse en las diferencias entre el sistema anterior y el nuevo.

Compare los resultados por clases, en vez de ocultarlos en un único porcentaje general de «precisión»:

  • coincidencias esperadas devueltas u omitidas;
  • registros limpios o conocidos sin coincidencia que generen nuevo trabajo de revisión;
  • registros rechazados, truncados o transformados de forma distinta;
  • decisiones anteriores que ya no puedan aplicarse sin más;
  • personas, entidades o fuentes monitorizadas que falten en cualquiera de los sistemas;
  • alertas y casos enviados a la cola equivocada;
  • documentación que no pueda reconstruirse.

Una ejecución en paralelo puede ayudar a detectar diferencias cuando sea proporcionada y tenga sentido desde el punto de vista técnico, pero no es obligatoria en todos los casos ni exige una duración fija arbitraria. Investigue las diferencias no explicadas: el objetivo no es obligar a ambos sistemas a producir resultados idénticos.

Controle la transición, la reversión y los incidentes

Defina la autoridad de aceptación, las excepciones sin resolver, la secuencia de transición y el último momento en que todavía sea seguro revertir el cambio. Asigne responsables para los fallos de integración, los problemas de fuentes, los registros rechazados, las lagunas de monitorización, los fallos de las colas y los problemas de documentación.

Un registro útil de la transición identifica:

  • la configuración y el estado de las fuentes aprobados;
  • los recuentos conciliados de personas y entidades y de monitorización;
  • las excepciones abiertas y los controles compensatorios;
  • el último punto de procesamiento del sistema actual y el primero del sistema objetivo;
  • la aprobación responsable, la marca temporal y los criterios de reversión;
  • las comprobaciones posteriores al cambio y cualquier carga retrospectiva necesaria.

No prometa una disponibilidad ininterrumpida cuando el objetivo real del control es una continuidad detectable y conciliada.

Cierre el sistema anterior sin perder documentación

Antes de la terminación, confirme qué puede exportarse, en qué formato, hasta cuándo y con qué metadatos. Pruebe el acceso a las ejecuciones históricas de cribado, los casos, los adjuntos y las justificaciones después de la transición operativa.

La conservación depende de los requisitos jurídicos, regulatorios, contractuales e internos aplicables. No existe un periodo universal de conservación para el cribado de sanciones. Documente dónde permanecerá la información, quién podrá recuperarla, cómo se respaldarán las investigaciones abiertas y qué pruebas de supresión o devolución exige el contrato.

La guía de investigación de alertas explica la documentación necesaria para conectar una posible coincidencia con la identidad, el análisis de titularidad o control y la actuación final. La migración debe preservar esa separación; importar únicamente una etiqueta de estado no basta.

Dónde encaja Checklynx

Después de definir el estado objetivo y los criterios de aceptación, evalúe si el cribado de sanciones de Checklynx se adapta al plan de migración aprobado. Checklynx permite realizar cribados mediante portal, CSV o lotes y procesos API en tiempo real, además de monitorización configurada, revisión de casos y documentación de auditoría.

Checklynx ofrece asistencia para planificar e implantar la migración sin coste adicional. El trabajo se circunscribe al sistema actual, las exportaciones disponibles, las integraciones necesarias y el plan de implantación acordado.

Estas capacidades no significan que Checklynx convierta automáticamente todas las exportaciones del sistema anterior, reproduzca el comportamiento de otro motor, importe todos los casos históricos ni garantice una migración sin interrupciones. El cliente sigue siendo responsable de su perímetro, la asignación de datos, la aceptación, el análisis jurídico y las decisiones autorizadas.

Preguntas frecuentes

¿En qué se diferencia cambiar de software de cribado de sanciones de seleccionar un proveedor?

La selección define y evalúa la solución futura. La migración controla el paso de un sistema de producción existente al destino aprobado sin perder poblaciones, monitorización, decisiones ni documentación. Ambas tareas deben estar vinculadas, pero no duplicarse.

¿Deben funcionar en paralelo los sistemas de cribado de sanciones anterior y nuevo?

La ejecución en paralelo puede ser útil cuando sea proporcionada y los resultados puedan conciliarse de manera significativa. No es un requisito regulatorio universal y no cabe esperar resultados idénticos de motores que no sean equivalentes. Defina la finalidad, los criterios de aceptación, el responsable de las excepciones y la condición de finalización.

¿Pueden importarse al nuevo sistema las decisiones anteriores sobre falsos positivos?

Es posible si el sistema objetivo permite un estado controlado equivalente y la decisión sigue siendo defendible respecto a la fuente, la documentación de identidad y el contexto de cotejo pertinentes. No copie las exclusiones sin más. Vuelva a validar, migre, archive o retire cada clase conforme a una regla aprobada.

¿Qué ocurre con las alertas de sanciones abiertas durante la migración?

Asigne un destino a cada alerta o caso abierto antes de la transición: complételo en el sistema actual, recréelo en el sistema objetivo cuando sea posible o consérvelo con acceso controlado y un responsable. Concilie el inventario después del cambio.

¿Una migración satisfactoria valida el programa de sanciones?

No. La aceptación de la migración puede demostrar que las poblaciones, fuentes, integraciones y procesos definidos se trasladaron según lo previsto. No demuestra la identidad, la titularidad o el control, el vínculo jurídico, las licencias, las comunicaciones ni todas las decisiones finales en materia de sanciones.

Fuentes oficiales

Footnotes

  1. Financial Conduct Authority, Sanctions systems and controls: our firms, our findings, conclusiones supervisoras británicas sobre configuración de sistemas, transferencia de datos, integración, pruebas y evaluación de proveedores, publicadas el 28 de mayo de 2026, consultadas el 10 de septiembre de 2026.

  2. Financial Conduct Authority, SYSC 8.1: General outsourcing requirements, normas y guía para las entidades dentro del ámbito aplicable de la FCA sobre responsabilidad conservada, supervisión, acceso, continuidad y terminación, consultadas el 10 de septiembre de 2026.

Pie de página

Cambiar de software de cribado de sanciones | Checklynx