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 propias cargas. 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 escrituras relevantes.
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 y mapa de campos |
| Vinculación de identidad | Siga una solicitud hasta el resultado y el caso interno | Identificadores de correlación y ruta de consulta |
| Cambio de contrato | Pruebe el tratamiento documentado de un campo añadido, ausente o inválido | Versión de contrato, resultado y aprobación |
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 correlación e impacto 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 revisor 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 revisor, 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 procesado 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 |
| Resolución | Brecha abierta; requiere seguimiento antes de 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, datos y resiliencia
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.
Defina un volumen acotado de lote, concurrencia, picos y dependencias posteriores. Observe colas, fallos parciales, señales de monitorización, escalado y recuperación, no solo un tiempo de respuesta favorable. Registre condiciones, resultados, fallos abiertos, responsables y continuidad manual. Los requisitos que dependan de su política o jurisdicción son criterios propios, no capacidades universales.
7. Registre evidencia y brechas abiertas
Para cada criterio conserve requisito, datos de prueba, entorno, resultado esperado y real, ubicación de evidencia, revisor, fecha y resolución. Una respuesta sin documentación, una demostración no repetible o un resultado fuera del recorrido acordado es una brecha hasta resolverla. Repita las pruebas relevantes tras cambios materiales de integración, proceso, fuentes o configuración.
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