Faut-il une licence bancaire pour lancer une app fintech ?

« Faut-il une licence bancaire pour lancer une app fintech ? » recouvre en réalité trois questions sous un même manteau. Détenez-vous l'argent des clients ? Le faites-vous circuler ? Et quel agrément réglementaire couvre ce mouvement — le vôtre, ou celui d'un autre ? Répondez-y et la question de la licence se résout presque d'elle-même. La version courte, qui surprend la plupart des équipes : la majorité des apps fintech n'ont jamais de licence bancaire, car la majorité d'entre elles ne font jamais la seule chose pour laquelle une licence bancaire existe. Ce qui suit est une carte du spectre, pas un conseil juridique — l'objectif est de savoir quelles questions poser avant que quiconque vous annonce un délai ou un prix.

À quoi sert vraiment une licence bancaire

Une licence bancaire complète — dans la terminologie européenne, un agrément d'établissement de crédit — autorise une activité précise et étroitement encadrée : recevoir des dépôts du public et prêter cet argent. Cette transformation d'échéances, qui consiste à financer des prêts longs avec des soldes que les clients peuvent retirer à tout moment, explique pourquoi les banques supportent de lourdes exigences de capital, des obligations de garantie des dépôts et un superviseur qui lit leur bilan ligne à ligne. Si votre app ne reçoit pas de dépôts pour prêter en face, vous n'avez presque certainement pas besoin d'une licence bancaire. Vous relevez d'un statut plus léger, plus loin dans le spectre — et le spectre, c'est toute l'histoire.

Le spectre des autorisations, du plus lourd au plus léger

Les autorisations financières se déclinent en niveaux. Tout en haut, l'établissement de crédit — la banque — peut recevoir des dépôts et accorder des prêts. En dessous, l'établissement de monnaie électronique (EME) peut émettre de la monnaie électronique : il peut conserver la valeur de ses clients et la placer sur des cartes ou dans des wallets, mais les fonds qu'il détient doivent être cantonnés — séparés et intouchables, jamais prêtés. Plus bas, l'établissement de paiement (EP) peut exécuter des paiements — initier des virements, encaisser, transférer des fonds, acquérir des transactions par carte — mais n'est pas conçu pour conserver de la valeur dans la durée ; l'argent transite, il ne reste pas. Enfin, tout en bas, l'agent ou distributeur ne détient aucun agrément propre : il opère sous l'autorisation d'une entité agréée qui l'a enregistré.

La logique : chaque échelon vers le bas abandonne une capacité et, avec elle, une part de capital et d'obligations. Détenir des dépôts est ce qu'il y a de plus lourd à pouvoir faire ; être l'agent de quelqu'un qui le peut est ce qu'il y a de plus léger. La plupart des applications fintech grand public — wallets, cartes, virements, liens de paiement — se situent dans la zone EME et établissement de paiement, ou s'appuient sur un partenaire qui détient l'une de ces autorisations. Très peu ont besoin d'être une banque, et le savoir tôt évite beaucoup d'efforts mal dirigés.

Pour vous situer rapidement : si vos clients conservent un solde dans l'application — un wallet qu'ils alimentent, une carte qu'ils préchargent — vous êtes sur le terrain de la monnaie électronique, car la conservation de valeur est ce qui définit un EME. Si l'argent ne fait que transiter — vous initiez un virement, encaissez une facture, reversez un paiement directement — un agrément d'établissement de paiement est le choix naturel, détenu par vous ou par un partenaire. Si vous ne touchez jamais aux fonds et vous contentez de présenter des informations sur des comptes détenus ailleurs, même cela relève d'un enregistrement plus léger. Plus votre position est lourde, plus le capital et la supervision suivent ; l'objectif de conception est de ne pas être plus lourd que ce que le produit exige réellement.

Louer l'autorisation : les modèles partenaires

Vous n'avez pas besoin de détenir vous-même l'autorisation pour construire dessus. La voie la plus courante est de la louer. Dans un schéma de banque sponsor ou de Banking-as-a-Service, une banque ou un EME agréé tient les comptes, émet les IBAN et les cartes, et cantonne les fonds ; vous développez l'application sur leur API et livrez l'expérience. Dans un modèle d'agent, vous vous enregistrez comme agent d'un établissement de paiement — ou comme distributeur d'un émetteur de monnaie électronique — et leur agrément couvre votre activité, le régulateur vous connaissant par leur intermédiaire. Des contrats différents, un même fait sous-jacent : quelque part dans la chaîne, quelqu'un détient l'autorisation. La seule question est de savoir si c'est vous ou un partenaire.

Qui porte quelle responsabilité

Louer un agrément ne revient pas à se décharger de la responsabilité. L'entité agréée est celle qui répond devant le régulateur — de la protection des fonds clients, de la surveillance anti-blanchiment, de la conduite de l'ensemble du programme. Mais ces obligations descendent en cascade par contrat. Si vous vous appuyez sur l'agrément d'un partenaire, vous menez toujours le KYC et l'onboarding, surveillez toujours les transactions au titre de l'AML, respectez toujours les plafonds et les reportings auxquels le partenaire est tenu. La responsabilité n'est pas tant externalisée que répartie : le partenaire en répond devant le régulateur et vous tient, vous, par un contrat qui rejette une grande part du devoir quotidien de votre côté. Lisez ce contrat aussi attentivement que vous liriez l'agrément que vous avez choisi de ne pas obtenir.

Un agrément est l'autorisation de détenir ou de transférer l'argent d'autrui. Le logiciel est ce qui permet de donner les instructions, de réconcilier et de restituer cet argent au client. Vous pouvez les acheter auprès d'un fournisseur ou de deux — mais vous achetez toujours les deux.

Le logiciel et l'agrément sont deux achats distincts

C'est la prise de conscience qui réorganise tout le projet. Une application de paiement ressemble à une seule chose pour le client, mais elle en fusionne deux : l'autorisation réglementée de détenir ou de transférer de l'argent, et le logiciel qui commande les mouvements, tient le registre, réconcilie les crédits et affiche un solde à l'écran. Ces deux éléments s'obtiennent séparément. Vous pouvez détenir votre propre agrément et acheter le logiciel ; détenir un agrément et développer le logiciel en interne ; louer l'autorisation via un partenaire et acheter un logiciel par-dessus ; ou prendre les deux chez un seul fournisseur qui les a regroupés. Les quatre cas sont normaux. Ce qui ne l'est pas — et ce qui coûte discrètement des mois aux projets — c'est de confondre les deux : chercher une « licence bancaire » alors qu'il vous fallait un partenaire BaaS et une application, ou chercher une application en supposant que l'autorisation y est soudée.

Voir ces deux achats comme distincts clarifie les choses, car cela permet de les chiffrer et de les planifier indépendamment. Le logiciel se juge sur ses mérites — le parcours d'onboarding fonctionne-t-il, le registre est-il juste, les opérateurs peuvent-ils vraiment l'exploiter — tandis que l'autorisation se juge sur la juridiction, le cantonnement et les conditions. Protocore Pay (/products/pay) illustre la couche logicielle seule : une plateforme d'applications whitelabel et une console opérateur qui tournent sur les rails réglementés que vous apportez. Ce n'est pas un agrément, et aucun logiciel n'en est un — c'est précisément pourquoi l'agrément reste une ligne distincte du plan.

Questions à poser à tout éditeur de plateforme

Quel que soit celui qui vous vend une plateforme pour « lancer votre fintech », la même courte liste lève l'essentiel des ambiguïtés. Votre produit inclut-il une autorisation réglementée, ou dois-je apporter la mienne ? S'il en inclut une, de qui est l'agrément, dans quels pays, et suis-je client direct de cette entité ou de son agent ? Qui cantonne les fonds clients, et où sont-ils conservés ? Qui est désigné auprès du régulateur pour la lutte anti-blanchiment — vous, le partenaire ou moi ? Quelles obligations me reviennent par contrat alors que l'agrément n'est pas le mien ? Et si le partenariat prend fin, que deviennent l'argent de mes clients et leurs données ? Les réponses classent vite les fournisseurs entre ceux qui vendent du logiciel, ceux qui revendent l'autorisation d'un partenaire et ceux qui ont réellement regroupé les deux — et vous disent à qui vous avez réellement affaire.

Le côté rassurant : la plupart des applications se lancent avec un logiciel plus l'autorisation d'un partenaire, et ne passent à leur propre agrément que lorsque le volume, la marge ou la stratégie justifient le capital et les équipes de conformité. Savoir quel échelon vous est réellement nécessaire — et que logiciel et autorisation s'achètent sur des lignes séparées — c'est l'essentiel du travail. Le reste consiste à poser les questions ci-dessus et à lire attentivement les réponses. Rien de tout cela ne constitue un conseil juridique, et les seuils comme les noms de catégories varient selon la juridiction ; voyez-y la carte à apporter dans la discussion avec un régulateur ou un conseil, pas un substitut.