Extraction de relevés bancaires

Un relevé bancaire est un document périodique qu'une banque émet pour un titulaire de compte, listant les transactions, les soldes et les identifiants du compte sur une période donnée. Les équipes finance et conformité traitent ces documents en permanence : pour l'instruction de dossiers de crédit, l'onboarding KYC, les audits de dépenses et les enquêtes de fraude. Extraire ces données manuellement est lent et source d'erreurs, d'autant plus qu'il faut composer avec des dizaines de formats et de langues bancaires différents. L'extraction automatisée transforme un PDF scanné en données structurées au niveau transactionnel, directement exploitables par les modèles de risque, la comptabilité ou les workflows d'onboarding KYC.

Champs à extraire

Pourquoi ce document est difficile à traiter

Les relevés bancaires ne sont pas standardisés. Chaque banque a sa propre mise en page, son propre ordre de colonnes et sa propre terminologie pour les débits et les crédits, et beaucoup de banques changent de modèle tous les quelques années sans préavis. Un même système d'extraction doit gérer des relevés provenant de centaines d'établissements, dans plusieurs langues, avec des polices, des logos et des structures de tableaux qui n'ont presque rien en commun.

Les tableaux de transactions constituent la principale difficulté. Ils s'étendent sur plusieurs pages, parfois avec des soldes courants qui se réinitialisent à chaque page, parfois avec des sous-totaux insérés au milieu du tableau. Les lignes peuvent se répartir sur deux lignes physiques lorsque le libellé est long, ce qui pousse un OCR naïf à traiter une seule transaction comme deux. Les relevés scannés au téléphone ajoutent de l'inclinaison, des ombres et des cadrages partiels. Certains relevés arrivent encore par fax ou en photocopie, avec une impression pâle et des annotations manuscrites du titulaire du compte ou d'un employé de banque.

Il existe aussi une dimension fraude. Les relevés bancaires sont couramment falsifiés pour gonfler des revenus ou masquer des découverts avant une demande de crédit ; une extraction qui ignore la cohérence interne (le solde courant s'additionne-t-il vraiment correctement ?) passe totalement à côté du sujet. Un système qui se contente de lire le texte sans vérifier l'arithmétique ne fait pas de la véritable extraction, il fait de la retranscription. Voir détection de fraude documentaire pour comprendre comment ces contrôles fonctionnent en pratique, et OCR vs VLM pour comprendre pourquoi les modèles sensibles à la mise en page gèrent mieux ce cas qu'un simple OCR.

Comment Sygnet traite ce document

Sygnet commence par classer le fichier entrant (relevé bancaire, par opposition à un bulletin de paie ou une facture, par exemple), puis déduit la mise en page spécifique du document plutôt que de le forcer dans un modèle fixe. Chaque champ est extrait avec un score de confiance, et chaque valeur porte une provenance au niveau du champ : une zone de délimitation (bounding box) renvoyant à l'emplacement exact sur la page, ce qui permet à un relecteur de vérifier un chiffre en quelques secondes plutôt que de relire l'intégralité du relevé.

L'extraction applique automatiquement les règles de validation décrites plus bas : arithmétique des soldes, clés de contrôle IBAN, ordre chronologique des dates. Lorsqu'une règle échoue ou que le score de confiance descend sous un certain seuil, la transaction ou le champ concerné est signalé pour une relecture human-in-the-loop, plutôt que de renvoyer tout le document pour une ressaisie manuelle complète. L'attention humaine reste ainsi concentrée sur la faible fraction de cas qui en a réellement besoin.

Pour les workflows combinant plusieurs documents, par exemple pour vérifier un revenu déclaré sur un relevé par rapport à un bulletin de paie ou à une demande de crédit, Sygnet applique une validation croisée entre documents afin de détecter les incohérences entre sources. Le résultat est livré sous forme de sortie structurée propre, prête à être injectée dans une comptabilité ou un moteur de risque, avec une piste d'audit complète indiquant ce qui a été extrait, d'où, et avec quel niveau de confiance. Le traitement des données suit les pratiques décrites sur la page sécurité et conformité.

Règles de validation à appliquer

• Recalculer le solde courant ligne par ligne : le solde initial plus chaque montant de transaction doit correspondre au solde suivant indiqué.
• Vérifier la clé de contrôle de l'IBAN (mod 97) et confirmer que le code pays correspond bien à la juridiction connue de la banque.
• Vérifier que chaque date de transaction est comprise dans la période du relevé indiquée, sans date antérieure à l'ouverture ni postérieure à la clôture.
• Confirmer que la convention de signe débit/crédit est appliquée de manière cohérente sur l'ensemble du document, et pas seulement sur la première page.
• Recouper la date d'émission du relevé avec la date de fin de période : la date d'émission doit toujours être postérieure, jamais antérieure.
• Additionner séparément tous les débits et tous les crédits, et vérifier que cela se réconcilie avec la différence entre solde initial et solde final.
• Signaler les relevés dont la numérotation des pages présente une rupture ou dont une page semble manquante.
• Comparer le nom du titulaire et le numéro de compte avec les autres documents du même dossier pour en vérifier la cohérence.

FAQ

L'extraction peut-elle détecter un relevé bancaire falsifié ?

Elle peut repérer les signes les plus courants : une arithmétique des soldes incohérente, des polices ou des espacements irréguliers dans le tableau de transactions, ou des soldes courants qui ne correspondent pas. Elle ne peut pas prouver une intention frauduleuse ni détecter toute manipulation, en particulier un faux bien réalisé avec une arithmétique correcte. Combiner les contrôles automatisés avec les techniques de détection de fraude documentaire et une relecture humaine ciblée offre la meilleure couverture.

Comment l'extraction gère-t-elle les relevés en différentes langues ?

Les modèles sensibles à la mise en page, entraînés sur des documents multilingues, reconnaissent des libellés comme "débit", "crédit", "solde" ou "balance" sans nécessiter un modèle distinct par langue. Le système fait correspondre ces éléments à un schéma commun (montant de la transaction, solde courant, etc.) afin que les systèmes en aval reçoivent des noms de champs cohérents, quelle que soit la langue source.

Faut-il développer cela en interne ou passer par un prestataire ?

Cela dépend du volume traité et du nombre de formats bancaires distincts à gérer. Développer un moteur d'analyse robuste couvrant des centaines de mises en page bancaires, avec en plus les contrôles de fraude et les outils de relecture, demande un investissement d'ingénierie réel et une maintenance continue à mesure que les banques changent de modèles. Voir développer ou acheter une solution IDP pour une comparaison plus complète, et la page tarifs pour estimer le coût en fonction du volume.