Quelle place tiennent les API dans le modèle de Fidor ?
Lorsque Fidor a été lancé en 2009, l’objectif était de créer une expérience où le client était au centre de l’offre et pouvait échanger avec la communauté sur le thème des finances personnelles. Nous voulions donc créer une banque, mais sans pour autant développer l’ensemble des services par nous-mêmes. Nous avons obtenu une licence bancaire auprès de la BaFin allemande et décidé d’être un guichet unique offrant des services produits, soit par Fidor (compte bancaire, compte à terme…), soit par des tiers spécialistes. Nous offrons ainsi à nos clients l’achat de devises et de métaux précieux, respectivement grâce à Currency Cloud et Gold Money. Les deux FinTechs interviennent en marque blanche et nous utilisons leurs API pour nous connecter à leur système. Nous avons également une relation moins intégrée avec des plates-formes de crowdfunding et de peer-to-peer lending. Il s’agit davantage, dans ce cas, d’affiliation : la FinTech peut ainsi utiliser notre API pour permettre à son prospect, par ailleurs client de Fidor, de s’inscrire sans avoir à ressaisir l’ensemble de ses informations. Nous partageons notre KYC. Les API sont donc au cœur de notre ADN.
D’autres acteurs que les FinTechs sont-ils connectés à vous via des API ?
Suite au succès de la banque Fidor, des banques, des opérateurs téléphoniques et des distributeurs sont venus nous trouver pour utiliser notre plate-forme. Nous sommes ainsi devenus fournisseur de solutions technologiques pour des groupes comme l’opérateur O2 en Allemagne ou l’ADIB (Abu Dhabi Islamic Bank) au Moyen-Orient. Dans ce dernier cas, nous ne fournissons que la technologie. Dans le premier, nous apportons aussi à O2 notre licence bancaire – et donc notre bilan pour porter les crédits –, notre service-client et notre marketing. Nous leur offrons une banque clés en main leur permettant de monétiser leur audience.
Vos clients peuvent-ils directement utiliser vos API ?
Oui, s’ils le veulent, la condition étant qu’ils soient développeurs. Certains clients entreprises choisissent ainsi d’importer leurs transactions directement sur leur plate-forme comptable. Les API sont accessibles sur un site dédié aux développeurs (connect.fidor.com) auquel il est possible d’accéder, tout d’abord via un « bac à sable », pour tester, avant d’opter pour une version payante.
Qu’apportent les API par rapport à un core banking system traditionnel ?
Elles apportent davantage de flexibilité : on peut arrêter un service, le reprendre, le remplacer sans tout recommencer. C’est très modulaire. Avec les systèmes bancaires créés dans les années 1970, changer quelques lignes de code d’un service peut en perturber un autre, car tout est interdépendant. Sans compter le fait que l’historique des intégrations s’est perdu au fur et à mesure des départs des personnes ayant développé ces lignes de code.
La plate-forme logicielle (Fidor.com) a-t-elle pour vocation de devenir votre activité principale, par rapport à la banque de plein exercice ?
Non, c’est une filiale au même titre que Fidor Bank. Cette dernière porte l’innovation, lance de nouveaux produits, prouve que les concepts fonctionnent.
Que va changer la DSP 2 pour Fidor ?
À travers nos API existantes, nous sommes d’ores et déjà plus ouverts que ce qu’exige la DSP 2.
Une étude récente de Temenos et Capgemini chiffre à 69 % la part des banquiers qui voient l’« open banking » comme une opportunité et non comme une menace, contre 52 % en
C’est encore compliqué pour elles. Il existe des blocages technologiques : elles doivent réorganiser leur core banking system, tant les données elles-mêmes (back-end) que les interfaces pour y accéder (front-end). Ce sont d’importants investissements et elles ont du mal à savoir par où commencer. Il y a également des freins culturels : le management peine à voir les avantages de l’ouverture. Pourtant, elle peut leur offrir de nouvelles sources de revenus. Les banques devraient aller au-delà de ce que la DSP 2 leur impose, à savoir l’accès au compte (solde, vérification de la disponibilité des fonds, vérification du compte…), et proposer des services payants, comme le transfert d’argent en temps réel, les paiements conditionnés ou encore les vérifications de KYC.
Vous êtes basée à Londres. Quel est le travail de la Place britannique sur le sujet des API ?
L’industrie élabore des recommandations au gouvernement britannique sur la manière de mettre en place des API ouvertes. Il s’agit de l’Open Banking Initiative. Elle se tient en parallèle des travaux européens autour de la DSP 2 avec des experts de l’industrie britannique. Il ne faut toutefois pas perdre de vue qu’il est impossible aujourd’hui de dire ce qui sera inventé demain grâce à ces API ouvertes. D’où la difficulté de devoir réglementer une matière aussi mouvante.
La mise en place d’un standard européen pour ces API vous semble-t-il important ?
Oui, indéniablement. Il faut s’assurer que les tiers n’auront pas à s’adapter aux formats de chaque banque et que la connexion aux différents SI bancaires se fera facilement. C’est important aussi pour les banques elles-mêmes qui perdront sinon du temps et de l’argent à répondre aux multiples demandes de ces tiers.
La multiplication des standards est donc un des écueils pour les FinTechs qui voudront bénéficier de l’open banking. Y en a-t-il d’autres ?
Recruter des spécialistes de la DSP 2 est coûteux pour ces start-up de la finance. De plus, elles devront se mettre en conformité dans un laps de temps très court, ce qui leur sera difficile, étant donné leurs ressources limitées. Enfin, la question de l’évolution de leur modèle économique se pose, à l’instar de celui des agrégateurs : les connexions qu’ils avaient établies une à une avec chaque banque vont être ouvertes d’un coup à tous, à l’entrée en vigueur de la DSP 2, ce qui les expose à une concurrence nouvelle frontale.
