Playbook · Calibrer et auditer la matrice de risques (BCT)

Pour qui : compliance officers + directeurs compliance + DSI des tenants bancaires tunisiens VitaKYC. Objectif : cadrer la création, la calibration, la publication et l’audit de la matrice de risques client conformément à la Circulaire BCT 2017-08 et aux recommandations FATF.

Pré-requis : lecture préalable de ADR-025, de la page engineering Risk Engine, et du POC.

1. Contexte réglementaire

Source	Obligation
BCT Circulaire 2017-08 art. 8 + annexe D	Approche par les risques (RBA) obligatoire. Classification type annexée : client, géographie, produit, canal. Revue périodique obligatoire.
Loi tunisienne 2015-26 (LCB-FT) art. 99-106	Documentation écrite de la politique, application effective, traçabilité par client, sanctions en cas de défaut.
Loi 2019-9 (modificative)	Renforcement des PEP et obligations de vigilance renforcée.
FATF Reco. 1, 10, 12, 15	Identification et mitigation des risques ML/TF, revue régulière.
RGPD art. 22	Droit à l’explication pour les décisions automatisées affectant significativement une personne.
Wolfsberg Group — RBA Guidance (2015)	Bonnes pratiques industrie bancaire internationale.

En audit, l’inspecteur BCT demande : la politique écrite, les procédures d’application, la preuve d’application effective à chaque client, la traçabilité des revues, la démonstration de l’adéquation des seuils et pondérations au risque de l’établissement.

2. Rôles et responsabilités

Rôle	Responsabilités
Compliance officer	Propose la matrice, édite via UI, applique au quotidien
Directeur compliance	Approuve la publication (dual control), signe la policy, arbitre les exceptions
DSI	Co-approuve la publication (dual control), valide l’impact technique
Auditeur interne	Vérifie application effective, échantillonne les décisions
Auditeur BCT / DGI	Contrôle externe, demande reproductibilité et pistes d’audit
Équipe CSM VitaKYC	Accompagne la calibration initiale + revue annuelle

Matrice RACI :

Étape	Compliance officer	Dir. compliance	DSI	Auditeur interne	VitaKYC CSM
Drafter la policy	R	A	C	I	C
Backtester	R	A	I	I	C
Shadow mode	R	A	C	I	C
Publier (dual control)	R	A	A	I	I
Appliquer au quotidien	R	A	I	C	I
Revue annuelle	R	A	C	C	C
Audit externe	C	R	C	R	C

3. Phase 1 — Drafter la première matrice (semaines 1-2)

3.1 Choix du template de base

Choisir parmi les 4 templates livrés :

TEMPLATE_BANK_TN_BCT (recommandé pour banque TN classique)
TEMPLATE_BANK_EU_6AMLD (filiale EU ou corporate international)
TEMPLATE_FINTECH_WALLET (si établissement de paiement ou wallet)
TEMPLATE_INSURANCE_CREDIT (si organisme de crédit ou assurance)

3.2 Ajuster pondérations et seuils aux spécificités de l’établissement

Questions à se poser (workshop 2h, compliance officer + directeur compliance + CSM VitaKYC) :

Quelle est notre typologie client principale ? (Retail, corporate, premium, non-résident)
Avons-nous une exposition PEP significative ? (Si oui, augmenter weight client de 0.30 à 0.35)
Quels produits offrons-nous qui portent du risque intrinsèque ? (Comptes devises, crédits structurés, produits d’épargne sophistiqués)
Quels canaux d’entrée ? (Agence / remote / video-KYC / distributeurs tiers / mobile)
Quels pays de contreparties typiques ? (Résidence client, origine/destination des fonds)

3.3 Templates de référence par profil

Profil établissement	client	geo	product	channel	aml_screening
Banque TN retail classique (défaut)	0.30	0.25	0.20	0.15	0.10
Banque TN avec forte activité internationale	0.25	0.35	0.15	0.15	0.10
Banque avec exposition PEP / premium	0.40	0.20	0.15	0.15	0.10
Fintech / wallet crypto-friendly	0.20	0.25	0.25	0.10	0.20
Crédit / assurance	0.20	0.15	0.40	0.10	0.15

3.4 Listes et overrides obligatoires

Non négociable dans toute matrice BCT :

mustProhibit sur OFAC true positive + UN sanctions + BCT liste nationale
mustProhibit sur pays FATF blacklist (KP, IR, MM)
mustProhibit sur mineur pour produit non autorisé aux mineurs
mustHigh sur PEP OWN (conformément FATF Reco. 12)
mustHigh sur adverse media score > 0.9 (Wolfsberg)

3.5 Model cards

Pour chaque dimension, remplir la model card obligatoire (format YAML dans la policy) :

dimension: client
owner: compliance-officer@banquex.tn
purpose: Évaluer le risque intrinsèque lié à la personne
variables:
  - client.pep (source: WorldCheck + OpenSanctions, refresh daily)
  - client.profession (source: form KYC, référentiel BCT codes)
regulatory_basis:
  - "BCT Circulaire 2017-08 art. 8.2"
  - "FATF Reco. 12 (PEP)"
last_review: 2026-04-15
last_reviewer: directeur-compliance@banquex.tn
next_review: 2027-04-15
known_limitations:
  - "Adverse media uniquement en FR/AR/EN"
  - "Définition 'close associate' PEP subjective, tolérance 10% FP"

4. Phase 2 — Backtester (semaines 3-4)

4.1 Objectif du backtest

Avant de publier, valider la draft sur 6 mois de dossiers historiques (échantillon 5000) pour quantifier l’impact sur :

taux auto-approve LOW (cible ≥ 60%)
taux HIGH (cible ≤ 20%)
taux PROHIBITED (cible ≤ 2%)
SLA agents (charge EDD prévisionnelle)

4.2 Lancer le backtest

POST /v1/risk/policies/{id}/backtest
Content-Type: application/json
Authorization: Bearer <compliance-officer-token>

{
  "window_months": 6,
  "sample_size": 5000,
  "reproducibility": {
    "use_lists_at_evaluation_time": true   // important : utilise les versions FATF/OFAC originales
  }
}

→ 202 Accepted  (Temporal workflow, durée typique 10-20 min)

4.3 Lire le rapport de backtest

Le rapport inclut :

Métrique	Seuil d’alerte	Action si dépassé
% dossiers dont le niveau change	> 15%	Revoir seuils/pondérations, faire un second draft
Confusion matrix (ancien niveau vs nouveau)	Inspection visuelle	Identifier patterns systémiques
Top 20 dossiers dont la décision changerait	Revue manuelle par compliance officer	Valider ou justifier
Impact auto-approve LOW	± 10%	Si baisse significative : re-calibrer
Impact charge EDD	+X% dossiers HIGH	Prévoir renforts agents OU ajuster seuils
Faux-positifs estimés (vs feedback historique)	> 2x prod	Re-calibrer dimensions contribuant le plus aux FP

4.4 Itérer

Si métriques KO : ne pas publier. Ajuster draft, rebacktester. Compte 2-3 itérations en moyenne pour une première matrice.

5. Phase 3 — Shadow mode (semaines 5-6)

5.1 Activer le shadow mode

POST /v1/risk/policies/{id}/shadow-activate
→ 200 OK

Pendant cette période :

La policy ACTIVE prend les décisions en vrai (production inchangée)
La policy SHADOW évalue en parallèle chaque dossier, sans impact
Les métriques de divergence sont collectées

5.2 Métriques shadow à monitorer

Métrique	Seuil	Alerte
% divergence de niveau (prod vs shadow)	≤ 15%	Email compliance officer si > 15%
% nouveaux PROHIBITED	≤ 5% de + par rapport à prod	Revue manuelle obligatoire
% auto-approve LOW perdus	≤ 10%	OK si c’est le but (politique plus stricte)
Erreurs runtime (nouvelle policy crashe)	0	Revert immédiat, fix bug, re-shadow

5.3 Durée minimale du shadow

2 semaines minimum, idéalement 4 semaines pour couvrir un cycle mensuel complet (paies, remises de chèques, échéances fiscales).

5.4 Décision go / no-go

Fin du shadow → comité (compliance officer + directeur compliance + DSI) :

Métriques OK + pas d’erreur → go pour publication
Métriques KO → retour en phase draft

6. Phase 4 — Publier (dual control + signature)

6.1 Préparer la publication

Compliance officer initie :

POST /v1/risk/policies/{id}/submit-for-approval
{
  "backtest_report_id": "btr_...",
  "shadow_report_id": "shr_...",
  "justification": "Adaptation au renforcement BCT 2025-10 (nouvelle greylist + seuil COMPTE_DEVISE relevé)"
}
→ 200 OK, status = PENDING_APPROVAL

6.2 Dual control

Deux approbateurs distincts doivent signer :

Directeur compliance (valide la dimension métier / conformité)
DSI (valide l’impact technique, fenêtres, capacité)

Chaque approbateur reçoit un email avec :

Diff vs policy ACTIVE (dimensions changées, seuils, overrides)
Rapport backtest (1 page)
Rapport shadow (1 page)
Model cards modifiées

Signature : Ed25519 via Vault (clé personnelle liée au compte SSO + MFA). Horodatage serveur.

POST /v1/risk/policies/{id}/approve
{
  "signature": "ed25519:...",
  "comment": "Approuvé après revue du backtest (ligne 234 du doc), scan des model cards."
}

6.3 Publication effective

Une fois les 2 signatures en place :

POST /v1/risk/policies/{id}/publish
{
  "effective_from": "2026-05-01T00:00:00Z",
  "rollout_strategy": "BIG_BANG"   // ou "CANARY_5_25_50_100" pour rollout progressif
}
→ 200 OK, status = PUBLISHED → ACTIVE à effectiveFrom

6.4 Communication

Email automatique à :

Tous les compliance officers du tenant
Directeur compliance
DSI
Head of customer experience (agents impactés)
Équipe CSM VitaKYC (tracking)

Avec : changelog condensé, liens vers rapports, date d’effet, contact en cas d’incident.

7. Phase 5 — Revue périodique (annuelle + trigger event)

7.1 Revue annuelle obligatoire

Chaque année, minimum (FATF Reco. 1, BCT implicite). Rappels automatiques à :

J-60 : email compliance officer “échéance revue dans 60j”
J-30 : escalade directeur compliance
J-7 : alerte urgente
J+0 : incident compliance ouvert

Pendant la revue, re-jouer toutes les phases 1 à 4. Budget typique : 1 semaine de travail compliance + 2 semaines shadow + publication.

7.2 Revue ad-hoc (trigger event)

Re-évaluer immédiatement si :

Nouvelle liste FATF (greylist / blacklist) publiée
Nouvelle sanction internationale majeure
Changement législatif (nouvelle circulaire BCT, nouvelle directive UE)
Incident compliance (fraude passée à travers le filet)
Changement de stratégie produit (nouveau produit à risque)
Fusion / acquisition (portefeuille client changé)

7.3 Traçabilité des revues

Chaque revue produit un rapport archivé au audit WORM :

Date
Motif (annuel / trigger event XXX)
Changements proposés (diff)
Décision (publier nouvelle version / conserver)
Signatures

8. Audit — préparer une inspection BCT

8.1 Dossier type à présenter à l’auditeur

L’auditeur BCT demandera typiquement, dans l’ordre :

Politique écrite — la matrice active + historique versions + model cards
Procédures — ce playbook + procédures agents (décisions, 4-eyes)
Preuve d’application — échantillon aléatoire de 20-50 dossiers avec leur RiskEvaluation JSON complet
Traçabilité des revues — rapports annuels + revues ad-hoc
Traçabilité des publications — audit WORM : qui a drafté, signé, publié, quand
Reproductibilité — refaire tourner un ancien dossier avec la policy de l’époque (listRefs l’exige) et obtenir le même verdict
Backtesting — rapports des dernières publications
Exceptions — liste des overrides manuels par senior compliance officers avec justifications
Model cards — pour chaque dimension
Formations — preuve que les agents et compliance officers sont formés

8.2 Questions pièges fréquentes

Question BCT	Réponse attendue
”Pourquoi le poids de `client` est 0.30 et pas 0.40 ?”	Model card + workshop d’origine + backtest qui montre que 0.30 donne un taux de faux-positifs acceptable tout en capturant les PEP/professions à risque via les overrides
”Comment empêchez-vous un agent d’outrepasser un PROHIBITED ?”	L’ADR-025 impose que les overrides ne peuvent qu’ÉLEVER le niveau. Un PROHIBITED ne peut être abaissé que via un processus séparé de “re-classification justifiée” avec 4-eyes + audit WORM + approbation directeur compliance
”Combien de temps gardez-vous les évaluations ?“	10 ans (table WORM chiffrée), conforme BCT + RGPD (mais pseudonymisation si suppression demandée)
“Que faites-vous si un client est PEP mais refuse de le déclarer ?”	Screening tiers (WorldCheck, OpenSanctions) détectera. `screening.pepConfirmed` trigger `mustHigh`. Si client persiste à nier : rejet manuel + note incident
”Comment avez-vous calibré le seuil 50 pour le passage STANDARD → HIGH ?”	Backtest sur historique 6 mois + benchmarking concurrents (Jumio/Onfido publient ~55) + avis CSM VitaKYC basé sur 5 autres tenants TN

8.3 Export audit

POST /v1/audit/export
{
  "tenant_id": "TN-BANQUEX",
  "date_from": "2025-01-01",
  "date_to": "2026-04-23",
  "types": ["policy", "evaluation", "override"],
  "format": "ZIP_PDF"   // ou "JSON" pour machine-readable
}
→ signed URL valide 7j

Le ZIP contient :

Tous les rapports de revue
Toutes les publications de policy (diff inclus)
Échantillon d’évaluations (ou toutes si demandé)
Hash chain pour vérification intégrité
Model cards

9. Incidents classiques et comment les gérer

Incident	Détection	Action
Dossier classé LOW alors qu’il était une fraude	Feedback agent après détection fraude	Revue post-mortem, reclassement si possible (profil changé), backtest pour voir si la policy aurait dû le détecter, ajuster dimensions si oui
Taux HIGH qui explose (>30%)	Dashboards KPI	Alerte auto, revue compliance officer, ajuster seuils ou dimensions
Liste OFAC mise à jour mais pas propagée	Monitor technique + alerte refresh Kafka KO	Incident technique P1, rollback version liste, re-play dossiers impactés dans la fenêtre
Override PROHIBITED contesté par le client (RGPD)	Demande explicite client	RGPD art. 22 : fournir l’explain sanitisé (niveau + raisons, sans PII tierces), permettre contestation auprès du directeur compliance, tracer la contestation
Deux approbateurs valident sans backtest	Audit interne	Incident compliance majeur, rollback policy, revue processus, formation obligatoire
Policy draft publiée par erreur	Alerte diff surprise ou feedback agent	Rollback immédiat (la policy précédente est ARCHIVED mais restaurable < 5 min), incident post-mortem
Score d’un dossier diverge entre 2 évaluations identiques	Auditeur rejoue, verdict différent	Bug critique — vérifier si listes FATF/OFAC ont changé entre temps (listRefs doit différer), sinon investigation bug determinisme

10. Checklist go-live tenant

11. Références

ADR-025 — Modèle de risque client
Risk Engine — architecture
POC — risk engine
Maquettes UI workflow 10 — Admin Risk Matrix
Playbook audit BCT (playbook général)
Playbooks compliance (autres procédures : STR, gel avoirs, data breach)
BCT Circulaire 2017-08 — texte intégral + annexe D
Loi tunisienne 2015-26 + 2019-9 (LCB-FT)
FATF Recommendations (2023 révision)
Wolfsberg Group — RBA Guidance (2015)
RGPD art. 22, considérant 71