Cumplimiento de las sanciones en materia de pagos

1) Por qué es necesario (marco de riesgo)

Riesgo legal: multas/revocación de licencia por infracción de regímenes sancionadores.
Riesgo financiero: congelación de fondos/cuentas en el corredor (corresponsal/PSP/esquema).
Riesgo operativo: devoluciones por fuerza mayor, transacciones pendientes, aumento de comprobaciones manuales.
Reputación: los incidentes «sancionadores» golpean a los bancos socios y el acceso a los corredores.

2) Regímenes y principios

Listas: OFAC (SDN/SSI), EU, UK (OFSI), CA, AU, ONU, local.
Embargo geográfico: prohibición total de los países y territorios.
Sectorial: límites por industria/plazo de financiación (SSI/Directive).
«Regla del 50%»: si uno o más SDN poseen colectivamente el ≥50% - el sujeto se considera bloqueado, aunque no esté nominado.
Exportación-control/doble uso: pago por un producto/servicio prohibido (importante en las remisiones A2A/SWIFT).
Crypto/Travel Rule: transferencia de atributos KYC entre VASP en transferencias transfronterizas.

3) Dónde y cómo capturar (circuito de pago)

3. 1. Depósitos

Pagador: nombre/dirección/fecha de nacimiento (si está disponible), tarjeta (BIN-geo), billetera, IP/ASN, device.
Proveedor: PSP/MID y su jurisdicción; comprobar la «limpieza» de la ruta.
Eventos: creación de perfil (L0), primer depósito (L1), anomalías (velocity/geo-conflicto).

3. 2. Conclusiones

Beneficiario: IBAN/BIC/nombre/dirección, tarjeta/cartera, dirección criptográfica (VASP).
Ruta: same-method/return-to-source, banco receptor, posibles corresponsales.
Regla de viaje (cripto): intercambio de datos originador/beneficiario, validación del estado VASP.

3. 3. Enrutamiento/corredores

A2A/SEPA/FPS/PIX/RTP: Banco receptor y su país/riesgo de riesgo.
Push-to-card: banco emisor de la tarjeta (BIN-país/banco).
SWIFT: bancos corresponsales (todos los eslabones de la cadena).
E-wallets: jurisdicción del emisor/operador de la cartera.

4) Tipos de detección y señales

Nombre/alias/transliteraciones (partido de fase, reducción de diacrítica).
Dirección/ciudad/código postal (geo-desencadenantes, ubicaciones «sancionadoras»).
Fecha de nacimiento/pasaporte/MRN (cuando están disponibles desde KYC).
Organizaciones/BENEFICIARIOS (UBO): due diligence extendido.
IBAN/BIC y banco receptor: país, «banco sancionador» o subprocurador de la UBO.
BIN/emisor de la tarjeta: país/banco, cross-check con listas de trineo.
IP/ASN/VPN/hosting: sank geo, proxy/ASN de sombra.
Device-graph/household: intersecciones con bloqueados previamente.
Direcciones cifradas: las etiquetas «clústeres de sanciones/mezcladores/riesgos» de los proveedores de blockchain.
Geo-conflicto: KYC-país ≠ IP ≠ SIM ≠ BIN-geo.

5) Orquestación de cribado: «dónde incrustar»

1. Onboarding: cribado fácil por nombre/RD, risk country.
2. Payment init: hit-check sincrónico del pagador/beneficiario, IBAN/BIN, IP/ASN.
3. Pre-enrutamiento: deny/hold/step-up (SoF/documentos) antes de ser enviado al pasillo.
4. In-flight: monitoreo de estados de PSP/bancos (returns/holds).
5. Post-event: retrospectiva al actualizar las listas (backfill).

6) Política de soluciones (risk-based)

AUTO-PASS: sin hits; bajo riesgo del país/banco; same-method; ND≥0.
REVISIÓN MANUAL: un éxito fuzzy por debajo del umbral alto; el nuevo beneficiario; geo-conflicto; alto país/sector risk.
DENY/BLOCK: hit SDN preciso, «regla del 50%», embargo GEO, banco de sanciones/corredor.
STEP-UP: solicitud SoF/SoW, confirmación de la dirección/nombre del beneficiario, «name check/IBAN» (donde está disponible).

7) Reducción de falsos positivos (precision)

Normalización de la FIO (permutación de nombres/apellidos, patronímicos, casos, partículas).
Atributos contextuales: la fecha de nacimiento/ciudad reduce la RPF.
Listas blancas: beneficiarios verificados/bancos/IBAN (con TTL y revalidación).
Lista negra ASN/VPN: Menos visitas ruidosas por IP.
Umbrales segmentarios: más estrictos para GEO de alto riesgo/corredores, más suaves para bajo riesgo.
Resolución automática después de APPROVE manual con la misma huella dactilar (device/IBAN).
Registros de explicabilidad: por qué se rechaza/permite (score, reglas, campos de coincidencia).

8) UX y comunicaciones

Razones transparentes: «Es necesaria la validación del destinatario debido al banco/país».
Plazos: ETA honesta para la verificación manual/SoF.
Devoluciones: Refand automático en la cartera de juego, enlace «seleccionar otro método/destinatario».
Localización: textos legales, referencias a la política de sanciones/apoyo.

9) Ingeniería: modelo de datos (mínimo)

sql sanctions.watchlists (
source TEXT,      -- OFAC, EU, UK, UN, etc.
entity_id TEXT,    -- уникальный ID записи entity_type TEXT,   -- person    org    vessel    bank name TEXT, aliases TEXT[], dob DATE, country TEXT,
programs TEXT[],    -- санкционные программы ownership_json JSONB, -- связи для "50% правила"
updated_at TIMESTAMP
);

sanctions.hits (
hit_id PK, user_id, payout_id, deposit_tx_id,
entity_id, source, match_score NUMERIC, match_fields JSONB,
status TEXT,      -- OPEN    APPROVED    DENIED    ESCALATED    FALSE_POSITIVE reviewer TEXT, decided_at TIMESTAMP, created_at TIMESTAMP
);

payments.endpoints (
beneficiary_id PK, user_id, type, -- IBAN    CARD    WALLET    CRYPTO iban TEXT, bic TEXT, bin TEXT, wallet_ref TEXT, crypto_addr TEXT,
bank_country TEXT, bank_name TEXT, verified BOOLEAN,
last_screened_at TIMESTAMP, risk_tags TEXT[]
);

risk.context (
user_id, ip INET, asn INT, device_hash TEXT,
geo_ip TEXT, geo_kyc TEXT, geo_sim TEXT, updated_at TIMESTAMP
);

10) Política pseudo-DSL

yaml policy: "sanctions_payments_v4"
lists:
sources: [OFAC, EU, UK, UN, CA]
refresh_interval_hours: 6 screening:
on_user_create: true on_deposit_init: true on_payout_init: true on_new_beneficiary: true rescreen_on_list_update: true thresholds:
name_fuzzy_pass: 0.72 name_fuzzy_manual: 0.62 org_fuzzy_pass: 0.80 crypto_risk_max: "MEDIUM"
routing_guards:
deny_if:
- geo in [EMBARGOED]
- bank_sanctioned == true
- ownership_sdn_agg >= 0.5  # "50% правило"
manual_review_triggers:
- fuzzy_hit == true
- new_beneficiary == true AND amount > 1000 EUR
- geo_conflict_score >= 2
- vasp_untrusted == true stepups:
- if: payout_amount > 2000 EUR then: ["name_check_iban"]
- if: crypto == true then: ["travel_rule", "beneficiary_vasp_check"]
audit:
store_feature_snapshot: true store_decision_tree: true exceptions:
whitelist_beneficiary_ttl_days: 180

11) Plantillas SQL

11. 1. Búsqueda de fazzi por nombre/alias

sql
SELECT w.entity_id, w.source, w.name,
similarity(unaccent(lower(:full_name)), unaccent(lower(w.name))) AS score
FROM sanctions.watchlists w
WHERE w.entity_type='person'
AND (unaccent(lower(:full_name)) % unaccent(lower(w.name))
OR EXISTS (SELECT 1 FROM unnest(w.aliases) a
WHERE unaccent(lower(:full_name)) % unaccent(lower(a))))
ORDER BY score DESC LIMIT 20;

11. 2. Comprobar «50% de la regla de propiedad»

sql
SELECT entity_id
FROM sanctions.watchlists
WHERE entity_type='org'
AND (ownership_json->>'sdn_agg_share')::numeric >= 0.5;

11. 3. Desencadenador de recuperación cuando se actualiza la lista

sql
INSERT INTO sanctions.hits (user_id, entity_id, source, match_score, status, created_at)
SELECT u.user_id, w.entity_id, w.source, 0.0, 'OPEN', now()
FROM users u
JOIN sanctions.watchlists w ON w.updated_at >:last_run
WHERE u.country IN (:risk_geos);

11. 4. IBAN/banco receptor: guardia de riesgo

sql
SELECT e.beneficiary_id,
(e.bank_country = ANY(:embargo_geos)) AS embargo_hit,
(e.bic IN (SELECT bic FROM ref.sanctioned_banks)) AS bank_hit
FROM payments.endpoints e
WHERE e.beneficiary_id=:bid;

11. 5. Crypto Travel Rule (control simplificado)

sql
SELECT v.vasp_id, v.trust_level, tx.crypto_addr
FROM crypto.transfers tx
JOIN ref.vasps v ON v.domain = tx.beneficiary_vasp
WHERE tx.payout_id =:pid;

12) KPI y dashboards

Tasa de éxito: proporción de transacciones/beneficiarios con hits sancionadores.
False Positive % и Manual Approve %.
Manual TAT p50/p95 (tiempo de solución).
Denied% por modos/geo/corredores/bancos.
Recreen backlog después de actualizar las listas.
Returns/holds% en códigos de trineo de PSP/bancos.
Travel Rule coverage% (cripto).
Whitelisted TTL breach% (filtrado «de confianza» sin revalidación).

13) Alertas

List Update Spike: un fuerte crecimiento en los hits después de actualizar las listas.
FPR Surge: False Positive%> umbral d/d.
Manual Backlog: casos abiertos> límites o p95 TAT> SLA.
Embargo Route Hit: intentos de realizar pagos en geo/bancos prohibidos.
Travel Rule Missing: transferencias criptográficas sin intercambio de datos VASP.
Policy Drift: transacciones sin reglas/soluciones.

14) Playbucks de incidentes

A. Éxitos masivos tras la actualización de la OFAC/EU

1. Congelar el enrutamiento automático en los corredores de riesgo → MANUAL.
2. Prioridad por suma/ATA, formación rápida a los operadores de nuevas alias/ortografías.
3. Comunicación PSP/bancos: alertar sobre el crecimiento temporal de los manuales.

B. Reembolsos del banco correspondiente

1. Normalizar el código de causa, recoger muestras (BIC, pasillo).
2. Excluir temporalmente el banco/corredor de la cascada, reroute.
3. Post mortem: actualizar el directorio de «bancos de sank», reforzar el precheck.

C. Crypto sin Travel Rule

1. Bloquear los pines en VASP no verificados, solicitar datos.
2. Habilite «sólo VASP confiable» antes de corregir la integración.
3. Retest e informe al regulador si es necesario.

15) Mejores prácticas (corto)

1. Policy-as-code con versiones y snapshots de características/soluciones.
2. Cribado en varios puntos (perfil, init, pre-route, post).
3. Tenga en cuenta la regla del 50% y las comunicaciones UBO, no solo las entradas nominales.
4. Name normalización y contexto (RD/ciudad) para reducir la RPF.
5. Listas blancas de beneficiarios verificados/bancos con TTL y revalidación.
6. Segmentar los umbrales por GEO/método/corredor.
7. Logs de explicabilidad y auditoría-trail: «quién/cuándo/por qué».
8. Negocie con PSP/bancos los códigos de devolución y SLA manuales.
9. Regla de viaje y registro de VASP de confianza para cripto.
10. Incidentes posteriores regulares y afinación de reglas.

16) Lista de verificación de implementación

• Fuentes de listas y frecuencia de actualización (OFAC/EU/UK/UN/local).
• Política «50%» y gráfico UBO.
• Detección en onboarding/deposition/payout/new beneficiary/rescreen.
• Integraciones: PSP/bancos/vaspas, códigos de devolución.
• Matriz de umbral (pase/manual/deny), segmentos GEO/métodos.
• Listas blancas/negras (beneficiario/banco/ASN/IP) con TTL.
• Registros de explicabilidad, trampolines de señales/soluciones, informes para licencias.
• Dashboards KPI y alertas; SLA manual.
• Playbooks (actualización de listas, devoluciones, Travel Rule).
• Formación de operadores (alias/transliteraciones, rarezas de país).

Resumen

El cumplimiento sancionador de los pagos es una orquestación de reglas, datos e itinerarios, y no solo «perforar la lista». Incorpore la detección en los puntos clave de la ruta de pago, tenga en cuenta la UBO y la regla del 50%, administre corredores/bancos, reduzca los falsos positivos a través de la normalización y el contexto, almacene soluciones explicables y versiones de políticas como código. Así que usted mantendrá el acceso a los corredores, reducir los costos de transacción y soportar los requisitos de licencia sin matar la conversión.