AML · Transaction Monitoring

Module : aml-svc + add-on premium Transaction Monitoring (cf. cahier des charges §4.2.3, ADR-004 sur le moteur de règles, ADR-006 sur les listes AML).

Ce document est le guide d’architecture opérationnel pour brancher VitaKYC au système bancaire du client et détecter les flux suspects en temps réel ou en batch. Il formule mes recommandations sur le format de fichier et les patterns d’intégration avec le core banking.

1. Objectifs du module

Ingérer les transactions financières du client (banque, PSP, fintech, crédit) — temps réel ou batch.
Appliquer un ensemble de règles et de modèles de détection de comportement suspect.
Scorer chaque transaction et chaque compte, maintenir un profil comportemental.
Alerter et orchestrer les enquêtes back-office.
Reporter aux autorités (CRF Tunisie, TRACFIN France, FIU UAE, FinCEN US, BaFin…) selon le besoin via STR / SAR générés.

2. Vue d’ensemble de l’architecture

3. Mon conseil — architecture recommandée

3.1 Choix du format d’ingestion principal

Recommandation : support multi-format avec un modèle canonique interne unique.

Format	Cas d’usage	Mode	Recommandé pour…
ISO 20022 (`pacs.008`, `pacs.009`, `pain.001`, `camt.053`, `camt.054`)	Normes officielles paiements internationaux	Batch / streaming XML	Banques tier-1 et tier-2, migration SWIFT MT→MX d’ici 2026, SEPA obligatoire
Modèle canonique JSON VitaKYC	Format interne simplifié	REST + streaming Kafka	Fintechs, PSP modernes, prototypage rapide
SWIFT MT (`MT103`, `MT202`, `MT900/910/940`)	Messages legacy SWIFT	Batch fichier flat	Banques avec canaux SWIFT legacy (encore majoritaire jusqu’en 2025)
CSV VitaKYC	Export batch nocturne core banking	SFTP drop	Banques avec core banking fermé, MVP fast
CDC (Debezium) sur DB réplique	Capture-data-change de la DB core banking	Streaming Kafka	Architectures avancées, pas de dev côté core banking

Stratégie d’adoption recommandée :

MVP (0-6 mois) : CSV VitaKYC + JSON VitaKYC + ISO 20022 pacs.008. Trois formats couvrent 90 % des cas banques tunisiennes et fintechs MENA.
V1 (6-12 mois) : ajouter SWIFT MT103 + camt.053 (extraits de compte) + Kafka streaming.
V2 (12-24 mois) : CDC Debezium sur Oracle/PostgreSQL + pain.001/pain.002 pour initiation de paiement si un client l’exige.

3.2 Modèle canonique JSON VitaKYC (format « pivot »)

Tous les formats en entrée sont normalisés vers ce modèle unique avant de rentrer dans le moteur de règles. Cela isole la logique métier des variations de formats.

{
  "batch_id": "b_2026-04-22T00-00Z_tenant42",
  "transactions": [
    {
      "tx_id": "TN59-1234-20260422-000123",
      "timestamp": "2026-04-22T08:34:12Z",
      "account": {
        "id": "ACCT-TN59-1234567",
        "iban": "TN59 1000 1234 5678 9012 3456",
        "currency": "TND",
        "customer_id": "CUST-42",
        "product": "compte_courant_retail"
      },
      "direction": "DEBIT",            // DEBIT | CREDIT
      "type": "transfer",              // transfer | cash_deposit | cash_withdrawal |
                                       // card_payment | fx | loan_disbursement |
                                       // loan_repayment | fees | interest
      "channel": "swift",              // branch | atm | online | mobile | swift |
                                       // rtgs | sepa | card | correspondent
      "amount": { "value": 250000.00, "currency": "TND" },
      "amount_eur_equivalent": 74500.00,
      "counterparty": {
        "name": "ACME Trading LLC",
        "iban": "GB29 NWBK 6016 1331 9268 19",
        "bic": "NWBKGB2L",
        "country": "GB",
        "bank_name": "NatWest"
      },
      "purpose": {
        "code": "SUPP",                 // code ISO 20022 Purpose Code
        "description": "Supplier Payment Invoice INV-2026-00123"
      },
      "end_to_end_ref": "INV-2026-00123",
      "source_system": "TEMENOS_T24",
      "source_format": "iso20022_pacs008",
      "raw_ref": "s3://vkl-archive/tenant42/2026/04/22/pacs008-batch-0834.xml#msg-42"
    }
  ]
}

Pourquoi JSON + modèle pivot plutôt que tout-en-ISO-20022 interne :

Performance : JSON parse 5-10× plus rapide que XML sur JVM.
Évolutivité : ajouter un champ métier propre à VitaKYC (amount_eur_equivalent, raw_ref) sans toucher aux schémas ISO.
DX : développeurs VitaKYC écrivent des règles Kotlin sur un objet stable, pas sur xmlNamespace('urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08').

3.3 Intégration Core Banking — mes 4 patterns recommandés

Pattern 1 — SFTP batch (conservateur, MVP)

Cas : banque tunisienne / MENA avec core banking fermé, équipe IT prudente, cycles batch nocturnes.
Technique : le core banking dépose un fichier CSV ou camt.053 (extrait de compte end-of-day) sur un SFTP sécurisé géré par VitaKYC.
Fréquence : 1×/jour à 1×/heure selon le volume.
Avantages : minimum d’intrusion, pas de dev côté core banking.
Inconvénients : latence de détection (pas de temps réel), pas adapté au fraud prevention.
Recommandé pour : le MVP avec La Poste Tunisienne, Banque de l’Habitat, Attijari, mid-banks MENA.

Pattern 2 — REST pull via API

Cas : core banking moderne exposant des API (Mambu, Finastra Fusion Creator SDK, Temenos Infinity APIs).
Technique : service ingest-pull-svc poll les endpoints REST (OAuth2 + mTLS), stocke l’offset (dernière transaction lue) pour idempotence.
Fréquence : 5-15 min.
Avantages : pas de dev côté banque au-delà de l’ouverture de l’API.
Inconvénients : tributaire de la performance des API (rate limits core banking).
Recommandé pour : fintechs, néobanques Mambu, banques Finastra ayant ouvert Fusion APIs.

Pattern 3 — Kafka streaming (temps réel)

Cas : banques avec architecture événementielle, fintechs cloud-native.
Technique : le core banking publie sur un topic Kafka partagé, VitaKYC consomme via ingest-stream-svc. mTLS + ACL topics.
Fréquence : temps réel (latence < 1 s).
Avantages : détection fraude + scoring en direct.
Inconvénients : exige un backbone Kafka côté client.
Recommandé pour : fintechs modernes, Enterprise V1+.

Pattern 4 — CDC (Change Data Capture) via Debezium

Cas : impossible d’obtenir un dev côté core banking, mais on a accès à une réplique en lecture de sa base de données.
Technique : Debezium (Kafka Connect) lit les logs de transaction de l’Oracle/PostgreSQL/SQL Server et publie les inserts/updates sur Kafka.
Fréquence : temps réel.
Avantages : zéro dev côté banque, on consomme l’état de vérité sans API.
Inconvénients : complexe à opérer, dépend du schéma DB du core banking (casse sur upgrades).
Recommandé pour : projets où la banque refuse de développer mais accepte une réplique DB (pattern très utilisé chez les Tier-1).

3.4 Connecteurs pré-packagés par core banking

Core banking	Canal recommandé	Niveau effort VitaKYC	Références clients
Temenos T24 / Transact	MQ Series (messages) + TOCF (Temenos Outbound Connector Framework) OR Temenos Infinity API (REST récent)	Medium	Banques tier-1/2 TN, MA, EU
Finastra Fusion Banking	FusionFabric.cloud APIs + Fusion Creator SDK	Medium	Crédit Agricole, SG, etc.
Oracle FlexCube Universal Banking	Oracle Integration Cloud + FCUBS webservices SOAP OR CDC Debezium sur Oracle	Medium-High	Banques publiques MENA
Mambu	REST API v2 + webhooks natifs	Low	Néobanques, Fintech
Sopra Banking Amplitude	Amplitude Webservices (SOAP / REST)	Medium	Banques FR / MENA
Nymbus SmartCore	REST API + Kafka	Low	Néobanques US / EU
ProgressSoft PSPay / ProgressSoft PS-Interpay	Connecteurs propriétaires	High	Banques centrales MENA
Custom legacy	SFTP CSV + CDC fallback	High	Environnements fermés

Mon conseil : au MVP, développer les connecteurs Temenos T24 (MQ + TOCF) et Mambu (REST) en priorité. Ils couvrent ~50 % du marché banque tunisien et les fintechs MENA. Finastra et Oracle FlexCube viennent en V1. Les autres sont livrés sur demande contractuelle via services professionnels.

4. Typologies de détection

4.1 Règles paramétrables (moteur OPA + DSL Kotlin)

Référence : ADR-004.

Famille	Exemples de règles
Seuils	`amount > 50 000 TND` · `cumul_journalier > 100 000 TND` · `cumul_mensuel cash > 20 000 TND`
Vélocité	`> 10 transactions / 24 h sur un compte` · `> 3 pays counterparty / 7 jours`
Structuring (smurfing)	`> 5 dépôts cash entre 8000 et 9999 TND / 7 jours` (évasion seuil 10 000 TND de reporting)
Geo-risk	`counterparty_country in [IR, KP, SY, MM, SS, ...]` (listes FATF haut risque)
Devise inhabituelle	transaction en devise non détenue habituellement par le compte
Heure inhabituelle	`transaction 02:00-05:00` pour un compte retail non actif la nuit
Canal inhabituel	`atm` sur un compte pro qui n’utilise jamais d’ATM
Round-number bias	montants multiples de 1 000 ou 10 000 (signal de mise en scène)
Cross-border vs profil	profil déclaré « retail salarié » + paiement à société offshore
Pass-through	argent qui rentre et ressort en < 24 h
Dormancy awakening	compte dormant > 12 mois qui redevient actif avec gros volumes

4.2 Modèles ML (V2, add-on premium)

Modèle	Usage	Données d’entraînement
Isolation Forest	Détection d’outliers transaction-level	12 mois historique client
Autoencoder	Anomalies comportementales compte-level	Séquences de transactions
Graph Neural Network	Détection de réseaux (structuring, mules)	Graphe counterparty
LSTM Séquentiel	Prédiction dérive de comportement	Historique temporel compte

Recommandation : commencer par Isolation Forest + Autoencoder en V2 comme couche de scoring complémentaire aux règles. GNN + LSTM en V3 pour banques avec volume et historique riches.

4.3 Scoring composite

Chaque transaction produit un tx_risk_score ∈ [0, 1] fusionnant :

tx_risk_score = w1 * rules_score + w2 * ml_anomaly_score + w3 * counterparty_aml_score
              + w4 * geo_risk_score + w5 * historical_deviation

Pondérations w1…w5 paramétrables par tenant. Seuils d’alerte :

< 0,3 → pas d’alerte
0,3 – 0,6 → alerte niveau low, fil back-office
0,6 – 0,85 → alerte medium, assignation agent sous SLA 4 h
> 0,85 → alerte critical, escalade superviseur + possibilité de bloquer la transaction (si canal temps réel)

5. Modèle de données (complément architecture)

table: tx_transaction            -- transactions normalisées, partitionnée par mois
  tx_id              VARCHAR(128) PK (composite avec tenant_id)
  tenant_id          UUID
  timestamp          TIMESTAMPTZ
  account_id         VARCHAR(128)
  customer_id        VARCHAR(128)
  direction          VARCHAR(8)       -- DEBIT | CREDIT
  type               VARCHAR(32)
  channel            VARCHAR(32)
  amount             NUMERIC(18,2)
  currency           CHAR(3)
  amount_eur_equiv   NUMERIC(18,2)
  counterparty       JSONB            -- {name, iban, bic, country, bank}
  purpose            JSONB
  end_to_end_ref     VARCHAR(128)
  source_system      VARCHAR(64)      -- TEMENOS_T24, MAMBU, ...
  source_format      VARCHAR(32)
  raw_ref            TEXT
  tx_risk_score      NUMERIC(5,4)
  rules_triggered    TEXT[]
  created_at         TIMESTAMPTZ

table: tx_account_profile        -- profil comportemental par compte
  account_id         VARCHAR(128) PK
  tenant_id          UUID
  last_90d_volume    NUMERIC(18,2)
  last_90d_count     INT
  typical_channels   TEXT[]
  typical_currencies TEXT[]
  typical_countries  TEXT[]
  typical_time_of_day JSONB           -- histogramme heure
  average_tx_size    NUMERIC(18,2)
  stddev_tx_size     NUMERIC(18,2)
  updated_at

table: tx_alert                   -- alertes TxMon
  alert_id           UUID PK
  tenant_id          UUID
  tx_id              VARCHAR(128) FK
  triggered_at       TIMESTAMPTZ
  rule_code          VARCHAR(64)      -- ex: STRUCTURING_WEEKLY
  severity           VARCHAR(16)
  status             VARCHAR(16)      -- open | assigned | resolved | false_positive
  assignee_user_id   UUID FK user
  resolution         JSONB            -- {decision, notes, str_id}
  resolved_at

table: str_report                 -- STR / SAR générés
  str_id             UUID PK
  tenant_id          UUID
  filing_date        DATE
  authority          VARCHAR(32)      -- CTAF (Tunisie) | TRACFIN (FR) | FinCEN (US) | FIU_UAE | ...
  subject_case_id    UUID FK kyc_case
  transactions       JSONB            -- liste tx_id
  narrative          TEXT
  status             VARCHAR(16)      -- draft | filed | ack_received
  xml_object_key     VARCHAR(512)
  submitted_at

6. Reporting STR / SAR

Génération automatique à partir d’une ou plusieurs alertes :

Autorité	Format	Fréquence
Tunisie · CTAF (Commission Tunisienne d’Analyses Financières)	XML gouvernemental + dossier narratif PDF	À chaque cas suspect
France · TRACFIN	XML ERMES (télédéclaration via ERMES)	À chaque cas suspect
UAE · goAML	XML UNODC goAML standard	À chaque cas suspect
US · FinCEN SAR	PDF Form 111 OR BSA eFiling XML	< 30 jours après détection
Allemagne · FIU / goAML	XML UNODC goAML	À chaque cas suspect

Mon conseil : implémenter goAML XML en premier (V1). Ce standard UNODC est utilisé par UAE, Allemagne, Belgique, Maroc, Égypte, Libye et plus de 60 pays. Avec un seul format, VitaKYC couvre la moitié des juridictions clientes potentielles. CTAF Tunisie, TRACFIN France et FinCEN US = formats spécifiques à implémenter en modules nationaux.

7. Performance cible

Indicateur	Cible MVP	Cible V1	Cible V2
Latence ingestion → alerte (streaming)	< 5 s	< 2 s	< 500 ms
Débit ingestion	1 000 tx/s/tenant	5 000 tx/s/tenant	20 000 tx/s/tenant
Latence rule engine par tx	< 50 ms p95	< 20 ms p95	< 10 ms p95
Backfill massif	100 k tx / min	500 k tx / min	2 M tx / min
Taux de faux positifs (rules seules)	< 40 %	< 25 %	< 15 % (avec ML)

8. Sécurité et conformité

Chiffrement : mTLS sur toutes les connexions (core banking ↔ VitaKYC).
Segrégation multi-tenant : Kafka topics ACL-isolés par tenant ; tenant_id obligatoire dans chaque message.
Rétention : 10 ans minimum pour transactions + alertes + STR (obligation LCB-FT).
WORM archive : chaque batch est archivé sur MinIO en Object Lock mode Compliance.
Audit : toute consultation de transaction ou STR est loguée dans audit_event (cf. architecture technique §5.2.5).
Air-gap : le module fonctionne en on-prem sans Internet, sauf les listes AML (§ADR-006).

9. Roadmap indicative

MVP (0-6 mois) : ingestion CSV + JSON + ISO 20022 pacs.008 via SFTP et REST ; règles paramétrables seuils/vélocité/structuring ; connecteurs Temenos T24 (MQ + TOCF) et Mambu (REST) ; export STR au format goAML. Add-on commercial « TxMon Starter ».
V1 (6-12 mois) : + SWIFT MT103/202 + camt.053 ; + Kafka streaming + CDC Debezium ; + scoring ML Isolation Forest + Autoencoder ; + reporting CTAF Tunisie + TRACFIN France ; connecteurs Finastra, Oracle FlexCube. Add-on « TxMon Growth ».
V2 (12-24 mois) : + GNN pour network detection ; + pain.001 pour prévention fraud en temps de décision ; + reporting FinCEN SAR ; connecteurs Sopra Amplitude + Nymbus. Add-on « TxMon Enterprise ».

10. Tarification du module (rappel)

Plan	Inclus	Add-on
Starter	Screening unitaire simple	—
Growth	1 source de liste, ongoing monitoring	TxMon Starter 800 €/mois (jusqu’à 1 M tx/mois)
Enterprise	Multi-sources, monitoring	TxMon Growth 2 500 €/mois (jusqu’à 10 M tx/mois)
Regulated On-Prem	inclus dans licence	TxMon Enterprise 15 000 €/an fixe + 0,005 €/tx au-delà de 50 M/mois

11. Synthèse de mon conseil

Format pivot JSON VitaKYC — tous les formats externes (ISO 20022, SWIFT MT, CSV) sont normalisés vers un modèle canonique avant traitement. Cela isole la logique métier.
Support multi-format dès le MVP pour ne rejeter aucun client : CSV + JSON + ISO 20022 pacs.008 suffit pour 90 % des cas.
Quatre patterns d’intégration selon la maturité tech du client : SFTP batch (conservateur), REST pull, Kafka streaming (temps réel), CDC Debezium (zéro-dev côté banque).
Connecteurs Temenos T24 + Mambu prioritaires au MVP — cible 50 % du marché banque tunisien et fintechs MENA.
Moteur hybride — règles OPA + DSL Kotlin au MVP, ajout ML (Isolation Forest + Autoencoder) en V2 comme couche complémentaire, pas remplacement.
goAML XML d’abord — format UNODC utilisé par plus de 60 pays, couvre la moitié des juridictions clientes potentielles avec un seul format.
Archivage WORM 10 ans — ne pas négocier la rétention, c’est une contrainte LCB-FT.
mTLS partout + segrégation multi-tenant Kafka — sécurité de base non négociable pour une banque.

Document vivant · compléter au fil des premières intégrations core banking réelles.