📖 Manuel

Vérificateur de Conformité Fintech

Workflow en 5 étapes

1. Cartographier le périmètre : identifier les flux de données financières (carte, virement, wallet, crypto) et les marchés cibles (UE, US, MENA…).
2. Sélectionner les référentiels : croiser type de service × géographie → liste des normes applicables (tableau ci-dessous).
3. Auditer point par point : pour chaque norme, dérouler la checklist correspondante ; noter les gaps avec niveau de risque (critique / élevé / moyen).
4. Corriger et prioriser : implémenter les contrôles manquants critiques en premier ; documenter chaque décision (ADR ou ticket).
5. Maintenir la preuve : logs d'audit, scans périodiques, enregistrement des consentements — tout doit être traçable et exportable.

1. Sélection des référentiels applicables

2. PCI-DSS v4 — Checklist développeur

Données de carte : ce qui est interdit

INTERDIT (même chiffré) :
  - Stocker le CVV/CVC après autorisation
  - Stocker le contenu de la piste magnétique
  - Logger le PAN complet dans les fichiers de log

INTERDIT :
  - Envoyer des données de carte par email, chat, SMS
  - Recevoir le numéro de carte sur vos propres serveurs si scope SAQ A possible

Tokenisation — flux recommandé

# Stripe / Adyen / Braintree
Client (browser/app)
  └─► Stripe.js / Hosted Fields
        └─► PSP (hors scope PCI)
              └─► token  tok_live_xxxxx  → votre backend
                          ↓
              api.stripe.com/v1/charges { source: tok_live_xxxxx }

Votre backend ne voit jamais le PAN. Scope réduit à SAQ A ou SAQ A-EP.

Niveaux PCI-DSS et obligations

Exigences techniques PCI-DSS v4 nouvelles (2025+)

• Exigence 6.4.3 : gestion d'inventaire et intégrité de tous les scripts de page de paiement (CSP + SRI).
• Exigence 11.6.1 : détection des modifications non autorisées des pages de paiement (script tamper detection).
• TLS 1.0 et 1.1 définitivement interdits ; TLS 1.2 minimum, TLS 1.3 recommandé.

# Vérifier TLS d'un endpoint
openssl s_client -connect api.monservice.com:443 -tls1_2 </dev/null 2>&1 | grep "Protocol"
# Ou avec testssl.sh (outil open source)
./testssl.sh --protocols api.monservice.com

3. KYC/AML — Approche basée sur le risque

Niveaux de due diligence (5AMLD / DLTF)

Screening sanctions — intégration code

# Exemple avec l'API Comply Advantage / ComplyLaunch
import requests

def screen_customer(name: str, dob: str) -> dict:
    resp = requests.post(
        "https://api.complyadvantage.com/searches",
        headers={"Authorization": f"Token {API_KEY}"},
        json={
            "search_term": name,
            "filters": {"birth_year": dob[:4]},
            "share_url": False,
            "types": ["sanction", "pep", "warning", "adverse-media"],
        },
        timeout=10,
    )
    resp.raise_for_status()
    hits = resp.json()["content"]["data"]["hits"]
    return {"clear": len(hits) == 0, "hits": hits}

Alternatives : Refinitiv World-Check, Dow Jones Risk & Compliance, listes publiques OFAC/EU/ONU (CSV téléchargeables).

Checklist AML

• [ ] Screening initial à l'onboarding + re-screening périodique (min. annuel)
• [ ] Détection PEP (Personne Politiquement Exposée) et membres de famille
• [ ] Monitoring transactionnel : règles de seuil + modèle comportemental
• [ ] Déclaration de soupçon automatisée vers Tracfin (FR) / CRF (TN) / FinCEN (US)
• [ ] Conservation des données KYC : 5 ans après fin de relation (obligation légale)
• [ ] Gel des avoirs : blocage immédiat si match sanctions confirmé

Red flags à coder comme règles de détection

STRUCTURING : montant < seuil déclaration sur N transactions proches dans le temps
VELOCITY    : > X transactions en 24 h sur un même compte
GEOGRAPHY   : destination dans pays FATF liste grise/noire
ROUND_TRIP  : dépôt → retrait immédiat sans utilisation intermédiaire
NEW_ACCOUNT : volume élevé les 48 h suivant la création du compte

4. PSD2 / SCA — Authentification Forte

Règle SCA

Transaction > 30 € → 2 facteurs obligatoires parmi :
  - Connaissance  : mot de passe, PIN
  - Possession    : téléphone (OTP SMS/TOTP), carte physique
  - Inhérence     : biométrie (empreinte, face ID)

Exemptions applicables (à documenter)

Implémentation 3DS2 (Stripe exemple)

// Côté client — gérer le défi SCA
const { error, paymentIntent } = await stripe.confirmCardPayment(clientSecret, {
  payment_method: { card: cardElement },
});
if (error?.code === "authentication_required") {
  // Redemander la SCA via stripe.handleNextAction(clientSecret)
}

5. RGPD — Données financières

Durées de conservation légales

Droits des utilisateurs — implémentation minimale

• Portabilité : endpoint /api/user/export → JSON/CSV des transactions (format Account Statement ISO 20022 recommandé).
• Effacement : pseudonymiser (ne pas supprimer) les données soumises à conservation légale ; effacer les données hors obligations.
• Accès : réponse sous 30 jours ; authentification forte avant divulgation.
• Rectification : formulaire avec audit trail de la modification.

# Pseudonymisation irréversible pour données hors conservation légale
import hashlib, os

def pseudonymize(value: str, salt: bytes = None) -> str:
    salt = salt or os.urandom(16)
    return hashlib.blake2b(value.encode(), key=salt, digest_size=32).hexdigest()

6. Garde-fous et anti-patterns fréquents

7. Commandes d'audit utiles

# Scanner les secrets dans le code (clés API, PANs…)
trufflehog git file://. --only-verified

# Vérifier les headers de sécurité d'un endpoint
curl -I https://api.monservice.com/v1/payments | grep -E "Strict-Transport|Content-Security|X-Frame"

# Tester les ciphers TLS (rejeter TLS < 1.2)
nmap --script ssl-enum-ciphers -p 443 api.monservice.com

# Vérifier l'inventaire des scripts de paiement (PCI v4 req. 6.4.3)
# Générer les SRI hashes pour les scripts tiers
curl -s https://cdn.js.stripe.com/v3/ | openssl dgst -sha384 -binary | openssl base64 -A

Ce skill fournit des orientations techniques et opérationnelles. Pour des décisions de conformité engageant la responsabilité légale de l'entreprise, consulter un juriste spécialisé en droit financier et/ou un QSA PCI certifié.