Appel API
Votre système appelle notre API REST avec le nom ou l’identifiant du bénéficiaire et son IBAN.
ENTREPRISE
Digiteal SA
BE 0630675588
LEI 9845000A44AB9CA60605
Rue Emile Francqui 6/9
1435 Mont-Saint-Guibert
Belgium
À PROPOS DE DIGITEAL
VoP vs Confirmation of Payee : quelle différence ?
Si vous suivez l’actualité du secteur des paiements, vous avez peut-être déjà entendu parler de Confirmation of Payee, ou CoP, l’équivalent britannique de la VoP. Ce sont deux mécanismes proches : même objectif fondamental, mais cadres réglementaires différents.
Confirmation of Payee a été introduit au Royaume-Uni à partir de 2020, sous l’autorité du Payment Systems Regulator, ou PSR. Il couvre les paiements via Faster Payments et CHAPS. Le Royaume-Uni a été pionnier dans ce domaine, avec des résultats mesurables : les banques participantes ont signalé d’importantes réductions de la fraude APP dans les années qui ont suivi la mise en œuvre.
Verification of Payee (VoP) est la version européenne, régie par l’European Payments Council, ou EPC, dans le cadre de son VoP Rulebook. Elle couvre les virements SEPA, ou SCT, et les virements instantanés SEPA, ou SCT Inst, et est devenue obligatoire dans toute la zone euro en octobre 2025.
Au-delà de ces deux dispositifs, SWIFT exploite également des services de prévalidation pour les paiements transfrontaliers, mais le périmètre de la VoP au sein de SEPA est distinct et porté par la réglementation.
L’enseignement général est clair : partout dans le monde, les régulateurs vont dans la même direction. La vérification du nom du titulaire du compte avant l’exécution du paiement devient une attente universelle.
La réglementation qui rend la VoP obligatoire
Le règlement (UE) 2024/886, communément appelé règlement sur les paiements instantanés, ou IPR, impose à tous les prestataires de services de paiement, ou PSP, opérant dans l’UE de fournir la Verification of Payee, c’est-à-dire la Vérification du nom du bénéficiaire, pour les virements SEPA classiques et instantanés.
Cela signifie que :
- En tant que PSP, vous devez être capable à la fois d’envoyer des demandes VoP, pour le compte de vos clients qui initient des paiements, et de répondre à des demandes VoP lorsqu’une personne tente de payer l’un de vos titulaires de compte.
- La vérification doit être effectuée avant l’exécution de tout virement, et non après.
- Le règlement s’applique que le virement soit standard ou instantané.
- En tant que PSP initiateur, si vous n’effectuez pas de vérification VoP ou si vous ne présentez pas d’avertissement à votre client en cas de doute avant le paiement, vous êtes responsable de la fraude et devrez rembourser votre client.
L’EPC a publié le VoP Rulebook technique, qui définit les règles du schéma, les formats de données pris en charge, les résultats de correspondance acceptés et les obligations de chaque participant. La conformité au schéma EPC est ce qui confère à une implémentation VoP sa validité juridique et technique.
Quels pays sont concernés, et quand ?
Le déploiement se fait en deux vagues, selon la devise.
1. Vague 1 : pays de la zone euro
20 États membres, échéance au 9 octobre 2025
Autriche, Belgique, Chypre, Allemagne, Estonie, Espagne, Finlande, France, Grèce, Croatie, Irlande, Italie, Lituanie, Luxembourg, Lettonie, Malte, Pays-Bas, Portugal, Slovénie, Slovaquie.
2. Vague 2 : États membres de l’UE avec une devise non euro
7 pays, échéance au 9 juillet 2027
Bulgarie, Tchéquie, Danemark, Hongrie, Pologne, Roumanie, Suède.
3. Au-delà de l’UE : autres pays SEPA
Des pays comme le Royaume-Uni, la Suisse, la Norvège, l’Islande et le Liechtenstein entrent dans le périmètre du schéma VoP de l’EPC, mais ne sont pas liés par les échéances de la réglementation européenne. Leur adoption dépend de la législation locale et de l’adhésion volontaire de leurs PSP au VoP Rulebook de l’EPC.
En pratique : si votre entreprise, vos clients ou les utilisateurs de votre logiciel touchent à un paiement à destination ou en provenance d’un compte de la zone euro, la VoP est déjà active et obligatoire.
Pour les éditeurs de logiciels : pourquoi intégrer une API VoP ?
Si vous développez un logiciel qui touche aux paiements, aux comptes bancaires ou aux données fournisseurs, la Vérification du nom du bénéficiaire n’est pas le problème de quelqu’un d’autre : c’est le vôtre.
Pensez aux endroits où les IBAN entrent dans votre système :
- Un nouveau fournisseur est créé dans votre ERP ou votre plateforme de comptes fournisseurs.
- Le compte bancaire d’un employé est modifié dans votre logiciel de paie.
- Un client fournit ses coordonnées bancaires pour un mandat de domiciliation SEPA.
- Un remboursement ou un dédommagement est initié via votre plateforme.
- Un fichier de paiement est préparé et exporté vers la banque.
Chacun de ces moments est une occasion pour un IBAN incorrect, frauduleux ou accidentel, d’entrer dans le système. Et chacun de ces moments est une occasion où une vérification VoP peut l’empêcher.
Vos utilisateurs, qu’il s’agisse d’équipes finance, de comptables ou de gestionnaires de trésorerie, ne s’attendent pas à devoir vérifier manuellement les IBAN. Ils font confiance à votre logiciel pour les aider à travailler de manière sécurisée. Intégrer la VoP signifie que votre produit fait ce dont ils ont besoin, au bon moment, sans ajouter de friction.
La proposition de valeur pour les éditeurs de logiciels repose sur trois axes :
- Attraction réglementaire : vos clients PSP et bancaires doivent déjà prendre en charge la VoP. Si votre logiciel alimente leurs flux de paiement, vous faites partie de cette chaîne sécurisée.
- Différenciation commerciale : proposer une vérification VoP native est un véritable différenciateur produit, une fonctionnalité que les acheteurs finance demanderont de plus en plus souvent.
- Réduction de la responsabilité : en cas d’incident de fraude, la question sera posée : « votre logiciel aurait-il pu signaler ce problème ? » Une vérification VoP intégrée constitue la réponse.
Questions-réponses : ce que les éditeurs de logiciels demandent sur l’intégration VoP
Quels types de logiciels sont directement concernés ?
Tout logiciel qui collecte, stocke ou traite des IBAN dans un contexte de paiement est concerné.
Les catégories les plus courantes sont :
- ERP : données maîtres fournisseurs, campagnes de paiement.
- Plateformes de comptes fournisseurs ou P2P : traitement des factures, workflows d’approbation des paiements.
- Logiciels de paie : gestion des comptes bancaires des employés.
- Systèmes de gestion de trésorerie : référentiels de comptes bancaires, initiation de paiements.
- Plateformes d’e-invoicing : portails fournisseurs, gestion des remises.
- Facturation d’abonnements et SaaS : création de mandats de domiciliation SEPA.
- Marketplaces et plateformes de payout : paiements aux vendeurs, affiliés ou partenaires.
Si votre produit contient un champ appelé « IBAN », la VoP a un cas d’usage.
Mon logiciel n’initie pas directement les paiements. La VoP s’applique-t-elle quand même ?
Oui, et c’est un point important à comprendre. La valeur de la Vérification du nom du bénéficiaire ne se limite pas au moment de l’exécution du paiement. Elle est tout aussi utile lorsque l’IBAN entre pour la première fois dans votre système.
Si votre logiciel stocke l’IBAN d’un fournisseur, le compte bancaire d’un employé ou les données de mandat d’un client, vous êtes la première ligne de défense. Au moment où un paiement est initié, que ce soit par votre logiciel ou par une banque externe, l’IBAN est déjà dans le système, souvent considéré comme fiable implicitement.
Intégrer la VoP à l’étape d’onboarding et de capture des données signifie que vous détectez les IBAN frauduleux ou incorrects avant qu’ils ne deviennent un problème, et non après.
Quelles données sont nécessaires pour effectuer une demande VoP ?
Une demande VoP nécessite deux informations :
1. L’IBAN du bénéficiaire
Le numéro de compte bancaire qui recevra le paiement.
2. Une référence de vérification
Soit :
- Le nom du bénéficiaire, c’est-à-dire le nom complet d’une personne ou la dénomination d’une société.
- Soit un identifiant professionnel reconnu, par exemple :
- Numéro de TVA, ou TXID.
- Legal Entity Identifier, ou LEI.
- Bank Identifier Code, ou BIC.
- SIREN / SIRET, pour la France.
- Numéro de certificat d’incorporation.
- Numéro D-U-N-S.
La vérification basée sur le nom est l’approche la plus largement prise en charge et recommandée. La vérification basée sur un identifiant peut être utile lorsque le nom exact est incertain, par exemple lors de l’onboarding d’un nouveau fournisseur B2B en utilisant son numéro de TVA comme référence principale.
À quoi ressemble la réponse de l’API en pratique ?
Voici un exemple simplifié d’appel et de réponse API VoP avec l’API de Digiteal :
Request:
```bash
POST /api/v1/ibanAccountHolderVerification
{
"iban": "BE03130000000184",
"name": "Digiteal SA"
}
```
Response — Match:
```json
{
"vopMatchResult": { "result": "MATCH" },
"bankAccountHolder": { "name": "Digiteal SA" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```
Response — Close match (name provided: "Digiteal", missing the "SA" suffix):
```json
{
"vopMatchResult": { "result": "CLOSE_MATCH" },
"bankAccountHolder": { "name": "Digiteal SA" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```
Response — No match (name provided: "John Doe"):
```json
{
"vopMatchResult": { "result": "NO_MATCH" },
"bank": { "bic": "DIGEBEB2", "name": "DIGITEAL SA" }
}
```
Chaque réponse inclut également un horodatage et un identifiant unique de demande, appelé request-id, dans les en-têtes de réponse, à des fins de piste d’audit.
Comment gérer chaque réponse dans l’UX ?
L’approche recommandée équilibre sécurité et facilité d’utilisation. La VoP est conçue pour informer, pas pour bloquer automatiquement.
| Résultat | Modèle UX recommandé |
|---|---|
| MATCH | PContinuer automatiquement : aucune friction nécessaire. |
| CLOSE_MATCH | Afficher un avertissement avec l’écart détecté. Demander à l’utilisateur de confirmer ou de vérifier avant de poursuivre. |
| NO_MATCH | Bloquer l’action ou imposer une revue manuelle obligatoire, en expliquant clairement pourquoi. |
| NO_AP | Indiquer que la vérification n’a pas été possible pour ce compte. Appliquer d’autres méthodes de vérification si disponibles. |
Un principe de conception essentiel : ne jamais bloquer silencieusement et ne jamais effrayer inutilement. Un close match sur un nom d’entreprise, parce qu’un utilisateur a saisi « Acme Corp » au lieu de « Acme Corporation », n’est pas en soi un signal de fraude. C’est une invitation à vérifier. Votre UX doit faire clairement cette distinction.
Il est tout aussi important de toujours journaliser le résultat VoP, même lorsque le paiement se poursuit. Cela crée une piste d’audit qui démontre la diligence raisonnable, ce qui devient essentiel en cas de litige ou d’enquête.
Comment la VoP gère-t-elle les noms approximatifs, abréviations et caractères spéciaux ?
C’est là que l’intelligence d’une bonne implémentation VoP se révèle.
L’algorithme de correspondance côté banque émettrice gère toute une série de variations courantes :
- Abréviations de formes juridiques, comme SA, SRL, GmbH ou Ltd, qui peuvent être présentes ou absentes.
- Fautes de frappe courantes et erreurs de transposition.
- Caractères accentués et leurs équivalents non accentués.
- Noms commerciaux vs dénominations légales, selon ce que la banque a enregistré.
- Inversion prénom / nom pour les personnes physiques.
Lorsqu’une telle variation est détectée, la réponse est CLOSE_MATCH plutôt que MATCH, ce qui permet à votre système de signaler l’écart à un réviseur humain au lieu de bloquer automatiquement.
Une remarque pratique : la qualité de vos données sortantes compte. Si vos données fournisseurs sont mal entretenues, avec des noms tronqués, d’anciens noms commerciaux ou des suffixes juridiques manquants, vous verrez plus de close matches que nécessaire. L’intégration de la VoP est aussi une occasion de revoir et nettoyer vos données de référence.
Peut-on vérifier toute une base de données fournisseurs en masse ?
Oui. La vérification en masse est l’un des cas d’usage les plus puissants pour les éditeurs de logiciels.
Le scénario typique : une entreprise possède des milliers d’IBAN stockés dans son ERP ou sa plateforme de comptes fournisseurs. Ils n’ont jamais été vérifiés de manière systématique. L’intégration d’une API VoP vous permet de proposer une vérification unique ou périodique de toute la base de données, afin de signaler les enregistrements suspects avant qu’ils n’atteignent une campagne de paiement.
Quelques considérations pratiques pour la vérification en masse :
- Le principe d’intention de paiement reste applicable. Les vérifications en masse sont généralement justifiées comme exercice de gestion des risques dans le contexte d’opérations de paiement à venir.
- Les limites de débit et la tarification au volume doivent être discutées avec votre fournisseur VoP.
- Le résultat d’une vérification en masse doit alimenter un workflow de revue, et non déclencher des suppressions automatiques. Le jugement humain reste nécessaire pour les cas limites.
C’est une fonctionnalité particulièrement convaincante pour les fournisseurs d’ERP et les plateformes de comptes fournisseurs, où un workflow de type « nettoyer vos données bancaires fournisseurs » peut constituer une offre premium à part entière.
Quelle est la couverture géographique ? Qu’en est-il des IBAN hors zone euro ?
Depuis octobre 2025, la VoP est opérationnelle pour les IBAN de la zone euro, c’est-à-dire les 20 États membres de l’UE dont la monnaie est l’euro. Cela couvre la grande majorité du volume de paiements SEPA.
Pour les IBAN issus d’États membres de l’UE hors zone euro, comme la Pologne, le Danemark ou la Tchéquie, la conformité obligatoire arrive en juillet 2027, mais certaines banques de ces pays peuvent déjà prendre en charge la VoP.
Pour les IBAN de pays SEPA non membres de l’UE, comme le Royaume-Uni, la Suisse ou la Norvège, la disponibilité dépend de la participation de chaque banque au schéma VoP de l’EPC.
Lorsqu’une vérification VoP est demandée pour un IBAN dont la banque émettrice n’est pas encore connectée au schéma, la réponse sera NO_AP, c’est-à-dire not applicable.
Votre système doit gérer ce cas avec souplesse : cela ne signifie pas que le paiement est suspect, mais simplement que la vérification n’est actuellement pas disponible pour ce compte.
Combien de temps prend l’intégration ? Quel est l’effort technique réel ?
La réponse courte : quelques jours maximum.
L’API VoP de Digiteal est une interface REST/JSON simple avec Basic Authentication. L’intégration de base, via un seul endpoint POST, peut être réalisée dans n’importe quelle stack de développement moderne.
Des SDK sont disponibles pour Java, .NET, Python et PHP, entre autres.
Ce qui rend la VoP complexe à construire de zéro, ce n’est pas l’appel API lui-même. C’est tout ce qui l’entoure : l’enregistrement au schéma EPC et à l’EDS Directory Service, l’implémentation de la logique de routage RVM pour trouver la bonne banque pour n’importe quel IBAN, le maintien de la conformité au VoP Rulebook de l’EPC au fil de ses évolutions, la soumission de rapports statistiques trimestriels à l’EPC, la gestion de la certification et des tests de conformité…
En intégrant l’API de Digiteal, tout cela est pris en charge pour vous. Votre équipe engineering écrit l’appel API et la logique UX. Nous gérons la plomberie réglementaire.
Un environnement sandbox est disponible dès le premier jour pour les tests d’intégration. Le passage en production est simple, avec un support développeur dédié.
Quel est le modèle économique ? Peut-on monétiser cela auprès de nos propres clients ?
L’intégration VoP peut être structurée de plusieurs façons selon votre modèle produit :
Comme fonctionnalité incluse
Vous absorbez le coût de l’API et positionnez la VoP comme une fonctionnalité de confiance et de sécurité incluse dans votre offre standard. Cela renforce la position concurrentielle de votre produit et peut réduire le churn en rendant votre plateforme plus indispensable pour les clients sensibles aux enjeux finance.
Comme module premium
Vous proposez la VoP comme option complémentaire pour les clients qui souhaitent renforcer la sécurité des paiements. C’est particulièrement pertinent pour les éditeurs d’ERP et de plateformes de comptes fournisseurs dont les clients enterprise subissent eux-mêmes la pression de leurs équipes conformité et risques.
Comme fonctionnalité basée sur l’usage
Pour les plateformes dont les volumes de paiement varient, comme les marketplaces, les fournisseurs de paie ou les plateformes de payout, une tarification par vérification peut être répercutée aux clients, avec ou sans marge.
Le calcul du ROI est simple : un seul virement frauduleux évité, souvent d’une valeur de plusieurs dizaines de milliers d’euros, couvre des années de coûts d’API VoP. Présenté ainsi dans une conversation avec un CFO, la question cesse d’être « est-ce que cela en vaut la peine ? » et devient « pourquoi ne l’avons-nous pas encore fait ? ».
Comment fonctionne l’API VoP de Digiteal ?
Digiteal est un établissement de paiement agréé par la Banque nationale de Belgique et certifié ISO/IEC 27001:2022 pour la gestion de la sécurité de l’information.
Notre service VoP est conforme au VoP Rulebook de l’European Payments Council, ou EPC, et fonctionne dans un environnement de production live avec une garantie de disponibilité assortie d’un SLA.
Le flux de vérification
Quatre points d’intégration dans votre cycle de paiement
Prêt à intégrer la Vérification du nom du bénéficiaire ?
Contactez notre équipe via le formulaire de contact sur notre site web pour demander l’accès à l’environnement sandbox, recevoir vos identifiants API et discuter de vos besoins d’intégration.
