Intégration KYC/AML avec les fournisseurs de vérification

1) Pourquoi cela est nécessaire et quels KPI sont importants

Objectifs : conformité des régulateurs, prévention de la fraude/blanchiment, réduction des risques de chargbacks et de partenaires/payeurs avec un minimum de friction.

Mesures clés :

Taux approval (par segment de marché/paiement/VIP), FPR/FNR, temps d'onbording (p95), coût de vérification par joueur.
Taux de sanctions/PEP/Adverse Media, proportion de cas manuels, pourcentage de vérifications en cours.
SLA du fournisseur (aptyme, latency, p95 réponses), retrai/erreurs d'intégration.

2) Architecture d'intégration de base

Calques :

1. Orchestrator (votre service de risk-onboarding) : routera les demandes entre les fournisseurs selon les règles/pays/types de vérification.

2. Providers SDK/API: KYC (ID + Liveness), AML (санкции/PEP/Adverse Media), Address, Age, Device.

3. Feature Store/Risk Engine : stocke les résultats, les drapeaux, les fiches de scoring et les antifrods.

4. Gestion des cas : contrôles manuels, appels, examen en ligne.

5. Audit & Conformité : logiques de décision immuables, versioning des règles/modèles, rapports au régulateur.

Flux d'événements :

Enregistrement → Age/ID (KYC minimum par juridiction).
First Deposit/Withdrawal → Enhanced Due Diligence (EDD par montant/risque).
Recurring AML Screening : redémarrage des sanctions/REER à l'horaire (quotidien/hebdomadaire).
Trigger-based : changer les détails/périphériques/geo → re-screen.

3) Types de contrôles et exactement ce qu'ils font

Vérification du document : passeport/ID/eaux. Carte de séjour/permis de séjour ; OCR + MRZ/Barcode, chèque d'authenticité.

Liveness & Biometrics : liveness actif/passif, face-match (selfie↔document).

Vérification de l'adresse : proof of address (projet de loi d'utilité/relevé bancaire), parfois des registres d'adresses.

Santé/PEP/Observateurs : OFAC/UN/EU/UK HMT + locaux ; des personnes politiquement importantes ; listes des médias indésirables/chroniques judiciaires (Adverse Media).

Age Verification : date de naissance vs seuils locaux.

Device/Email/Phone : signaux à risque (domaines jetables, numéros virtuels, proxy/hébergement).

KYB (pour partenaires/merchants) : documents statutaires, bénéficiaires (UBO), registres d'enregistrement, nouvelles négatives.

4) Orchestration et approche fondée sur les risques

Règles de routage : pays du document → fournisseur A s'il n'y a pas de couverture → fournisseur B ; VIP/montant élevé → paquet EDD.

Logique step-up : soft-chèque (sources de données) → au risque de demander des selfies/documents.

Composition : la combinaison AML screening + IDV + Address dépend de la juridiction (MGA/UKGC/Curacao et al.) et de l'étape du cycle de vie (onboarding vs payout).

Re-screening : périodique (par exemple, quotidien sur les sanctions) et événement (changement de pays/document).

5) Conception API et modèles d'intégration

Idempotency & retries : tous les appels sont avec la clé d'idempotentialité ; retraits exponentiels, timeouts, circuit-breaker.

Webhooks : états asynchrones (processing → completed → reviewed).

Validation des entrées : contrôle du format (MRZ, ISO country, document-tip).

Stockage des artefacts : cryptage, TTL/rétention par juridiction, accès selon le principe du « minimum nécessaire ».

Exemple de requête (pseudo) :

http
POST /kyc/start
{
"user_id": "u_123",  "flows": ["IDV","AML"],  "country_hint": "DE",  "document_types": ["PASSPORT","NATIONAL_ID"],  "webhook_url": "https://risk. example. com/webhooks/kyc"
}

Réponse du fournisseur :

json
{
"session_id": "sess_abc",  "status": "pending",  "redirect_url": "https://provider/flow/sess_abc"
}

Webhook Résumé :

json
{
"session_id": "sess_abc",  "status": "approved",  "checks": {
"idv": {"liveness": "pass", "face_match": 0. 92, "doc_authenticity": "pass"},   "aml": {"sanctions": "clear", "pep": "clear", "adverse_media": "none"}
},  "risk_score": 18
}

6) Qualité des données : problèmes et solutions types

Translittération/variabilité des noms : utilisation d'algorithmes phonotiques, normalisation, tables alias.

Scripts non latins : comparaison des noms en cyrillique/en arabe/en hanzi → des modules locaux de comparaison.

Date de naissance/adresse : mise en forme, vérification croisée avec le document et l'adresse de paiement (BIN/AVS).

Fausses coïncidences dans les sanctions/RER : mise en place de fuzzy-score et règles d'escalade (jeunes toss, noms de famille fréquents).

Qualité photo : indices UX (lumière, cadre, éblouissement), contrôle automatique de netteté/angle.

7) SLA, observabilité et alertes

Objectifs de latitude : onbording interactif ≤ 60-120 ms pour une demande de catalogue/screening + étapes asynchrones ≤ 2-3 min (documents).

Aptyme : ≥ 99. 9 % pour les endpoints critiques ; double fournisseur (active-active/active-standby).

Alert : croissance 'error _ rate', dégradation 'hit _ rate', saut 'review _ rate', « fenêtres silencieuses » de webhooks, retards OCR/Liveness.

Logi/tracing : correlation-ID du front au fournisseur ; masked payloads; stockage de la solution et des causes.

8) Gestion des cas (Gestion des cas)

File d'attente : priorité par montant/risque/région.

Pleybooks : que demander au client (selfie à nouveau, autre document, proof of address).

SLA par case manuelle : p95 ≤ 24 h ; high-value ≤ 2 ч.

Appels : match de répétition + reviewer indépendant ; documenter les causes du refus (avis d'action).

9) Conformité et vie privée

RGPD/analogues locaux : limitation des données, minimisation des données, droit d'accès/suppression (le cas échéant).

PCI DSS : si les données de paiement sont affectées.

PSD2/SCA : corrélation avec une forte authentification sur les étapes de paiement.

Retraite : ne stocker que les artefacts requis et seulement autant que la loi/le régulateur l'exige.

Explainability : fixez « decision rationale » - sur quoi reposait le système (liveness fail, doc mismatch, PEP hit).

10) Coût et modèle d'achat

Prix : per-check, tarifs groupés, ratios régionaux, suppléments pour EDD/Adverse Media.

Optimisation : orchestration à risque (fournisseur bon marché → cher avec folback), mise en cache des résultats sur TTL, re-screen par delta.

Liste de vérification RFP : couvertures par document/pays, précision liveness/face-match, taux de mise à jour des sanctions/RER, latency, webhooks, SDK, rapports, DPIA/certification, options on-prem, pratique judiciaire/réglementaire, références d'iGaming.

11) KYB : Quand vous travaillez avec B2V/partenaires

Registres : Companies House, registres du commerce local, chaînes UBO.

Documents : constitution, statuts, lettres bancaires, administrateurs/procurations.

Dépistage : sanctions/REER pour UBO et les directeurs, Adverse Media par marque/entité juridique.

Déclencheurs re-screen : changement de directeur/adresse/bénéficiaire, forte augmentation du chiffre d'affaires.

12) UX et conversion : comment ne pas « casser » l'onbording

Mobile-first : SDK avec des histoires d'auto (cadre, inclinaison, protection éblouissante).

Hyde pour l'utilisateur : quoi préparer à l'avance (document, éclairage), combien de temps le processus prendra.

Une barre de progrès et des statuts clairs.

Graceful fallback : si la caméra/les capteurs ne sont pas disponibles → un flux alternatif (manuel upload + vérification ultérieure).

13) Incidents et folbacks

Mode fail-safe : lorsque le fournisseur tombe, passer à la réserve + appliquer des règles minimales suffisantes.

Politique de degradation : nous n'autorisons que les dépôts de petite limite sans retrait jusqu'à la fin de la vérification.

Vérification différée : délivrance de limites de temps indiquant la nécessité d'une vérification.

14) Test et certification de l'intégration

Sandbox des fournisseurs : scripts « heureux « /« malheureux », mallettes edge (éblouissement, document coupé, jumeaux).

Tests de contrat : fixation du schéma de réponse, migration des versions de l'API.

Charge : pic de sortie/promo (trafic x5-x10), longs webhooks, reorder des événements.

Exercice DR : Désactivation d'un fournisseur, chute de webhooks, version rollback.

15) Règlement type pour la prise de décisions

Exemple de décision-table (simplifié) :

Condition	Action	Commentaire
Sanctions=hit (strong match)	DENY	L'escalade de la conformité, rapport
PEP=possible + Adverse=negative	REVIEW/EDD	Dop. sources de fonds
Liveness=fail или FaceMatch<0. 8	RETRY (1 à 2 fois) → REVIEW	Indices UX
Address=fail + High-risk country	HOLD	Proof of address à nouveau
Clean KYC/AML + Low risk score	APPROVE	Limites de politique

16) Exemple de cas complet (abrégé)

Scénario : nouveau joueur allemand, dépôt de 300 €, demande de bonus.

1. Soft check (AML fast): clear.

2. IDV : passeport + selfie, liveness = pass, face_match=0. 93, doc=authentic.

3. Address : utility bill est passé.

4. Décision : APPROVE, limite de retrait jusqu'à 2 000 €, re-AML-re-screen quotidien.

5. Audit : les versions moteur, fournisseur, règles, fiches et rationales sont enregistrées.

17) Chèque de mise en œuvre

Orchestrateur c failover et itinérance par juridiction.
Contrats/SLA/étiquettes de prix, DPIA et approbations juridiques.
Webhooks, idempotence, retraits, tracing.
Gestion de cas et playbooks EDD.
Periodic re-screen (sanctions/RER) et déclencheurs basés sur l'événement.
Suivi de la qualité (taux hit, FPR/FNR, temps de passage).
Politique de retrait/suppression et d'accès (RBAC).
Plan DR et exercice de dégradation.

Résumé

Une forte intégration KYC/AML n'est pas de « connecter un seul fournisseur », mais de construire une orchestration à partir de plusieurs sources où les décisions sont prises de manière risquée, transparente et rapide. Combinez l'IDV, la Liveness, les sanctions/RER et l'adresse, mettez en œuvre la gestion des cas et l'audit rigoureux, gardez les fournisseurs de folback et n'oubliez pas l'UX - de sorte que vous répondez aux exigences des régulateurs et conservez une conversion élevée de l'onbording.