Un faux relevé bancaire débloque crédits et baux — la vérification visuelle ne le détecte pas
Les équipes KYC des néobanques et des prêteurs, les souscripteurs hypothécaires et les gestionnaires locatifs acceptent les relevés bancaires comme justificatif de revenus et de patrimoine. Les fraudeurs ouvrent le relevé authentique dans un éditeur PDF, modifient les soldes et les opérations, puis ré-exportent — et le relevé manipulé arrive directement dans votre processus d'onboarding.
htpbe? analyse la couche structurelle du fichier PDF — la couche qui enregistre toutes les modifications, y compris les plus discrètes. Nous n'inspectons pas les hologrammes, les photos de téléphone ou la biométrie d'identité, et nous ne remplaçons pas les plateformes KYC ni les API d'agrégation bancaire. Si votre problème de fraude porte sur un relevé bancaire PDF manipulé ou falsifié numériquement, nous sommes l'outil le plus adapté.
Lorsque htpbe? renvoie INCONCLUSIVE sur un relevé bancaire, c'est en soi un signal de fraude à haute confiance — les relevés authentiques proviennent toujours des systèmes d'émission bancaire ou des moteurs d'export en ligne, jamais d'un logiciel bureautique.
Un appel REST, un verdict déterministe
Soumettez le PDF. L'API renvoie INTACT, MODIFIED ou INCONCLUSIVE avec des marqueurs nommés — en environ trois secondes.
À quoi ressemblent concrètement les relevés bancaires manipulés
Trois mécaniques de fraude réelles que nous détectons au niveau de la couche structurelle du PDF.
Relevé authentique avec soldes modifiés
Le candidat télécharge son vrai relevé depuis son espace en ligne, l'ouvre dans un éditeur PDF, modifie le solde, ajoute des virements de salaire fictifs, puis ré-exporte. La table xref révèle une mise à jour incrémentale — un système d'émission bancaire n'écrit jamais de seconde xref.
Relevé entièrement falsifié dans Word ou Excel
Sans aucun relevé original. Le candidat compose la mise en page dans Word en y intégrant un logo bancaire trouvé sur le web, saisit les soldes souhaités et exporte en PDF. Le champ Producer affiche Microsoft Word — et non le système bancaire (LCL, BNP Paribas, Crédit Agricole, Boursorama) dont sont issus les relevés authentiques.
Générateur en ligne avec opérations inventées
Des outils en ligne proposent des « relevés bancaires en quelques secondes » et génèrent des PDF avec des opérations et des soldes entièrement fictifs. Le champ Producer trahit la chaîne d'outils du générateur (Chrome Headless, Puppeteer, wkhtmltopdf, ReportLab) — sans aucun lien avec le système d'une vraie banque.
L'étendue du problème
Pourquoi vos contrôles actuels passent à côté
KYC et agrégation bancaire lisent les données. Ils ne lisent pas le fichier.
L'OCR lit les montants. Il ne lit pas l'origine du PDF.
Les plateformes KYC (Onfido, Jumio, Sumsub, Ariadnext) extraient les données par OCR et vérifient les identités — elles sont incapables de détecter si le PDF sous-jacent provient d'un système bancaire ou a été manipulé sur un poste de travail. Les API d'agrégation bancaire (Bridge, Tink, Powens) se connectent directement à la banque et fournissent des données en temps réel — mais elles ne fonctionnent que si le candidat autorise la connexion, ce que les fraudeurs refusent souvent. htpbe? inspecte la structure du fichier (Producer, xref, cohérence des soldes, flux d'images) et produit des signaux structurels de fraude avant l'accord de crédit ou la signature du bail.
Cinq couches forensiques, un verdict déterministe
Chaque PDF reçu passe par le même pipeline structurel — sans entraînement de modèle ni seuils à configurer.
Analyse des métadonnées
Horodatages de création et de modification, champs Producer et Creator, métadonnées XMP — la première couche expose les manipulations de base.
Structure du fichier
Tables xref, chaîne de trailer, mises à jour incrémentielles. Toute modification après export laisse une empreinte structurelle ici.
Signatures numériques
Intégrité de la chaîne de signature et modifications post-signature — signaux à niveau de certitude déterministe.
Intégrité du contenu
Polices, objets, contenu incorporé, assemblage des pages. Les modifications multi-sessions et les objets insérés sont visibles à ce niveau.
Verdict avec marqueurs
Résultat déterministe : INTACT / MODIFIED / INCONCLUSIVE, avec des marqueurs nommés pour chaque constat — adapté à la piste d'audit.
Relevés bancaires et PDF connexes que nous vérifions
Chaque type listé ci-dessous est analysé au niveau de la couche structurelle du fichier — pas en tant qu'image rendue.
Capacités de détection
Signaux structurels déterministes. Aucun score probabiliste, aucun entraînement de modèle.
Signature Producer du relevé
Les relevés bancaires authentiques sont générés par des systèmes d'émission internes (moteurs d'impression propriétaires s'appuyant sur des bibliothèques PDF d'entreprise). Lorsque le champ Producer indique Microsoft Word, Microsoft Excel, LibreOffice, Chrome Headless ou un outil PDF générique, le relevé a été produit sur un poste de travail — il ne provient pas de la banque.
Trace de mise à jour incrémentale
Un export issu d'un système bancaire ne contient qu'une seule table de références croisées. Toute ré-enregistrement via un éditeur PDF ajoute une seconde xref — preuve structurelle directe d'une modification des soldes, des opérations ou des dates.
Vérification des soldes ligne par ligne
La cohérence du solde courant est contrôlée sur l'ensemble des opérations (solde précédent + opération = nouveau solde). Les relevés manipulés rompent cette cohérence dès qu'une opération est modifiée ou insérée — à moins que chaque solde dépendant ait également été corrigé.
Écart entre les horodatages de création et de modification
Sur un relevé authentique, la ModDate est identique ou très proche de la CreationDate (export en session unique depuis le portail bancaire). Un écart de plusieurs jours ou semaines sur un relevé « fraîchement téléchargé » constitue un signal à haute confiance d'une édition post-export.
Artefacts d'image dans les logos insérés
Les en-têtes bancaires authentiques sont intégrés directement dans les objets de polices et d'images du gabarit. Les logos bancaires copiés depuis des sites web apparaissent comme des flux d'images redondants avec des caractéristiques de compression distinctes — empreinte structurelle caractéristique d'une falsification.
Divergence de sous-ensembles de polices
Les relevés authentiques utilisent un seul sous-ensemble de polices pour l'ensemble du document. Les relevés dans lesquels des montants ont été insérés après coup présentent souvent des décalages de préfixe de sous-ensemble — signe d'une construction en plusieurs sessions distinctes.
Deux appels HTTP suffisent pour vérifier n’importe quel relevé bancaire
Les acheteurs peuvent passer cette section — pour les développeurs, l'intégration se résume à deux appels HTTP.
Étape 1 — soumettre le PDF
curl -X POST https://api.htpbe.tech/v1/analyze \
-H "Authorization: Bearer $HTPBE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://your-storage/releve-bancaire-candidat.pdf"}'Étape 2 — lire le verdict
{
"id": "r1e2l3v4-5b6q-7r8e-9z0v-a1b2c3d4e5f6",
"status": "modified",
"modification_confidence": "high",
"modification_markers": [
"Deux tables de références croisées — mise à jour incrémentale",
"Date de modification 9 jours après la date de création",
"Éditeur PDF détecté comme Producer",
"Cohérence des soldes rompue à l’opération n° 14"
],
"producer": "Adobe Acrobat Pro",
"creator": "BNP Paribas Mes Comptes",
"creation_date": 1707091200,
"modification_date": 1707868800,
"has_digital_signature": false,
"xref_count": 2,
"has_incremental_updates": true
}Original issu de BNP Paribas Mes Comptes — source institutionnelle. Neuf jours plus tard, le fichier a été ouvert dans Adobe Acrobat Pro et ré-enregistré, ce qui a ajouté une seconde table xref. Verdict : modified, confiance élevée. Par ailleurs, la cohérence des soldes est rompue à partir de l'opération 14 — le candidat a inséré une ligne sans recalculer les soldes dépendants.
Témoignages clients
Des équipes qui ont mis fin à la fraude documentaire
Les équipes conformité, finance et risque utilisent htpbe? pour détecter les PDF manipulés avant qu'ils ne deviennent des erreurs coûteuses.
Caught an invoice where the total had been changed by less than a thousand dollars. Without this I would have approved it without a second look.
Sarah M.
AP Manager
United States
We had three applicants in the same week with bank statements that looked completely fine. Two of them were flagged as modified. You simply cannot see this by reading the document — it is in the file structure.
Lars V.
Risk Analyst, Online Lending
Netherlands
Salary slips were coming with altered figures. We identified two problematic files before the placement was finalised.
Priya K.
HR Operations Lead
India
Since we started checking documents this way, we stopped two applications early in the process that would have been very difficult to reverse later.
Julien R.
Fraud Analyst, Fintech
France
Some applicants were sending PDFs that looked authentic but had been edited in ways not visible to the eye. We now ask for verified originals when something is flagged. Already saved us from a few bad decisions.
Marta S.
Compliance Coordinator
Spain
One invoice was caught because there was a mismatch between the document dates and structure. That particular case would have cost us significantly.
Tariq A.
Finance Manager
United Arab Emirates
Questions fréquentes
modified avec le marqueur correspondant, quel que soit le rendu visuel.Solutions et guides connexes
Fintech & Crédit
Détection de fraude documentaire pour équipes risk-ops chez les prêteurs.
Détection fausse fiche de paie
Page connexe — même approche forensique appliquée aux fiches de paie dans les flux KYC et crédit.
Bank Statement Fraud Detection
Version anglaise — forensique des relevés bancaires pour les équipes internationales.
Sécurisez votre workflow
Créez votre compte — clé API à l'inscription, environnement de test gratuit sur chaque plan.
Dès $15/mois. Sans appel commercial. Résiliable à tout moment.