Spécification KYC unifié v1

Document de référence pour les équipes produit, conformité et technique des SGI partenaires. Architecture, niveaux, API publique, portabilité inter-SGI et audit cryptographique.

1. Principes fondateurs

• Portabilité : un KYC validé dans une SGI peut, avec consentement de l'investisseur, être réutilisé par toute autre SGI partenaire sans refaire les documents.
• Preuve cryptographique : chaque artefact validé est scellé par une signature Ed25519 Inopay + horodatage qualifié. Le SGI consommateur vérifie l'authenticité sans dépendre d'Inopay.
• Audit trail inaltérable : toutes les actions (soumission, validation, consultation, retrait de consentement) sont journalisées en log append-only, consultables 5 ans.
• Non-custodial de données : Inopay est sous-traitant au sens de la LOI UEMOA. Les données restent la propriété du SGI et de l'investisseur.
• Niveaux standardisés : 3 niveaux (KYC1/2/3) alignés sur la grille CREPMF anticipée et les meilleures pratiques CIMA.

2. Les 3 niveaux

3. Cycle de vie d'un KYC

1. NEW — parcours initié côté investisseur, brouillon sauvegardé automatiquement.
2. PENDING — soumis, en cours de validation (IA + revue humaine conditionnelle).
3. REQUIRES_COMPLETION — document manquant ou non conforme, demande ciblée envoyée à l'investisseur.
4. VALIDE — accepté, scellé cryptographiquement, utilisable. Valable 12 mois.
5. REJECTED — rejeté après 3 tentatives ou fraude avérée. Investisseur notifié avec motif clair.
6. EXPIRED — au-delà de 12 mois sans renouvellement.
7. REVOKED — révoqué après incident (fraude post-validation, demande investisseur, ordre CREPMF).

4. Architecture technique

Composants

• API REST (api.getinopay.com/v1/kyc/*) — authentification par clés SGI (inopay_live_* / inopay_test_*), signatures HMAC-SHA256 sur corps des requêtes sensibles.
• Pipeline de validation — magic bytes MIME → OCR → vision multimodale (modèle primary : Gemini ; fallback : DeepSeek) → scoring anti-fraude → file de revue humaine conditionnelle.
• Stockage documents — MinIO S3-compatible, chiffrement AES-256-GCM au repos, rotation des clés tous les 90 jours.
• Registre signé — table kyc_attestations append-only, chaque validation produit une attestation Ed25519 avec hash SHA-256 des documents.
• Webhooks signés — événements temps réel poussés vers les SGI, signature HMAC-SHA256 dans l'en-tête X-Inopay-Signature.

Flux de portabilité inter-SGI

1. Investisseur existant chez SGI A (KYC VALIDE) → s'inscrit chez SGI B
2. SGI B appelle : GET /v1/kyc/by-email/{email}
   → Inopay répond : { exists: true, level: "KYC2", validated_at: "...", ... }
3. SGI B initie : POST /v1/kyc/{id}/request-portability
   → Inopay envoie un SMS/email à l'investisseur :
     « SGI B souhaite accéder à votre KYC. Autorisez ? »
4. Investisseur clique → consent enregistré (journalisé, signé)
5. SGI B appelle : GET /v1/kyc/{id}
   → Inopay livre l'attestation signée + documents (URLs pré-signées 1 h)
6. SGI B vérifie la signature Ed25519 localement → accepté sans refaire les docs
7. Inopay facture 300 FCFA de réutilisation au SGI B

5. Endpoints API principaux

6. Événements webhook

• kyc.submitted — nouvelle soumission reçue
• kyc.validated — validation effective, attestation générée
• kyc.rejected — rejet avec motif
• kyc.requires_completion — complément demandé à l'investisseur
• kyc.portability_requested — un autre SGI demande l'accès
• kyc.portability_consented — investisseur a accordé l'accès
• kyc.revoked — révocation effectuée
• kyc.expired — expiration sans renouvellement

7. Sécurité & conformité

• Chiffrement en transit : TLS 1.3 exclusivement
• Chiffrement au repos : AES-256-GCM, clés gérées HashiCorp Vault (roadmap T2 2026)
• Authentification API SGI : clés distinctes test/prod, rotation possible à la demande
• Rate limiting : 1 000 req/min par clé SGI, 100 KYC/jour/SGI par défaut (ajustable)
• Anti-fraude : détection document modifié (EXIF + hash perceptuel), selfie liveness, bloqueurs VPN détectés
• RGPD / LOI UEMOA : droit d'accès, rectification, effacement (après délais légaux), portabilité
• CREPMF : dépôt d'une demande d'agrément PSP-KYC à échéance 18 mois
• ISO 27001 : certification visée T4 2026

8. Engagements de qualité

9. Interopérabilité

L'API Inopay suit la spécification OpenAPI 3.1, documentée et versionnée. Les SGI peuvent générer des clients dans leur langage (Node, Python, Java, Go, PHP).

La spec est exportable au format PAS-CIMA si la CIMA publie un standard régional KYC (travail en cours avec le Conseil Régional).