Cahier des charges

Produit : VitaKYC — Plateforme SaaS / On-Premise KYC / AML / TCR Version : 1.0 Date : 22 avril 2026 Auteur : Chaouki Barkia Document lié : VitaKYC_Etude_Concurrentielle.md

---

Sommaire

1. Résumé exécutif
2. Contexte, enjeux et marché cible
3. Positionnement produit et différenciation
4. Périmètre fonctionnel détaillé
5. Architecture logique et licensing modulaire
6. Architecture technique et stack recommandé
7. Modèle de déploiement hybride SaaS + On-Premise
8. Exigences non-fonctionnelles
9. Conformité réglementaire multi-juridictions
10. Sécurité et protection des données
11. UX, accessibilité, multilingue
12. Intégrations et API
13. Modèle tarifaire et licensing commercial
14. Go-to-market et roadmap produit
15. KPIs produit et success metrics
16. Gouvernance projet et organisation
17. Risques et plan de mitigation
18. Annexes

---

1. Résumé exécutif

1.1 Mission

VitaKYC est une plateforme logicielle unifiée KYC / AML / TCR (Tax Compliance & Reporting), conçue pour les institutions financières MENA et Europe, disponible au choix en SaaS multi-tenant ou en déploiement on-premise, avec un licensing modulaire par module (KYC, AML, TCR).

1.2 Proposition de valeur

« La seule plateforme KYC / AML / TCR (Tax Compliance & Reporting) modulaire, disponible en SaaS ou on-premise, conçue pour les institutions financières MENA et Europe qui veulent consolider leur stack de conformité sans sacrifier l’UX ni céder au lock-in Tier-1. »

1.3 Quatre piliers de différenciation

1. Déploiement hybride réel — même base de code distribuable en SaaS ou on-prem, via image OCI durcie + Helm chart Kubernetes — là où les concurrents modernes (Onfido, Jumio, Sumsub, Persona) sont 100 % SaaS.
2. Licensing modulaire KYC / AML / TCR — chaque module est un SKU activable indépendamment, facturable en subscription et/ou per-check.
3. TCR (Tax Compliance & Reporting) nativement intégré au KYC — capture indicia US au moment du KYC initial, e-signature des formulaires W-8BEN / W-8BEN-E / W-9, reporting FATCA (IRS 8966 XML) + CRS (OECD XML) + DAC6 (UE) + retenues à la source, templates régionaux pré-configurés.
4. MENA-first + Europe-ready — support arabe RTL natif, OCR arabe + chiffres hindi, templates BCT Tunisie, CBE Égypte, UAE CB, conformité GDPR, eIDAS, BaFin, AMF en option activable par tenant.
5. Form Designer intégré (parcours KYC configurable) — éditeur no-code qui permet à chaque tenant (ou à l’équipe d’intégration) de construire et adapter ses propres parcours KYC via une UI admin (drag-drop de champs, règles de visibilité, validation, localisation FR/AR/EN). Exigence bloquante pour le marché tunisien et attente majeure des banques MENA.

1.4 Cibles prioritaires

• Banques tunisiennes et nord-africaines (lots publics type La Poste Tunisienne)
• Fintechs MENA (wallets, néobanques, paiement)
• Assurance et organismes de crédit MENA + Europe du Sud
• Banques mid-market Europe du Sud / Est (Espagne, Portugal, Italie, Roumanie)

---

2. Contexte, enjeux et marché cible

2.1 Enjeux marché

• Fraude d’identité et deepfake en hausse ; les liveness niveau 2 (passif) deviennent insuffisants sans couche anti-deepfake.
• Coût et complexité KYC : les banques multiplient les fournisseurs (IDV + AML + KYB + FATCA), d’où une pression à la consolidation.
• Expérience client : drop-off massif sur les parcours > 3 minutes ; la conversion est devenue un KPI de revenu direct.
• Conformité mouvante : AMLA UE (2026-2028), circulaires BCT 2025-06 et 06/2025 (Tunisie), loi Fédérale UAE n°10/2025 AML/CFT, évolution continue des listes de sanctions.

2.2 Enjeux réglementaires (synthèse)

Juridiction	Référentiels principaux
Tunisie	Circulaire BCT 2025-06 (conditions minimales d’entrée en relation) ; Circulaire BCT 06/2025 (enrôlement électronique) ; Circulaire BCT 2017-08 (contrôle interne LCB-FT) ; loi organique 2015-26 modifiée par 2019-9 (LAB/FT) ; Accord IGA FATCA Tunisie-USA du 13/05/2019 ; article 17 bis du CDPF (loi de finances 2016-78 art. 38) ; Cahier des charges DGI « Transfert FATCA par procédé informatique » V1.0-2019 (plateforme IDES)
UE	GDPR ; eIDAS 2.0 (Wallet européen) ; AMLD5/6 puis AMLA (2026-2028) ; PSD2 ; AI Act (2024-2025)
France	AMF / ACPR ; décret anti-blanchiment ; ANSSI PVID (prestataire vérification d’identité à distance)
Allemagne	BaFin — Circular 3/2017 (VideoIdent) ; GwG (AML Act)
Espagne	SEPBLAC
UAE	Federal Law n°10/2025 AML/CFT ; Central Bank of UAE ; DIFC ; ADGM
Égypte	AML Law n°80/2002 ; Central Bank of Egypt ; NTRA (télécom)
US (FATCA)	IRC §1471-1474 ; IRS Form 8966 XML ; W-8BEN, W-8BEN-E, W-9
International	OECD CRS (Common Reporting Standard) ; FATF 40 recommandations ; FATCA IGA Model 1 & 2

2.3 Segments cibles

Segment	Besoins clés	Déploiement préféré	Module(s) prioritaire(s)
Banques MENA (Tunisie, Maroc, Algérie, Égypte, UAE)	Conformité BCT / CB locale, on-prem souvent imposé, reporting BCT, arabe RTL	On-premise majoritairement	KYC + AML + FATCA (banques avec exposition US)
Banques mid-market Europe du Sud/Est	GDPR, eIDAS, BaFin (DE), AMF (FR), CRS	SaaS ou cloud privé	KYC + AML + CRS
Fintechs / néobanques / wallets MENA	Volume, UX, time-to-market, API-first	SaaS multi-tenant	KYC + AML
Assurance & crédit	Onboarding distant, AML adapté aux produits d’investissement, CRS pour assurance-vie	SaaS	KYC + AML + CRS (+ FATCA si US clients)
PSP, acquireurs, marketplaces régulés	KYB, UBO, onboarding merchants	SaaS	KYC + KYB + AML

---

3. Positionnement produit et différenciation

3.1 Synthèse du benchmark concurrentiel

Référence : VitaKYC_Etude_Concurrentielle.md.

Attente marché	Leader actuel	Gap observé
KYC moderne + UX + SaaS	Sumsub, Onfido, Jumio, Persona	Pas d’option on-premise
AML profond	ComplyAdvantage, Sumsub	Nécessite intégration tiers pour KYC
Tax Compliance & Reporting (FATCA, CRS) rigoureux	Thomson Reuters ONESOURCE, Fenergo	Ergonomie legacy, silos vs KYC
VideoKYC conformité UE	IDnow	Cher, UE-only
Biométrie vocale	Veridas	AML léger
Présence MENA + arabe	uqudo, Valify, Veridas	Couverture EU limitée

VitaKYC adresse les 5 gaps simultanément.

3.2 Angles de différenciation défendables

1. Architecture hybride native — conçue dès le design pour les deux modes (SaaS multi-tenant et on-prem single-tenant) sans fork de code.
2. Licensing modulaire KYC / AML / TCR — activation feature flag + clé de licence signée ; facturation granulaire.
3. TCR (Tax Compliance & Reporting) first-class, pas un add-on — FATCA + CRS + DAC6 couverts dans un seul module, intégré à l’onboarding KYC : capture indicia dans le parcours, génération et e-signature de formulaires W-8 / W-9, reporting XML 8966 et CRS, audit trail immutable.
4. Templates régionaux — BCT (Tunisie), CBE (Égypte), CB UAE, Banque du Liban, AMF (France), BaFin (Allemagne), IRS, OECD CRS — livrés prêts à l’emploi, maintenus par l’éditeur.
5. UX arabe RTL native — non une traduction, une conception RTL-first avec chiffres hindi en option.
6. Pricing transparent (à la Shufti Pro) avec self-serve pour fintechs — tout en gardant enterprise negotiated pour banques.

---

4. Périmètre fonctionnel détaillé

4.1 Module KYC — Know Your Customer

4.1.0 Form Designer — parcours KYC configurable (transverse au module KYC)

⚠️ Fonctionnalité bloquante commerciale sur le marché tunisien — exigée par les banques locales et les AO publics, attendue par défaut dans le segment MENA. Scope MVP.

• Éditeur no-code accessible depuis le back-office, rôle admin tenant ou integrator.
• Palette de champs standards : texte, texte long, nombre, date, date de naissance, email, téléphone, dropdown (valeurs paramétrables), radio, cases à cocher, upload fichier, capture document, selfie, signature, consentement.
• Groupement en étapes (steps) ordonnées, titres, descriptions, étapes conditionnelles selon la valeur d’un champ ou selon le segment client.
• Règles de visibilité et de validation : expressions simples (field_x == "value", field_y > 18) avec éditeur assisté.
• Localisation par champ : libellé + description + messages d’erreur en FR, AR (RTL), EN a minima.
• Versioning par tenant : chaque publication est numérotée et révocable ; une version active par produit (ex : « compte courant » vs « compte jeune » vs « compte professionnel »).
• Preview live multi-devices (desktop / mobile / tablette) et multi-langues.
• A / B testing en V1 (MVP = version active unique).
• Export / import au format JSON pour portabilité inter-tenants.
• Templates sectoriels pré-livrés : banque retail MENA, fintech wallet, crédit / leasing, assurance, crypto.
• Stockage : schéma de formulaire en JSONB + données collectées en JSONB typé ; rendu par le SDK Web qui consomme la définition et s’adapte.
• Le Form Designer n’altère pas les briques figées (liveness, face match, OCR, screening AML, génération XML FATCA) — il orchestre leur insertion dans le parcours.

4.1.1 Onboarding individuel (KYC-P)

• Capture documents : recto / verso / photo ; passeports, CNI, permis de conduire, titres de séjour ; support minimum de 150 pays et 5 000 templates de documents au lancement (extensibles).
• OCR multi-langue : français, anglais, arabe (écriture + chiffres hindi), espagnol, portugais, allemand, italien. Précision cible ≥ 98 % sur documents nominaux.
• NFC eMRTD : lecture puce passeport ICAO 9303 (BAC et PACE), CNI électronique UE, Emirates ID (via ICP Gateway UAE), CNI tunisienne biométrique quand déployée.
• Liveness detection :
  • Passif par défaut, conforme ISO/IEC 30107-3 niveau 2 (certification iBeta visée).
  • Actif en fallback (clignement, tête) pour documents faibles résolution.
  • Anti-deepfake niveau 3 : détection de replay, spoof, genAI (roadmap V2).
• Face match : comparaison selfie ↔ photo document, seuil configurable par tenant (FAR/FRR ajustables).
• Proof of address : capture + OCR justificatif domicile, détection d’altération.
• Vérifications secondaires : email, téléphone (OTP, HLR lookup), bureau de crédit (via connecteurs régionaux).
• Entretien vidéo live (VideoKYC) : agent humain ou bot, enregistrement chiffré, conforme BaFin Circular 3/2017 (mode qualifié) et AMF PVID (France).

4.1.2 Onboarding entreprise (KYC-B / KYB)

• Extraction registres du commerce par pays (via partenariats data : Creditsafe, Bisnode, Refinitiv World-Check, Dun & Bradstreet ; registres officiels nationaux).
• Intégration native RNE Tunisie — le Registre National des Entreprises expose deux web services officiels pour l’échange de données (cf. §12.3.1) : un service KYC (identité légale de l’entreprise, dirigeants, capital, forme juridique, statut d’activité) et un service UBO (bénéficiaires effectifs). L’abonnement se contractualise auprès du RNE (contact : interop@e-rne.tn, M. Tarek Dhifi, +216 70 248 162) sous un cadre légal défini par la loi organique n°22-2016 du 24 mars 2016 (droit d’accès à l’information) et la législation anti-terrorisme tunisienne. VitaKYC intégrera ces deux services comme connecteurs de premier niveau pour le marché tunisien. Référence : home.registre-entreprises.tn/echange_des_donnees.
• Autres registres officiels : Infogreffe / INPI (France), Handelsregister (Allemagne), Registro Mercantil (Espagne), Companies House (UK), UAE trade license via partenaires locaux, CBE business registry (Égypte).
• Détection et vérification UBO (Ultimate Beneficial Owner) avec traversée d’arborescence actionnariale ; en Tunisie, consommation directe du service UBO du RNE.
• Screening dirigeants (PEP, sanctions, adverse media) via module AML.
• Scoring d’entreprise basé sur données financières publiques quand disponibles.
• Capture & validation documents constitutifs : statuts, K-bis, extrait RNE tunisien, trade license UAE, certificate of incorporation.

4.1.3 Gestion du consentement

• Recueil explicite du consentement, granulaire par finalité (KYC, AML, FATCA, marketing, partage tiers).
• Horodatage (RFC 3339 + fuseau UTC), signature serveur (HMAC) sur chaque enregistrement.
• Archivage WORM (Write Once Read Many) — minimum 10 ans (obligations FATF).
• Droit de retrait conforme GDPR, avec effet rétroactif et journalisation.

4.2 Module AML — Anti-Money Laundering

4.2.1 Screening d’entrée en relation

• Sanctions : OFAC SDN + consolidated, UN, UE consolidated, HMT (UK), listes locales BCT, listes SEPBLAC, listes UAE CB — mise à jour en continu (abonnements data).
• PEP (Politically Exposed Persons) : base agrégée, classification par niveau (domestic, foreign, international organization), hiérarchie RCA (Relatives and Close Associates) avec règle 50 %.
• Adverse media : corpus NLP multilingue (≥ 200 pays), catégorisation (corruption, trafic, terrorisme, fraude, etc.).
• Matching fuzzy avec transliteration arabe ↔ latin (cruciale pour marché MENA — ex : « محمد » ↔ « Mohamed / Mohammed / Muhammad »).

4.2.2 Ongoing monitoring

• Rescreening programmé (quotidien minimum) de la base cliente contre listes mises à jour.
• Alerting configurable par niveau de risque.
• Historisation complète des changements de statut.

4.2.2.bis Batch screening (rescreening de masse)

• Initial screening du stock cliente lors de la mise en service (50 k → 10 M+ sujets).
• Rescreening périodique (mensuel / trimestriel) pour conformité LCB-FT.
• Delta rescreening quotidien contre les ajouts/modifications des listes des 24 dernières heures.
• Rescreening ciblé sur demande (audit BCT, segment haute-valeur, cohorte spécifique).
• Entrées : CSV upload, JSON API, query base cliente VitaKYC.
• Sortie : rapport CSV + XLSX + PDF attestation signée Ed25519 pour preuve aux régulateurs.
• Planification intégrée (cron) + webhook aml.batch.completed.
• Détails techniques : Engineering · AML Batch Screening.

4.2.3 Transaction monitoring (module premium, optionnel)

• Moteur de règles configurable (ex : seuils cash, velocity, geo risk, structuring).
• Modèles ML optionnels (anomaly detection, typologies).
• Case management intégré avec enquête, escalade, STR/SAR génération.
• Génération rapport CTR/STR au format attendu par l’autorité locale (CRF Tunisie, TRACFIN France, FIU UAE, FinCEN US).

4.2.4 Risk scoring unifié

• Score de risque composite par client : (KYC_risk × w1) + (AML_risk × w2) + (FATCA_risk × w3).
• Pondérations ajustables par tenant et par produit.
• Scoring dynamique recalculé à chaque événement significatif.
• Intégration au workflow d’orchestration (auto-approve, manual review, reject, escalate).

4.3 Module TCR — Tax Compliance & Reporting

Le module TCR (Tax Compliance & Reporting) couvre l’ensemble des obligations de diligence fiscale et de reporting à destination des autorités fiscales nationales et internationales. Il regroupe FATCA, CRS, DAC6, retenues à la source (withholding tax) et QI reporting dans une plateforme unifiée, là où le marché oblige aujourd’hui à combiner plusieurs outils (cf. §3.1).

4.3.0 Périmètre fonctionnel du module TCR

Sous-domaine	Description	Statut
FATCA	Loi US 2010 + IGA Model 1 ; classification US person / EENF passive / IF participante ; formulaires W-8BEN / W-8BEN-E / W-9 ; reporting XML v2.0 conforme IRS Publication 5124 ; transmission indirecte via autorité fiscale locale (ex : DGI Tunisie → IRS) ou directe (QI)	Must V1 (Tunisie)
CRS (OECD)	Common Reporting Standard, résidence fiscale, TIN, auto-certification, reporting XML OECD v2.0 / v3.0 aux autorités nationales	Must V1
QI Reporting	Qualified Intermediary agreement (optionnel pour banques avec flux US directs)	Roadmap V2
Retenues à la source (Withholding Tax)	Calcul et déclaration de retenues (taux, abattements conventions fiscales)	Roadmap V2
DAC6 (UE)	Directive 2018/822 — transparence sur dispositifs transfrontières à risque d’évasion fiscale	Roadmap V2
Reporting fiscal local	Templates DGI Tunisie (FATCA XML v2.0), BCT, CBE (Égypte), Bercy DGFiP (France), BZSt (Allemagne), AEAT (Espagne), UAE MoF	Must V1 (Tunisie + France)

4.3.1 Classification client

• Détection d’indicia US au moment du KYC initial : US place of birth, US address, US phone, US signatory authority, standing instructions to US account, US joint account holder.
• Moteur règles + NLP pour address parsing et détection fine.
• Classification automatique : US person, Non-US person, Passive NFFE, Active NFFE, FFI, Exempt beneficial owner, etc. (catégories IRS Form W-8BEN-E).
• Classification CRS : résidence fiscale principale + additionnelles, TIN par juridiction, auto-certification required.

4.3.2 Formulaires fiscaux

• Génération dynamique W-8BEN (individus non-US), W-8BEN-E (entités non-US), W-9 (US persons).
• Pré-remplissage automatique depuis les données KYC.
• E-signature intégrée — provider configurable par tenant : module natif VitaKYC (SES), DocuSign (international), Yousign/Universign (France, eIDAS QES), TunTrust / ANCE (Tunisie, QES conforme loi 2000-83) pour force probante locale auprès des tribunaux tunisiens. Cf. ADR-011.
• Versioning, horodatage, expiration (3 ans pour W-8), alertes de revalidation.

4.3.3 Reporting XML & chaînage (modèle IGA 1)

• FATCA : génération XML conforme au schéma IRS FATCA XML v2.0 (FatcaXML_v2.0.xsd, isofatcatypes_v1.1.xsd, oecdtypes_v4.2.xsd, stffatcatypes_v2.0.xsd) — référence : IRS Publication 5124 FATCA XML Schema v2.0 User Guide.
• Transmission indirecte (IGA Model 1) : la plupart des juridictions MENA (Tunisie notamment) reposent sur un accord IGA Model 1 — l’IF déclarante transmet le fichier XML à l’autorité fiscale nationale, qui le retransmet à l’IRS. VitaKYC produit le fichier, l’IF le dépose sur la plateforme nationale (en Tunisie : IDES à https://www.ides.finances.gov.tn). Détail en §12.3.3.
• CRS : génération XML conforme OECD CRS Schema v2.0 / v3.0, transmission vers autorité fiscale nationale.
• Chaînage des déclarations : support natif des 4 types de messages FATCA conformément aux règles de gestion DGI :
  • FATCA 1 — déclaration initiale (ou réémission après annulation FATCA 3).
  • FATCA 2 — déclaration de correction, uniquement sur notification IRS renvoyée par l’autorité tunisienne (jamais spontanée).
  • FATCA 3 — annulation pure et simple (éléments déclarés à tort) ; ou étape 1 d’une procédure « annule et remplace ».
  • FATCA 4 — modification d’un fichier déjà validé par l’IRS (autres cas que FATCA 2 / FATCA 3).
  • Chaînage via CorrMessageRefID et CorrDocRefID pointant vers le fichier d’origine, gestion du séquencement (FATCA 3 avant FATCA 1 de réémission).
• Contraintes techniques du fichier XML (obligatoires) :
  • Encodage UTF-8 sans BOM.
  • En-tête XSD : xsi:schemaLocation="urn:oecd:ties:fatca:v2 FatcaXML_v2.0.xsd".
  • Taille max 100 Mo avant compression ; compression GZIP (zlib ≥ 1.2.3) acceptée.
  • Nom de fichier <MatriculeFiscal>-<exercice>.xml (réel) ou <MatriculeFiscal>-<exercice>-Test.xml (test).
  • Échappement obligatoire & < > " ' ; séquences interdites -- /* &# ; pas d’hyperliens, JavaScript, exécutables, archives.
• Unicité des identifiants (règles DGI) :
  • MessageRefID = <GIIN> + horodatage à la seconde + GUID optionnel (unique dans l’espace et le temps).
  • DocRefID = <GIIN du déclarant>.<numéro unique référencement> (21 à 200 caractères, alphanumérique + - et . uniquement) ; un DocRefID distinct par ReportingFI, AccountReport, NilReport.
• NilReport : génération automatique d’une déclaration « néant » conforme NilReport + NoAccountToReport pour les IF entrant dans le champ FATCA mais sans compte déclarable.
• Accusé de dépôt : récupération et archivage de l’AD (horodatage, référence DGI, empreinte SHA du fichier déposé) ainsi que du compte-rendu d’erreur (RE) en cas d’anomalie.
• Notifications IRS : parsing des notifications ICMM (Publication 5189) retournées à la DGI puis à l’IF ; orchestration automatique des corrections (FATCA 2 ou FATCA 3+1).
• Change-of-status tracking : alertes et re-classification automatique.
• Rapports de management (réconciliation, exceptions, volumétries).

4.3.4 Règles de gestion spécifiques (conformes au cahier des charges DGI Tunisie, v3.7-2019)

• RG1 — Adresses : choix AddressFix (structuré) ou AddressFree (texte libre) selon la qualité des données ; parsing automatique pour maximiser AddressFix.
• RG2.1 — TIN / Matricule Fiscal titulaire :
  • Si TIN inconnu et titulaire = personne physique → série de neuf « A » (AAAAAAAAA).
  • Si TIN inconnu et titulaire = EENF passive (AccountHolderType = FATCA102) → série de neuf « 0 » (000000000).
  • Si TIN inconnu et personne américaine contrôlant une EENF passive → neuf « A ».
• RG2.2 — GIIN de l’IF déclarante : obligatoire, délivré par l’IRS (un GIIN par matricule fiscal).
• RG2.3 — FilerCategory (catégorie déclarative) : codification configurable
  • Bloc ReportingFI : FATCA601 (IF étrangère participante), FATCA602 (deemed-compliant enregistrée), FATCA603 (succursale limitée), FATCA604 (SANSOBJET IGA 2), FATCA605 (QI / WP / WT), FATCA610 (withholding agent), etc.
  • Bloc Sponsor : seule valeur possible FATCA607.
• RG3 — Titulaire du compte : identification complète (MF, nom, prénom, adresse, date de naissance) ; si prénom indisponible → valeur NFN.
• RG4 — Compte / contrat : codification du numéro via OECD601 (IBAN), OECD602 (OBAN), OECD603 (ISIN), OECD604 (OSIN), OECD605 (autre) ; NANUM si aucun numéro ; génération d’un bloc 2.6 par compte et par co-titulaire américain.
• RG5 — Sommes et valeurs :
  • Comptes à déclarer : nouveaux (≥ 01/12/2014) + préexistants haute valeur + préexistants faible valeur identifiés (périmètre configurable par IGA national).
  • Solde au 31/12 de l’exercice (ou à la clôture si fermé en cours d’année).
  • Montants en centièmes de la devise (séparateur « . »).
• RG6 — Constitution des fichiers : un fichier = une IF déclarante + un exercice (un seul ReportingFI et un seul ReportingPeriod par fichier).
• RG7 — Déclaration néant : support du bloc NilReport (ajouté en schéma v2.0) pour IF sans compte déclarable.

4.3.5 Templates régionaux

Livrés prêts à l’emploi pour les juridictions prioritaires :

• Tunisie : FATCA XML v2.0 format DGI (cahier des charges V1.0-2019, schéma V3.7) + NilReport + rapports internes BCT format circulaires 06/2025.
• France : reporting Bercy (DGFiP) pour FATCA et CRS.
• Allemagne : BaFin + BZSt (Bundeszentralamt für Steuern) XML.
• Belgique : FPS Finance.
• Espagne : AEAT.
• UAE : Ministry of Finance.
• Égypte : Egyptian Tax Authority.
• IRS direct : pour banques ayant un QI Agreement (modèle IGA 2).

4.4 Case management & workflow (transverse aux 3 modules)

• Workflow builder no-code / low-code — à la Persona / Sumsub — avec règles, branches, escalade, SLA configurables par tenant.
• Queue back-office agent — assignation manuelle ou automatique, SLA par priorité, commentaires, pièces jointes, chat interne.
• Journalisation immutable (WORM + hash chain) — piste d’audit complète, export SIEM.
• Entretien client intégré — vidéo, planification, enregistrement, résumé automatique (GenAI optionnel, désactivable par conformité).
• Gestion des versions de dossier — historique de chaque modification.

4.5 Reporting, analytics & audit

• Tableaux de bord KPI : conversion onboarding, drop-off par étape, auto-approval rate, fraud rate, volumes, SLA agents, coûts par vérification.
• Rapports réglementaires : tous les templates de la section 4.3.4, plus BCT 06/2025, 2017-08, CRF.
• Rapports opérationnels : volumes, délais, exceptions, cas en back-office.
• Exports : CSV, PDF, XML, API.
• Export SIEM : Syslog CEF, Splunk HEC, Elastic (integration standard).

---

5. Architecture logique et licensing modulaire

5.1 Découpage fonctionnel en modules

5.2 Modules, sous-modules et add-ons

Module	Sous-modules inclus	Add-ons facturables séparément
KYC	Form Designer (parcours configurable no-code, MVP) ; KYC-P (individu), KYB (entreprise, avec connecteur RNE Tunisie), OCR, liveness, face match, proof of address	NFC eMRTD ; VideoKYC agent live ; Biométrie vocale (roadmap) ; Connecteurs registres souverains premium
AML	Screening sanctions / PEP / adverse media, ongoing monitoring, risk scoring	Transaction monitoring ; STR / SAR generation ; ML typologies
TCR (Tax Compliance & Reporting)	Classification fiscale client, indicia detection, formulaires W-8BEN / W-8BEN-E / W-9, reporting FATCA (IRS 8966 XML), reporting CRS (OECD XML), templates régionaux standards (Tunisie, France)	Templates régionaux premium (multi-pays) ; QI Agreement support ; Retenues à la source (withholding tax) ; DAC6 reporting (UE)

5.3 Licensing technique

• Chaque module expose un identifiant (module_id) et un ensemble de features (feature_flags) activables.
• Clé de licence signée (Ed25519) délivrée par un serveur de licence VitaKYC, contenant :
  • tenant_id (ou installation_id pour on-prem)
  • Liste des modules activés + features
  • Date d’expiration
  • Volumétrie maximale (checks/mois) par module
  • Mode de déploiement (SaaS / on-prem)
• Vérification de la licence à chaque appel API (cache 5 min) en SaaS, et au démarrage + check périodique (phone-home optionnel) en on-prem.
• Activation / désactivation à chaud d’un module sans redéploiement (flag en base + cache invalidation).

5.4 Isolation des données par tenant

• SaaS multi-tenant : tenant_id en clé primaire logique sur chaque table ; chiffrement per-tenant (clé KMS par tenant) ; segmentation réseau au niveau service mesh.
• SaaS dédié : même base de code, infrastructure dédiée (cluster K8s isolé).
• On-prem : single-tenant nativement, le tenant_id devient trivial.

---

6. Architecture technique et stack recommandé

🧭 Cette section est une recommandation d’architecte, pas une injonction. Les choix doivent être validés par l’équipe technique à partir des compétences internes et de contraintes spécifiques (licences, contrats cloud, etc.).

6.1 Principes directeurs

1. Un seul codebase, deux modes de déploiement — même image OCI, même Helm chart, ce qui varie = configuration et chart values.
2. API-first, event-driven — chaque interaction passe par l’API publique ou des événements internes (bus de messages) ; la plateforme s’auto-consomme.
3. Microservices à granularité raisonnable — éviter l’écueil Tier-1 (centaines de micro-services). Viser ~10-15 services cohérents (par domaine métier).
4. Données chiffrées par défaut — au repos (AES-256), en transit (TLS 1.3), clés gérées par KMS externe (AWS KMS / GCP KMS / HashiCorp Vault selon déploiement).
5. Observabilité native — OpenTelemetry, Prometheus, Grafana, Loki (ou Splunk/Datadog selon client).
6. Portabilité — pas de lock-in cloud provider ; tout composant doit avoir un équivalent on-prem.

6.2 Stack recommandé

Couche	Recommandation	Alternatives acceptables	Justification
Backend services métier	Java 21 + Spring Boot 3.x ou Kotlin + Spring Boot 3.x	Node.js 22 + NestJS ; Go 1.22 + chi/echo	Écosystème bancaire mature, recrutement facile en Tunisie/MENA, JVM = stabilité et outillage enterprise (audit, monitoring, profilage). Kotlin recommandé pour concision.
Services IA / ML (OCR, liveness, face match)	Python 3.12 + FastAPI + modèles ONNX Runtime ou TensorRT	Triton Inference Server	Python = écosystème ML dominant. ONNX = portabilité modèle (GPU et CPU on-prem). FastAPI = performance et typage.
Frontend back-office	React 18 + TypeScript 5.x + Vite + TanStack Query + Tailwind + shadcn/ui	Next.js 14 (si SSR nécessaire) ; Vue 3	React = bassin de talents, ergonomie, écosystème composants. TanStack Query = state serveur propre. Tailwind + shadcn = design system maintenable.
SDK mobile	Kotlin (Android natif) + Swift (iOS natif) + React Native wrapper pour distribution cross-platform aux clients	Flutter wrapper si demande spécifique	Natif = accès aux APIs sensibles (NFC, caméra, secure enclave). Wrapper RN/Flutter = coût intégration réduit pour clients.
SDK Web	TypeScript + Web Components (standards W3C) + bundle ESM + UMD	JS vanilla simple pour sites legacy	Web Components = intégration sans contrainte de framework côté client.
Base de données principale	PostgreSQL 16 (chiffrement transparent via TDE ou disque, extension pgaudit)	Oracle 21c (si imposé par un client banque) ; SQL Server (si imposé)	PostgreSQL = open-source, robuste, extensions (pgvector pour embeddings, PostGIS, pgcrypto). L’AO La Poste Tunisienne liste explicitement Oracle / SQL Server / PostgreSQL — VitaKYC doit supporter au moins PostgreSQL nativement et Oracle/SQL Server en option on-prem.
Stockage documents	S3-compatible : AWS S3 / GCS en SaaS, MinIO en on-prem	Azure Blob si client Microsoft	Même API, portabilité totale. Chiffrement SSE-KMS.
Moteur de workflow	Temporal.io (ou Camunda 8 Zeebe)	Cadence ; Flowable	Temporal = durabilité, retry natif, long-running workflows (idéal pour onboarding multi-étapes et ongoing monitoring).
Bus d’événements	Apache Kafka (Redpanda en on-prem léger)	NATS JetStream	Standard bancaire, exactly-once, retention configurable, audit.
Cache	Redis 7 (ou Valkey OSS)	Memcached	Pub/Sub + cache + rate limiting + locks distribués.
Recherche	OpenSearch (fork Elasticsearch)	Typesense ; Meilisearch	Recherche full-text multilingue (arabe), analytics, SIEM-ready.
Orchestration	Kubernetes (EKS / GKE en SaaS ; K3s ou OpenShift en on-prem)	Nomad (plus rare en banque)	Standard de fait.
API Gateway	Kong (OSS) ou Envoy	AWS API Gateway en SaaS	Rate limiting, auth, plugins.
IAM	Keycloak (OIDC / SAML / OAuth2)	Auth0 / Okta en SaaS	Keycloak = portable, SSO fédéré banques, open-source.
Signature électronique	Intégration DocuSign + alternative native via eIDAS QES (DocuSign, Yousign, Universign pour FR)	SignNow ; HelloSign	Pour W-8/W-9, onboarding banque, QES pour UE.
OCR engines	Combinaison Tesseract 5 (open-source, baseline) + modèles custom ONNX fine-tunés + fallback commercial (Veryfi, Mistral OCR, Google Vision) paramétrable	—	Indépendance + précision. Modèles arabe spécifiques.
Liveness / Face match	Modèles propriétaires (roadmap) + fallback commercial iProov, FaceTec, ou modèle open équivalent certifié iBeta	—	Build+buy hybride pour démarrer, puis internaliser en V2.
Observabilité	OpenTelemetry + Prometheus + Grafana + Loki (logs) + Tempo (traces)	Datadog / New Relic en SaaS si demandé	Stack OSS, portable.
CI/CD	GitHub Actions ou GitLab CI + ArgoCD (GitOps)	Jenkins (legacy)	Déploiement auditable, GitOps.
Infrastructure as Code	Terraform + Helm	Pulumi	Standard.
Secrets	HashiCorp Vault (ou cloud KMS)	Kubernetes Sealed Secrets	Rotation automatique.

6.3 Justification du choix Java/Kotlin + Spring Boot

Quatre raisons objectives pour VitaKYC :

1. Bassin de compétences MENA — en Tunisie, au Maroc, en Égypte, Java reste la stack dominante des SSII bancaires et des écoles d’ingénieurs. Recrutement plus rapide et moins cher que Go ou Rust.
2. Écosystème bancaire — les clients banque attendent une stack “sérieuse” : JVM + Spring = crédibilité immédiate en RFP. Outillage mature pour audit, profilage, monitoring, security scanning.
3. Portabilité — JVM tourne partout (Linux, Windows Server, AIX pour certains clients historiques), se package en image OCI, n’impose pas de choix d’OS aux clients on-prem.
4. Librairies FATCA/XML — l’écosystème JAXB + JAXP + validation XSD est le plus mature pour générer les XML IRS 8966 et OECD CRS. Node.js et Python sont viables mais moins outillés côté validation stricte XSD.

6.4 Architecture cible — vue macro

                    Internet / Intranet client
                              │
                              ▼
                    ┌──────────────────┐
                    │   WAF + CDN      │  (Cloudflare en SaaS ; F5/NGINX en on-prem)
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │   API Gateway    │  (Kong)
                    │ (authN, rate lim)│
                    └────────┬─────────┘
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
          ▼                  ▼                  ▼
  ┌────────────┐    ┌────────────┐    ┌────────────┐
  │  KYC API   │    │  AML API   │    │ FATCA API  │  ← microservices métier
  │ (Kotlin +  │    │ (Kotlin +  │    │ (Kotlin +  │    (JVM + Spring Boot)
  │  Spring)   │    │  Spring)   │    │  Spring)   │
  └──────┬─────┘    └──────┬─────┘    └──────┬─────┘
         │                 │                 │
         └────────┬────────┴────────┬────────┘
                  │                 │
                  ▼                 ▼
         ┌──────────────┐    ┌──────────────┐
         │   Workflow   │    │   Event bus  │
         │  (Temporal)  │    │   (Kafka)    │
         └──────┬───────┘    └──────┬───────┘
                │                   │
                ▼                   ▼
  ┌────────────────────────────────────────────────┐
  │           Services IA / ML (Python)            │
  │  OCR │ Liveness │ Face match │ Voice │ NLP AML │
  │            (FastAPI + ONNX Runtime)            │
  └────────────────────────────────────────────────┘
                  │
                  ▼
  ┌────────────────────────────────────────────────┐
  │              Couche données                   │
  │ PostgreSQL │ MinIO/S3 │ Redis │ OpenSearch     │
  │         (chiffrement AES-256 + KMS)           │
  └────────────────────────────────────────────────┘
                  │
                  ▼
         ┌──────────────────┐
         │  Observabilité   │
         │  OTEL + Prom +   │
         │  Grafana + Loki  │
         └──────────────────┘

6.5 Résumé de l’avis d’architecte demandé

La recommandation nette est la suivante :

• Backend en Kotlin + Spring Boot 3 pour les services métier, Python + FastAPI + ONNX Runtime pour les services IA, React + TypeScript pour le back-office, SDK mobiles natifs (Kotlin Android + Swift iOS) + wrapper React Native.
• PostgreSQL en base principale avec support Oracle en option contractuelle (pour banques imposant Oracle), MinIO / S3 pour documents, Temporal pour les workflows, Kafka comme backbone événementiel.
• Kubernetes partout — EKS / GKE en SaaS, K3s ou OpenShift en on-prem selon préférence client.
• Keycloak pour l’IAM, HashiCorp Vault pour les secrets, OpenTelemetry pour l’observabilité.

Ce stack est portable, auditable, recrutable en MENA, et compatible avec les contraintes on-prem des banques régulées. Il évite les écueils suivants :

• ❌ Choisir une stack trop trendy (Rust, Deno, Bun) qui pénalisera le recrutement MENA.
• ❌ Choisir une stack full SaaS cloud-locked (AWS Lambda + DynamoDB) qui rendrait l’on-prem impossible.
• ❌ Choisir une stack trop fragmentée (microservices par domaine + polyglotte massif) qui alourdira le TCO.

---

7. Modèle de déploiement hybride SaaS + On-Premise

7.1 Les deux modes cibles

Mode A — SaaS multi-tenant (cloud VitaKYC)

• Hébergement dans un cloud public (AWS / GCP / Azure, une région MENA + une région UE obligatoires : AWS Bahrain + Frankfurt, ou GCP Tel-Aviv + Paris).
• Isolation logique par tenant_id, chiffrement par tenant.
• Multi-région en actif-actif pour HA.
• SLA disponibilité 99,9 % cible.

Mode B — SaaS dédié (cloud privé client)

• Cluster K8s dédié pour le client, même base de code, mêmes images.
• Hébergement sur infrastructure client (AWS Account client, Azure Subscription client, OVH privé, etc.) ou sur un cloud provider tiers.

Mode C — On-premise (datacenter client)

• Installation sur Kubernetes du client (OpenShift ou K3s) OU sur VMs via Ansible si K8s non disponible.
• Supporte Windows Server ou Linux (contrainte AO La Poste Tunisienne).
• Bases de données : PostgreSQL, Oracle, SQL Server (contrainte AO La Poste Tunisienne).
• Connexion Internet non requise en fonctionnement nominal.
• Phone-home optionnel pour mises à jour de listes AML (ou mise à jour par fichier signé, mode air-gap).

7.2 Principes de design hybride

1. Même code, même version — un client on-prem doit exécuter la même release numérotée que le SaaS (avec retard maximal 30 jours).
2. Mêmes artefacts — images OCI signées (cosign), Helm chart, manifests K8s, scripts Ansible pour VM fallback.
3. Configuration externalisée — tout ce qui varie (endpoints cloud / self, secrets, résidence données, connecteurs) via variables d’environnement + ConfigMap + Helm values.
4. Dépendances minimales — seuls les composants OSS (PostgreSQL, Kafka, Redis, OpenSearch, MinIO, Keycloak) sont requis ; aucun cloud-specific SDK en chemin critique.
5. Opérabilité par l’équipe du client — runbooks, observabilité, alerting livrés ; formation ops dédiée.

7.3 Matrice de fonctionnalités SaaS vs On-Prem

Fonctionnalité	SaaS	On-Prem	Notes
KYC / AML / TCR core	✓	✓	Identique
Listes AML (sanctions, PEP, adverse media)	✓ auto-update	✓ via fichier signé ou phone-home	Air-gap supporté
Templates reporting régionaux	✓	✓	Livrés dans les releases
Mise à jour automatique	✓	✗ (manuelle)	Client on-prem fait ses maintenances
Multi-région DR	✓	À la charge du client	Guide fourni
Scalabilité élastique	✓	Limitée à l’infrastructure client	—
Support 24/7	✓ option	✓ option	SLA selon contrat
Accès au code source	✗	✗ (sauf escrow contractuel)	Images OCI uniquement

---

8. Exigences non-fonctionnelles

8.1 Performance

Indicateur	Cible
Latence API (P95)	< 300 ms (hors calls IA)
Latence OCR document	< 2 s par document
Latence liveness passif	< 1,5 s
Latence face match	< 500 ms
Temps de décision KYC automatique (P50)	< 30 s bout-en-bout
Throughput plateforme	≥ 100 onboardings / minute / tenant en SaaS

8.2 Disponibilité et robustesse

Indicateur	Cible
Disponibilité SaaS	99,9 % (43 min downtime/mois max)
RPO (Recovery Point Objective)	< 5 min
RTO (Recovery Time Objective)	< 30 min
Sauvegardes	Incrémentales horaires + full quotidiennes, rétention 90 j + 1 an archivé

8.3 Scalabilité

• SaaS : scaling horizontal auto (HPA) sur services stateless, jusqu’à 1 M vérifications/jour/tenant.
• On-prem : dimensionnement recommandé livré en fonction du volume (3 / 10 / 50 nœuds types).

8.4 Auditabilité

• Journalisation WORM (Write Once Read Many) de toute action (user, agent, API).
• Hash chain pour détection de modification a posteriori.
• Export SIEM (CEF / Syslog).
• Rétention minimale 10 ans (LAB/FT).

---

9. Conformité réglementaire multi-juridictions

9.1 Paramétrage par tenant

Chaque tenant configure les juridictions applicables parmi :

• Tunisie (BCT 2025-06, 06/2025, 2017-08 ; loi 2015-26 / 2019-9)
• France (AMF, ACPR, ANSSI PVID, GDPR)
• Allemagne (BaFin, GwG, GDPR)
• Espagne (SEPBLAC, GDPR)
• Italie, Portugal, Belgique, Pays-Bas (adaptations locales CRS + AML)
• UAE (CB UAE, DIFC, ADGM, Law 10/2025)
• Égypte (CBE, AML Law 80/2002)
• Maroc, Algérie (selon disponibilité templates)
• Liban (Banque du Liban, sanctions OFAC spécifiques)
• International : FATF, OECD CRS, FATCA IRS

9.2 Règles de conformité activables

• Niveau de diligence (simplifié, standard, renforcé).
• Documents minimum par type de client (résident, non-résident, entité).
• Durée de conservation par type de donnée.
• Format et destinataire des reportings.

9.3 Preuves auditables

• Piste d’audit par client : qui a validé quoi, quand, sur quel critère.
• Traçabilité des versions de règles (un changement de règle ne réécrit pas les anciennes décisions).
• Export PDF audité signé horodaté (pour contrôleurs BCT, AMF, BaFin).

---

10. Sécurité et protection des données

10.1 Certifications cibles

Certification	Priorité	Horizon
ISO 27001	Must	V1 (M+12)
ISO 27701	Should	V2 (M+18)
SOC 2 Type I	Must	M+9
SOC 2 Type II	Must	M+18
PCI DSS (si paiement)	Conditionnel	Selon demande client
iBeta ISO/IEC 30107-3	Must (pour liveness)	M+12
ANSSI PVID (France)	Should	V2 (M+18)
BaFin-compliant VideoIdent	Should	V2 (M+18)

10.2 Principes sécurité

• Zero Trust by default : mTLS service-à-service (Istio ou Linkerd), OIDC pour utilisateurs, tokens courts (15 min).
• Chiffrement : AES-256 au repos, TLS 1.3 en transit, clés rotées 90 jours via KMS.
• Gestion des secrets : HashiCorp Vault, pas de secret en clair dans Git ni en ConfigMap.
• Pen-tests : annuels externes + continuous bug bounty (HackerOne ou YesWeHack).
• Dépendances : SBOM (Software Bill of Materials) généré à chaque release ; scan Trivy / Grype sur images.
• RBAC + ABAC : rôles standards (agent, superviseur, admin, auditeur) + contrôle d’accès basé sur attributs (département, juridiction).
• MFA obligatoire pour utilisateurs back-office ; SSO fédéré (SAML, OIDC) pour clients enterprise.

10.3 Protection des données personnelles

• Privacy by design : minimisation des données, pseudonymisation dès que possible.
• Résidence des données : configurable par tenant (UE, Tunisie, UAE, …).
• Droits des personnes concernées (GDPR) : accès, rectification, effacement, portabilité, opposition — implémentés nativement.
• DPA (Data Processing Agreement) type, fourni à chaque client.
• Registre des traitements : livré par défaut, adapté au client.

---

11. UX, accessibilité, multilingue

11.1 Principes UX

• Parcours individu < 3 minutes, ≤ 5 écrans en cas nominal.
• Taux de drop-off cible < 15 % sur le parcours complet (hors échecs documentaires).
• White-label complet : logo, couleurs, domaine, emails, PDFs.
• Mobile-first : 70 % du trafic mondial est mobile sur onboarding.
• Accessibilité : WCAG 2.1 AA minimum ; tests avec NVDA, VoiceOver, contraste.

11.2 Multilingue

• Langues de première classe au lancement : arabe (RTL), français, anglais.
• V1 : espagnol, allemand.
• V2 : portugais, italien, turc.
• L’arabe est RTL-first : la conception est pensée dès le départ pour la direction droite-gauche, non une simple inversion CSS.
• Support de chiffres hindi en option pour affichage (formulaires gouvernementaux égyptiens notamment).

11.3 Prévention du drop-off

• Sauvegarde de l’état à chaque étape (reprise sur un autre device).
• Hints contextuels dynamiques (ex : détection floue → guide recapture).
• Feedback temps réel sur la qualité d’image document.
• Simulation offline du parcours (démo publique).

---

12. Intégrations et API

12.1 API REST publique

• OpenAPI 3.1 documentée.
• Versioning par URL (/v1/, /v2/).
• Idempotency keys sur les opérations d’écriture.
• Rate limiting par clé API et par tenant.
• Webhooks signés (HMAC + timestamp) pour notifications (décision KYC, alerte AML, rapport généré).

12.2 SDK

• Web (TypeScript, Web Components, bundle ~150 KB gzipped cible).
• iOS (Swift Package Manager).
• Android (Gradle + Maven Central).
• React Native wrapper.
• Flutter wrapper (roadmap V2).

12.3 Connecteurs pré-packagés

Catégorie	Connecteurs prioritaires
Registres officiels & référentiels souverains (Tunisie)	RNE (Registre National des Entreprises — services KYC + UBO) ; IDES / DGI Tunisie (plateforme de dépôt FATCA — voir §12.3.3) ; INSAF (identification employeurs CNSS — accès conditionnel) ; portail BCT online (consultations individuelles autorisées)
Registres officiels (International)	Infogreffe / INPI (France), Handelsregister (Allemagne), Registro Mercantil (Espagne), Companies House (UK), UAE trade license / AECB, CBE business registry (Égypte)
Core banking	Temenos T24, Finastra Fusion, Oracle Flexcube, Sopra Amplitude
CRM	Salesforce Financial Services Cloud, Microsoft Dynamics 365
Case management	ServiceNow
Identity	Okta, Auth0, Keycloak, Azure AD
e-Signature	DocuSign (international) ; Yousign, Universign, Signaturit (France / UE) ; TunTrust / ANCE (Tunisie, QES loi n°2000-83)
Data enrichment	Dun & Bradstreet, Creditsafe, Refinitiv World-Check, Dow Jones Risk, LSEG, LexisNexis
Telecom (MENA)	Ooredoo, Tunisie Telecom, Orange Tunisie, Etisalat, du (pour HLR lookup)

12.3.1 Connecteur RNE (Registre National des Entreprises — Tunisie)

Deux web services officiels de la plateforme RNE api.registre-entreprises.tn:8243, consommés par le connecteur connector-rne de VitaKYC.

Cadre contractuel & légal

• Accès sur contrat d’abonnement auprès du RNE (contact interop@e-rne.tn, +216 70 248 162, responsable M. Tarek Dhifi).
• Cadre légal : loi organique n°22-2016 du 24 mars 2016 (droit d’accès à l’information) + législation anti-terrorisme tunisienne.
• Consommation unitaire décomptée sur un solde d’abonnement (erreur 400 « Le solde disponible est insuffisant » si épuisé).
• Contrôle d’IP source par le RNE (erreur 400 « Adresse IP non autorisé »). Chaque tenant VitaKYC doit déclarer l’IP de sortie de son instance (SaaS : IP sortante VitaKYC ; on-prem : IP sortante du client).

Authentification

• Authorization: Bearer <token> — Bearer Token délivré en privé par le RNE lors de la souscription.
• Stockage VitaKYC : HashiCorp Vault, un secret par tenant, rotation supportée.

12.3.1.1 Service WS-KYC — fiche entreprise

GET /WS-KYC/1?subscriptionId={id}&subscriberId={id}&identifiantUnique={id_entreprise} HTTP/1.1
Host: api.registre-entreprises.tn:8243
Authorization: Bearer <token>

• Paramètres :
  • subscriptionId (entier, obligatoire) — identifiant d’abonnement
  • subscriberId (entier, obligatoire) — identifiant utilisateur
  • identifiantUnique (string, 7 chiffres + 1 lettre, obligatoire) — identifiant RNE de la personne morale ou physique
• Format de retour : JSON structuré en 4 blocs :
  • Fiche Entreprise : identifiant_UNIQUE, num_REGISTRE_INTERNE, denomination_AR/FR, nom_COMMERCIAL_AR/FR, enseigne_AR/FR, STATUS (Normal / RADIE_PROVISOIREMENT / RADIE_DEFINITIVEMENT), type_ENTITE (P=Personne Physique / M=Personne Morale), auto_ENTREPRENEUR, categorie (A=Association / S=Société / E=Établissement public pour PM ; A=Artisan / C=Commerçant / M=Métier libérale pour PP), capital_TND (NUMBER 30,3), dernier_BILAN_DEPOSE, adresse_EMAIL, date_DEBUT_ACTIVITE, date_CLOTURE_EXERCICE, date_ENREGISTREMENT_RNE, date_PUBLICATION_BORNE, date_RADIATION, date_DERNIERE_MAJ, declaration_BENEFICIAIRES_EFFECTIFS (Oui/Non), forme_Juridique_AR/FR, situation_JURIDIQUE_AR (CLOB), nature_MODIFICATIO_AR/FR, adresses siège + activité (gouvernorat / ville / rue / code postal, AR + FR), nature_ASSOCIATION, object_ASSOCIATION_AR/FR, objectifs_ASSOCIATION_AR/FR.
  • Activités : primaryActivity + secondaryActivities[] avec codeActivite (norme NAT 1996), detailActiviteArabe, detailActiviteLatin.
  • Direction (tableau) : IDENTIFIANT_UNIQUE_GESTION, NUM_PIECE_IDENTITE_GESTION, DATE_PIECE_IDENTITE_GESTION, NOM_PRENOM_GESTION_AR/FR, NOM_GESTION_AR/FR, PRENOM_GESTION_AR/FR, GENRE_GESTION, NATIONALITE_GESTION_AR/FR, DATE_NAISSANCE_GESTION, PAYS_NAISSANCE_GESTION_AR/FR, QUALITE_GESTION_AR/FR (ex : Commissaire aux Comptes, Directeur Général), STATUTAIRE, DATE_NOMINATION, DATE_FIN_NOMINATION, adresse gestion (rue / ville / gouvernorat / CP, AR + FR).
  • Pouvoirs (tableau) : LIBELLE_POUVOIR_AR/FR (ex : Représentant légal, Pouvoir étendu).
• Exceptions métier (HTTP 400) :
  • « Le solde disponible est insuffisant pour effectuer cette opération. »
  • « Identifiant Unique non associé à une entité active dans la base de données RNE »
  • « Aucune inscription correspondant à l’identifiant fourni n’a été trouvée. »
  • « L’abonné n’est pas autorisé : il n’est pas répertorié parmi les abonnés associés à cet abonnement. »
  • « Adresse IP non autorisé ! »
  • « L’inscription à cet abonnement est inactive et ne peut pas être utilisée. »
• Exception HTTP 404 : « Not Found ».

12.3.1.2 Service WS-BE — bénéficiaires effectifs

GET /WS-BE/1?subscriptionId={id}&subscriberId={id}&codeMotif={motif}&identifiantUnique={id} HTTP/1.1
Host: api.registre-entreprises.tn:8243
Authorization: Bearer <token>

• Paramètre supplémentaire : codeMotif (entier, obligatoire) — motif de consommation du service, attribué par le RNE selon l’usage déclaré (KYC banque, KYC assurance, etc.).
• Format de retour : JSON (un élément ou tableau selon la PM) :
  • IDENTIFIANT_UNIQUE, NUM_DECLARATION, DENOMINATION_AR/FR
  • TYPE_BENFICIAIRE ∈ {Détention du Capital (détention > 20 %), Gestion (membre de direction), Pouvoir (possession ou contrôle)}
  • NP_PERSONNE (nom+prénom AR), NP_PERSONNE_FR
  • NATIONALITE, NID_PERSONNE (numéro identité), RESIDENT (Résident / Non Résident)
  • CAPITAL_DIRECT (%), CAPITAL_INDIRECT (%), DROIT_VOTE (%)
  • DATE_DECLARATION, DATE_DEBUT_ETRE_BENEFICIAIRE
  • STATUS (ACTIF / INACTIF)
• Cas « pas de déclaration » : HTTP 200 avec message « Cette entité ne possède pas de déclaration de bénéficiaire Effectif. » → le workflow KYB enregistre l’absence de BE et peut demander une déclaration manuelle complémentaire.
• Exception supplémentaire : « Ce motif WS Be n’a pas été trouvée dans le système ! » si codeMotif invalide.

12.3.1.3 Implémentation VitaKYC

• Service connector-rne (Kotlin + Spring Boot), exposé en interne uniquement.
• Cache Redis TTL 24 h par identifiant ; invalidation manuelle via API admin du tenant.
• Rate limiting côté VitaKYC (200 req/min par tenant par défaut) pour protéger le solde RNE.
• Circuit breaker (Resilience4j) : après 5 erreurs 5xx en 60 s, bascule en mode dégradé fallback.
• Fallback documentaire : si 5xx persistant ou solde insuffisant, le dossier KYB passe en branche « capture manuelle de l’extrait RNE + OCR » avec notification agent.
• Mapping vers le modèle VitaKYC (cf. architecture technique §5.2.2) :
  • kyc_business.rne_id ← identifiant_UNIQUE
  • kyc_business.legal_name ← denomination_FR
  • kyc_business.legal_form ← forme_JURIDIQUE_FR
  • kyc_business.capital_amount ← capital_TND
  • kyc_business.capital_currency ← “TND”
  • kyc_business.registration_number ← num_REGISTRE_INTERNE
  • kyc_business.status ← mapping STATUS → active|suspended|closed
  • Direction → kyc_business_officer[] (pour screening AML)
  • BE → kyc_business_ubo[] (pour screening AML + traçabilité compliance)
• Traçabilité : chaque appel logué dans audit_event avec rne_request_id, subscription_id, subscriber_id, status_code, response_hash.
• Horizon 2026 : au second semestre 2026, le RNE bascule vers des services 100 % en ligne (DIGIGO pour personnes morales, MobileID pour individus). VitaKYC devra adapter le schéma et les contrats d’API en conséquence.
• Documentation de référence : home.registre-entreprises.tn/echange_des_donnees + Annexe 2 — Description du web service KYC et Annexe 2 — Description du web service de consultation d’une déclaration du Bénéficiaire Effectif (fournies par le RNE).

12.3.2 Connecteur IDES / DGI Tunisie (dépôt FATCA)

• Nature : la DGI tunisienne (Direction Générale des Impôts — Unité des recoupements, de l’échange international de renseignements, de la programmation et de la gestion des risques — 25 avenue Kheireddine Pacha, 1073 Tunis) exploite la plateforme IDES (ides.finances.gov.tn), service en ligne officiel de dépôt FATCA. Accessible aussi via www.impots.finances.gov.tn > Services en ligne > FATCA TUNISIE.
• Cadre légal : Accord intergouvernemental (IGA Model 1) signé entre la Tunisie et les États-Unis le 13 mai 2019 + article 17 bis du CDPF (ajouté par l’article 38 de la loi de finances n°2016-78 du 17 décembre 2016). Pénalités : 1 000 à 20 000 TND + 100 TND par information manquante ou erronée, doublée dès la 2ᵉ constatation.
• Pré-requis opérationnels pour l’IF cliente :
  1. Inscription de l’IF auprès de l’IRS → obtention d’un GIIN (un GIIN par matricule fiscal).
  2. Désignation officielle d’un interlocuteur unique auprès de la DGI via courrier.
  3. Obtention d’un certificat électronique ANCE (Agence Nationale de Certification Électronique) pour chaque interlocuteur unique.
  4. Authentification IDES : login = matricule fiscal de l’IF déclarante + mot de passe délivré par la DGI.
• Fonctionnalités du connecteur VitaKYC :
  • Génération du fichier FATCA XML v2.0 conforme (§4.3.3-4.3.4) avec nommage <MatriculeFiscal>-<exercice>.xml (réel) ou -<exercice>-Test.xml (environnement test IDES).
  • Compression GZIP optionnelle (fichiers > seuil configurable, 100 Mo max avant compression).
  • Dépôt automatisé sur IDES (option, sous mTLS + certificat ANCE) ou export pour dépôt manuel via le portail DGI (mode par défaut recommandé).
  • Récupération et archivage de l’Accusé de Dépôt (AD) avec horodatage, référence DGI et empreinte SHA calculée côté DGI.
  • Récupération et parsing du Compte-Rendu d’erreur (RE) en cas de rejet (erreurs CF01-CF15 fichier, CV01-CV02 validation XSD, CM01 DocRefID invalide) avec remédiation guidée côté back-office VitaKYC.
  • Support du chaînage des déclarations correctives (FATCA 2 sur notification IRS, FATCA 3 annulation, FATCA 4 modification) avec séquencement automatique (ex : FATCA 3 avant FATCA 1 de réémission, avec délai minimal aligné sur le calendrier DGI → IRS).
  • Support du NilReport (déclaration néant) pour IF sans compte déclarable.
  • Suivi du calendrier réglementaire : phase de test, phase de dépôts initiaux, phase de dépôts correctifs, jalons de transmission DGI → IRS (fenêtres annuelles rappelées dans le cahier des charges DGI).
  • Parsing des notifications ICMM (Publication IRS 5189) retournées à la DGI puis à l’IF ; orchestration automatique des corrections.
• Assistance DGI : DGI, Unité des recoupements, 25 Av. Kheireddine Pacha, 1073 Tunis. Support technique DGI/CIMF pour anomalies de transmission.
• Références documentaires : « Transfert d’informations en application de la loi FATCA par procédé informatique » — Cahier des charges V1.0-2019 (DGI Tunisie) + Cahier des Charges FATCA XML V3.7 (01/02/2019) ; IRS Publication 5124 FATCA XML Schema v2.0 User Guide ; IRS Publication 5189 ICMM Notification User Guide. Fichier source local : Cahier_des_charges-1.pdf.

12.4 Open API publique pour partenaires

• Marketplace de workflows partageables entre tenants (opt-in).
• SDK tiers documentés pour étendre les règles.

---

13. Modèle tarifaire et licensing commercial

13.1 Structure tarifaire

Trois paliers principaux + un palier régulé.

Plan	Cible	Déploiement	Tarif indicatif
Starter	Fintech early-stage, faible volume	SaaS multi-tenant	Self-serve, à partir de ~0,50 $/check (modules KYC + AML basiques), fee mensuel plateforme minime
Growth	Fintech scale-up, néobanque, assurance mid	SaaS multi-tenant	Subscription plateforme + tiered per-check dégressif ; FATCA/CRS en add-on
Enterprise	Banque mid / large, assurance large	SaaS dédié ou on-prem	Licence annuelle + subscription + per-check ; modules à la carte ; support 24/7
Regulated On-Prem	Banque publique, client à contrainte souveraineté (ex : type La Poste Tunisienne)	On-prem exclusif	Licence perpétuelle ou annuelle + maintenance 3 ans renouvelable + services d’intégration

13.2 Transparence

• Pricing public pour Starter et Growth (à la Shufti Pro / Persona) : calculette en ligne, tarif par module.
• Enterprise sur devis avec grille interne de référence cohérente.

13.3 Licensing modulaire

• Chaque module (KYC, AML, TCR) est un SKU indépendant.
• Add-ons (VideoKYC, NFC, Biométrie vocale, Transaction Monitoring premium, Templates régionaux premium) = SKUs séparés.
• Le client peut ajouter / retirer des modules à chaque date anniversaire (SaaS) ou via avenant (on-prem).

13.4 Services professionnels

• Intégration (estimation 30-120 j/h selon périmètre).
• Formation : métier (5 j pour équipe de 10), technique (3 j pour équipe de 6) — aligné sur le référentiel AO La Poste Tunisienne.
• Maintenance évolutive en J/H (aligné marché : ~800-1 500 € J/H selon séniorité).
• Maintenance curative forfaitaire, avec SLA (24 h intervention sur incident bloquant).

---

14. Go-to-market et roadmap produit

14.1 Phasage produit

MVP — M0 à M6

• Modules : KYC (individu, OCR, liveness passif, face match, proof of address) + AML (screening sanctions/PEP/adverse media, ongoing monitoring basique).
• Déploiement : SaaS multi-tenant en AWS Frankfurt uniquement.
• Juridictions : Tunisie + France (templates BCT + AMF).
• Langues : français, anglais, arabe.
• SDK : Web + API REST.
• Objectif commercial : 3 clients pilotes dont 1 banque MENA (AO type), 1 fintech MENA, 1 assurance EU.

V1 — M6 à M12

• Modules : + KYB, + FATCA/CRS (reporting IRS 8966 + OECD CRS, templates Tunisie + France).
• Déploiement : ajout on-premise (image OCI + Helm + Ansible fallback), PostgreSQL + Oracle.
• Juridictions : + UAE, + Égypte, + Allemagne (BaFin AutoIdent style).
• SDK : + iOS + Android natifs.
• Langues : + espagnol.
• Licensing : activation modulaire opérationnelle, clé signée, mode air-gap on-prem.
• Certifications : ISO 27001 en cours, SOC 2 Type I acquis.
• Objectif commercial : 10 clients, 3 on-prem dont 1 AO public MENA remporté.

V2 — M12 à M24

• Modules : + VideoKYC agent live (BaFin + AMF PVID cibles), + NFC eMRTD, + Transaction Monitoring premium, + biométrie vocale.
• Liveness niveau 3 (anti-deepfake GenAI).
• Juridictions : + Maroc, + Liban, + Espagne SEPBLAC, + Portugal.
• Langues : + portugais, + italien, + allemand RTL complet.
• Certifications : SOC 2 Type II, ISO 27701, ANSSI PVID, iBeta.
• AI Document Agent (classification/extraction LLM, à la Fenergo 2025).
• Objectif commercial : 30 clients, 8 on-prem.

14.2 Go-to-market

• MENA : vente directe Tunisie / UAE + partenaires SSII bancaires locaux (ex : CCF, Axedom, Wevioo en Tunisie ; Emitac, Finesse en UAE).
• Europe du Sud/Est : vente via partenaires intégrateurs (Capgemini, Atos, SII, Sopra Banking) + équipe directe à Paris.
• Fintech : self-serve + inbound marketing (SEO, content), plus sales léger.
• Banque publique : réponse aux AO avec dossier type optimisé (le référentiel AO La Poste Tunisienne sera un gabarit interne).

14.3 Équipe recommandée à l’amorçage (M0-M12)

Fonction	FTE M0-M6	FTE M6-M12
Product Manager	1	1
Lead Tech / Architecte	1	1
Backend engineers (Kotlin / Python)	3	5
ML / Data engineer (OCR, biométrie)	1	2
Frontend engineer (back-office + SDK Web)	1	2
Mobile engineer (iOS + Android)	0	2
DevOps / SRE	1	2
Security engineer	0	1
QA / Test engineer	1	2
Compliance / Regulatory specialist	0,5	1
UX designer	1	1
Sales + CSM	1	3
Total	~10	~22

---

15. KPIs produit et success metrics

15.1 KPIs produit

Indicateur	Définition	Cible 12 mois
Auto-approval rate	% de dossiers décidés automatiquement sans intervention agent	≥ 85 %
False Acceptance Rate (FAR)	% de fraudeurs acceptés	≤ 0,05 %
False Rejection Rate (FRR)	% de bons clients rejetés	≤ 3 %
Drop-off rate	% d’abandons sur le parcours complet	≤ 15 %
Median time-to-decision	Temps médian de la décision KYC	≤ 60 s
SLA back-office	% de cas traités dans le SLA	≥ 95 %

15.2 KPIs business

Indicateur	Cible 12 mois	Cible 24 mois
Clients payants	10	30
ARR	1 M €	4 M €
NRR	≥ 110 %	≥ 120 %
NPS clients	≥ 40	≥ 50
% revenu modules ≥ 2	≥ 40 %	≥ 60 %
% revenu on-prem	≥ 25 %	≥ 35 %

---

16. Gouvernance projet et organisation

16.1 Cadence produit

• Releases : bi-hebdomadaires en SaaS ; trimestrielles packagées pour on-prem.
• Release notes : publiées publiquement (transparence vs concurrents opaques).
• Breaking changes API : préavis 6 mois minimum, deprecation headers.

16.2 Conseil consultatif

Constituer un Customer Advisory Board (3-5 personnes : 1 banquier MENA, 1 banquier EU, 1 fintech, 1 DPO, 1 regtech consultant) — se réunit trimestriellement.

16.3 Compliance officer interne

Rôle dédié à temps plein à partir de M+6 : veille réglementaire, mise à jour des templates, relations autorités (BCT, CNIL, BaFin, etc.).

---

17. Risques et plan de mitigation

Risque	Impact	Probabilité	Mitigation
Fonds de roulement insuffisant pour cycle AO public long	Élevé	Moyenne	Priorité à 2-3 deals fintech SaaS pour cash-flow court, puis AO avec appui banque/partenaire
Coût de certification ISO / SOC 2	Moyen	Élevée	Plan de provision dans le business plan, accompagnement cabinet spécialisé
Concurrence Sumsub / Onfido sur même deal	Élevé	Élevée	Différenciation on-prem + FATCA/CRS + MENA comme arguments décisifs
Modification réglementaire majeure (AMLA UE)	Moyen	Élevée	Veille continue, provision maintenance évolutive, rôle compliance officer
Accidents IA (biais, faux rejets sur populations arabes)	Fort	Moyenne	Datasets d’entraînement équilibrés, audits tiers, fairness metrics publiés
Perte d’un partenaire data critique (World-Check, D&B)	Moyen	Basse	Double sourcing contractuel, couche d’abstraction data
Incident sécurité / data breach	Critique	Basse	Sécurité by design, pen-tests, incident response plan, assurance cyber
Dépendance à un fournisseur IA (OCR / liveness)	Moyen	Moyenne	Stratégie build+buy, internalisation progressive V2

---

18. Annexes

18.1 Glossaire

• AML — Anti-Money Laundering ; LCB-FT en français.
• AMLA — Anti-Money Laundering Authority (nouvelle autorité UE 2026).
• BCT — Banque Centrale de Tunisie.
• CRS — Common Reporting Standard (OECD) ; équivalent multilatéral de FATCA.
• CTF / LCB-FT — Counter Terrorism Financing / Lutte Contre le Blanchiment – Financement du Terrorisme.
• eMRTD — electronic Machine Readable Travel Document (passeport biométrique, CNI électronique).
• CDPF — Code des Droits et Procédures Fiscaux (Tunisie).
• DGI — Direction Générale des Impôts (Tunisie) — destinataire des déclarations FATCA.
• EENF — Entité Étrangère Non Financière (terminologie DGI FATCA ; équivalent NFFE).
• EIN — Employer Identification Number (identifiant US).
• FATCA — Foreign Account Tax Compliance Act (loi US 2010).
• FATF / GAFI — Financial Action Task Force / Groupe d’Action Financière.
• FAR / FRR — False Acceptance Rate / False Rejection Rate.
• FFI / IF / IFE — Foreign Financial Institution / Institution Financière / Institution Financière Étrangère.
• GIIN — Global Intermediary Identifying Number (délivré par l’IRS à chaque IF).
• ICMM — International Compliance Management Model (notifications IRS).
• IDES — International Data Exchange Service (nom utilisé par la DGI Tunisie pour sa plateforme de dépôt FATCA : ides.finances.gov.tn).
• IGA — Intergovernmental Agreement (Model 1 : transmission via autorité locale ; Model 2 : transmission directe à l’IRS).
• MF — Matricule Fiscal (Tunisie).
• IDV — Identity Verification.
• KYB — Know Your Business.
• KYC — Know Your Customer.
• NFC — Near Field Communication (lecture puce).
• NFFE — Non-Financial Foreign Entity (FATCA).
• NFR — Non-Functional Requirements.
• OCR — Optical Character Recognition.
• PEP — Politically Exposed Person.
• PVID — Prestataire de Vérification d’Identité à Distance (ANSSI, France).
• QES — Qualified Electronic Signature (eIDAS).
• RCA — Relatives and Close Associates.
• SDN — Specially Designated Nationals (OFAC).
• SLA — Service Level Agreement.
• STR / SAR — Suspicious Transaction Report / Suspicious Activity Report.
• TIN — Taxpayer Identification Number.
• UBO — Ultimate Beneficial Owner.
• VASP — Virtual Asset Service Provider (régulateurs crypto).
• WORM — Write Once Read Many (stockage inaltérable).

18.2 Références réglementaires clés

• Tunisie — Circulaire BCT 2025-06 ; Circulaire BCT 06/2025 ; Circulaire BCT 2017-08 ; Loi organique n°2015-26 ; Loi organique n°2019-9.
• UE — Règlement (UE) 2016/679 (GDPR) ; Règlement (UE) n°910/2014 (eIDAS) + eIDAS 2 ; AMLD5 (Dir. 2018/843), AMLD6 (Dir. 2018/1673), AMLA en cours ; Règlement AI Act (2024).
• France — AMF / ACPR ; ANSSI référentiel PVID.
• Allemagne — BaFin Rundschreiben 3/2017 (Videoidentifizierung) ; Geldwäschegesetz (GwG).
• UAE — Federal Law n°10 of 2025 on AML/CFT.
• Égypte — AML Law n°80/2002.
• International — FATF 40 Recommendations ; OECD CRS Standard + Commentaries + XML Schema v2.0 / v3.0.
• US (FATCA) — IRC §1471-1474 ; Form W-8BEN, W-8BEN-E, W-9 ; Form 8966 + FATCA XML Schema v2.0 (IRS Publication 5124) ; ICMM Notification User Guide (IRS Publication 5189) ; IGA Model 1 & 2.
• Tunisie FATCA — Accord IGA Tunisie-USA du 13/05/2019 ; article 17 bis du CDPF (article 38 loi de finances 2016-78 du 17/12/2016) ; Cahier des charges DGI « Transfert d’informations en application de la loi FATCA par procédé informatique » V1.0-2019 ; Cahier des charges FATCA XML V3.7 (01/02/2019) ; plateforme IDES de la DGI.

18.3 Document source

• VitaKYC_Etude_Concurrentielle.md — Étude concurrentielle détaillée qui alimente les sections 3 et 10.
• CC- AO N12-UCA-DAI-2025 E-KYC- V final.pdf — Référentiel AO La Poste Tunisienne, utilisé comme baseline d’exigences MENA régulées.
• Cahier_des_charges-1.pdf — Cahier des charges DGI Tunisie « Transfert d’informations en application de la loi FATCA par procédé informatique » V1.0-2019 (schéma FATCA XML V3.7) — source directe des §4.3.3, 4.3.4, 4.3.5 et 12.3.2 (connecteur IDES).

---

Fin du Livrable 2 — Cahier des Charges VitaKYC.

Prochaine étape recommandée : revue collaborative section par section, priorisation des itérations, puis éventuellement export .docx / .pdf pour diffusion formelle.