Requisitos técnicos de aceptación para software de cribado de sanciones en 2026
Esta lista sirve a los equipos de cumplimiento, riesgo, seguridad e ingeniería para probar un flujo de cribado en su propio entorno. No es una lista regulatoria universal, una tabla de contratación ni una promesa sobre un proveedor.
Para comparar proveedores, solicitar evidencia contractual y organizar una RFP o implantación, consulte la guía para elegir software de cribado de sanciones. El diseño detallado de pruebas y la calibración se tratan en la guía para reducir falsos positivos.
1. Delimite la aceptación antes de la demostración
Registre las partes, procesos, sistemas, jurisdicciones y fuentes incluidos. Distinga altas, importaciones por lotes, solicitudes API, monitorización y procesos de pagos o contrapartes. Una demostración en pantalla no prueba que producción envíe los mismos campos ni conserve la misma evidencia. Para cada recorrido, identifique responsable, sistema de referencia, entrada esperada, resultado de aceptación y derivación a revisión.
2. Verifique el contrato de campos de la API y la vinculación de identidad
Solicite el contrato de API y pruébelo con sus propios datos de solicitud. Confirme campos obligatorios y opcionales, normalización, rechazos, truncamiento y conservación de valores. Pruebe nombres, alias, fechas de nacimiento, direcciones, identificadores, denominaciones sociales, países y los sistemas de escritura pertinentes.
La evidencia debe incluir:
- Esquemas de solicitud y respuesta, formatos, límites y errores de validación.
- Identificadores estables de solicitud, resultado, registro fuente y caso vinculables con sus registros.
- Comportamiento ante datos ausentes, contradictorios, duplicados o no admitidos.
- Si el trabajo es síncrono, en cola o parcial y cómo se obtiene el estado final.
- Versionado y aviso de cambios de campos, endpoints y significado de las respuestas.
No presuponga que una puntuación, estado o identificador significa lo que necesita su proceso. Conserve el significado documentado y pruebe el sistema que consume la respuesta.
| Requisito que probar | Prueba práctica | Evidencia que conservar |
|---|---|---|
| Integridad de entrada | Envíe una parte representativa y compare campos enviados y aceptados | Solicitud anonimizada, respuesta, resultado de validación y registro de correspondencia de campos |
| Vinculación de identidad | Siga una solicitud hasta el resultado y el caso interno | Identificadores de correlación y ruta de consulta en ambos sistemas |
| Cambio de contrato | Pruebe el tratamiento documentado de un campo añadido, ausente o inválido | Versión de contrato, resultado de la prueba, aprobación del responsable y aviso del cambio |
La evidencia esperada no es un nombre concreto de campo o endpoint, sino una demostración repetible del comportamiento del que depende su integración.
3. Pruebe fallos, tiempos de espera, reintentos e idempotencia
Ejecute pruebas de interrupción de red, espera agotada en el cliente, error del servicio, entrada mal formada, límite de uso, envío duplicado, finalización retrasada y reentrega de webhooks. Solicite códigos de error, reglas de reintento, límites de espera, comportamiento de retry-after, semántica de claves de idempotencia y el modelo de estados asíncronos.
Confirme qué ocurre si el cliente no recibe respuesta pero la solicitud fue aceptada. Pruebe si reintentar devuelve el resultado original, crea una nueva ejecución o exige conciliación. Documente quién investiga un estado desconocido, dónde se consulta el estado de referencia, cuándo puede repetirse el trabajo y cómo se detectan duplicados.
| Escenario | Pregunta de prueba | Evidencia que evaluar |
|---|---|---|
| Espera agotada tras el envío | ¿Puede el equipo saber si se aceptó la solicitud? | Guía contractual, consulta de estado y conciliación |
| Lote parcialmente completado | ¿Se distinguen elementos terminados y elementos a recuperar? | Resultado por elemento, detalle de error y proceso de repetición |
| Solicitud duplicada | ¿El enfoque documentado evita trabajo duplicado? | Evidencia de idempotencia o correlación y resultado observado |
| Webhook tardío o repetido | ¿El consumidor procesa la notificación de forma segura? | Registro de entrega, log del consumidor y estado interno final |
Use como referencia la temporización de reintentos y la semántica de estados documentadas por el proveedor. Si no puede demostrarlas o no sirven al proceso, registre una brecha abierta, no una regla inventada.
4. Exija trazabilidad de fuentes, versiones y cambios
Para una coincidencia potencial, compruebe que el analista pueda recuperar o exportar el registro fuente, su identificador, versión o fecha de publicación, fecha de incorporación, alias e identificadores relevantes. Pruebe una actualización de fuente, o un equivalente controlado: determine qué cambió, cuándo llegó al proceso y si el evento conserva vínculo con el resultado y caso previos. Defina la evidencia de fuentes y actualizaciones que exige su organización, sin aceptar afirmaciones generales de cobertura.
5. Convierta la reconstrucción de auditoría en una prueba práctica
Pida a una persona independiente reconstruir un caso de prueba terminado sin ayuda de quien presenta la solución. Debe identificar datos enviados y remitente, ejecución, configuración o política, estado de fuentes, contexto visible, acciones del analista, notas, escalado, decisión, marcas de tiempo y cambios posteriores que reabrieran el trabajo.
Guarde exportación, respuestas API, capturas y ruta de acceso. Si la evidencia se reparte entre sistemas, documente identificadores de correlación y responsabilidades de conservación. La guía para documentar una investigación de alertas trata los detalles por alerta.
Ejemplo de registro de aceptación
El ejemplo es ilustrativo; no prescribe estados, respuestas API ni funciones de producto.
| Campo | Entrada ilustrativa |
|---|---|
| Elemento de aceptación | Recuperar una solicitud cuyo resultado no recibió el cliente |
| Referencia de prueba | INT-REC-04 |
| Resultado esperado | Identificar el resultado final y evitar el procesamiento interno duplicado |
| Resultado observado | Pendiente de revisión: la consulta no aportó correlación suficiente |
| Responsable de evidencia | Responsable de integración, con revisión de cumplimiento |
| Ubicación de la evidencia | Repositorio de pruebas aprobado y referencia al expediente del caso |
| Resolución | Brecha abierta; requiere seguimiento antes de la aprobación para producción |
Un aprobado exige prueba pactada y evidencia recuperable. Un fallo contradice el criterio. Una brecha abierta indica que falta resultado, documentación, acceso o responsable y no debe contarse como aprobada. Asigne un responsable para obtener evidencia del proveedor y otro interno para aceptarla o rechazarla.
6. Valide accesos, seguridad y operaciones de datos
Pruebe el modelo de acceso, no solo un cuestionario. Confirme que los roles de analista, aprobador, administrador, integración y auditor solo ejecuten las acciones previstas. Acorde la evidencia sobre datos en tránsito y reposo, separación de entornos, registros, conservación, eliminación, residencia, subencargados, notificación de incidentes, copias de seguridad y continuidad. Los requisitos que dependan de su política o jurisdicción son criterios propios, no capacidades universales del producto.
7. Pruebe la resiliencia operativa con una carga realista
Defina un volumen acotado de prueba para el tamaño de los lotes, la concurrencia, los periodos de máxima actividad y las dependencias de los sistemas posteriores. Observe colas, fallos parciales, señales de monitorización, escalado al soporte y recuperación, no solo un tiempo de respuesta favorable. Registre condiciones, resultados, fallos sin resolver, responsables y procedimientos de reversión o continuidad manual. Confirme cómo se comunican los incidentes, el mantenimiento y los cambios incompatibles, y qué información está disponible para conciliar los resultados tras la recuperación.
8. Registre evidencia y brechas abiertas
Para cada criterio conserve requisito, datos de prueba, entorno, resultado esperado y real, ubicación de la evidencia, analista, fecha y resolución. Trate una respuesta sin documentación, una demostración no repetible o un resultado fuera del proceso acordado como una brecha abierta hasta resolverla. El conjunto de evidencias corresponde a los datos, la configuración, el estado de las fuentes y la integración especificados en ese momento; repita las pruebas relevantes tras cambios materiales.
Mantenga el registro de aceptación separado de la decisión comercial. La guía de compra ayuda a estructurar esa decisión; este registro debe mostrar los supuestos técnicos y las rutas de recuperación aún sin resolver.
¿Desea evaluar el encaje operativo de un flujo de cribado? Conozca el cribado de sanciones de Checklynx y valide con su equipo el contrato, proceso y ruta de evidencia necesarios.
Siga leyendo: IA aplicada al cribado PBC/FT