Glossaire

Open banking

Tokénisation
left arrow icon

Remplacer une donnée sensible, par exemple un numéro de carte, par un jeton de substitution dépourvu de sens exploitable hors du système qui l'a émis.

Lorsqu'une carte est ajoutée à un portefeuille mobile, l'appareil stocke un jeton et non le PAN réel. Intercepté, ce jeton ne peut pas être utilisé ailleurs.

La tokénisation réduit le périmètre de données qu'un commerçant doit protéger, puisque le numéro de carte réel n'atteint jamais ses systèmes.

Environnement sandbox
left arrow icon

Un environnement de test isolé qui reproduit l'API d'une banque ou d'un prestataire, avec des données fictives, afin que les développeurs construisent et testent une intégration sans toucher à de vrais comptes.

Sous la DSP2, les banques doivent mettre un dispositif de test à disposition des tiers avant la mise en production. Un sandbox sert aussi à valider une intégration après qu'une banque a modifié son interface.

Le terme désigne aussi les sandboxes réglementaires, où un superviseur autorise des entreprises à tester des services innovants dans un cadre assoupli. Les deux sens n'ont pas de rapport.

Fintech
left arrow icon

Technologie financière : le recours au logiciel et à l'infrastructure numérique pour fournir des services financiers, souvent par des entreprises extérieures à la banque traditionnelle.

Le terme couvre les paiements, le crédit, le placement, l'assurance, l'automatisation comptable et l'infrastructure d'open banking qui les relie.

Il décrit une approche plutôt qu'un secteur : les banques établies exploitent aussi des produits fintech, et la frontière entre une fintech et une banque bien outillée a largement cessé d'être utile.

Finance embarquée
left arrow icon

Des services financiers proposés au sein d'un produit non financier, au moment où ils sont utiles, plutôt que via une banque ou un prestataire distinct.

Exemples : le paiement en plusieurs fois à la caisse d'un site marchand, une assurance proposée lors d'une réservation, ou un outil comptable qui permet de régler une facture fournisseur sans quitter le logiciel.

La finance embarquée est ce que l'infrastructure BaaS sert généralement à construire.

BaaS
left arrow icon

Banking as a Service : des banques agréées mettent leur infrastructure réglementée à disposition d'acteurs non bancaires, afin qu'une autre entreprise puisse proposer comptes, cartes ou paiements sous sa propre marque.

La banque détient l'agrément et porte les obligations réglementaires, tandis que le partenaire garde la relation client et l'interface. Un commerçant qui propose une carte à son enseigne s'appuie généralement sur un dispositif BaaS plutôt que sur une licence bancaire propre.

Portabilité des données
left arrow icon

Le droit des personnes d'obtenir leurs données personnelles dans un format structuré, couramment utilisé et lisible par machine, et de les faire transférer à un autre prestataire.

Dans l'UE, ce droit découle du RGPD. En Suisse, la loi fédérale révisée sur la protection des données, en vigueur depuis septembre 2023, a introduit un droit équivalent.

Appliquée à la banque, la portabilité est le principe qui permet d'emporter son historique de transactions en changeant de prestataire, au lieu de le laisser derrière soi.

Gestion du consentement
left arrow icon

Les processus par lesquels un client accorde, consulte et retire l'autorisation donnée à un tiers d'accéder à ses données financières ou d'initier des paiements.

Le consentement doit être explicite, limité à une portée et une durée définies, et révocable à tout moment. Sous la DSP2, un consentement d'accès est limité dans le temps et doit être renouvelé, raison pour laquelle les connexions d'agrégation s'interrompent périodiquement et exigent une nouvelle authentification.

Une bonne gestion du consentement permet au client de voir d'un coup d'œil qui accède à quoi, et d'y mettre fin en une étape.

Agrégation de données financières
left arrow icon

Collecter et consolider des données financières provenant de plusieurs banques ou sources, généralement via des API, en une vue unique.

Pour une entreprise disposant de comptes dans trois banques, l'agrégation produit une position de trésorerie consolidée au lieu de trois connexions distinctes. C'est le service que permet un agrément AISP, et le socle sur lequel reposent les outils de trésorerie et de comptabilité.

Agrégateur d'API
left arrow icon

Un prestataire qui se connecte à de nombreuses banques et les expose via une interface unique, de sorte qu'un éditeur logiciel s'intègre une seule fois au lieu de banque par banque.

L'agrégateur absorbe les différences entre établissements : normes d'API, parcours d'authentification, formats de données et couverture variables. Sans lui, prendre en charge vingt banques suppose vingt intégrations à construire et à maintenir.

En contrepartie, l'entreprise accepte une dépendance et un coût par connexion, en échange de l'effort d'ingénierie économisé.

API bancaire
left arrow icon

Une interface publiée par une banque qui permet à un logiciel externe autorisé d'interroger directement les données de compte ou de soumettre des paiements, sans passer par un transfert de fichiers ni un portail web.

En Suisse, la plupart des API bancaires sont atteintes via bLink, la plateforme de SIX qui standardise la connexion : un éditeur logiciel s'intègre une fois plutôt qu'avec chaque banque séparément.

Pour la comptabilité, c'est une API bancaire qui fait apparaître les transactions automatiquement, là où EBICS ou le camt.053 supposent de récupérer puis d'importer un fichier.

API
left arrow icon

Interface de programmation applicative : une manière définie, pour un logiciel, de demander des données ou des actions à un autre, sans intervention humaine.

Une API précise ce qui peut être demandé, dans quel format, et ce qui est renvoyé. C'est ce contrat qui permet à des systèmes conçus par des entreprises différentes de fonctionner ensemble de manière fiable.

En finance, les API ont remplacé les téléchargements de fichiers et les ressaisies : au lieu d'exporter un relevé pour l'importer ailleurs, un système interroge directement l'autre.

OBIE
left arrow icon

L'organisme créé en 2016 par l'autorité britannique de la concurrence pour élaborer les normes d'open banking des neuf plus grandes banques du Royaume-Uni.

Il a produit l'Open Banking Standard, l'une des premières spécifications d'API détaillées du genre, dont l'influence a dépassé le Royaume-Uni.

L'OBIE a cédé la place en 2022 à Open Banking Limited, qui poursuit ces travaux. Le sigle figure encore dans la documentation ancienne.

RTS
left arrow icon

Normes techniques de réglementation : les règles contraignantes et détaillées qui précisent comment un texte européen doit être appliqué en pratique.

En open banking, les RTS sur l'authentification forte et la communication sécurisée définissent le fonctionnement de la SCA, les exemptions applicables et ce que l'interface d'une banque destinée aux tiers doit permettre. Elles sont rédigées par l'Autorité bancaire européenne et adoptées par la Commission.

La distinction compte : la directive pose le principe, les RTS déterminent ce qu'un prestataire doit effectivement construire.

SCA (authentification forte)
left arrow icon

Authentification forte du client : l'exigence posée par la DSP2 de confirmer les paiements électroniques et les accès aux comptes par au moins deux facteurs indépendants.

Les trois catégories sont :

  • Connaissance : ce que seul l'utilisateur sait, comme un mot de passe ou un code.
  • Possession : ce que seul l'utilisateur détient, comme un téléphone ou un lecteur de carte.
  • Inhérence : ce que l'utilisateur est, comme une empreinte ou un visage.

Les deux facteurs doivent relever de catégories différentes, raison pour laquelle un mot de passe assorti d'une question secrète ne suffit pas. Certains paiements de faible montant ou récurrents bénéficient d'exemptions.

PIS
left arrow icon

Service d'initiation de paiement : le service réglementé, défini par la DSP2, par lequel un tiers initie un paiement pour le compte d'un client, directement depuis son compte bancaire.

Exemple : régler une facture en ligne directement depuis un compte bancaire via une application tierce, sans saisir de données de carte.

Prestataires : des PISP comme Tink, Token ou TrueLayer.

L'intérêt tient au coût et à la rapidité : le paiement emprunte les rails bancaires, sans commission d'interchange, et le commerçant voit les fonds plus tôt.

PISP
left arrow icon

Prestataire de services d'initiation de paiement : un tiers agréé pour initier un paiement directement depuis le compte bancaire d'un client, avec son consentement.

Le client autorise le paiement dans sa propre application bancaire, et les fonds circulent par virement plutôt que via un réseau de cartes. Comme aucun schéma de carte ne s'interpose, les frais sont généralement plus bas.

Les PISP doivent détenir un agrément complet d'établissement de paiement, régime plus lourd que le simple enregistrement des AISP, puisqu'ils déplacent des fonds et ne se contentent pas de lire des données.

AISP
left arrow icon

Prestataire de services d'information sur les comptes : un tiers agréé pour consulter les données du compte bancaire d'un client, avec son consentement, mais sans pouvoir déplacer de fonds.

C'est l'agrément qui sous-tend les applications d'agrégation de comptes, les outils de budget et l'import automatique des transactions dans un logiciel comptable. Sous la DSP2, un AISP s'enregistre sans détenir un agrément complet d'établissement de paiement : un régime plus léger que celui des PISP.

TPP
left arrow icon

Prestataire tiers : une entreprise autorisée, sous la DSP2, à accéder aux comptes bancaires pour le compte d'un client, sans être la banque qui tient le compte.

Les TPP relèvent de deux catégories d'agrément, qu'un prestataire peut détenir séparément ou cumulativement :

  • AISP : peut consulter les informations de compte.
  • PISP : peut initier des paiements.

Les TPP sont surveillés et doivent être agréés par une autorité nationale avant de pouvoir se connecter aux banques.

DSP2
left arrow icon

La deuxième directive européenne sur les services de paiement, en vigueur depuis 2018, qui a créé la base légale de l'open banking en Europe.

Elle oblige les banques à donner accès aux comptes de paiement à des tiers agréés avec le consentement du client, a créé les catégories d'agrément AISP et PISP, et a imposé l'authentification forte pour les paiements électroniques.

La DSP2 ne s'applique pas à la Suisse, qui n'est pas membre de l'UE. Les banques suisses ouvrent leurs interfaces par accord commercial et non par obligation légale.

La suite : la DSP2 doit être remplacée par un paquet de deux textes, la directive DSP3 et le règlement sur les services de paiement (PSR), d'application directe. Un accord politique a été trouvé en novembre 2025 et la commission parlementaire a approuvé les textes en mai 2026, mais l'adoption formelle et la publication restaient pendantes : la DSP2 demeure donc le cadre en vigueur. L'application est attendue environ 21 mois après publication.

Open finance
left arrow icon

L'extension des principes de l'open banking au-delà des comptes de paiement : épargne, prévoyance, assurance, hypothèques et placements, de sorte qu'un client puisse autoriser l'accès à l'ensemble de sa situation financière.

Dans l'UE, c'est l'objectif du cadre proposé sur l'accès aux données financières (FiDA), encore en négociation. L'open banking couvre le compte courant ; l'open finance couvrirait tout le reste.

Open banking
left arrow icon

La pratique consistant, pour les banques, à ouvrir l'accès aux données de compte et à l'initiation de paiements à des tiers agréés, avec le consentement explicite du client, via des API sécurisées.

Dans l'UE, cette ouverture est imposée par la DSP2 : les banques doivent donner accès aux comptes de paiement aux prestataires autorisés. La Suisse a suivi une autre voie. Il n'existe pas d'obligation légale équivalente, et l'accès se développe par le marché, notamment via bLink, la plateforme de SIX par laquelle les banques suisses exposent des interfaces standardisées.

Pour un fiduciaire, la conséquence pratique est que les données bancaires peuvent alimenter automatiquement le logiciel comptable, au lieu d'être téléchargées puis importées à la main.