ADR-0186 : Navin KYC / AML Agent, couche produit KYC, KYB, screening et AML au-dessus du Control Plane

• Statut : accepté le 2026-11-04 ; les deux choix ouverts ont été tranchés par l'utilisateur (section 12)
• Date : 2026-11-04
• Version anglaise : en/ADR-0186-navin-kyc-aml-agent.md
• Portée : nouveau projet navin-kyc-aml/ (backend FastAPI, workers, écrans dans le frontend commun des agents sectoriels (ADR-0180), intégration Navin), domaine additif du Control Plane services/control-plane/src/eai/domains/kyc_aml (cycle de vie des instances, migrations V240 à V249), types OpenFGA additifs (deploy/policies/openfga/model.fga), paquet OPA eai.kyc_aml (deploy/policies/opa/kyc_aml.rego), contrats contracts/v1/kyc-*.schema.json, parcours du portail Enterprise, gabarit de service préparé et non publié
• Documents liés : ADR-0101 (politique de licences), ADR-0108 (Opik), ADR-0110 (OpenSearch), ADR-0111 (SeaweedFS, pas de MinIO), ADR-0166 (ClamAV et YARA-X), ADR-0174 (mémoire Mem0 et Cognee), ADR-0175 (Navin Enterprise RAG Agent), audit navin-kyc-aml/docs/NAVIN_INTEGRATION_AUDIT.md

Contexte

Le client demande un agent KYC / AML pour une banque : dossiers KYC des personnes physiques et morales, documents avec extraction et provenance, KYB et bénéficiaires effectifs, screening sanctions, PEP et médias défavorables, scoring de risque, CDD, EDD et revues périodiques, surveillance transactionnelle AML, investigations et déclarations de soupçon, copilote, rapports et administration.

L'audit du 2026-11-04 montre que le Control Plane fournit déjà l'analyse des fichiers, le stockage objet, les approbations, les connecteurs, la DLP et Presidio, le RAG, la mémoire, le runtime d'agents, le lignage, les preuves et l'audit chaîné. Il ne fournit aucune logique KYC, KYB, screening ou AML. Le seul produit précédent présent dans le dépôt est le RAG Agent (ADR-0175), dont la structure est reprise.

Décision

1. Couche produit, même modèle que l'ADR-0175

Qui	Fait quoi
Navin Manager	installe et exploite le runtime (API, workers, web), TLS, santé, sauvegardes, mises à jour
Control Plane	tenants, projets, rôles, analyse des fichiers, stockage, approbations, connecteurs, DLP, RAG, mémoire, quotas, audit, politiques, traces, cycle de vie des instances (/v1/kyc-aml/instances)
Backend KYC / AML	dossiers, documents et extraction, KYB, screening, risque, revues, surveillance AML, investigations, déclarations, rapports ; il appelle le Control Plane uniquement par le SDK enterprise_ai

Le backend ne parle jamais directement à Docling, ClamAV, YARA-X, Presidio, Qdrant, Cognee ou LiteLLM. Il possède le schéma PostgreSQL kyc_aml (Alembic, RLS forcée, contexte posé par set_config local à la transaction) et un espace de noms Redis réservé à l'éphémère. Ports de développement : web 3475, API 8475.

2. Réutilisation

Les briques du RAG Agent sont reprises par copie adaptée et testée dans le nouveau projet : validation des jetons Keycloak et JWKS, contexte depuis /v1/me, autorisations OpenFGA et OPA par le Control Plane, transactions par tenant, file durable à identité signée, SSE avec reprise, citations validées, observabilité sans donnée personnelle, BFF OIDC PKCE. Les briques annoncées pour les produits Compliance & Audit, Customer Operations et Fraud & Anomaly Investigation ne sont pas présentes au moment de cette décision : elles ne sont pas supposées, une mise en commun se fera après leur fusion.

3. Le système bancaire reste la source des clients

Un dossier KYC référence le client du système bancaire (external_ref, système source) ; le produit ne crée pas de référentiel concurrent. Les connecteurs sont en lecture seule par défaut ; une écriture vers le système bancaire exige une configuration explicite, une politique OPA et une approbation.

4. Rien de réglementaire n'est codé en dur

• Cadres réglementaires, versions, obligations, contrôles et applicabilité sont des données choisies par la banque et validées par la conformité : aucun texte (européen ou autre) n'est appliqué par défaut, rien n'est applicable sans validation.
• Seuils de propriété et de contrôle, seuils de correspondance, pondérations du risque, périodicités des revues, règles AML et listes de screening sont versionnés par juridiction et configurés par la banque. Une juridiction sans seuil configuré refuse le calcul au lieu d'appliquer une valeur implicite (aucun 25 % codé en dur).

5. Calculs déterministes

• Participations : moteur déterministe sur le graphe de propriété, chemins multiples, participations croisées et structures circulaires résolues par sommation des chemins simples avec arrêt sur cycle (aucune multiplication naïve), droits de contrôle séparés des droits de propriété, arithmétique décimale exacte. Le résultat est une proposition d'UBO, jamais validée sans un analyste.
• Scoring de risque : modèle versionné, facteurs explicites, données manquantes visibles, score reproductible ; un override exige un motif, une approbation et une trace.
• Le modèle de langue n'établit jamais un fait réglementaire : il propose, résume et cite.

6. Screening

• Moteur Navin déterministe (normalisation Unicode, translittération, alias, correspondance exacte et approximative, attributs comme la date de naissance et la nationalité), sans dépendance ni donnée tierce sous licence.
• Les sources de listes sont configurées et licenciées par la banque (connecteur ou import) ; chaque version de liste est hachée (SHA-256), datée, sa fraîcheur est contrôlée et une liste périmée est signalée.
• Une correspondance est une alerte de correspondance potentielle, jamais « sanctionné » sur un score de nom ; chaque décision passe par une revue humaine. Le module PEP est distinct ; les médias défavorables distinguent allégation, enquête et décision.

7. Documents

Pipeline par le Control Plane : quarantaine, ClamAV, YARA-X (refus si un moteur ne répond pas), stockage SeaweedFS ou stockage du client, Docling. Chaque champ extrait garde son document, sa page, sa méthode, son statut et son relecteur. L'OCR n'est jamais présentée comme une vérification d'authenticité ; « identité vérifiée » exige une procédure approuvée. Un service de vérification externe n'est appelé que s'il est configuré ; la biométrie est désactivée par défaut.

8. Surveillance AML, investigations et déclarations

• Règles AML versionnées, lisibles et modifiables par les seuls habilités (les seuils ne sortent jamais vers les autres rôles), ingestion idempotente (un événement rejoué ne crée pas de seconde alerte), corrélation sans effacement des alertes d'origine, distincte de la fraude transactionnelle.
• Investigations avec chronologie, preuves à chaîne de conservation (empreinte et historique, aucune modification silencieuse), hypothèses et décisions.
• Déclarations de soupçon : préparation, validation, archive confidentielle, aucun envoi électronique sans interface officielle configurée et jamais automatique. Cloisonnement dans le schéma kyc_aml par la RLS et OpenFGA (choix de l'utilisateur, section 12) : une politique RLS dédiée exige en plus du tenant un drapeau de transaction posé par le seul chemin habilité après le contrôle OpenFGA et OPA. Interdiction de divulgation au client (tipping-off), y compris vers le copilote généraliste, les canaux, les notifications et les modèles externes.

9. Autorisations

• Types OpenFGA additifs : kyc_instance, kyc_customer, kyc_case, kyc_document, kyc_ubo, kyc_screening, kyc_edd, aml_alert, aml_investigation, aml_report, kyc_export, kyc_tool.
• Paquet OPA eai.kyc_aml : approbation KYC, override de risque, clôture d'alerte, accès à une déclaration, soumission réglementaire, export, modification des règles AML, maker-checker (aucune auto-approbation). Tout est refusé si le moteur ne répond pas (fail-closed) ; un objet d'un autre tenant répond 404.
• Lecture seule par défaut pour les agents et les connecteurs ; une délégation n'élargit jamais les droits.

10. IA, mémoire et observabilité

• Base de connaissances réglementaire par l'ingestion existante du domaine knowledge, avec juridiction et version ; citations vérifiées par le serveur.
• Cognee selon l'essai validé de l'ADR-0175 (profil standard de l'ADR-0174, pgvector, LadybugDB), isolé par tenant ; jamais source officielle des UBO, jamais mémoire d'une suspicion comme fait.
• Agents logiques sur le runtime Navin, outils à contrats complets, approbations pour les actions à risque.
• Observabilité selon l'ADR-0101 : OpenTelemetry, Opik sans donnée d'identité, Prometheus à faible cardinalité, Alloy, OpenSearch, Jaeger, OpenLineage. Grafana, Loki et Tempo sont sous AGPL-3.0 et refusés.

11. Vérité des capacités

Aucune fonction n'est déclarée terminée sans test réel ; un connecteur non testé n'est jamais déclaré opérationnel ; les listes externes ne sont pas actualisées automatiquement hors ligne ; les limites sont écrites dans navin-kyc-aml/docs/KNOWN_LIMITATIONS.md.

12. Choix posés à l'utilisateur

1. Moteur de screening : moteur déterministe Navin, listes fournies et licenciées par la banque (choisi). Écartés : yente et nomenklatura d'OpenSanctions (données sous CC-BY-NC, usage commercial payant, exception de licence nécessaire) et un fournisseur externe seul (contrat commercial, aucun test réel possible).
2. Cloisonnement des déclarations : même schéma kyc_aml, RLS et OpenFGA (choisi). Écarté : schéma séparé avec un rôle de base dédié. Risque accepté : une erreur d'autorisation applicative peut exposer une déclaration ; il est réduit par la politique RLS dédiée de la section 8 et couvert par des tests de fuite.

Conséquences

• Le produit reste léger et versionné séparément ; ses règles et ses listes sont des données de la banque.
• Deux outils de migration : Alembic pour kyc_aml, V*.sql (V240 à V249) pour le Control Plane.
• Les tests utilisent des listes locales fictives ; la qualité du screening en production dépend des listes de la banque.

Alternatives écartées

• Backend autonome avec sa propre analyse des fichiers, son OCR et ses appels de modèles : duplication de la gouvernance.
• Référentiel client concurrent du système bancaire.
• Décision « sanctionné » ou validation d'UBO par l'IA.
• Envoi automatique d'une déclaration de soupçon.
• Publication immédiate dans le catalogue du Manager.