Rapports sur AML et KYC

1) Objet et portée

Objectif : fournir des rapports reproductibles, vérifiables et en temps opportun sur la LAM/CJC à toutes les juridictions et partenaires (banques, PSP, fournisseurs de CJC/CJC), réduire le risque de sanctions/blocages et renforcer les fonctions de contrôle.
Couverture : onbording des joueurs et partenaires (KYC/KYB), sanctions/REER, suivi des transactions, EDD, SAR/STR, sources de fonds (SoF/SoW), signaux RG, stockage et accès à l'IPI, incidents et notifications.

2) Classification des rapports et de la fréquence

1. Réglementation : sommaires sur l'onbording, alertes sur les sanctions/REER, SAR/STR, plaintes sur les mesures prises.

Fréquences : mensuelles/trimestrielles ; les rapports d'incident - dans les délais prescrits (p. ex., ≤72 h).

2. Banques/PSP : volumes de transactions, chargbecks, modèles suspects, cas EDD.

Fréquences : hebdomadaires/mensuelles, sur demande - ad hoc.

3. Interne : KRIs/KPIs, entonnoirs KYC, FPR/FNR, fournisseurs SLA, statuts de cas AML.

Fréquences : dashboards diurnes, comités hebdomadaires, rétrospectives mensuelles.

4. Vendeurs/externalisés : qualité et SLA KUS/Sanctions fournisseurs, tolérance aux pannes, faux positifs.

Fréquences : mensuels, examens trimestriels.

3) Structure de données unique (minimum de champs)

Cubject (le joueur/partenaire) : subject_id, le type (player/partner), le pays, le statut d'âge (18 +), risk_score, kyc_level, pep_flag, sanctions_flag, soe/sow_status.
Документы KYC: doc_type, doc_number_hash, issuer_country, expiry_date, liveness_passed, verification_provider, verification_result, confidence_score.
Транзакции: tx_id, ts, amount, currency, method, psp, device_id, ip_geo, velocity_flags, rule_hits[].
Алерты AML: alert_id, rule_id, severity, reason_codes[], owner, status, opened_at, closed_at, action_taken (EDD/SAR/STR/block/none).
Санкции/PEP: list_version, hit_type (sanctions/pep/adverse media), match_score, disposition (true/false positive), reviewer_id.
Journal d'accès PII : actor, action (view/export/delete), dataset, ts, purpose, ticket_id.

4) KRIs/KPIs pour les rapports

• KYC pass rate, KYC fail %, Liveness dropout %, Avg TAT (min/heure), modèles FPR/FNR.

• Hit-rate sur 1k onbordings, FPR %, Dispo TAT, proportion de contrôles secondaires.

• Alerts per 10k tx, % d'escalade dans EDD, SAR/STR per 10k active, Conversion alert→action.

• Aptyme fournisseur, API latency moyenne, % de retraits, proportion d'indisponibilité> X min.

• % d'omissions de champs obligatoires, de prises, de divergences de otchet↔bukhuchet, de taux de réussite de l'ETL journalier.

5) Contrôle de qualité et rapprochement

Règles DQ : not null/format/gammes/références ; SLA de correction.

• Registres d'onbording vs KYC-fournisseur,
• Transactions DWH vs rapports PSP/banque,
• Registre SAR/STR vs messages envoyés,
• Liste des sanctions version N vs N-1 (delta).
• Probabilité : montants de hachage des téléchargements, journaux de recalculage, logs immuables (WORM/stockage objet).

6) Formulaires de rapport standard (modèles)

6. 1 Résumé réglementaire AML/KYC (mensuel)

Violations/incidents : 0 critique, 1 moyenne (latence du fournisseur KYC 18 min).
Mesures prises : fallback activé, règles de velocity mises à jour.

6. 2 Rapport à la banque/PSP (mensuel)

Volume des dépôts/retraits sur les canaux de paiement, taux de charge, modèles suspects, liste des comptes/appareils bloqués (hashi), mesures EDD/hold.

6. 3 Rapport interne sur les sanctions/REER (hebdomadaire)

7) Workflows (SOP) et RACI

7. 1 SOP : Rapport réglementaire mensuel

1. Début de l'ETL T + 1 02:00 → 2) Validation DQ → 3) Rapprochement avec PSP/DWH → 4) Préparation PDF/CSV/JSON → 5) Revue juridique → 6) Signature/Soumission de → 7) Archive/hachage/journal.
RACI: Responsible — Compliance Analyst; Accountable — Head of Compliance; Consulted — Legal, DPO, Payments, Security; Informed — C-level.

7. 2 SOP: SAR/STR

Déclencheurs (rule/machine-learning/manuel), contrôle EDD, solution (file/not), fichier, accusé de réception, mise à jour du registre, suivi (hold/bloc/message à la banque/au régulateur).

7. 3 SOP : Incident du CUS/Sanctions

FPR> seuil ou dégradation SLA → incident-bridge → inclusion d'un deuxième fournisseur → étalonnage des règles → rapport d'incident (TTR/cause/mesures).

8) Automatisation : contour architectural

Collecte : CDC/stream avec prod-DB, webhooks KUS/sanctions, PSP-SFTP, collecteurs de journaux.
Хранилище: Data Lake (RAW → CURATED), DWH (reporting marts: aml_alerts, kyc_events, sanctions_hits, psp_recon).
Traitement : orchestrateur (Airflow/Argo) avec SLA/Retrays, policy-as-code pour les agrégats.
SOAR : playbooks pour SAR/EDD, auto-escalade aux seuils, tickets et notifications.
Catalogue de données/lineage : génération automatique de schémas et de dépendances, versions de rapports.

9) Agrégations et exemples de réalisation

9. 1 exemple SQL (pseudo)

sql
-- Sanctions/PEP weekly hit-rate with FPR
SELECT date_trunc('week', screening_ts) AS week,
COUNT() FILTER (WHERE hit = true) 100.0 / COUNT() AS hit_rate_pct,
COUNT() FILTER (WHERE hit = true AND disposition = 'false_positive') 100.0
/ NULLIF(COUNT() FILTER (WHERE hit = true),0) AS fpr_pct
FROM sanctions_screenings
WHERE screening_ts >= current_date - interval '90 day'
GROUP BY 1
ORDER BY 1 DESC;

9. 2 Schéma JSON de déchargement SAR/STR (simplifié)

json
{
"report_id": "SAR-2025-000128",
"filed_at": "2025-11-01T10:42:12Z",
"subject": {"id":"player_9f4a", "country":"EE", "risk_score":82},
"transactions": [{"tx_id":"T123", "amount":950.00, "currency":"EUR", "ts":"2025-10-28T21:10:00Z"}],
"reasons": ["velocity_withdrawals", "device_cluster"],
"actions": ["hold","EDD","bank_notification"],
"attachments": ["/evidence/aml/SAR-2025-000128.pdf"],
"confidentiality":"restricted"
}

10) Seuils et escalades (repères)

Santé/PEP hit-rate:> 3 % - escalade ; FPR%:> 12 % est un incident d'étalonnage.
KYC fail%:> 15% 24 heures - activer fallback/flux manuel VIP.
Dispo TAT:> 48h - redistribution des cas et hiérarchisation de la valeur élevée.
SAR/STR per 10k active : bond> × 2 à la médiane - révision urgente des règles/campagnes.
ETL success : <99 % - analyse des causes, rapport SRE/Compliance.

11) Stockage, accès et audit

Retraite : rapports et registres - au moins X ans (établis par la politique) ; SAR/STR - selon la juridiction (généralement plus longtemps).
Contrôle PII : minimisation des champs, pseudonymisation des subject_id, accès selon le principe des privilèges les plus bas, logs d'audit obligatoires des vues/exportations.
Exportation : listes blanches des destinataires ; tous les décharges sont signés et hachés ; Stockage WORM pour les versions finales.

12) Gestion du changement (Change/BOU)

Les modifications apportées aux mesures et aux règles de déclaration passent par l'ACR : description d'entreprise, incidence sur les IRC, échantillons de test, A/B sur la boîte à sandwich, date d'inclusion, plan de retrait.
Versionalité des rapports : report_version, changelog, tabs comparatifs (v-1 vs v).

13) Vendeurs et obligations contractuelles

Avant l'onbording : diligence raisonnable (sanctions/REER sur les bénéficiaires, ISO/SOC2, DPIA/DTIA, DPA/SCC).
En service : contrôles trimestriels SLA, alertes de test, rapprochement des logs, fixation des sous-processeurs.
Offboarding : révocation des clés/accès, suppression/retour des données, acte de fermeture et rapport de suppression complète.

14) Rôles et interactions

Tête de conformité (A) : approbation des rapports, risque-appétit.
Compliance Analyst (R) : сбор/валидация/сверки/формирование des rapports.
DPO/Legal (C) : légalité du traitement, de la notification.
Paiements/FRM (C) : transactions, chargebacks, antifrod.
Sécurité/SRE (C) : incidents, accès, logging, stabilité ETL.
Data/BI (R) : modèles, vitrines, dashboards.
Support/VIP (I) : communications sur les mallettes RG/EDD.

15) Dashboards et visualisation (minimum de widgets)

KYC Funnel : inscription → KYC init → pass/fail → SoF/SoW passée.
Santé/PEP : hit-rate/FPR/TAT, version des listes, proportion de contrôles secondaires.
Alerts AML : par règles/segments/régions ; conversion alert→action; Part EDD.
SAR/STR : dynamique filings, raisons, partager sur les méthodes de paiement.
SLA des fournisseurs : aptyme, latinité, retraits, incidents.
DQ&ETL : erreurs, omissions, succès des piplines, « feu rouge » de qualité.

16) Chèque de préparation du rapport

• Ensemble de données formé avec lineage et versions de schémas
• Validations et rapprochements DQ passés
• Confirmé par KRIs/KPIs et seuils
• Revue Legal/DPO terminé
• Signé/zaché/archivé
• Envoyé aux destinataires, logs de livraison conservés

17) Applications (modèles)

17. 1 Carte SAR/STR (registre)

ID, date, sujet, pays/méthodes, montant, raisons (rule_ids), mesures EDD, décision, date du dossier, confirmation, responsables, références à la preuve.

17. 2 Modèle de rapport mensuel KYC (CSV)

month;country;onboardings;kyc_pass;kyc_fail;avg_tat_min;liveness_dropout_pct;provider_sla_uptime;notes
2025-10;EE;14320;12688;1632;9.6;3.1;99.92;fallback activated 10/21

17. 3 Modèle de rapport sur les sanctions/RER (CSV)

week;onboardings;screened;hits;fpr_pct;dispo_tat_min;list_ofac;list_eu;list_uk
2025-W43;11982;11982;252;9.1;42;2025-10-21;2025-10-18;2025-10-19

TL; DR

Rapports AML/KYC stables = diagramme de données standardisé + DQ/rapprochement rigoureux + KRIs/KPIs compréhensibles et seuils + automatisation ETL/SOAR + RACI transparent et stockage/audit. Cela réduit les risques réglementaires, accélère les réponses aux menaces et soutient la résilience des entreprises iGaming.