Maquettes UI · spec d'ingénierie A→Z

Cette page rassemble toutes les maquettes de l'application VitaKYC, ordonnées par workflow utilisateur. Chaque écran est annoté pour servir de spécification exploitable par un développeur : quand l'écran s'affiche, quelles données il consomme, quelles API il appelle, quelles transitions il permet, ses états alternatifs (empty / loading / error).

Les boutons en haut permettent de basculer thème clair/sombre et direction LTR/RTL arabe. Les workflows suivent l'ordre d'utilisation réel. Les annotations engineering apparaissent en pied de chaque écran.

Persona · client · agent · admin · compliance · supervisor · auditor · developer Trigger · ce qui déclenche l'écran Inputs/Outputs · contrats API États alternatifs Transitions
1

Client runtime · parcours KYC individu

Parcours rendu par le SDK Web VitaKYC embarqué sur le site du tenant. Mobile-first, 8 écrans max. Chaque écran lit sa définition depuis GET /v1/forms/{id}/active (Form Designer). L'état du parcours est sauvegardé en localStorage + synchronisé via PATCH /v1/kyc/cases/{id}.

1.1 · Bienvenue + consentement

Persona · client Étape 0
Banque Exemple TN

Bienvenue 👋

Nous avons besoin de vérifier votre identité pour ouvrir votre compte. Le processus prend environ 3 minutes et se déroule entièrement en ligne.

En continuant, j'accepte le traitement de mes données personnelles dans le cadre de l'obligation légale LCB-FT (loi 2015-26 modifiée 2019-9), la conservation 10 ans, et la transmission éventuelle à la DGI (FATCA) ou à l'INPDP. Voir la politique de confidentialité.

Trigger

  • Client clique lien magique https://kyc.tenant/s/JWT reçu par email/SMS.
  • Résolution du JWT → case_id + form_id + locale.

API appelées

  • GET /v1/kyc/cases/{case_id}
  • GET /v1/forms/{form_id}/active (définition JSONB)
  • POST /v1/kyc/cases/{id}/consent au clic

États alternatifs

  • JWT expiré : message erreur + bouton régénérer.
  • Case déjà clos : redirection récap.
  • Network offline : écran offline avec reprise auto.

Transitions

  • « Commencer » → 1.2 (Identité).
  • « Retour » → fermer onglet ou redirect on_cancel_url.
  • Audit WORM : kyc.consent.given avec timestamp + hash.

1.2 · Identité · formulaire rendu par le Form Designer

Persona · client Étape 1/7
Banque Exemple TN

Votre identité

Étape 1 sur 7

Trigger

  • Après consentement (écran 1.1).
  • Le SDK lit form.schema.steps[1] et rend dynamiquement les champs.

Inputs / mapping

  • Chaque champ du Form Designer → propriété canonique (first_name, last_name, dob, nationality).
  • Validation côté client (min length, regex, date ≥ 18 ans).

API appelées

  • PATCH /v1/kyc/cases/{id} au submit (idempotency-key).
  • Persistance draft toutes les 5 s en localStorage.

Transitions

  • « Continuer » → 1.3 si valid.
  • Erreur validation : inline aria-live + scroll vers premier champ ko.
  • Support RTL automatique si locale=ar-TN.

1.3 · Document d'identité · capture recto & verso

Persona · client Étape 2/7 Déclenche OCR
Banque Exemple TN

Pièce d'identité

Placez votre CNI ou passeport dans le cadre.

Prévisualisation caméra
Recto ✓ Verso

Trigger

  • Après validation écran 1.2.
  • Activation caméra via navigator.mediaDevices.getUserMedia.

Pipeline OCR

  • Upload vers POST /v1/kyc/cases/{id}/documents (multipart, kind=id_card_front).
  • Événement Kafka document.uploaded → ocr-svc.
  • Feedback temps réel qualité image : flou, reflet, cadrage.

États alternatifs

  • Pas de caméra : fallback upload fichier.
  • Image floue : retour + retry avec hint.
  • OCR confidence < seuil : retry ou fallback commercial (silencieux).
  • Document non reconnu : message explicatif.

Transitions

  • Recto + verso capturés → 1.4 (selfie).
  • Passeport = recto uniquement → skip verso.

1.4 · Selfie + liveness

Persona · client Étape 3/7 Biométrie P3
Banque Exemple TN

Selfie

Regardez l'objectif et attendez la détection.

Détection en cours… ne bougez pas.

Trigger

  • Document validé (1.3).
  • Demande permission caméra frontale.

Liveness

  • Passif par défaut (ISO/IEC 30107-3 niv.2).
  • Fallback actif : clignement + rotation tête.
  • API : POST /v1/kyc/cases/{id}/biometric-check.

États alternatifs

  • Échec liveness : retry max 3, escalade manuelle.
  • Attaque suspectée (deepfake) : blocage + alerte sécurité.
  • Luminosité insuffisante : hint utilisateur.

Transitions

  • Face match selfie ↔ doc → 1.5.
  • Score < seuil tenant → manual review (case-svc).

1.5 · Justificatif de domicile

Persona · client Étape 4/7 · conditionnelle
Banque Exemple TN

Justificatif de domicile

Facture d'électricité, quittance de loyer, relevé bancaire de moins de 3 mois.

📄
Déposer un document
PDF, JPG, PNG · max 10 MB
💡 OCR automatique · si votre adresse extraite diffère, vous pourrez la corriger.

Trigger / conditionnelle

  • Rendue seulement si form.rules l'impose.
  • Ex : skip si KYC simplifié (compte jeune).

API / pipeline

  • POST /v1/kyc/cases/{id}/documents?kind=proof_address
  • OCR extract adresse → comparaison avec adresse déclarée 1.2.

États alternatifs

  • Document > 3 mois : warning + confirmation.
  • Adresse non lisible : capture manuelle.
  • « Plus tard » → dossier en attente documents (workflow agent).

Transitions

  • Validation OK → 1.6 FATCA si US indicia, sinon 1.8 succès.

1.6 · Indicia FATCA · questions ciblées

Persona · client Étape 5/7 · conditionnelle Module TCR
Banque Exemple TN

Quelques questions fiscales

Nous sommes tenus par la loi tunisienne FATCA d'identifier les personnes US.

Êtes-vous citoyen ou résident fiscal des États-Unis ?

Êtes-vous né aux États-Unis ?

Trigger

  • Rendu uniquement si le tenant a activé le module TCR.
  • Peut être skip si classifié low-risk automatiquement.

API / Classification

  • POST /v1/tcr/classifications
  • Indicia détectés : US birth, US address, US phone, US joint account, US signatory.

États alternatifs

  • Si US person = oui : route vers 1.7 W-9 (et non W-8BEN).
  • Si aucun indicia : skip 1.7.
  • Si doute → manual review compliance officer.

Transitions

  • US indicia confirmés → 1.7 formulaire fiscal à signer.
  • Sinon → 1.8 succès.

1.7 · E-signature W-8BEN / W-9

Persona · client Étape 6/7 · conditionnelle Module TCR
Banque Exemple TN

Formulaire W-8BEN

Auto-certification de non-résidence US (expire dans 3 ans).

Form W-8BEN — pré-rempli
Name: Mohamed Ben Ali · Country: Tunisia · DOB: 1985-03-12
TIN (fiscal local): 1234567A · Treaty: Tunisia · Claim: 0%
✍️
Signer dans la zone
Canvas · horodatage + hash

Trigger

  • Classification TCR requiert W-8BEN / W-8BEN-E / W-9.
  • Formulaire généré POST /v1/tcr/forms.

Providers e-signature

  • SES natif VitaKYC (canvas) par défaut.
  • TunTrust QES (loi TN 2000-83) pour tenants régulés TN.
  • DocuSign / Yousign pour tenants internationaux.

Sécurité

  • Horodatage RFC 3339 + hash SHA-256 + signature HMAC serveur.
  • Stockage WORM 10 ans.
  • Alerte expiration 90 j avant fin de validité.

Transitions

  • Signature OK → 1.8.
  • Refus : dossier bloqué « refus auto-certification TCR ».

1.8 · Écran succès

Persona · client Terminal
Banque Exemple TN
✓

Merci !

Votre dossier est transmis. Vous recevrez un email sous 24 à 48 h avec le résultat de la vérification.

Référence dossier : CASE-2026-00123

Trigger

  • Tous les écrans validés.
  • Appel final POST /v1/kyc/cases/{id}/submit.

Pipeline aval

  • Workflow Temporal KycOnboardingWorkflow décide : auto-approve / manual-review / reject.
  • Screening AML en parallèle.
  • Webhook kyc.case.decided émis au tenant.

États alternatifs

  • Auto-approve instantané : email « compte ouvert ».
  • Manual review : email « en cours, 24-48 h ».
  • Rejet : email + raison lisible + recours.

Transitions

  • Redirect on_complete_url tenant (site banque).
  • Retour ultérieur : écran récap dossier avec statut.
2

Agent back-office · revue des dossiers KYC

Application web desktop utilisée par les agents conformité des tenants pour revoir les dossiers placés en manual_review, décider (approve / reject), et traiter les alertes AML. Authentification via Keycloak OIDC, MFA obligatoire, RBAC (agent, supervisor, admin, auditor).

2.1 · Login SSO + MFA

Persona · agent Keycloak OIDC

Connexion

Étape 2 : code TOTP via Okta Verify / YubiKey

Trigger

  • Accès à back-office.vitakyc.io ou domaine tenant white-label.
  • Redirection Keycloak OIDC authorization code + PKCE.

Auth

  • Step 1 : email + password.
  • Step 2 : MFA obligatoire (TOTP / WebAuthn).
  • Session JWT 1 h + refresh 7 j.

États alternatifs

  • Compte bloqué après 5 échecs.
  • MFA non configuré : écran d'enrôlement.
  • Password expiré : workflow reset obligatoire.

Transitions

  • Login OK → 2.2 Dashboard.
  • Audit : user.login.success WORM.

2.2 · Dashboard agent

Persona · agent
Bonjour Mohamed 👋
Banque Exemple TN · Agent senior
MB
Dossiers à revoir
12
+3 depuis hier
Dossiers traités (24h)
47
↑ 18%
Alertes AML ouvertes
3
2 critiques
SLA respect
96%
cible 95%
Derniers dossiers à traiterVoir tout →
ClientScoreMotifSLA
Mohamed Ben Ali0.58Liveness score faible2h restantes
ACME Trading SARL0.71UBO incomplet4h restantes
Sophia Boulouma0.45Document flouDépassé 15min
Ahmed El Khouri0.63Face match < seuil1h30 restantes
Alertes AML critiques
OFAC match (96%)
Viktor Popov · compte TN59 1000…
PEP update
Nouvelle fonction publique
Pass-through suspect
923k USD en 72h

Trigger

  • Login réussi (2.1).
  • Page d'atterrissage par défaut pour rôle agent.

Données / API

  • GET /v1/kyc/cases?status=manual_review&assignee_me=true&limit=10
  • GET /v1/aml/alerts?severity=critical&status=open
  • GET /v1/me/kpis?period=24h

États alternatifs

  • Aucun dossier : empty state illustré.
  • SLA breach : banner rouge en haut.
  • Connexion perdue : mode offline read-only.

Transitions

  • Clic sur dossier → 2.4.
  • Clic alerte → 2.6.
  • Nav latérale → autres modules.

2.3 · Queue dossiers · filtres + pagination

Persona · agent

Dossiers KYC

47 résultats
RefClientTypeStatutRiskCrééSLAAgent
CASE-00123Mohamed Ben AliIndividuManual review0.58il y a 2h1h52MB
CASE-00124ACME Trading SARLKYBManual review0.71il y a 4h3h47MB
CASE-00125Sophia BouloumaIndividuSLA breach0.45il y a 24h-15min—
CASE-00126Ahmed El KhouriIndividuManual review0.63il y a 1h2h30MB
CASE-00127Hana ChakhariIndividuApprouvé0.22il y a 5h—AL
1-20 sur 47

Trigger

  • Clic item menu « Dossiers KYC ».

API

  • GET /v1/kyc/cases?status=&cursor=&limit=20&assignee=&risk_min=&...
  • Tri + filtres persistés en URL query.

États alternatifs

  • Empty state : « Aucun dossier ».
  • Loading : skeleton rows.
  • Breach SLA : mise en évidence rouge.

Actions batch

  • Sélection multi → assigner, exporter.
  • « Prendre » : POST /v1/kyc/cases/{id}/claim.

2.4 · Detail dossier · timeline + docs + biométrie + AML

Persona · agentÉcran clé
← Retour

Mohamed Ben Ali · CASE-00123

Manual review Risk 0.58
Timeline
14:32 · il y a 15 min
Pipeline terminé → manual_review
Motif : liveness score 0.72 < seuil 0.80
14:30
Screening AML · 0 hit
14:29
Face match · score 0.91 ✓
14:28
Liveness passif · score 0.72 ⚠
14:26
Selfie uploadé
14:24
CNI recto/verso · OCR confidence 0.98 ✓
14:20
Consentement GDPR + LCB-FT · horodaté
14:19
Dossier créé · ref externe CLIENT-2026-00123
Documents · pièces capturées
CNI recto
CNI verso
Selfie
📄
Justif domicile
Actions
Identité · OCR extracté
Nom : Ben Ali
Prénom : Mohamed
Naissance : 1985-03-12
Nationalité : TN
CNI : 09876543
Scoring
OCR0.98
Liveness0.72
Face match0.91
AML0 hit
Composite0.58

Trigger

  • Clic sur une ligne queue (2.3).
  • Deep link email « dossier en attente ».

API

  • GET /v1/kyc/cases/{id} (full detail)
  • GET /v1/kyc/cases/{id}/documents → URLs signées
  • GET /v1/kyc/cases/{id}/timeline (audit WORM)

Actions disponibles

  • Approuver / rejeter → modal 2.5
  • Demander pièces (email auto client)
  • Escalader → rôle supervisor
  • Zoom documents en lightbox

Transitions

  • Décision prise → 2.5 modal puis retour queue.
  • Audit WORM automatique pour chaque action.

2.5 · Modal décision · motif + confirmation

Persona · agent
Rejeter le dossier · CASE-00123
⚠ Cette décision est irréversible. Le dossier sera archivé WORM 10 ans (LCB-FT).

Trigger

  • Clic sur « Rejeter » en 2.4 (même modal pour « Approuver »).

API

  • POST /v1/kyc/cases/{id}/decision
  • Payload : {decision, reason_code, internal_notes, client_email}
  • Idempotency-Key obligatoire.

Règles

  • Motif obligatoire (ENUM tenant-configurable).
  • Email client peut être édité mais template obligatoire.
  • Audit WORM + piste immutable.

Transitions

  • Confirmation → case.status = rejected.
  • Webhook kyc.case.decided émis au tenant.
  • Retour queue (2.3).

2.6 · Liste alertes AML

Persona · agent / compliance

Alertes AML · 23 ouvertes

SevTypeSujetSourceScoreCrééStatut
CriticalSanction hitViktor PopovOFAC SDN0.96il y a 10 minOuvert
HighPass-throughACME Trading SARLTxMon rules0.89il y a 1 hAssigné MB
HighPEP updateAhmed El KhouriDow Jones0.85il y a 3 hOuvert
MediumAdverse mediaFiras B. (PEP)ComplyAdv NLP0.72hierAssigné AL
LowVelocitycompte xxx3456TxMon rules0.42hierOuvert

Trigger

  • Menu « Alertes AML ».
  • Webhook aml.alert.created pousse vers ce listing en temps réel.

API

  • GET /v1/aml/alerts?severity=&status=&source=&cursor=
  • SSE pour alertes temps réel : GET /v1/aml/alerts/stream.

Actions

  • Traiter : ouvre fiche alerte détail.
  • True positive → générer STR (workflow 5.4).
  • False positive → cause + retour au modèle (rétroaction ML).

Anti-tipping off

  • Les STR déjà déposés ne sont visibles qu'aux rôles compliance_officer et admin.
  • Agent peut créer draft STR, le compliance valide.
3

Admin tenant · Form Designer

Éditeur no-code utilisé par les admin tenant pour construire les parcours KYC consommés par le SDK Web. Drag-drop de champs, règles conditionnelles, traductions FR/AR/EN, versioning + publication.

3.1 · Liste formulaires + versions

Persona · admin

Form Designer

Banque Exemple TN · 5 formulaires
NomCodeLanguesVersion activeUsages 30jDernière MAJ
Compte courant retail
Parcours standard individus
tn-retail-v2🇫🇷 🇹🇳 🇬🇧v2.11 247il y a 14 j
KYB entreprise TN
Parcours B2B avec RNE + UBO
tn-kyb-v1🇫🇷 🇹🇳v1.342il y a 3 j
Compte jeune 18-25tn-youth-v1🇫🇷 🇹🇳v1.089il y a 30 j
Crédit immobiliertn-mortgage-v1🇫🇷Draft0il y a 1 j
FATCA annex formtn-fatca-v1🇫🇷 🇬🇧Archivé—il y a 6 mois

Trigger

  • Menu « Form Designer » (role admin tenant).

API

  • GET /v1/forms + GET /v1/forms/{id}/versions

États alternatifs

  • Premier login : empty state avec 5 templates sectoriels prêts à cloner.
  • Tenant sans licence Form Designer : CTA upsell.

Transitions

  • Édition → 3.2.
  • Nouveau → wizard 3 étapes (nom, template, langues).

3.2 · Éditeur canvas · palette + drag-drop + propriétés

Persona · adminÉcran clé

Compte courant retail · v2.2-draft

Palette
Identité
📝 Texte
🔢 Nombre
📅 Date de naissance
🌍 Nationalité
⚤ Genre
Coordonnées
📧 Email
📞 Téléphone
🏠 Adresse
Documents
🪪 Pièce d'identité
🤳 Selfie
📄 Justificatif
Conformité
✅ Consentement
🇺🇸 Indicia FATCA
✍️ Signature W-8
Étape 1 · Identité4 champs · requis
📝
Prénom*
📝
Nom*
📅
Date de naissance*
🌍
Nationalité*
Étape 2 · Document2 champs · requis
🪪
Pièce d'identité*
🤳
Selfie + liveness*
Étape 3 · FATCAConditionnelle (si US indicia)
🇺🇸
US person ?
✍️
Signature W-8BEN
Propriétés · champ Nom
Variable canonique partagée avec Risk Matrix + AML — obligatoire (ADR-026).
Obligatoire
🔗 Utilisé par 3 règles de risque
  • policy TN-BANQUEX@2.1 — dimension client rule 3
  • policy TN-BANQUEX@2.1 — dimension client rule 5
  • aml-txmon@1.0 — rule cash_intensive_profession
⚠ Ce champ ne peut pas être supprimé tant qu'il est référencé.

Trigger

  • Clic « Éditer » dans 3.1.

API

  • GET /v1/forms/{id}/versions/{vid}
  • Auto-save toutes les 5 s : PATCH /v1/forms/{id}/versions/{vid}
  • GET /v1/cps/tenant/{id}/variable/client.last_name → usedBy[] pour badge

Interactions

  • Drag & drop via React DnD.
  • Shadow DOM sur canvas pour isoler styles.
  • Shortcut ⌘Z / ⌘⇧Z undo/redo.
  • Suppression d'un champ référencé ouvre une modal : « Déprécier 90j » OU « Demander à compliance de retirer les règles ».

Contrat CPS (ADR-026)

  • Chaque champ doit déclarer son path CPS (client.*, entity.*).
  • Publication → event Kafka form.published consommé par profile-schema-svc.
  • Le CPS propage les changements vers les consommateurs (Risk Matrix, AML).

Blocages publication

  • Champs sans mapping CPS (obligatoire depuis ADR-026).
  • Traductions manquantes pour langues activées.
  • Pas de consentement ni signature W-8 si FATCA actif.
  • Tentative de supprimer un champ référencé par une policy ACTIVE / SHADOW.

3.3 · Règles conditionnelles (no-code)

Persona · admin

Règles · 4 définies

R1 · Afficher « Justificatif US »
SI us_birth == true OU us_address == true
ALORS visible(step_fatca) = true
R2 · Blocage mineur
SI age < 18
ALORS block = true
message = "Client mineur non éligible"
R3 · Skip justif domicile pour KYC light
SI product_type == "compte_jeune"
ALORS skip_steps = ["step_proof_address"]

DSL

  • Opérateurs : ==, !=, <, >, <=, >=, in, contains, matches.
  • Combinés par ET / OU.
  • Actions : visible, required, skip_step, block, prefill.

Stockage

  • JSONB dans form_version.schema.rules.
  • Évalué côté SDK Web ET côté API (cohérence server-side enforcement).

Tests

  • Simulateur intégré : renseigner valeurs + voir impact.
  • Export cas de test JSON pour CI tenant.

Transitions

  • Règle ajoutée / modifiée → auto-save draft.

3.4 · Traductions FR / AR / EN

Persona · admin

Traductions · 38 clés · 94% complètes

CléFRARENStatut
step_1_titleIdentitéالهويةIdentity✓
field_first_name_labelPrénomالاسمFirst name✓
field_dob_labelDate de naissanceتاريخ الميلادDate of birth✓
field_us_birth_labelNé aux États-Unis ?— manquanteBorn in the US?⚠ AR
error_requiredChamp obligatoireحقل إلزاميRequired field✓
button_continueContinuerمتابعةContinue✓

Trigger

  • Onglet « Traductions ».

Workflow

  • Les clés sont dérivées automatiquement des champs + messages d'erreur.
  • Export CSV → pour traducteurs externes.
  • Import CSV → merge avec existant.

Traduction IA

  • Option intégrée (GPT-like) avec tag « À réviser ».
  • Activable / désactivable par tenant.

Publication

  • 100% obligatoire pour langues activées dans tenant.
  • Sinon publication bloquée.

3.5 · Publier version · validation + diff

Persona · admin
Publier v2.2

Checklist avant publication

✅ Tous les champs ont un mapping KYC
✅ Consentement + signature W-8 présents
⚠ 2 traductions manquantes (AR)
✅ 4 règles validées au simulateur

Différences vs v2.1 active

+ step_fatca · nouvelle étape conditionnelle
+ field_us_birth, field_us_address, field_us_phone
~ rule_R1 · condition mise à jour
- field_middle_name · supprimé
Cette version sera active dans ~1 min après publication. Les dossiers en cours continueront avec v2.1.

API

  • POST /v1/forms/{id}/versions/{vid}/publish
  • Payload : {strategy: "replace" | "ab_test" | "scoped"}

Validations bloquantes

  • Mapping KYC non résolu.
  • Traductions < 100% pour langues obligatoires.
  • Consentement + W-8 manquants si FATCA actif.
  • Règles avec cycles ou variables inconnues.

Diff

  • Comparaison automatique avec version active.
  • Champs ajoutés / modifiés / supprimés.
  • Impact sur dossiers en cours.

Rollback

  • Retour v(N-1) en 1 clic dans l'historique.
4

Admin tenant · configuration générale

Écrans de paramétrage hors Form Designer : utilisateurs & rôles, API keys + webhooks, licence + modules activés, branding + résidence des données.

4.1 · Utilisateurs & rôles (RBAC)

Persona · admin

Utilisateurs · 18 actifs

UtilisateurEmailRôleMFADernière connexionStatut
Mohamed Ben Alim.benali@banque.tnAgent senior✅ YubiKeyil y a 5 minActif
Amira L.a.lachheb@banque.tnSuperviseur✅ TOTPil y a 30 minActif
Leila M.l.mestiri@banque.tnCompliance officer✅ YubiKeyhierActif
Karim S.k.smaali@banque.tnAuditor❌il y a 7 jMFA requis

Rôles et permissions

RôleKYC casesAML alertsSTRForm DesignerConfig tenantAudit
AgentR/WR/WDraft only——Own actions
SuperviseurR/W + assignR/W + assignDraft + review——Team actions
Compliance officerRR/WR/W + submit——All
AdminRRRR/WR/WAll
AuditorRRRRRRead all

API

  • GET /v1/users
  • POST /v1/users/invite
  • PATCH /v1/users/{id}/role

Sécurité

  • MFA obligatoire pour tous.
  • Auditor : lecture seule stricte.
  • Compliance officer : accès exclusif STR déposés.

SSO fédéré

  • Option SAML / OIDC sur l'AD client (Enterprise).
  • Provisioning SCIM V1.

Audit

  • Chaque changement de rôle → WORM.

4.2 · API keys + webhooks

Persona · admin / developer

Clés API

NomPréfixeScopesEnvironnementCrééeExpire
Production backendpk_live_abc…kyc.*, aml.read, tcr.*liveil y a 30 j2027-04-22
Sandbox testspk_test_xyz…*sandboxil y a 60 j—

Webhooks

https://core-banking.banque.tn/hooks/vitakyc
Secret : whsec_…m3z4
Actif
kyc.case.decided aml.alert.created tcr.declaration.generated form.submission.received
Dernière livraison OK : il y a 12 min (HTTP 200, 234ms) · 7 événements aujourd'hui · 0 échec 24h

Création clé API

  • Affichée UNE FOIS à la création (modal copier).
  • Scopes granulaires : kyc.read, kyc.write, etc.
  • Expiration configurable (90 j / 1 an / 2 ans / jamais).

Signatures webhook

  • Header X-VitaKYC-Signature: t=<ts>,v1=<hmac-sha256>
  • Retry exponentiel (1 min, 5 min, 15 min, 1 h, 3 h, 6 h, 24 h) puis DLQ.

Monitoring

  • Dashboard livraisons + replay manuel.
  • Alerte tenant si taux d'échec > 5 % sur 1 h.

Transitions

  • Clic webhook → détail + logs (4.2.1 hors scope ici).

4.3 · Licence & modules activés

Persona · admin

Licence · Plan Regulated On-Premise

Vérifications / mois
38 412
sur 50 000 inclus
Expire le
2027-03-31
342 j restants
Support tier
Enterprise 24/7
Résidence données
On-prem
TN

Modules activés

KYCActif
Form Designer · KYC-P · KYB + RNE · OCR · liveness · face match · NFC
AMLActif
Screening sanctions/PEP/adverse media · ongoing · batch · TxMon add-on
TCRActif
FATCA DGI · CRS OECD · DAC6 en add-on V2

Trigger

  • Menu « Licence ».

Clé de licence technique

  • JWT signé Ed25519 (cf. ADR-001 licensing).
  • Vérifiée à chaque appel API + au démarrage en on-prem.

Alertes

  • 80% quota : notif CSM tenant.
  • 100% : passage en mode queueing.
  • 30 j avant expiration : email renouvellement.

Upsell

  • Ajout module ou add-on en 1 clic (passe en commande via CSM).

4.4 · Branding + résidence des données

Persona · admin

Branding SDK Web

🏦
SVG recommandé · max 200×60 px
CNAME à pointer vers embed.vitakyc.io

Résidence des données

Impact branding

  • SDK Web lit via GET /v1/tenants/me/branding.
  • Preview live dans le Form Designer.

Résidence

  • Verrouille la région d'hébergement pour tous les buckets + DB.
  • Les logs d'audit suivent la même résidence.

Juridictions

  • Active les templates compliance (circulaires BCT, reportings FATCA, etc.).
  • Active les règles de consentement spécifiques (GDPR vs INPDP).

Audit

  • Tout changement → event WORM + notification DPO.
5

Compliance officer · AML + TCR

Workflows dédiés au responsable LCB-FT : revue des alertes AML, batch screening périodique, rédaction + transmission STR, suivi des déclarations FATCA/CRS.

5.1 · Dashboard AML compliance

Persona · compliance officer

Compliance dashboard · avril 2026

Alertes AML ouvertes
23
-8 vs mars
STR déposés (YTD)
7
CTAF
Faux positifs
62%
-4 pts
Délai moyen traitement
2h14
cible < 4h
Alertes par source (30 j)
OFAC SDN
42
PEP
30
UN 1267
13
BCT local
8
Adverse media
19
Calendrier réglementaire
15 mai 2026
Batch screening mensuel planifié
15 sept 2026
1ère fenêtre FATCA DGI→IRS
30 sept 2026
Rapport trimestriel au CA
2027-02-28
Échéance CRS OECD

Trigger

  • Login role compliance officer.

API

  • GET /v1/compliance/dashboard?period=30d
  • GET /v1/compliance/calendar

Exports

  • PDF mensuel signé Ed25519 pour le CA.
  • CSV pour intégration BI externe.

Transitions

  • Clic alerte → fiche alerte détail.
  • Clic « Batch » → 5.2.
  • Clic « STR » → liste 5.4.

5.2 · Créer un batch screening

Persona · compliance

Nouveau batch screening

💡 Temps estimé : ~17 min · Webhook aml.batch.completed + rapport PDF attestation Ed25519 livré à la fin.

API

  • POST /v1/aml/batches ou POST /v1/aml/batches/csv

Performance

  • 500 k sujets/h MVP, 5 M sujets/h V1 (cf. doc batch screening).
  • Chunking Kafka 1 k subjects/message.

Preuves

  • Rapport PDF signé Ed25519 avec snapshot des listes utilisées, hash, horodatage.
  • Valable pour audit BCT.

Transitions

  • Batch lancé → 5.3 progress + results.

5.3 · Résultats batch · progress + hits

Persona · compliance

Rescreening mensuel avril 2026

Démarré il y a 10 min · mode delta
En cours · 42%
Sujets traités
53 125
sur 125 030
Hits détectés
387
0.73%
Temps restant
~10 min
Workers actifs
8

Hits à revoir · 387

SujetSourceMatchTypeScoreDécision
Ahmed El KhouriOFAC SDNSDN-45692Sanction0.91Pending
Firas BouzguendaDow Jones PEPPEP-TN-4421PEP0.85Pending
Karim SmaaliAdverse mediacorruption 2024Adverse0.76Pending
Leila MestiriPEP RCAPEP-RCA-117PEP RCA0.72False +
Mohamed Ben AliOFAC Cons.CON-1234Sanction (homonymie)0.64False +

API

  • GET /v1/aml/batches/{id} polling SSE
  • GET /v1/aml/batches/{id}/hits?decision=pending
  • PATCH /v1/aml/batches/{id}/hits/{hid}

Revue hit

  • True positive → ouverture enquête compliance.
  • False positive → motif documenté (homonymie, DOB diff, …).

Exports

  • CSV : ingestion SIEM.
  • XLSX : revue offline.
  • PDF signé : livrable audit BCT.

Transitions

  • True positive confirmé → génération STR draft (5.4).

5.4 · STR draft editor · narrative + transmission

Persona · complianceÉcran clé
← Alertes

STR draft · STR-2026-00008

Brouillon
Narrative (règle des 5W)
486 caractères · cible 5W · OK (min 50, max 10 000)
Transactions incluses · 3
DateMontantDirectionContrepartiePays
14/04/202676 000 USDCreditGlobal Holdings LtdVG
17/04/2026847 320 USDCreditStarfish Capital SAPA
18/04/2026840 000 USDDebitHorizon Business LLCAE
Destination
Validation
✅ Narrative > 50 chars
✅ ≥ 1 transaction incluse
✅ Sujet + counterparties documentés
⚠ Validation DPO requise avant envoi
⚠ Interdiction de tipping-off : ne divulguez à personne hors compliance + DG + juridique que ce signalement existe, y compris au client concerné (loi 2015-26 art. 121, GAFI R.21).

API

  • POST /v1/aml/str
  • POST /v1/aml/str/{id}/submit

Génération XML

  • POC Kotlin goAML (60+ FIU) ou variante nationale.
  • XML signé SHA-256 + archivage WORM 10 ans.

Anti-tipping off

  • Bannière visible en permanence.
  • Visibilité STR limitée aux rôles compliance_officer, admin, auditor.

Transitions

  • Envoi → webhook aml.str.submitted.
  • Accusé autorité → aml.str.acknowledged.

5.5 · Déclarations FATCA · liste

Persona · compliance

Déclarations FATCA · exercice 2025

RéfTypeExerciceComptesStatutSoumis leIDES
0005623A-2025-001FATCA 12025187Accepté IRS15/09/2025IDES-458912
0005623A-2025-002FATCA 320253Annulation OK31/10/2025IDES-462017
0005623A-2025-003FATCA 120253Accepté IRS15/11/2025IDES-465331
0005623A-2025-004NilReport2024 FY0Déposé15/09/2024IDES-412098
0005623A-2026-001FATCA 12026—Brouillon——

Calendrier DGI → IRS 2025

15 sept
✅ Envoyé
16 oct
✅ Envoyé
31 oct
✅ Envoyé
15 nov
✅ Envoyé
15 déc
⏳ En attente

API

  • GET /v1/tcr/declarations?year=2025
  • POST /v1/tcr/declarations pour générer (FATCA 1/2/3/4 + NilReport)

Chaînage

  • FATCA 3 + FATCA 1 : respecter la fenêtre DGI→IRS (cf. Playbook 5).
  • Hérité automatique : CorrMessageRefId.

Transmission

  • Dépôt automatique IDES via connector-ides (mTLS + cert ANCE).
  • AD + RE récupérés et archivés.

Transitions

  • Clic déclaration → 5.6 détail.

5.6 · Déclaration FATCA · détail + chaînage

Persona · compliance
← Liste

FATCA 1 · 0005623A-2025-001

Accepté IRS
En-tête du message
MessageRefId : 00Z148.00027.ME.788-20250915T101147-406abc8a1830…
ReportingFI GIIN : 00Z148.00027.ME.788
Matricule Fiscal : 0005623A
TransmittingCountry : TN
ReceivingCountry : US
Period : 2025-12-31
Type : FATCA 1 (initiale)
FilerCategory : FATCA601
Comptes déclarés · 187
Compte (IBAN)HolderTINTypeSolde USD
TN59 1000…JOHN SMITH123-45-6789FATCA104125 430.75
TN59 1001…EMILY JOHNSON987-65-4321FATCA1048 200.00
TN59 1002…ACME TRADING SARL—FATCA102440 000.00
TN59 1003…ROBERT BROWN111-22-3333FATCA10467 890.12
… 183 autres
Chaînage corrections
1
FATCA 1 · 0005623A-2025-001
Initial · 187 comptes · 15/09/2025
3
FATCA 3 · 0005623A-2025-002
Annulation · 3 comptes · 31/10/2025 (suite ICMM 8009)
1
FATCA 1 réémise · 0005623A-2025-003
Réémission données corrigées · 3 comptes · 15/11/2025
Actions
Empreinte
SHA-256 :
352b78a86f2db113c9053559e0a508133a598d05ce37cb430e19d760129c3b3c
IDES ref :
IDES-458912

API

  • GET /v1/tcr/declarations/{id}
  • GET /v1/tcr/declarations/{id}/xml

Chaînage visible

  • Arborescence FATCA 1 → 2/3/4 → 1 réémission.
  • Hash SHA-256 pour preuve d'intégrité IDES.

Notifications ICMM

  • Si erreur IRS retournée (code 8008/8009/8011), propose automatiquement la stratégie de correction (FATCA 2 ou 3+1).

Transitions

  • « Corriger » → wizard de correction qui copie les données et pré-remplit CorrMessageRefId.
6

Supervisor · pilotage équipe

Rôle intermédiaire entre agents et compliance officer. Supervise la performance de l'équipe, réassigne les dossiers, traite les escalades.

6.1 · Dashboard équipe

Persona · supervisor

Équipe KYC · 8 agents

Dossiers traités (7 j)
328
+12%
SLA respect
94%
cible 95%
Temps médian
1h42
-12min
Escalades
4
cette semaine

Performance par agent

AgentDossiersSLATemps moyenAuto-approve %EscaladesCharge actuelle
Mohamed B.6298%1h1584%0
Amira L.5896%1h3082%1
Karim S.4188%2h1078%2
Hana C.5597%1h2286%0
Leila M.5294%1h4080%1

API

  • GET /v1/team/performance?period=7d
  • GET /v1/team/agents

Actions

  • Réassignation de dossiers (drag & drop).
  • Alertes sur surcharge (> 80%).

Exports

  • Rapport hebdomadaire PDF pour la direction.

Transitions

  • Clic agent → 6.2 workload détail.

6.2 · Workload agent · réassignation

Persona · supervisor
← Dashboard

Karim Smaali · 12 dossiers en charge

Surcharge
Dossiers assignés
RefClientSLARisk
CASE-00118Ahmed K.-25 min0.68
CASE-00119Salma J.1h100.42
CASE-00122Nour H.2h300.55
CASE-00123Mohamed B.4h120.58
CASE-00125Sophia B.-15 min0.45
Réassigner les 2 sélectionnés à

API

  • PATCH /v1/kyc/cases/{id}/assign (bulk supporté)

Règles

  • Un dossier réassigné conserve son historique complet.
  • Notification email à l'agent recevant.

Audit

  • Event WORM case.reassigned avec raison.

Transitions

  • Assignation → retour au dashboard équipe.
7

Auditor · accès lecture seule pour audits

Rôle utilisé lors d'un audit BCT / AMF / interne. Lecture seule, mais accès illimité à l'audit trail WORM + vérification cryptographique du hash chain.

7.1 · Audit trail readonly · recherche + filtres

Persona · auditor
🔒 Mode auditeur · lecture seule. Toutes vos consultations sont journalisées en WORM.

Piste d'audit

TimestampActionActeurCibleIPHash
2026-04-22 14:32:11kyc.case.decision_madeMohamed B. (agent)CASE-00123192.168.1.424f2a8…
2026-04-22 14:28:01kyc.biometric.liveness_scoresystemCASE-00123—3b9d2…
2026-04-22 14:26:45kyc.document.uploadedclientCASE-00123197.11.80.245c110f…
2026-04-22 14:20:33kyc.consent.givenclientCASE-00123197.11.80.2458a4c1…
2026-04-22 14:19:12kyc.case.createdapi_client:backendCASE-0012310.0.1.42e7d82…
2026-04-22 14:15:00aml.list.ingestedsystemOFAC SDN—2d1b9…

API

  • GET /v1/audit/events?type=&actor=&target=&from=&to=&cursor=
  • Append-only table PostgreSQL + policy no-UPDATE no-DELETE.

Chaînage cryptographique

  • Chaque event a un event_hash = SHA-256(previous_hash || canonical_json).
  • Altération détectable.

Export

  • CSV / JSON signé Ed25519 pour audit externe.
  • Format CEF + syslog pour SIEM client.

Traçabilité

  • Consultation auditeur elle-même loguée (métadonnée).

7.2 · Vérification hash chain · preuve d'intégrité

Persona · auditor

Vérification intégrité audit trail

Lancer une vérification
Dernier résultat · 2026-04-22 10:00
✓
Chain intègre
Aucune altération détectée sur 2 148 719 events
Événements vérifiés : 2 148 719
Période : 2026-01-01 → 2026-04-22
Durée : 4 min 32 s
Dernier hash : 7a8c3…

API

  • POST /v1/audit/integrity/verify
  • Asynchrone pour grosses volumétries.

Algorithme

  • Reconstitution de la chaîne : pour chaque event, h(prev) || canonical_json → SHA-256 doit correspondre au hash stocké.

Incident

  • Si intégrité rompue : SEV-1 (cf. RB-008 runbook).
  • Freeze écriture + escalade CTO + CISO + CEO + régulateur (72h GDPR).

Preuve

  • PDF signé Ed25519 · horodatage · hash tête de chaîne.
  • Valable pour audit BCT / INPDP / auditeurs externes.
8

Developer / integrator · portail développeur

Portail pour les développeurs backend du tenant qui intègrent l'API VitaKYC. API explorer, documentation, logs webhooks, sandbox.

8.1 · API explorer · Swagger UI intégré

Persona · developer

API v1 · 40+ endpoints

POST /v1/kyc/cases  · créer un dossier KYC
Request body
{
  "external_ref": "CLIENT-2026-00123",
  "subject_type": "individual",
  "workflow_code": "default-tn-v1",
  "locale": "fr-TN",
  "initial_data": {
    "email": "client@example.tn",
    "phone": "+21698XXXXXX"
  },
  "tags": ["retail", "tn-residence"]
}
Response · 201 Created
{
  "case_id": "c9e1...",
  "status": "created",
  "embed_url": "https://kyc.vitakyc.io/s/eyJhbGci...",
  "expires_at": "2026-04-23T14:30:00Z"
}

Source

  • OpenAPI 3.1 publique : docs.vitakyc.e-vitalis.com/openapi/vitakyc.yaml
  • Swagger UI embeded + Postman collection export.

Try it out

  • Sandbox uniquement par défaut (live nécessite double confirmation).
  • Logs des essais dans 8.2.

SDK generation

  • Pipeline CI régénère SDKs TS / Kotlin / Python / Java à chaque merge.

Transitions

  • Voir logs appels → 8.2.

8.2 · Logs webhooks + replay

Persona · developer

Logs webhooks · https://core-banking.banque.tn/hooks/vitakyc

TimestampEventStatutHTTPLatenceRetry
14:32:12kyc.case.decidedDelivered200234ms0
14:28:05aml.alert.createdDelivered200187ms0
14:20:33form.submission.receivedRetried500timeout3
13:15:00tcr.declaration.generatedDelivered200412ms0
12:40:21aml.batch.completedDLQ——7

Signature

X-VitaKYC-Signature: t=1714118400,v1=4f2a8c9d5e1b7f6a…
# Vérification :
# hmac_sha256(secret, t + "." + body) == v1

API

  • GET /v1/webhooks/{id}/deliveries?status=&cursor=
  • POST /v1/webhooks/{id}/deliveries/{did}/replay

Retry policy

  • Backoff exponentiel : 1min, 5min, 15min, 1h, 3h, 6h, 24h.
  • DLQ après 7 tentatives.

Debug

  • Chaque delivery log : request body + headers envoyés + response body reçue + timings.
  • Masquage automatique des données PII dans les logs accessibles.

Alertes

  • Taux d'échec > 5% sur 1h → email tenant.
9

Mobile SDK · bootstrap + tenant resolution

Spec visuelle de l'intégration mobile dans l'app de la banque cliente. Trois variantes selon déploiement : SaaS partagé, on-premise, fallback PWA via SMS/QR. Source de vérité ingénierie : page Mobile SDK + ADR-024.

9.1

Variante A · SaaS partagé — SDK embarqué dans l'app banque

APP BANQUE X — MOBILE BANKING
Bonjour Rania
Votre compte courant est presque prêt
!
KYC à compléter
3 minutes — requis par la BCT
Propulsé par VitaKYC · confidentiel banque · pinned cert

Trigger

L'utilisateur clique "Compléter mon KYC" dans l'app banque. L'app appelle VitaKYC.startOnboarding(). Le SDK a déjà été configuré au Application.onCreate() avec les valeurs baked dans BuildConfig.

API / Inputs

  • tenantId = "TN-BANQUEX" (BuildConfig, figé au build)
  • apiBase = "https://api-tn.vitakyc.com"
  • pinnedSha256 = [current, backup, next] rotation hitless
  • sessionProvider() = callback vers backend banque qui émet JWT RS256 (TTL 30 min) avec aud=vitakyc:TN-BANQUEX + tenant_id claim

Alternative states

  • JWT invalide : VitaKYC API rejette 401, SDK logout + alerte SIEM.
  • Pinning fail (proxy MITM) : refus connexion, message "Votre réseau interfère avec la sécurité", lien support.
  • Device rooted : Play Integrity retourne fail → policy tenant décide (bloquant ou review manuelle).
  • SDK outdated : API 426 → écran "mettez à jour votre app".

Transitions

→ 1.1 (client runtime welcome) du workflow 1, mais le contexte user / tenant / session est déjà pré-hydraté par le JWT. Au submit final (1.8) → callback onResult + webhook banque kyc.decision signé HMAC.

9.2

Variante B · On-premise — SDK parle au gateway de la banque, pas à VitaKYC.com

┌──────────────────────────────────────────────────────────┐
│  📱 App Banque X (mobile client)                          │
│  └─ VitaKYC SDK                                           │
│     tenantId     = "TN-BANQUEX"                           │
│     apiBase      = "https://mobile.banquex.tn/kyc"  ← 🔒  │
│     pinnedSha256 = [cert BANQUE, pas cert VitaKYC]        │
│     jwt          = signé backend banque (RS256, 30min)    │
└──────────────────────┬───────────────────────────────────┘
                       │ HTTPS + TLS 1.3 + pinning
                       ▼
┌──────────────────────────────────────────────────────────┐
│  🏦 Mobile gateway Banque X (DMZ)                         │
│  nginx / F5 / APISIX — reverse proxy /kyc/*              │
│  WAF + rate-limit + mTLS vers zone interne                │
└──────────────────────┬───────────────────────────────────┘
                       │ mTLS interne (CA privée banque)
                       ▼
┌──────────────────────────────────────────────────────────┐
│  🔐 VitaKYC on-prem (zone sécurisée banque)               │
│  Namespace K8s ou stack Docker selon T-shirt             │
│  Mode mono-tenant · X-Tenant-Id validé statique          │
└──────────────────────────────────────────────────────────┘

✅ Aucun flux sortant mobile → vitakyc.com
✅ Aucune règle firewall nouvelle (port 443 déjà ouvert)
✅ Conforme BCT Circulaire 2017-08 §III (résidence données)

Trigger

Identique variante A côté user. Ce qui change : la config SDK pointe vers domaine banque, pas vitakyc.com.

API / Inputs

  • apiBase = "https://mobile.<banque>.tn/kyc" (domaine banque)
  • pinnedSha256 = cert banque (rotation pilotée par banque)
  • Mobile gateway banque reverse-proxy /kyc/* → VitaKYC on-prem via mTLS interne
  • VitaKYC on-prem mono-tenant : header X-Tenant-Id validé contre config, mismatch → 403

Alternative states

  • VitaKYC on-prem indisponible : gateway retourne 503 avec retry-after, SDK affiche "Service temporairement indisponible, réessayez".
  • Rotation cert banque : pinset multi-cert (current + backup + next) — ADR-024 §9.
  • Outage internet banque : KYC continue si user sur réseau interne (Wifi agence), sinon file d'attente.

Transitions

→ écrans 1.1 à 1.8 du workflow client runtime, **servis depuis VitaKYC on-prem via proxy banque**. Webhook final kyc.decision → endpoint interne backend banque (pas d'appel sortant WAN).

9.3

Variante C · Fallback PWA — client sans app banque (SMS / QR magic-link)

SMS · +216 71 xxx xxx
« Banque X — terminez votre inscription :
https://kyc.banquex.tn/s/ABC123 »
ou scan QR en agence
🏦 Banque X
Bienvenue Rania. Nous allons vérifier votre identité.
URL: kyc.banquex.tn (branded)

Trigger

Agent en agence crée une session onboarding depuis le back-office. VitaKYC émet URL signée (JWT 30 min). SMS envoyé au client. Clic → navigateur mobile ouvre PWA branded.

API / Inputs

  • POST /v1/onboarding/sessions → { session_token, url }
  • Domaine kyc.<banque>.tn = CNAME vers vitakyc-cdn.com (SaaS) ou vers l'edge on-prem (on-prem)
  • Résolution tenant : Host header OU claim tenant_id du JWT (cross-vérifiés)
  • SRI + CSP stricte + HSTS preload list

Alternative states

  • Lien expiré (> 30 min) : écran "Demandez un nouveau lien à votre banque" + bouton redemande via backend banque.
  • iOS sans Web NFC : parcours dégradé (pas de lecture puce passeport) — doc photo + selfie + liveness.
  • Navigateur non supporté (vieux Chrome/Safari) : écran "Votre navigateur n'est pas compatible" + liste navigateurs OK.
  • Caméra bloquée par permission OS : tuto avec deeplink vers settings.
  • Lien ouvert sur desktop : QR affiché pour scan depuis mobile (le flow exige caméra).

Transitions

→ écrans 1.1 à 1.8 (runtime client), adaptés pour PWA (pas d'API NFC sur iOS, DeviceCheck remplacé par signaux comportementaux + IP reputation). Submit final → redirect vers URL banque avec status query param.

9.4

Variante D · VitaKYC Agent Mobile — app standalone (agents en mobilité)

VK
VitaKYC Agent
MDM · Banque X · region TN
À REVIEW · 12
ksn_01HWR2X3
Rania B. · SLA 2h
High risk
ksn_01HWR4K8
Mohamed T. · SLA 4h
Review

Trigger

App VitaKYC Agent installée via App Store / Play / MDM enterprise. Agent se connecte avec SSO Keycloak + MFA TOTP. Tenant résolu au login (compte lié à un tenant).

API / Inputs

  • SSO : OIDC Authorization Code + PKCE
  • Tenant resolution : claim tenant_id du token Keycloak
  • Feature flags par tenant : peut bloquer l'app si le tenant est en MDM-only
  • Distribution : App Store + Play public pour tenants SaaS, MDM Jamf/Intune pour tenants sensibles (BCT tier-1, on-prem hors public internet)

Alternative states

  • MFA échoué 3 fois : blocage 15 min + alerte SIEM.
  • Device non-managé (MDM-only tenant) : refuse l'app au boot, message "contactez votre DSI".
  • Offline : mode consultation read-only des dossiers déjà chargés, pas d'action possible.
  • Session Keycloak expirée : re-login forcé, pas de refresh silencieux (sécurité accrue vs SDK client).

Transitions

→ écrans du workflow 2 (agent back-office) adaptés mobile : queue, detail case, decision. Actions critiques (approve high-risk) exigent 4-eyes — l'agent mobile demande validation d'un collègue via push notification.

10

Admin · Risk Matrix (matrice de risques client)

Interface d'administration de la matrice de risques client, par tenant. 5 écrans : liste des policies versionnées, éditeur dimensions avec pondérations, éditeur overrides + model cards, shadow mode + backtesting, publication avec dual control. Spec ingénierie : Risk Engine · ADR-025 · Playbook BCT.

10.1

Liste des policies + versions (versioning immuable)

Risk policies · TN-BANQUEX
3 versions · 1 ACTIVE · 1 SHADOW · 1 DRAFT
VersionStatutEffective fromOwnerDernière actionActions
v2.1 draft DRAFT — compliance@banquex.tn Édité il y a 2h Éditer →
v2.0 SHADOW (J+8/14) (shadow seulement) compliance@banquex.tn Divergence vs prod: 11,2% Backtest →
v1.9 ACTIVE 2026-01-15 compliance@banquex.tn Publié par directeur-compliance@banquex.tn Voir
v1.8 ARCHIVED 2025-07-01 → 2026-01-14 compliance@banquex.tn Remplacée par v1.9 Voir
v1.7 ARCHIVED 2025-02-10 → 2025-06-30 — — Voir

Trigger

Compliance officer clique « Risk Matrix » dans la navigation admin. RBAC : `risk.policy.read` requis.

API / Inputs

  • GET /v1/risk/policies?tenantId=TN-BANQUEX → liste versions
  • Badges : DRAFT, SHADOW, PENDING_APPROVAL, PUBLISHED→ACTIVE, ARCHIVED
  • Filtrable par statut, owner, date

Alternative states

  • Aucune policy (tenant fraîchement provisionné) : CTA « Choisir un template » → liste des 4 templates livrés
  • Policy expire (revue annuelle dépassée) : bandeau orange « Revue obligatoire dans X jours »
  • DSI tente accès : autorisé read-only sauf sur étape publish

Transitions

→ 10.2 (éditer draft) · → 10.4 (shadow report v2.0) · → audit export · → « + Nouvelle version » fork un draft depuis ACTIVE

10.2

Éditeur · dimensions, pondérations, thresholds

v2.1 DRAFT · éditeur visuel JSON ↔ DSL Kotlin round-trip
Dimensions — la somme des poids doit faire 1.0
DimensionWeightRègles (score)
client core 5 règles (PEP OWN → 100, PEP family → 75, profession → 50, non-resident → 30, fallback → 0) Éditer
geo 5 règles (FATF blacklist → 100, greylist → 70, CPI high → 50, safe → 0, fallback → 20) Éditer
product 5 règles (crypto → 80, devise >50k → 60, standard → 30, jeune → 10, autres → 25) Éditer
channel 4 règles (remote selfie → 60, QES TunTrust → 30, face-à-face → 0, autres → 40) Éditer
aml_screening 4 règles (sanctions → 100, media >0.8 → 80, PEP confirmed → 50, clean → 0) Éditer
Σ 1.00 ✓ UI refuse la sauvegarde si ≠ 1.00
Thresholds monotones obligatoires : LOW<STANDARD<HIGH<PROHIBITED
LOW 0 < ≤STANDARD≤ <HIGH≤ <PROHIBITED≤ 100
Éditeur de règle · dimension client Autocomplete CPS (ADR-026)
Règle #3 :
SI IN ALORS score =
✓ Variable client.profession validée par le CPS
Source : form:FORM_KYC_INDIVIDUAL@v2.7 · Type : ENUM (BCT_PROFESSION_CODES) · Sensitivity : PII · Statut : ACTIVE
⚠ Autocomplete propose 23 variables disponibles :
client.profession · client.country · client.pep · client.residentStatus · client.minor · client.maritalStatus · client.isLegalRep · entity.uboAnyPep · product.code · product.expectedMonthly · session.channel · screening.ofacMatch · screening.sanctionsHit · screening.pepConfirmed · screening.adverseMediaScore · …
❌ Essai : client.homeowner_status
HTTP 400 CPS_SYMBOL_UNKNOWN · Publication de la policy refusée. Suggestions proches : client.housing_type, client.home_owner.
Champs CPS consommés par cette policy 8 variables référencées · 1 dépréciée ⚠
Variable CPSSourceUtilisationStatut
client.profession form@v2.7 dim client rule 3 + aml-txmon rule 1 ACTIVE
client.country form@v2.7 dim geo + mustProhibit 2 ACTIVE
client.pep form@v2.7 dim client rule 1 + mustHigh 1 ACTIVE
client.housing_status (legacy) form@v2.6 dim product rule 4 DEPRECATED — 42j restants
screening.ofacMatch worldcheck+opensanctions mustProhibit 1 ACTIVE
⚠ 1 variable dépréciée : client.housing_status sera retirée dans 42 jours. Migrer les règles vers client.housing_type avant échéance.

Trigger

Clic « Éditer » depuis 10.1 sur une policy en statut DRAFT. Si PUBLISHED/SHADOW → redirige vers « Fork » (crée nouveau draft).

API / Inputs

  • PATCH /v1/risk/policies/{id} body = JSON canonique complet
  • GET /v1/cps/tenant/{id} pour hydrater l'autocomplete (cache Caffeine côté client 30s)
  • POST /v1/cps/tenant/{id}/validate-symbols à chaque save — refus 400 si symbole inconnu (ADR-026)
  • Validation serveur : somme weights=1.0, thresholds monotones, dimensions non vides, tous symboles CPS valides
  • Auto-save toutes les 30s (debounce) + lock optimiste (version ETag)

Alternative states

  • Somme weights ≠ 1.0 : bouton « Sauvegarder » désactivé + message rouge
  • Thresholds non monotones : input en erreur + message
  • Conflit (2 compliance officers éditent) : lock optimiste → 409 → message « Un collègue a modifié cette policy, recharger »
  • Référence à un symbole inexistant (ex: client.homeowner_status) : erreur inline sur la règle concernée + suggestions CPS proches (Levenshtein ≤ 3)
  • Variable CPS dépréciée : warning orange sur la règle, countdown jusqu'au retrait, lien vers variable de remplacement
  • Variable CPS retirée (post-90j) : bouton publier désactivé, must migrer avant de continuer
  • Form Designer ajoute une nouvelle variable : event Kafka reçu, autocomplete mis à jour automatiquement en ~2s

Contrat CPS (ADR-026)

  • L'éditeur ne permet jamais une chaîne libre : les variables viennent exclusivement du CPS.
  • Serveur refuse toute règle référant un symbole absent — HTTP 400 CPS_SYMBOL_UNKNOWN.
  • Bandeau alerte si une variable dépréciée est référencée par cette policy.
  • Vue « Champs consommés » cliquable → renvoie vers le Form Designer propriétaire du champ (Source traçable).

Transitions

→ 10.3 (overrides + model cards) · retour 10.1 (liste) · onglet « Code JSON » montre la sérialisation canonique éditable directement (expert mode) · clic sur source → ouvre Form Designer sur la version déclarante

10.3

Overrides (mustProhibit / mustHigh) + model cards

Overrides Les overrides ne peuvent qu'ÉLEVER le niveau, jamais abaisser
mustProhibit — si une de ces conditions matche, décision = PROHIBITED
  • screening.ofacMatch == TRUE_POSITIVE · raison : "OFAC true positive → refuse"
  • client.country in ["KP","IR"] · raison : "pays FATF blacklist"
  • client.minor && !product.allowsMinor · raison : "mineur pour produit adulte"
mustHigh — élève à HIGH (sauf si score tombe déjà en PROHIBITED)
  • client.pep == OWN · raison : "client est PEP"
  • client.isLegalRep && entity.ubo.anyPep · raison : "représentant légal d'entité avec UBO PEP"
  • screening.adverseMediaScore > 0.9 · raison : "adverse media sévère"
Model cards obligatoire pour audit BCT 
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)
regulatory_basis:
  - "BCT Circ. 2017-08 art. 8.2"
  - "FATF Reco. 12 (PEP)"
last_review: 2026-04-15
next_review: 2027-04-15
known_limitations:
  - "Adverse media uniquement en FR/AR/EN"
  - "Définition 'close associate' subjective"
✓ 5 / 5 dimensions documentées — prêt à soumettre pour backtest

Trigger

Clic « Overrides + model cards » depuis 10.2 ou onglet dédié du draft.

API / Inputs

  • PATCH /v1/risk/policies/{id}/overrides · PATCH /v1/risk/policies/{id}/model-cards
  • Validation serveur : interdit toute override qui ABAISSE le niveau (mustLow refusé structurellement)

Alternative states

  • Model card manquante : bouton « Soumettre pour backtest » désactivé + message
  • Override référence un symbole inexistant : erreur inline
  • Warning : si aucun mustProhibit OFAC/sanctions, bandeau orange « Attention : pas de garde-fou sanction, confirmé ? »

Transitions

→ 10.4 (soumettre backtest + activer shadow) · retour 10.2 · export JSON canonique

10.4

Shadow mode + rapport de backtesting

v2.0 — Shadow mode actif · J+8/14 5 234 évaluations comparées
Divergence niveau
11,2%
seuil 15% ✓
% LOW perdus
−7,8%
seuil ±10% ✓
Nouveaux PROHIBITED
+2,1%
seuil +5% ✓
Erreurs runtime
0
seuil 0 ✓
Backtest 6 mois · 5 000 dossiers Terminé · 16 min
Confusion matrix (ancien niveau v1.9 → nouveau v2.0)
LOW ▶STANDARD ▶HIGH ▶PROHIBITED ▶
▶ LOW2 845218120
▶ STANDARD451 120872
▶ HIGH01845541
▶ PROHIBITED005152
Impact : 376 dossiers changent de niveau (7,5% de l'échantillon). Dont : 43 passent de HIGH à PROHIBITED (nouveaux overrides adverse media > 0.9) · 87 de STANDARD à HIGH (seuil geo ajusté pour nouvelle greylist FATF 2025-10) · 218 de LOW à STANDARD (pondération channel relevée).
Reproductibilité : backtest utilise les listes FATF/OFAC de l'époque de chaque dossier (listRefs), pas les listes d'aujourd'hui.

Trigger

Écran ouvert : (a) via timer quotidien du shadow mode, (b) depuis 10.3 après clic « Soumettre pour backtest », (c) lien direct depuis report email.

API / Inputs

  • Shadow : POST /v1/risk/policies/{id}/shadow-activate, métriques via GET /v1/risk/policies/{id}/shadow-metrics
  • Backtest : POST /v1/risk/policies/{id}/backtest (Temporal workflow async), rapport via GET /v1/risk/policies/{id}/backtest-reports/{btrId}
  • Listes historiques : l'archive est lue depuis S3 bucket `aml-lists-archive` par date

Alternative states

  • Shadow divergence > 15% : bandeau rouge, bouton publier désactivé sauf override directeur compliance avec justif texte ≥ 500 car.
  • Erreur runtime ≠ 0 : détails stacktrace sanitisée, bouton « ouvrir incident support »
  • Backtest en cours : progress bar 0-100%, estimation temps restant
  • Pas assez de dossiers historiques (< 1000) : warning « résultats peu représentatifs »

Transitions

→ 10.5 (soumission dual control) · retour 10.3 (modifier draft si KO) · export PDF rapport pour audit

10.5

Publier — dual control + signature Vault

v2.0 — En attente d'approbation PENDING_APPROVAL (1/2 signatures)
Justification (proposée par compliance-officer)
Adaptation au renforcement BCT 2025-10 : nouvelle greylist FATF incluant Nigeria, Pakistan, Turquie. Seuil COMPTE_DEVISE relevé de 50k à 60k TND/mois. Ajout override `adverseMediaScore > 0.9` → mustHigh. Backtest montre +87 STANDARD→HIGH (charge EDD +7%, acceptable, capacité prévue).
Signatures requises (dual control)
Directeur compliance ✓ Signé
directeur-compliance@banquex.tn
ed25519:AAAA...
Signé il y a 1h · « Approuvé après revue backtest + model cards. »
DSI En attente
dsi@banquex.tn
Email envoyé · 3 rappels prévus (J+0, J+1, J+3)
Stratégie de rollout
Checklist pré-publication ✓ backtest passé · ✓ shadow 2 sem. passé · ✓ model cards complètes · ✓ 1 signature sur 2 · ⏳ en attente DSI · ☐ communication agents préparée

Trigger

Depuis 10.4 après clic « Soumettre pour approbation ». La policy passe en PENDING_APPROVAL, 2 emails envoyés aux approbateurs avec lien signé.

API / Inputs

  • POST /v1/risk/policies/{id}/submit-for-approval avec backtestReportId + shadowReportId + justification
  • POST /v1/risk/policies/{id}/approve body : signature Ed25519 (clé perso Vault + MFA + SSO), comment obligatoire
  • POST /v1/risk/policies/{id}/publish (serveur auto après 2ème signature) : publie la policy, effectiveFrom activé, ancienne archived
  • Audit WORM : chaque étape append-only avec hash chain SHA-256

Alternative states

  • Un approbateur rejette : comment obligatoire ≥ 100 car, policy passe en REJECTED, draft éditable à nouveau
  • Délai 7j sans 2ème signature : rappel auto chaque 48h, escalade directeur général à J+7
  • Compliance officer tente d'approuver sa propre policy : refusé (auto-approval interdit), message explicite
  • Signature invalide (clé expirée/révoquée) : refus avec 403, audit WORM incident
  • Policy publiée par erreur : endpoint `/rollback` réactive la précédente ACTIVE en < 5 min (1 clic, avec raison)

Transitions

→ (si approuvée) policy PUBLISHED → ACTIVE à effectiveFrom, emails à tous compliance officers + DSI + CSM VitaKYC · → (si rejetée) retour 10.2 avec comment du rejet · → (si rollback) ancienne policy réactivée, incident post-mortem ouvert

11

Compliance officer · Review Queue (case management)

Console agent compliance pour traiter les cases déclenchés par bio-svc (MANUAL_REVIEW), risk-matrix-svc (HIGH/PROHIBITED) et aml-svc (alerts). 4 écrans : file d'attente skill-based, détail case avec timeline audit, modal de décision 4-eyes, dashboard supervisor. Spec ingénierie : Case Management · ADR-029 · POC Kotlin.

11.1

File d'attente personnelle (queue list, filtres SLA, KPIs)

Mes cases · Léïla Ben Saïd · L2
12 ASSIGNED · 3 IN_REVIEW · 2 PAUSED · SLA breach aujourd'hui : 1
CaseSubjectTriggerPrioritéStateSLASkills
case_4127Mehdi B. (PEP)RISK_HIGH HIGH ASSIGNED ⚠ 0 h 12 min restantes RETAIL · PEP Ouvrir
case_4128SARL GalloniBIO_MANUAL_REVIEW STANDARD ASSIGNED 18 h 04 min CORPORATE Ouvrir
case_4119TX-92834 (1.2 M TND)AML_ALERT URGENT IN_REVIEW 0 h 28 min TRANSACTION Ouvrir
case_4112Sofiane T. (FATCA)RISK_HIGH STANDARD PAUSED SLA pausé FATCA · RETAIL Reprendre
11.2

Détail case (résumé · timeline audit · pièces jointes)

case_4127 · Mehdi BEN ALI · PEP
priority HIGH · IN_REVIEW depuis 2 h 14 min · SLA breach dans 0 h 12 min ⚠
Résumé Timeline audit (7) Pièces jointes (3) Commentaires (2)

Verdict pipeline biométrique

  • face match score : 0.91 ✅
  • liveness : live ✅ (Onfido iBeta L2)
  • MRZ checksum : 1.00 ✅
  • doc auth : 0.78 ⚠ (tampering possible)

Risk Matrix

  • level : HIGH
  • dimension client : 0.62 (PEP own)
  • dimension geo : 0.40 (TN normal)
  • policy : TN-BANQUEX@2.1

AML signaux

2 watchlist hits (PEP own + adverse media), 0 sanctions match. Score consolidé : 0.71
11.3

Modal de décision (4-eyes : proposer + confirmer)

Décision case_4127 · Mehdi BEN ALI (PEP)
4-eyes obligatoire

1. Proposition (vous · Léïla L2)

Checklist conformité : ☑ Source fonds vérifiée · ☑ Adverse media reviewed · ☑ Sanctions clean · ☑ UBO documenté

2. Confirmation (assignée à un autre L2/MLRO)

Sera routé vers la queue "to-confirm" d'un autre agent éligible
(différent agent · seniority L2 ou MLRO · même tenant)
  • Proposition : APPROVED
  • Proposeur : Léïla Ben Saïd · L2
  • Confirmer : en attente d'assignation
11.4

Dashboard supervisor (KPIs équipe + alertes actionnables)

Compliance team · TN-BANQUEX · vue 7 jours
8 agents actifs · 542 cases CLOSED · 91% SLA respect
Throughput jour
78
↑ 12% vs semaine dernière
SLA respect (STANDARD)
91%
cible ≥ 90%
Median resolution time
3 h 42
cible ≤ 4h
Reopen rate
2.1%
cible ≤ 3%

Alertes actionnables

  • Karim H. à 24/25 cases → router le bloque, redistribuer 4 cases à Léïla
  • 3 cases STANDARD avec SLA breach imminent < 30 min → assigner à un L2 disponible
  • 2 cases ESCALATED en attente de MLRO depuis 2 h → notifier MLRO ou réaffecter
  • chain audit OK sur 542/542 cases (0 tampering détecté ✅)
12

Admin · Sanctions screening (supervision + configuration)

Console compliance officer + DSI pour superviser les sources de listes (OFAC, UN, EU, UK, World Bank, OpenSanctions + DJ option), configurer la policy de matching et auditer les screenings. 5 écrans : sources status, cron calendar, configuration policy avec dual-control, audit search avec rejeu, KPIs + monitoring. Spec ingénierie : Sanctions admin UI · Sanctions screening · ADR-030 · Runbook SRE.

12.1

Sources status — grille 7 listes free + DJ avec snapshots

Sanctions sources · TN-BANQUEX
Healthy 6 / 7 · Stale 1 · Error 0 · Last full reindex il y a 6 j
SourceStatusLast syncEntrieslistVersionNext sync
OFAC SDN🟢 healthyil y a 3 h13 412v2026-04-27.a+21 hDétail →
OFAC Consolidated🟢 healthyil y a 3 h7 209v2026-04-27.a+21 hDétail →
UN Consolidated🟢 healthyil y a 2 j718v2026-04-25+5 jDétail →
EU CFSP🟡 staleil y a 28 h3 014v2026-04-26+20 minDétail →
UK OFSI🟢 healthyil y a 4 h7 142v2026-04-27+20 hDétail →
World Bank Debarred🟢 healthyil y a 2 j2 998v2026-04-25+28 jDétail →
OpenSanctions agg.🟢 healthyil y a 3 h52 187v2026-04-27+21 hDétail →
Dow Jones Watchlist🔵 OFF————Activer →

Détail · EU CFSP (stale)

  • Last sync attempt : 2026-04-27 06:00 UTC — HTTP 503
  • Last sync success : 2026-04-26 06:00 UTC
  • Next attempt : 2026-04-27 12:00 UTC (in 20 min)
  • Snapshots MinIO : v2026-04-26 → v2026-04-25 → v2026-04-24 (10 conservés / 10 ans WORM)
🔍 Voir runbook
12.2

Cron calendar — grid hebdo full + delta + détection conflits

Schedule ETL · TN-BANQUEX
timezone UTC · prochain événement OFAC delta dans 21 h 03 min · conflits 0
00-0404-0808-1212-1616-2020-24
Lundi·OFAC delta·EU delta··
Mardi·delta x4·delta x4··
Mercredi·delta x4·delta x4··
Jeudi·delta x4·delta x4··
Vendredi·delta x4·EU delta · 503··
Samedi·delta x4·delta x4··
DimancheFULL OFAC+UN
+UK+OS+WB		delta x4····
full reindex delta sync retry / erreur · idle
Charge max prédite cluster : 18 % CPU (OK) · stockage delta /j ≈ 12 MB
12.3

Configuration policy — thresholds + weights + flags + dual-control

Sanctions policy · TN-BANQUEX
policy v1.4 active depuis 12 j · brouillon v1.5 en cours
dual-control requis
Sources Thresholds Re-ranker weights Feature flags
Direct sanctions (OFAC, UN, EU, UK)0.92
strict · recommandé BCT (LCB-FT 2017-08)
PEP (DJ + OpenSanctions)0.85
RCA 1-hop (frère sanctionné, UBO direct)0.80
RCA 2-hop (UBO indirect via société)0.70
Adverse media (DJ Special Interest)0.75
⚠ manuel only — toujours review L2

💡 Calibration suggérée (90 j d'historique)

Threshold OFAC actuel 0.92 produit 4.2 % FP, 0.3 % FN.
Suggestion : 0.93 → 2.1 % FP, 0.4 % FN (BCT préfère minimiser FP).
12.4

Audit search — recherche dans events signés + rejeu de screening

Audit screenings · TN-BANQUEX
chain integrity ✅ 1 247 / 1 247 events
Date UTCScreeningQueryDécisionScoreSig
2026-04-27 11:42scr_8472Mehdi Ben Ali · TNMATCH_PEP0.92✅
2026-04-27 11:38scr_8471Sami Said · TNCLEAR—✅
2026-04-27 11:31scr_8470Ali Hassan Al Makki · SYMATCH_DIRECT_SANCTIONS1.00✅
2026-04-26 15:14scr_8312Layla Trabelsi · TNMATCH_PEP0.91✅

Détail · scr_8470

Query : Ali Hassan Al Makki, DOB 1968-03-15, NAT SY
listVersion : v2026-04-27.a (snapshot disponible MinIO)
Reranker version : 1.0.0 · weights {0.40 0.15 0.20 0.10 0.15}
Top 3 candidates
  1. ofac-001 Ali Hassan AL-MAKKI — score 1.00 → MATCH_DIRECT_SANCTIONS
  2. rca-001 Sami AL-MAKKI — score 0.74 → CLEAR (RCA below 0.80)
  3. ofac-103 Ali Bashar Hammoud — score 0.62 → CLEAR
Signature Ed25519 ✅ vérifiée · previousEventHash sha256:abc1d2…
12.5

KPIs + monitoring cluster — alertes actionnables temps réel

Sanctions KPIs · TN-BANQUEX · 24 h
auto-refresh 60 s · données Prometheus recording rules
Screenings
8 412
↑ +12 % j-1
Latence p95
147 ms
cible < 200 ms
Taux faux positifs
4.1 %
cible < 5 %
MATCH_DIRECT
23
tous routés L2
MATCH_PEP
148
MATCH_RCA
62
Adverse media
89
manuel only
Chain audit
✅ 100 %
no tampering

Latence pipeline (p50 / p95 / p99)

Phasep50p95p99
broad search OpenSearch17 ms28 ms41 ms
re-ranker Kotlin31 ms48 ms67 ms
pipeline total82 ms147 ms198 ms

Cluster OpenSearch

  • Heap utilisée : 68 % / 85 % threshold
  • Index sanctions_TN-BANQUEX : 2.1 GB · 35 487 docs · 1 primary · 0 replicas
  • Query rate : 142 req/s · indexation rate : 0 docs/s (idle)

Alertes actionnables

  • 1 source en stale : EU CFSP (28 h depuis dernier sync, attempt 503) — ⚡ Force refresh · 🔍 Voir runbook
  • Heap OS proche threshold : 68 % (cible < 85 %) → no action
  • OK : pas de tampering détecté audit chain
13

AML · Transaction Monitoring (alertes streaming temps-réel)

Console AML pour traiter les alertes générées par le moteur de streaming Kafka Streams sur le flux de transactions du core banking. 4 écrans : file d'alertes avec filtres typology + severity, détail alerte avec timeline tx + drill-down compte, investigation panel avec 4-eyes + draft STR goAML, gestion des règles avec shadow mode + backtest. Spec ingénierie : AML Streaming Engine · AML Transaction Monitoring (vue d'ensemble) · ADR-031 · POC Kotlin.

13.1

File alertes streaming — filtres typology + severity + account + window

AML alerts · TN-BANQUEX · live
42 ACTIVE · 15 last hour · streams lag 280 ms · 5 règles ACTIVE · 2 SHADOW
Time UTCAlert IDAccountTypologySeverityAggregateRule
11:47:02alert-7a3f9c2eACC-4127 THRESHOLD URGENT 60 000 TND → RU RULE_HIGH_AMOUNT_HIGH_RISK_COUNTRY Investiguer
11:42:15alert-c8e1d4a7ACC-3892 STRUCTURING HIGH 11 txs / 7j RULE_STRUCTURING_TND Investiguer
11:38:44alert-d2f8b3e1ACC-1102 AGGREGATE HIGH 250 K TND wires 24h RULE_INT_WIRE_24H_200K Investiguer
11:35:08alert-9b4f2e7dACC-7238 PATTERN_PASS_THROUGH HIGH 96% credit→debit 1h RULE_PASS_THROUGH_48H Investiguer
11:31:55alert-f5a1c0b8ACC-5614 VELOCITY MEDIUM 3.4× baseline 30j RULE_VELOCITY_3X_30D Investiguer
Live indicators · throughput in 142 tx/s · alerts/h 28 · dedup ratio 99.7 % · late event drop rate 0.04 %
13.2

Détail alerte — timeline tx + drill-down compte + alertes liées

alert-c8e1d4a7 · ACC-3892 · STRUCTURING
RULE_STRUCTURING_TND v1.0.0 · severity HIGH · window 7d sliding · count 11/10 threshold

Timeline transactions déclenchantes

Tx IDDateMontantCounterpartyChannel
tx-884104-25 09:148 500CP-001 (TN)ONLINE
tx-884204-25 14:228 200CP-002 (TN)ONLINE
tx-884704-26 10:089 100CP-001 (TN)MOBILE
tx-885104-26 16:338 700CP-003 (TN)ONLINE
… 7 autres · total déclenchantes : 11

Drill-down compte ACC-3892

  • Profil : retraité TN, 67 ans
  • CDD level : ENHANCED
  • Risk score : 0.72 (HIGH)
  • Ouverture compte : 2018-03
  • Volume mensuel moyen : 3 200 TND
  • Volume mois courant : 91 500 TND (28× baseline ⚠)

Alertes liées même account

  • alert-f5a1c0b8 · VELOCITY 3.4× baseline · MEDIUM · 11:31
  • Aucune autre sur 30 jours

Sanctions screening

  • Subject : ✅ CLEAR (last screening il y a 2 j)
  • Counterparties (3 distinct) : 1 PEP MATCH ⚠ CP-001 (Mehdi BEN ALI)
13.3

Investigation panel — disposition + 4-eyes + draft STR goAML

Disposition · alert-c8e1d4a7 · ACC-3892
4-eyes obligatoire si SUSPICIOUS_REPORT

1. Disposition agent (vous · Léïla L2)

Checklist conformité : ☑ Source fonds non documentée · ☑ Pattern récurrent · ☑ Counterparty PEP confirmé · ☑ Volume × baseline anormal

2. Confirmation MLRO (4-eyes)

Sera routé vers la queue MLRO (différent agent · seniority MLRO · même tenant)
  • Disposition : SUSPICIOUS_REPORT_TO_MLRO
  • Proposeur : Léïla Ben Saïd · L2
  • MLRO : en attente d'assignation
✨ Draft STR goAML pré-rempli automatique
→ identité subject, transactions déclenchantes, narrative draft, attachments
Validable + éditable par MLRO avant soumission CTAF
13.4

Gestion règles — list + shadow vs active + backtest + dual-control publish

AML rules · TN-BANQUEX
5 ACTIVE · 2 SHADOW · 3 DRAFT · 8 ARCHIVED
Rule IDTypologyStatusSeverityAlerts/30jPrecisionRecall
RULE_STRUCTURING_TNDSTRUCTURINGACTIVEHIGH1840.780.91Détail →
RULE_HIGH_AMOUNT_HIGH_RISK_COUNTRYTHRESHOLDACTIVEURGENT120.950.99Détail →
RULE_VELOCITY_3X_30DVELOCITYACTIVEMEDIUM5230.620.84Détail →
RULE_PASS_THROUGH_48HPATTERN_PASS_THROUGHACTIVEHIGH670.810.88Détail →
RULE_INT_WIRE_24H_200KAGGREGATEACTIVEHIGH890.740.92Détail →
RULE_PEER_DEVIATION_5XPEER_DEVIATIONSHADOW (10j)MEDIUM156 shadow0.550.79Backtest
RULE_NEW_BENEFICIARY_FIRST_TXNEW_BENEFICIARYSHADOW (3j)LOW42 shadow——Backtest
RULE_CASH_INTENSIVE_PROFESSIONVELOCITYDRAFTMEDIUM———Éditer

Backtest · RULE_PEER_DEVIATION_5X (en SHADOW depuis 10j)

Period
last 6 months
Tx scannées
2 871 542
Alerts émises
156 (shadow)
vs prod confirmées
86 / 108 vrais positifs
Precision
0.55
Recall
0.79
FP / TP ratio
0.81
Verdict gate
⚠ Precision < 0.70 cible