Conformité aux sanctions sur les paiements

1) Pourquoi est-ce nécessaire (cadre de risque)

Risque juridique : amendes/révocation de licence pour violation des régimes de sanctions.
Risque financier : gel des fonds/comptes sur le corridor (correspondant/PSP/schéma).
Risque opérationnel : retours de force majeure, transactions dépendantes, augmentation des contrôles manuels.
Réputation : les incidents de « sanctions » frappent les banques partenaires et l'accès aux couloirs.

2) Modes et principes

Listes : OFAC (SDN/SSI), UE, UK (OFSI), CA, AU, ONU, local.
Embargo géographique : interdictions complètes par pays/territoire.
Sectoriels : contraintes sectorielles/échéances de financement (SSI/Directive).
« Règle de 50 % » : si un ou plusieurs SDN possèdent globalement ≥50 %, le sujet est considéré comme bloqué, même s'il n'est pas nommé.
Exportation-contrôle/double usage : paiement pour un bien/service interdit (important dans les remites de A2A/SWIFT).
Crypto/Travel Rule : transfert d'attributs KYC entre VASP et transferts transfrontaliers.

3) Où et comment filtrer (circuit de paiement)

3. 1. Dépôts

Payeur : nom/adresse/date de naissance (si disponible), carte (BIN-geo), portefeuille, IP/ASN, device.
Fournisseur : PSP/MID et leur juridiction ; vérification de la « pureté » de l'itinéraire.
Événements : création d'un profil (L0), premier dépôt (L1), anomalies (velocity/géo-conflit).

3. 2. Conclusions

Bénéficiaire : IBAN/BIC/nom/adresse, carte/portefeuille, adresse crypto (VASP).
Itinéraire : same-method/return-to-source, banque bénéficiaire, correspondants éventuels.
Travel Rule (crypto) : échange de données originator/beneficiary, vérification du statut VASP.

3. 3. Routage/couloirs

A2A/SEPA/FPS/PIX/RTP : la banque bénéficiaire et son pays/sank risque.
Push-to-card : banque émettrice de la carte (pays BIN/banque).
SWIFT : banques correspondants (tous les maillons de la chaîne).
E-wallets : compétence de l'émetteur/opérateur de portefeuille.

4) Types de criblage et signaux

Nom/alias/translittérations (fazzi-match, réduction de la diacritique).
Adresse/ville/code postal (géo-déclencheurs, emplacements « sanctions »).
Date de naissance/passeport/MRN (quand disponible depuis KYC).
Organisations/BÉNÉFICIAIRES (UBO) : diligence raisonnable prolongée.
IBAN/BIC et banque bénéficiaire : pays, « banque de sanctions » ou UBO sous-groupe.
BIN/émetteur de la carte : pays/banque, cross-check avec les listes sank.
IP/ASN/VPN/hébergement : sank-geo, proxy/shadow ASN.
Device-graph/household : intersections avec des personnes précédemment bloquées.
Adresses cryptées : étiquettes « sanctions/mixeurs/clusters de risque » chez les fournisseurs de blockchain.
Géo-conflit : KYC-pays ≠ IP ≠ SIM ≠ BIN-geo.

5) Orchestration de criblage : « où intégrer »

1. Onboarding : dépistage facile par nom/DR, country risk.
2. Paiement init : hit-check synchrone du payeur/bénéficiaire, IBAN/BIN, IP/ASN.
3. Pré-routing : deny/hold/step-up (SoF/documents) avant d'être envoyé dans le couloir.
4. In-flight : suivi des statuts des PSP/banques (returns/holds).
5. Post-event : rétrospective lors de la mise à jour des listes (backfill).

6) Politique de décision (risk-based)

AUTO-PASS : pas de succès ; faible risque pour le pays/la banque ; same-method; ND≥0.
MANUAL REVIEW : fuzzy-hit en dessous du seuil haut ; un nouveau bénéficiaire ; géo-conflit ; risque élevé de pays/secteur.
DENY/BLOCK : succès exact du SDN, « règle des 50 % », embargo GEO, banque de sanctions/corridor.
STEP-UP : demande SoF/SoW, confirmation d'adresse/nom du bénéficiaire, « nom check/IBAN » (si disponible).

7) Réduction des faux positifs (precision)

Normalisation du nom de famille (changement de nom/prénom, prénom, chute, particules).
Attributs contextuels : date de naissance/ville réduit le RPF.
Listes blanches : bénéficiaires/banques/IBAN vérifiés (avec TTL et revalidation).
Liste noire ASN/VPN : moins de succès bruyants sur IP.
Seuils segmentaires : plus stricts pour le haut risque GEO/couloirs, plus doux pour le bas risque.
Auto-résolution après APPROVE manuel avec le même fingerprint (device/IBAN).
Logs d'explication : pourquoi rejeté/autorisé (score, règles, champs-coïncidences).

8) UX et communications

Raisons transparentes : « Il est nécessaire de valider le bénéficiaire à cause de la banque/pays ».
Délais : ETA honnête pour la vérification manuelle/SoF.
Retours : refand automatique dans le portefeuille de jeu, lien « choisir une autre méthode/destinataire ».
Localisation : textes juridiques, références à la politique de sanctions/soutien.

9) Ingénierie : modèle de données (minimum)

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) Pseudo-DSL de la politique

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) modèles SQL

11. 1. Recherche par nom/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. Vérification « 50 % de la règle » par propriété

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

11. 3. Déclencheur de recadrage lors de la mise à jour de la liste

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/banque bénéficiaire : garde de risques

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 (contrôle simplifié)

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 et dashboards

Hit Rate : proportion de transactions/bénéficiaires avec des succès de sanctions.
False Positive % и Manual Approve %.
Manuel TAT p50/p95 (temps de décision).
Denied % sur les modes/géo/corridors/banques.
Rescreen backlog après la mise à jour des listes.
Returns/holds % par code sank de PSP/banques.
Travel Rule coverage % (crypto).
Whitelisted TTL breach % (trempé « de confiance » sans revalidation).

13) Alert

List Update Spike : forte augmentation des succès après la mise à jour des listes.
FPR Surge : Faux Positif%> seuil d/d.
Manuel Backlog : cas ouverts> limite ou p95 TAT> SLA.
Embargo Route Hit : essayer de faire des paiements sur les géo/banques interdites.
Voyage Rule Missing : crypto-traductions sans échange de données VASP.
Policy Drift : transactions sans règles/solutions.

14) Pleybooks d'incidents

A. Succès massifs après la mise à jour de l'OFAC/UE

1. Geler le routage automatique sur les couloirs à risque → MANUAL.
2. Priorité sur le montant/ETA, formation rapide aux opérateurs de nouveaux alias/orthographes.
3. Communication PSP/banques : alerter sur la croissance temporaire des mains.

B. Déclarations de la banque correspondante

1. Normaliser le code de cause, prélever des échantillons (BIC, couloir).
2. Exclure temporairement la banque/le couloir de la cascade, reroute.
3. Post-mortem : mettre à jour l'annuaire des « sank banks », renforcer le precheck.

C. Crypto sans Travel Rule

1. Bloquer les conclusions sur les VASP non testés, demander des données.
2. Activer « only trusted VASP » jusqu'à ce que l'intégration soit corrigée.
3. Retest et rapport au régulateur si nécessaire.

15) Meilleures pratiques (en bref)

1. Policy-as-code avec des versions et des snapshots de caractéristiques/solutions.
2. Dépistage en plusieurs points (profil, init, pré-route, post).
3. Tenez compte de la règle de 50 % et des communications UBO, pas seulement des enregistrements nominatifs.
4. Normalisation du nom et contexte (RD/ville) pour réduire le RPF.
5. Listes blanches des bénéficiaires/banques vérifiés avec TTL et revalidation.
6. Segmentez les seuils selon GEO/méthode/corridor.
7. Logs d'explication et audit-trail : « qui/quand/pourquoi ».
8. Négociez avec PSP/banques les codes de retour et les SLA manuels.
9. Travel Rule et le registre VASP de confiance pour les crypto.
10. Après-incidents réguliers et réglage des règles.

16) Chèque de mise en œuvre

• Sources des listes et taux de rafraîchissement (OFAC/UE/UK/UN/local).
• La politique « 50 % » et le graphe UBO.
• Dépistage sur onboarding/deposit/payout/new beneficiary/rescreen.
• Intégrations : PSP/banques/vases, codes de retour.
• Matrice de seuil (pass/manuel/deny), segments GEO/méthodes.
• Listes blanches/noires (beneficiary/bank/ASN/IP) avec TTL.
• Logs d'explication, snapshots de caractéristiques/solutions, rapports pour les licences.
• Dashboards KPI et alertes ; SLA manuel.
• Pleybooks (mise à jour des listes, retours, rule de voyage).
• Formation des opérateurs (alias/translittérations, pays rares).

Résumé

La conformité des sanctions sur les paiements est l'orchestration des règles, des données et des itinéraires, et non pas simplement « percer sur la liste ». Intégrez le dépistage aux points clés du chemin de paiement, tenez compte de l'UBO et de la règle des 50 %, gérez les corridors/banques, réduisez les faux positifs grâce à la normalisation et au contexte, conservez les solutions explicables et les versions des politiques comme code. Ainsi, vous gardez l'accès aux couloirs, réduisez les coûts de transaction et résistez aux exigences de licence sans tuer la conversion.