FAQ

Questions fréquentes sur Analyseur de relevés bancaires

Confidentialité des données et conformité

Des données quittent-elles mon infrastructure ?

Non. Analyseur de relevés bancaires fonctionne comme une bibliothèque sans état. Tout le traitement -- analyse, masquage des DCP, extraction d'archives -- s'effectue dans la mémoire de votre environnement d'exécution local. Aucun appel API, aucun service cloud, aucune télémétrie. Les parseurs XML sont renforcés avec no_network=True, bloquant tout accès sortant au niveau du parseur. Vos données financières ne quittent jamais votre environnement.

Comment fonctionne le masquage des DCP ?

Les champs sensibles sont masqués avant d'atteindre votre logique applicative. Le parseur identifie les noms des débiteurs, les noms des créanciers, les IBAN et les adresses postales, les remplaçant par ***REDACTED*** dans la sortie console et le mode streaming.

  • Le masquage est activé par défaut en sortie CLI et en mode streaming.
  • Les exports de fichiers (CSV, JSON, Excel) conservent les données non masquées pour le traitement en aval.
  • Activez l'affichage complet avec --show-pii en CLI ou redact_pii=False dans l'API.

Le processus d'extraction est-il déterministe ?

Oui -- sortie identique octet par octet à chaque exécution. Pour un même fichier d'entrée, le parseur produit le même résultat à chaque fois. Aucun aléatoire, aucune inférence de modèle, aucun échantillonnage heuristique. La CI vérifie le déterminisme avec 467 tests à 100% de couverture de branches, y compris du fuzzing basé sur les propriétés via Hypothesis.

Quelles normes de conformité le projet suit-il ?

Le projet maintient une documentation alignée sur ISO 13485 avec traçabilité complète :

  • Un Registre des risques quantifié avec notation sévérité/probabilité et évaluation du risque résiduel.
  • Un Plan de vérification et validation avec 19 étapes jalons réparties sur 5 phases.
  • Une Procédure de contrôle des modifications avec évaluation d'impact et protocoles de retour en arrière.
  • Un Registre SOUP couvrant toutes les dépendances avec niveaux de risque et suivi de fin de vie.
  • Une Matrice de traçabilité reliant les entrées de conception à l'implémentation et à la vérification.

Chaque version inclut un SBOM CycloneDX, des sommes de contrôle SHA-256 et une attestation de provenance de build GitHub.

Performance et évolutivité

Quelle est la vitesse de Analyseur de relevés bancaires ?

Les seuils de performance sont validés en CI à chaque commit :

Métrique Valeur
Débit CAMT.053 27 000+ transactions/seconde
Débit PAIN.001 52 000+ transactions/seconde
Latence par transaction (CAMT) 37 microsecondes
Latence par transaction (PAIN.001) 19 microsecondes
Délai avant premier résultat < 2 ms

Comment les gros fichiers sont-ils gérés ?

Streaming avec mémoire constante -- testé avec 50 000 transactions par fichier. Utilisez parse_streaming() pour traiter les fichiers XML de manière incrémentale. Chaque transaction est produite sous forme de dictionnaire ; les éléments sont libérés après traitement pour éviter la croissance mémoire. La mémoire ne croît pas avec la taille du fichier -- le test à 50K transactions (25+ Mo) utilise moins de 2x la mémoire du test à 10K transactions.

Pour les fichiers dépassant 50 Mo (par exemple, les lots PAIN.001 host-to-host avec 100K+ paiements), le parseur traite en streaming via un fichier temporaire avec suppression des espaces de noms par blocs -- le document complet n'est jamais chargé en mémoire.

Comment les archives ZIP sont-elles traitées de manière sécurisée ?

iter_secure_xml_entries() valide chaque membre avant l'extraction :

  • Plafond de taille par entrée (10 Mo par défaut)
  • Plafond de taille totale décompressée (50 Mo par défaut)
  • Limite de ratio de compression (100:1 par défaut) pour prévenir les bombes ZIP
  • Rejet des entrées chiffrées

Aucun fichier n'est écrit sur le disque. Les octets XML passent directement au parseur via from_bytes().

Puis-je analyser plusieurs fichiers en parallèle ?

Oui. Utilisez parse_files_parallel() qui distribue le travail via un ProcessPoolExecutor :

from bankstatementparser import parse_files_parallel

results = parse_files_parallel([
    "statements/jan.xml",
    "statements/feb.xml",
    "statements/mar.xml",
])
for r in results:
    print(r.path, r.status, len(r.transactions), "rows")

Formats pris en charge

Quels formats de relevés bancaires sont pris en charge ?

Format Norme Types de fichiers Classe du parseur
CAMT.053 ISO 20022 Bank-to-Customer Statement .xml CamtParser
PAIN.001 ISO 20022 Credit Transfer Initiation .xml Pain001Parser
CSV Exports bancaires génériques .csv CsvStatementParser
OFX Open Financial Exchange .ofx OfxParser
QFX Quicken Financial Exchange .qfx QfxParser
MT940 Norme SWIFT .mt940, .sta Mt940Parser

Le parseur gère-t-il les dialectes bancaires spécifiques de CAMT.053 ?

Oui -- agnostique des espaces de noms par conception. Le parseur supprime les espaces de noms XML avant le traitement, gérant toute variante CAMT.053 (camt.053.001.02, camt.053.001.04 ou wrappers propriétaires) sans configuration spécifique. Les requêtes XPath ciblent la structure des éléments, pas les URI d'espaces de noms.

Pour les banques qui encapsulent le CAMT dans une enveloppe personnalisée, utilisez from_string() ou from_bytes() pour alimenter directement le document interne.

Puis-je mapper des en-têtes CSV personnalisés vers le schéma standard ?

Oui -- normalisation automatique, zéro configuration. CsvStatementParser reconnaît les variations d'en-têtes courantes : "Date", "Transaction Date", "Booking Date" correspondent tous au champ date. "Amount", "Value", "Sum" correspondent à amount. Les colonnes crédit/débit séparées (par ex., "Credit" et "Debit") sont détectées et combinées automatiquement en un montant signé unique.

Quel est le format de sortie ?

Tous les parseurs produisent des DataFrames pandas standardisés avec des types de colonnes cohérents :

Format Colonnes principales
CAMT Amount, Currency, DrCr, Debtor, Creditor, Reference, ValDt, BookgDt, AccountId
PAIN.001 PmtInfId, PmtMtd, InstdAmt, Currency, CdtrNm, EndToEndId, MsgId, CreDtTm, NbOfTxs
CSV/OFX/QFX/MT940 date, description, amount (normalisé)

Vous pouvez également exporter en CSV, JSON, Excel ou convertir en DataFrames Polars.

Flux de trésorerie

Comment le parseur gère-t-il les relevés multi-devises ?

Chaque transaction conserve sa devise d'origine -- aucune conversion implicite. Le champ Currency est extrait de l'attribut XML Ccy par transaction. Les relevés multi-devises sont conservés tels quels. La méthode get_account_balances() renvoie les soldes d'ouverture et de clôture par compte avec les codes de devise d'origine. Le rapprochement inter-devises est délégué à votre logique en aval, où vous contrôlez la source des taux de change.

Le parseur prend-il en charge les formats entrants et sortants ?

Oui. Pain001Parser gère les fichiers ISO 20022 PAIN.001 d'initiation de virement (paiements sortants). CamtParser gère les fichiers CAMT.053 de relevés bancaires (reporting entrant). Les deux prennent en charge le streaming, le masquage des DCP et l'export en CSV, JSON et Excel. Utilisez detect_statement_format() pour identifier le format automatiquement.

Que se passe-t-il quand une écriture est malformée ?

Le comportement dépend du mode d'analyse :

  • parse() (mode batch) -- Les écritures malformées dont les champs requis sont manquants (Amount, Currency ou CdtDbtInd) sont ignorées avec un avertissement dans les logs. Le reste du relevé s'analyse normalement.
  • parse_streaming() (mode streaming) -- Les erreurs d'analyse se propagent immédiatement sous forme d'exceptions. Aucune perte de données silencieuse. Ce comportement fail-fast est intentionnel pour les flux financiers où chaque transaction doit être comptabilisée.

Comment fonctionne le dédoublonnage ?

La classe Deduplicator détecte les doublons exacts et les correspondances suspectes avec des scores de confiance explicables :

from bankstatementparser import CamtParser, Deduplicator

parser = CamtParser("statement.xml")
dedup = Deduplicator()
result = dedup.deduplicate(dedup.from_dataframe(parser.parse()))

print(f"Unique: {len(result.unique_transactions)}")
print(f"Exact duplicates: {len(result.exact_duplicates)}")
print(f"Suspected matches: {len(result.suspected_matches)}")

Installation et compatibilité

Comment installer Analyseur de relevés bancaires ?

pip install bankstatementparser

Pour le support optionnel des DataFrames Polars :

pip install bankstatementparser[polars]

Quelles versions de Python sont prises en charge ?

Python 3.9 à 3.14. Toutes les versions sont testées en CI avec 467 tests à 100% de couverture de branches.

Quelles sont les dépendances ?

La bibliothèque a 5 dépendances directes :

  • lxml -- Analyse XML avec renforcement de la sécurité
  • pandas -- DataFrames et manipulation de données
  • openpyxl -- Export Excel
  • pydantic -- Validation de données et modèles
  • defusedxml -- Protection XXE

Toutes les dépendances ont des versions verrouillées par hash SHA-256. Le SBOM CycloneDX référence chaque composant d'exécution.

Est-ce compatible avec macOS, Linux et Windows ?

Oui. La bibliothèque fonctionne sur macOS, Linux et Windows (via WSL). Elle n'a aucune dépendance spécifique à une plateforme.

Reproductibilité et sécurité

Comment vérifier la reproductibilité ?

python -m pytest                              # 467 tests, 100% couverture de branches
python scripts/verify_locked_hashes.py        # Verification des hash SHA-256
git log --show-signature -1                   # Verifier la signature du commit

Quelles protections de sécurité sont intégrées ?

  • Protection XXE : resolve_entities=False, no_network=True, load_dtd=False
  • Protection anti-bombe ZIP : Limites de ratio de compression, plafonds de taille, rejet des entrées chiffrées
  • Prévention du parcours de répertoires : Liste noire de motifs dangereux et résolution des liens symboliques
  • Validation des entrées : Limites de taille de fichier (100 Mo par défaut), validation d'extension/format
  • Chaîne d'approvisionnement : Dépendances verrouillées par hash SHA-256, SBOM CycloneDX, attestation de provenance de build
  • Commits signés : Appliqués en CI

Comment Analyseur de relevés bancaires se compare-t-il à pyiso20022 ?

pyiso20022 est un toolkit ISO 20022 généraliste qui génère des dataclasses Python à partir des schémas XML ISO. Il couvre un large éventail de types de messages ISO 20022 (PACS, PAIN, CAMT, ADMI) avec validation de schéma. Analyseur de relevés bancaires est conçu spécifiquement pour l'analyse de relevés bancaires avec support du streaming, masquage des DCP, dédoublonnage et API unifiée sur six formats incluant les formats non-ISO (CSV, OFX, QFX, MT940). Si vous devez analyser des relevés bancaires en DataFrames avec une sécurité de niveau production, utilisez Analyseur de relevés bancaires. Si vous devez travailler avec le catalogue complet de messages ISO 20022, utilisez pyiso20022.

Quelles sont les échéances de migration SWIFT ISO 20022 ?

SWIFT a publié un calendrier de migration par phases :

  • Novembre 2026 : Les adresses structurées et hybrides deviennent obligatoires. Les messages MT101 multi-instructions seront rejetés. La phase 1 de la gestion des cas démarre.
  • Novembre 2027 : Toutes les institutions financières doivent pouvoir recevoir nativement les relevés CAMT.053. SWIFT cessera de convertir le format MT en ISO.
  • Novembre 2028 : Retrait complet de MT940, MT942, MT950, MT900 et MT910. Ceux-ci seront remplacés par les équivalents CAMT.052, CAMT.053 et CAMT.054.

Analyseur de relevés bancaires prend en charge à la fois le format historique MT940 et les formats modernes CAMT.053/PAIN.001, ce qui en fait un outil idéal pour la période de transition.