Compilazione delle sanzioni relative ai pagamenti

1) Perché è necessario (cornice di rischio)

Rischio legale: multe/revoca della licenza per violazione dei regimi sanzionatori.
Rischio finanziario: congelamento dei fondi/conti sul corridoio (corrispondente/PSP/schema).
Rischio operativo: rimborsi di forza maggiore, transazioni dipendenti, controlli manuali in aumento.
Reputazione: gli incidenti «sanzionatori» colpiscono le banche partner e l'accesso ai corridoi.

2) Modalità e principi

Elenchi: OFAC (SDN/SSI), EU, UK (OFSI), CA, AU, ONU, locali.
Il Geo-Embargo è un divieto totale per paese/territorio.
Restrizioni settoriali per settore/tempo di finanziamento (SSI/Direct).
Regola 50%: se uno o più SDN possiedono un totale del ≥50%, l'S.I. è considerato bloccato, anche se non denominato.
Esportazione/doppia destinazione: pagamento di un prodotto/servizio proibito (importante in A2A/SWIFT remit).
Kripto/Travel Rule - Trasferimento di attributi KYC tra VASP nelle traduzioni transfrontaliere.

3) Dove e come eseguire lo screen (circuito di pagamento)

3. 1. Depositi

Pagante: nome/indirizzo/data di nascita (se disponibile), carta (BIN-geo), portafoglio, IP/ASN, device.
Provider: PSP/MID e la loro giurisdizione; Verifica della purezza del percorso.
Eventi: creazione di un profilo (L0), primo deposito (L1), anomalie (velocity/geo-conflitto).

3. 2. Conclusioni

Beneficiario: BAN/BIC/nome/indirizzo, carta/portafoglio, cripto-indirizzo (VASP).
Percorso: same-method/return-to-source, banca destinataria, possibili corrispondenti.
Travel Rule (cripto) - Condivisione di originator/beneficenza, verifica dello stato VASP.

3. 3. Instradamento/corridoi

A2A/SEPA/FPS/PIX/RTP: la banca destinataria e il suo paese/rischio sank.
Push-to-card: banca emittente (BIN-paese/banca).
SWIFT: banche corrispondenti (tutti gli elementi della catena).
E-wallets - giurisdizione dell'emittente/operatore del portafoglio.

4) Tipi di screening e segnali

Nome/alias/traslazione (phaszi match, reading diacritica).
Indirizzo/città/codice postale (geo-trigger, localizzazioni «sanzioni»).
Data di nascita/passaporto/MRN (quando disponibile da KYC).
Organizzazioni/BENEFICIARI (UBO): due diligence estesa.
BAN/BIC e banca destinataria: paese, «banca delle sanzioni» o UBO.
BIN/emittente mappatura paese/banca, cross-check con sunk-list.
IP/ASN/VPN/hosting: sunk-geo, proxy/shadow ASN.
Device-graph/household - Intersezioni con precedenti bloccati.
Gli indirizzi crittografati sono etichette «sanzioni/mixer/cluster a rischio» nei provider blockchain.
Conflitto GEO-Paese KYC-IP-SIM-BIN-geo.

5) Pianificazione dello screening: «Dove incorporare»

1. Onboarding è uno screening leggero chiamato/DR, country risk.
2. Payment init: hit-check sincronizzato pagatore/beneficiario, IAN/BIN, IP/ASN.
3. Pre-routing: deny/hold/step-up (SoF/documenti) prima di essere spedito nel corridoio.
4. In-flight - Monitoraggio dello stato da PSP/banche (returns/holds).
5. Post-event - Recrining retrospettivo durante l'aggiornamento degli elenchi (backfill).

6) Regole di soluzione (risk-based)

AUTO-PASS: nessun successo basso rischio paese/banca; same-method; ND≥0.
MANUAL REVIEW: un successo fuzzy sotto la soglia alta; nuovo beneficiario; conflitto geo; country/sector risk alto.
DENY/BLOCK: esatta SDN, regola del 50%, embargo GEO, banca delle sanzioni/corridoio.
STEP-UP: richiesta di SoF/SoW, conferma dell'indirizzo/nome del beneficiario, «name check/BAN» (dove disponibile).

7) Riduzione dei falsi funzionamenti (precision)

Normalizzazione della FIO (riorganizzazione di nomi/cognomi, nome di conto, cadute, particelle).
Attributi contestuali: data di nascita/città riducono FPR.
White-lists: beneficiari/banche/BAN verificati (con TTL e rivalutazione).
Black list ASN/VPN - Meno hit su IP rumoroso.
Le soglie segmentate sono più severe per gli high-risk GEO/corridoi, più morbide per i low-risk.
Risoluzione auto dopo APPROVE manuale con lo stesso fingerprint (device/BAN).
I registri di spiegazione: perché rifiutato/consentito (scansione, regole, campi corrispondenti).

8) UX e comunicazioni

Motivi trasparenti: «È necessario convalidare il destinatario a causa della banca/paese».
Data: onesti ETA per controllo manuale/SoF.
Restituzioni: Reading automatico nel portafoglio di gioco, collegamento «scegli un altro metodo/destinatario».
Localizzazione: testi legali, collegamenti a regole di sanzioni/supporto.

9) Ingegneria: modello di dati (minimo)

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) Criteri 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) Modelli SQL

11. 1. Ricerca fazzi per nome/aliase

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. Verifica del 50% delle regole di proprietà

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

11. 3. Trigger rescrining durante l'aggiornamento dell'elenco

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. BAN/banca destinataria rischio-guardia

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 (controllo semplificato)

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 e dashboard

Hit Rate: percentuale di transazioni/beneficiari con successi sanzionatori.
False Positive % и Manual Approve %.
Manual TAT p50/p95.
Denied% per modalità/geo/corridoi/banche.
Rescreen backlog dopo l'aggiornamento degli elenchi.
Returns/holds% in codice sunk da PSP/banche.
Travel Rule coverage% (cripto).
Whitelisted TTL breach% («affidabili» senza rivalutazione).

13) Alerti

List Update Spike - Un forte aumento dei successi dopo l'aggiornamento degli elenchi.
FPR Surface: False Positive%> soglia d/d.
Manual Backlog: valigette aperte> limiti o p95 TAT> SLA.
Embargo Route Hit - Tentativi di pagamento di geo/banche proibite.
Travel Rule Missing - Traduzioni cripto senza scambio di dati VASP.
Policy Drivt: transazioni senza regole o soluzioni.

14) Playbook incidenti

A. Successi di massa dopo l'aggiornamento OFAC/EU

1. Congelare il routing auto sui corridoi a rischio MANUAL.
2. Priorità per importo/ETA, formazione rapida agli operatori di nuovi aliasmi/ortografie.
3. Comunicazione PSP/banche - Avvertire la crescita temporanea del manuale.

B. Rimborsi da parte della banca corrispondente

1. Regolare il codice causa, raccogliere campioni (BIC, corridoio).
2. Escludere temporaneamente la banca/corridoio dalla cascata, reroute.
3. Post mortem: aggiornare il manuale delle sunk bank, rafforzare la precheck.

C. Cripto senza Travel Rule

1. Blocca le conclusioni su VASP non verificati, richiedi i dati.
2. Abilita «only trusted VASP» prima di correggere l'integrazione.
3. Retest e rapporto al regolatore, se necessario.

15) Best practices (breve)

1. Policy-as-code con versioni e schemi di segni/soluzioni.
2. Screening in più punti (profilo, init, pre-route, post).
3. Prendere in considerazione la regola del 50% e le connessioni UBO, non solo le voci nominali.
4. Name normalization e contesto (DR/città) per ridurre la FPR.
5. Elenchi bianchi dei beneficiari/banche verificati con TTL e rivalutazione.
6. Segmentare le soglie GEO/metodo/corridoio.
7. «Chi/quando/perché».
8. Concordare con PSP/banche sui codici di rimborso e SLA manuali.
9. Travel Rule e il registro VASP affidabili per la cripto.
10. Regolari post-incidenti e sintonizzazioni.

16) Assegno-foglio di implementazione

• Fonti di elenco e frequenza di aggiornamento (OFAC/EU/UK/UN/locale).
• Politica «50%» e UBO-Conte.
• Screening su onboarding/deposit/payout/new beneficiary/rescreen.
• Integrazione: PSP/banche/vasp, codici di rimborso.
• Matrice soglia (pass/manual/deny), segmenti GEO/metodi.
• White/black list (beneficiary/bank/ASN/IP) con TTL.
• Login di spiegabilità, schemi di segni/soluzioni, report per licenze.
• Dashboard KPI e alert; SLA manuali.
• Playbook (aggiornamento degli elenchi, restituzioni, Travel Rule).
• Formazione degli operatori (alias/trasmissibilità, country-rarità).

Curriculum

La compilazione delle sanzioni per i pagamenti è un'orchestrazione di regole, dati e itinerari, non solo «perlustrare la lista». Incorporare lo screening nei punti chiave del percorso di pagamento, tenere conto della regola UBO e del 50%, gestire corridoi/banche, ridurre i falsi funzionamenti attraverso la normalizzazione e il contesto, conservare le soluzioni e le versioni di regole spiegabili come codice. In questo modo si salva l'accesso ai corridoi, si riducono i costi operativi e si superano i requisiti delle licenze senza uccidere la conversione.