Integración de Travel Rule de proveedores

1) Objetivo de integración

• mantener el modelo canónico de IVMS101,
• tener una capa adaptadora agnóstica al proveedor,
• proporcionar seguridad (mTLS, firma, cifrado) y SLA,
• cubrir hosted↔hosted y políticas para unhosted.

2) Selección de protocolo/proveedor: modelos

2. 1 Protocolos y redes de confianza

TRISA/TRP/OpenVASP - p2r/federaciones con PKI, directorios VASP, confirmación de envío.
Hubs/agregadores comerciales: abstraen el transporte, dan Discovery y enrutamiento.

2. 2 Criterios de selección (resumen)

Cobertura de jurisdicciones/VASR, calidad Directory/Discovery.
Compatibilidad con IVMS101 y extensiones.
Seguridad (PKI, mTLS, firma), latency/SLA, retrai/quórum.
Costo por mensaje/volumen, informes y auditoría.
Soporte de la política unhosted (validación de la propiedad de la dirección), sandbox y certificación.

3) Arquitectura de referencia de integración

1. Payments Core → inicia el cambio criptográfico.

2. Compliance Orchestrator → decide si se requiere una regla de viaje (umbral/geo/tipo de contraparte).

3. Travel Rule Gateway (su servicio)

Modelo IVMS101 canónico;

Adaptadores a TRISA/TRP/OpenVASP/agregador;

Firma/cifrado, idempotencia, retraídas/cuotas.
4. Directory/Discovery → búsqueda de contraparte, validación de certificados/políticas.
5. KYT/Sanctions Engine → pre-check antes del intercambio.
6. PII Vault → almacenamiento de campos personales, tokenización, RBAC/auditoría.

1. Creación de la solicitud → 2) CUT/sanciones pre-check → 3) Discovery VASP → 4) Intercambio de IVMS101 (request/response) → 5) Decisión allow/hold/reject → 6) Broadcast Onchain → 7) Registros/informe.

4) Modelo de datos canónicos (IVMS101)

• Originator: name, identifier, country/address or DOB, account/wallet id.
• Beneficiary: name (при VASP), account/wallet id.
• Transaction: asset, chain, amount, timestamp, internal transfer id.
• Compliance refs: KYT check id, sanctions screen id, Travel Rule message id.

Práctica: almacena IVMS101 como «modelo canónico» en tu DB; los adaptadores hacen transformaciones en un protocolo específico.

5) Security & Trust

mTLS con autenticación mutua (PKI/Directory).
Firma de mensajes y end-to-end cifrado de contenido (PII).
RBAC/SoD: separación de funciones para enviar/aprobar/exportar datos.
Registros/registros inmutables: quién/qué/cuándo envió, versión del diagrama.

6) Discovery/Directory

Busca la contraparte por medio de un identificador VASP, dominio, LEI/BIC (donde está disponible).
Almacenamiento en caché de registros, rotación de certificados, lista de CA de confianza.
Canal de folback: solicitud de confirmación de datos a través de un agregador o «puente» (si la política lo permite).

7) Control de flujo y SLA

• Discovery + exchange p95: ≤ 60–120 с.
• Pre-KYT p95: ≤ 5–15 с.
• Solución auto-case: ≤ 2-5 min, manual de alto riesgo: ≤ 4 h.

• Backoff + jitter exponencial; idempotencia por 'travel _ rule _ message _ id'.
• Se transfiere automáticamente a un adaptador/hub redundante en caso de degradación.
• Quórum de confirmaciones de entrega/lectura (ACK/NACK).

8) Manejo de errores (playbook)

9) Política para monederos sin alojamiento

Confirmación de la propiedad de la dirección (firma, «pruf-micro-recambio»).
KYT antes de la inscripción y antes de la retirada; límites por segmento.
Address book/whitelist con TTL y reverificación periódica.
Documente las excepciones de RBA (pequeñas cantidades/bajo riesgo) cuando sea legal.

10) PII Vault y privacidad

Separe la PII de los registros operativos y los datos de pago.
Cifrado (KMS/HSM), tokenización de ID, acceso need-to-know.
Retention por jurisdicción (a menudo 5 + años), auto-expiración, procedimientos DSR.
Versionar esquemas de IVMS101 y audit trail para cada intercambio.

11) Patrones de integración

11. 1 capa adaptadora

Interfaz: 'nat (ivms_payload) -> ack '/' receive () -> ivms_payload'.
Transformaciones: IVMS101 ⇄ formato específico (TRISA/TRP/OpenVASP/hub).
Versificación de API, webhooks firmados, reenvíos deterministas.

11. 2 Soluciones Compliance

Матрица RBA: `allow` / `limit` / `hold` / `reject` / `escalate`.
Release parcial si parte de los fondos son «limpios».
Ligamento con KYT: no envíe una Regla de Viaje a través de rutas aparentemente prohibidas.

11. 3 Confiabilidad

Dos o más proveedores/protocolos a través de un solo Gateway.
Health-checks, circuit-breaker, alertas de tiempo real.

12) Pruebas y puesta en marcha

Sandbox proveedor + su simulador de contraparte.
Conjunto de casos: datos completos/incompletos, tiempos de espera, mismatch, desconfianza PKI.
Pruebas de carga (torneos/promociones pico), medición p50/p95/pérdidas.
Payments/Risk/Support Training: scripts de comunicación con clientes.

13) Métricas y dashboards

Coverage%: proporción de transferencias VASP↔VASP con un intercambio exitoso.
SLA hit rate по Discovery/Exchange/Decision.
Retry/Failure rate, причины (timeout/mismatch/unsupported/trust).
Hold/Reject% y tiempo medio de desbloqueo.
Complaint/Ticket rate por Travel Rule, NPS de salida.
Costo por intercambio (todo en): proveedor + óperas. tiempo.

14) Anti-patrones

Envío de Onchain antes de completar la Regla de Viaje donde se necesita «pre-transferencia».
Atadura rígida por proveedor sin abstracción Adaptadora.
Almacenamiento de PII en logs/análisis compartidos sin tokenización.
Falta de idempotencia → toma de mensajes/soluciones.
Ignore la política desactivada y la verificación de direcciones.
No hay versionamiento de esquemas/directorios → soluciones «no repetibles».

15) Lista de comprobación RFP/implementación (corta)

• Soporte IVMS101 (campos obligatorios/opcionales), validaciones.
• Protocolo (s): TRISA/TRP/OpenVASP, agregadores; Discovery/Directory и PKI.
• Seguridad: mTLS, firma/cifrado, registro de actividades, señalización de webhooks.
• SLA/retraye: objetivos p95, backoff + jitter, circuit-breaker, feolover.
• Compatibilidad con CUT/Sanciones, API pre-check y corulación de casos.
• Unhosted-policy: confirmación de dirección, whitelist con TTL, límites.
• PII Vault: cifrado, RBAC/SoD, retention/DSR, auditoría.
• Reporting: artefactos de intercambio, versiones de diagramas/etiquetas, exportación para SAR/NAT.
• Sandbox/simuladores, pruebas de carga y de tolerancia a fallas.
• Formación de equipos y plantillas de comunicación con los clientes.

16) Resumen

La integración de Travel Rule es una arquitectura gateway con IVMS101 como modelo canónico, Discovery/PKI para confianza, adaptadores para múltiples proveedores y estrictas reglas de seguridad/PII. Vincularlo a las soluciones KYT y RBA, impregnar la política para unhosted, proporcionar SLA/failover y UX transparente - y sus pagos/depósitos crypto cumplirán con los requisitos sin comprometer la velocidad y la conversión.