KYC/AML integración con proveedores de validación

1) Por qué es necesario y qué KPI son importantes

Objetivos: cumplir con los requisitos de los reguladores, prevenir el fraude/lavado, reducir los chargebacks y los riesgos de los socios/pagadores con un mínimo de fricción.

Métricas clave:

Approval rate (por segmentos de mercado/pago/VIP), FPR/FNR, tiempo de onboarding (p95), costo de verificación por jugador.
Hit-rate por sanciones/PEP/Adverse Media, porcentaje de casos manuales, porcentaje de inspecciones pendientes.
SLA del proveedor (aptime, latency, p95 de respuesta), retroceso/errores de integración.

2) Arquitectura de integración básica

Capas:

1. Orchestrator (su servicio de risk-onboarding): enrutará las solicitudes entre proveedores según las reglas/países/tipos de verificación.

2. Providers SDK/API: KYC (ID + Liveness), AML (санкции/PEP/Adverse Media), Address, Age, Device.

3. Feature Store/Risk Engine: almacena resultados, banderas, fichas de puntuación y antifraude.

4. Gestión de casos: revisiones manuales, apelaciones, revisión de segunda línea.

5. Audit & Compliance: registros de soluciones inmutables, versionamiento de reglas/modelos, informes al regulador.

Flujos de eventos:

Registration → Age/ID (mínimo KYC por jurisdicción).
Primer Depósito/Withdrawal → Due Diligence Enhanced (EDD por montos/riesgos).
Recurring AML Screening: reprogramación de sanciones/RR programada (diaria/semanal).
Trigger-based: cambio de datos/dispositivo/geo → re-screen.

3) Tipos de inspecciones y qué hacen exactamente

Verificación de documentos: pasaporte/ID/aguas. Certificado/permiso de residencia; OCR + MRZ/Barcode, cheque de autenticidad.

Liveness & Biometrics: liveness activo/pasivo, face-match (selfie↔document).

Comprobación de dirección: prueba de dirección (factura de utilidad/extracto bancario), a veces registros de direcciones.

Sanctions/PEP/Watchlists: OFAC/UN/EU/UK HMT + local; personas políticamente significativas; listas de medios no deseados/crónicas judiciales (Adverse Media).

Verificación de edad: fecha de nacimiento vs umbrales locales.

Device/Email/Phone: señales de riesgo (dominios desechables, números virtuales, proxy/hosting).

KYB (para socios/comerciantes): estatutos, beneficiarios (UBO), registros de inscripción, noticias negativas.

4) Orquestación y enfoque basado en riesgos

Reglas de enrutamiento: país del documento → proveedor A si no hay cobertura → proveedor B; VIP/alta cantidad → paquete EDD.

Lógica de paso a paso: cheque soft (fuentes de datos) → en caso de riesgo, solicitamos selfies/documentos.

Composición: la combinación de AML screening + IDV + Address depende de la jurisdicción (MGA/UKGC/Curacao, etc.) y la etapa del ciclo de vida (onboarding vs payout).

Re-screening: periódico (por ejemplo, diario sobre sanciones) y eventual (cambio de país/documento).

5) Diseño API y patrones de integración

Idempotency & retries: todas las llamadas - con clave de idempotencia; retraídas exponenciales, taimautas, circuit-breaker.

Webhooks: estados asíncronos (processing → completed → reviewed).

Validación de entrada: control de formato (MRZ, país ISO, documento-taips).

Almacenamiento de artefactos: cifrado, TTL/retention por jurisdicciones, acceso bajo el principio de «mínimo necesario».

Ejemplo de consulta (pseudo):

http
POST /kyc/start
{
"user_id": "u_123",  "flows": ["IDV","AML"],  "country_hint": "DE",  "document_types": ["PASSPORT","NATIONAL_ID"],  "webhook_url": "https://risk. example. com/webhooks/kyc"
}

Respuesta del proveedor:

json
{
"session_id": "sess_abc",  "status": "pending",  "redirect_url": "https://provider/flow/sess_abc"
}

Resumen de la Web:

json
{
"session_id": "sess_abc",  "status": "approved",  "checks": {
"idv": {"liveness": "pass", "face_match": 0. 92, "doc_authenticity": "pass"},   "aml": {"sanctions": "clear", "pep": "clear", "adverse_media": "none"}
},  "risk_score": 18
}

6) Calidad de los datos: problemas y soluciones estándar

Transliteración/variabilidad de nombres: utilice algoritmos fonóticos, normalización, tablas alias.

Scripts no latinos: comparación de nombres en alfabeto cirílico/olmo árabe/hanzi → módulos de comparación locales.

Fecha de nacimiento/dirección: formato, verificación cruzada con documento y dirección de pago (BIN/AVS).

Falsas coincidencias en sanciones/RER: configuración de fuzzy-score y reglas de escalamiento (jóvenes tezks, apellidos frecuentes).

Calidad de la foto: consejos UX (luz, marco, resplandor), control automático de nitidez/ángulo.

7) SLA, observabilidad y alertas

Objetivos Latency: onboarding interactivo ≤ 60-120 ms para solicitar catálogo/cribado + pasos asíncronos ≤ 2-3 min (documentos).

Aptime: ≥ 99. 9% en endpoints críticos; proveedor doble (active-active/active-standby).

Alertas: crecimiento de 'error _ rate', degradación de 'hit _ rate', salto de 'review _ rate', «ventanas silenciosas» de webhooks, retrasos OCR/Liveness.

Logs/treising: correlation-ID desde el frente hasta el proveedor; masked payloads; almacenamiento de decisiones y razones.

8) Gestión de casos

Cola de casos: prioridad por cantidad/riesgo/región.

Playbucks: qué pedir al cliente (selfies repetidos, otro documento, prueba de dirección).

SLA por casos manuales: p95 ≤ 24 h; high-value ≤ 2 ч.

Apelaciones: re-match + reviewer independiente; documentar las causas de la falla (nota de acción avanzada).

9) Cumplimiento y privacidad

GDPR/contrapartes locales: límite de purpose, minimización de datos, derecho de acceso/eliminación (cuando corresponda).

PCI DSS: si los datos de pago se ven afectados.

PSD2/SCA: correlación con una fuerte autenticación en los pasos de pago.

Retención: almacenar sólo los artefactos requeridos y sólo todo lo que la ley/regulador requiere.

Explainability: fijar «decision rationale» - en qué se basó el sistema (liveness fail, doc mismatch, PEP hit).

10) Costo y modelo de compra

Pricing: per-check, tarifas por lotes, coeficientes regionales, recargos de EDD/Adverse Media.

Optimización: orquestación basada en riesgos (proveedor barato → caro con folback), almacenamiento en caché de los resultados en TTL, re-screen en delta.

Lista RFP: recubrimientos por documentos/países, precisión liveness/face-match, frecuencia de actualización de sanciones/RR, latency, webhooks, SDK, informes, DPIA/certificaciones, opciones on-prem, prácticas legales/regulatorias, referencias de i Gaming.

11) KYB: cuando se trabaja con B2V/socios

Registros: Companies House, registros comerciales locales, cadenas de UBO.

Documentos: incorporación, estatuto, cartas bancarias, directores/poderes.

Cribado: sanciones/RER para UBO y directores, Adverse Media por marca/entidad.

Desencadenantes re-screen: cambio de director/dirección/beneficiario, aumento drástico de las revoluciones.

12) UX y conversión: cómo no «romper» el onboarding

Mobile-first: SDK con indicaciones automáticas (marco, inclinación, protección deslumbrante).

Hyde para el usuario: qué preparar de antemano (documento, iluminación), cuánto tiempo llevará el proceso.

Barra de progreso y estados claros.

Graceful fallback: si la cámara/sensores no están disponibles → un flujo alternativo (manual upload + verificación posterior).

13) Incidentes y folbacks

Fail-safe modo: cuando el proveedor cae - cambiar a la reserva + aplicar reglas mínimamente suficientes.

Política de degradación: solo permitimos depósitos de límite pequeño sin retiro hasta que se complete la verificación.

Verificación diferida: emisión de límites de tiempo marcados sobre la necesidad de confianza.

14) Pruebas y certificación de integración

Sandbox de proveedores: scripts de caminos «felices «/« infelices », casos de edge (deslumbramiento, documento recortado, gemelos).

Pruebas de contrato: confirmación del esquema de respuesta, migraciones de versiones de API.

Carga: pico de lanzamientos/promociones (tráfico x5-x10), largos webhooks, reordenador de eventos.

Ejercicios de DR: desconexión de un proveedor, caída de webhooks, versión rollback.

15) Normas modelo para la adopción de decisiones

Ejemplo de tabla de decisión (simplificado):

Condición	Acción	Comentario
Sanctions=hit (strong match)	DENY	Escalada en cumplimiento, informe
PEP=possible + Adverse=negative	REVIEW/EDD	Dop. fuentes de fondos
Liveness=fail или FaceMatch<0. 8	RETRY (1-2 veces) → REVISIÓN	Consejos UX
Address=fail + High-risk country	HOLD	Proof of address
Clean KYC/AML + Low risk score	APPROVE	Límites de política

16) Ejemplo de caso completo (abreviado)

Escenario: nuevo jugador de Alemania, depósito de 300 €, solicitud de bonificación.

1. Soft check (AML fast): clear.

2. IDV: pasaporte + selfie, liveness = pass, face_match=0. 93, doc=authentic.

3. Address: utility bill pasado.

4. Decisión: APPROVE, límite de salida de hasta 2.000 €, repetido AML-re-screen diario.

5. Auditoría: se han registrado versiones del motor, proveedor, reglas, fichas y rationale.

17) Lista de verificación de implementación

Orquestrador c failover y routing por jurisdicciones.
Tratados/SLA/Precios, DPIA y Armonización Legal.
Webhooks, idempotencia, retraídas, senderismo.
Gestión de casos y playbucks EDD.
Periodic re-screen (sanciones/RER) y event-based desencadenantes.
Control de calidad (hit-rate, FPR/FNR, tiempo de paso).
Política de retiro/eliminación y acceso (RBAC).
Plan de DR y ejercicios de degradación.

Resumen

Una fuerte integración KYC/AML no es «conectar un solo proveedor», sino construir una orquestación a partir de múltiples fuentes donde las decisiones se toman de forma basada en el riesgo, transparente y rápida. Combine IDV, Liveness, sanciones/RR y dirección, implemente gestión de casos y auditorías rigurosas, mantenga a los proveedores de folback y recuerde acerca de UX, por lo que cumplirá con los requisitos de los reguladores y mantendrá una alta conversión de onboarding.