Agent PSP

Définition

Un agent PSP est un mandataire non agréé qui fournit des services de paiement au nom et pour le compte d'un PSP agréé — le « principal », généralement un EP ou un EME.

L'idée tient en une phrase : l'agent n'a pas d'agrément propre, il emprunte celui du principal. Il est simplement inscrit au registre de l'ACPR comme agent d'un principal donné, lequel reste juridiquement responsable des services rendus (CMF art. L. 523-3). C'est le mécanisme qui permet à une fintech de lancer un produit de paiement avant (ou sans jamais) obtenir son propre agrément.

Analogie. C'est le même principe qu'un opérateur mobile virtuel (MVNO) : Sosh ou Lebara vendent des forfaits sous leur marque, mais le réseau appartient à un opérateur agréé (Orange, Bouygues). L'agent PSP vend le compte ou la carte sous sa marque ; « l'usine » réglementée (agrément, comptes, conformité) est celle du principal.

L'essentiel

Agent PSP = un mode d'habilitation : agir sous le mandat (et l'agrément) d'un autre PSP, sans agrément propre.
Le principal (EP ou EME) porte l'agrément, la responsabilité et la conformité ; l'agent porte la marque, l'UX et la relation client.
Les fonds ne sont jamais chez l'agent : ils restent chez le principal.
C'est le véhicule juridique du Banking-as-a-Service européen depuis la DSP2.

TPP vs agent PSP : la confusion à lever

C'est la question la plus fréquente — et elle vient d'un piège : « TPP » et « agent » ne répondent pas à la même question.

TPP décrit ce que je fais → j'accède, avec le consentement du client, aux comptes qu'il détient dans d'autres banques : les lire (AISP), y initier un paiement (PISP) ou vérifier les fonds (CBPII).
Agent décrit comment je suis habilité → je ne suis pas agréé, j'agis sous le mandat d'un PSP (le principal), dans les limites de son agrément.

C'est parce qu'ils sont sur deux axes différents qu'on les confond. Dans la pratique du marché, le contraste est net :

	Agent PSP	TPP
Agrément	Non — emprunte celui du principal	Oui — agréé/enregistré (AISP, PISP, CBPII)
Rôle typique	Distribue le produit d'un PSP sous sa marque	Se branche sur des comptes détenus ailleurs
Où sont les comptes	Chez le principal	Chez la banque du client (ASPSP) — le TPP n'héberge rien
Relation clé	Mandat contractuel agent ↔ principal	API réglementée TPP ↔ banque (ASPSP)
Base réglementaire	DSP2 art. 19 · CMF L. 523-1	DSP2 (AIS, PIS, CBPII)
Exemple	Pixpay, agent de Treezor	Bridge, Tink (AISP + PISP)

Deux nuances importantes, pour être exact :

Un agent peut être mandaté pour de l'AIS ou du PIS au nom d'un PSP qui détient ces agréments (il apparaît alors dans REGAFI). Donc « agent » ne veut pas dire « jamais de fonctions TPP » : la vraie ligne de partage est agrément propre vs mandat, pas le type de service.
Les deux statuts ne s'excluent pas. Une même fintech peut être à la fois agent d'un BaaS (pour offrir son compte et sa carte) et agréée/enregistrée TPP (pour agréger les comptes que ses clients détiennent dans d'autres banques). Qonto, par exemple, a démarré agent d'un BaaS tout en étant AISP pour l'agrégation de comptes externes.

En résumé : le TPP se pose sur des comptes qui existent déjà ailleurs ; l'agent PSP distribue les comptes fabriqués par son principal.

Principal vs agent : qui fait quoi

Principal (EP ou EME) — détient l'agrément, porte la responsabilité réglementaire, opère la conformité (LCB-FT, fonds propres, reporting ACPR).
Agent — distribue le service sous sa marque, gère la relation client (UI, support, marketing), mais ne détient jamais les fonds.

Côté client, l'expérience est transparente : il utilise l'app de l'agent, mais l'argent est techniquement chez le principal. D'où la mention légale obligatoire de la qualité de mandataire (arrêté du 29 octobre 2009, art. 39), du type « comptes ouverts dans les livres de [Principal] ».

Le modèle BaaS en pratique

Le statut d'agent PSP est le véhicule juridique du Banking-as-a-Service européen. Schéma typique :

Une fintech veut lancer un produit (compte, carte, paiements).
Elle devient agent d'un BaaS principal (Treezor, Swan, Modulr, Solaris).
Le BaaS expose une API : ouverture de comptes, KYC, émission de cartes, virements SEPA.
La fintech construit son UX par-dessus et opère le marketing et le support N1.
Le BaaS opère la compliance lourde (LCB-FT, monitoring, reporting ACPR, intégration des réseaux carte).

Résultat : un lancement en 3 à 6 mois, là où l'agrément en propre demanderait 18 à 24 mois.

Inscription et obligations

C'est le principal qui déclare l'agent à l'ACPR (aucun échange direct ACPR ↔ agent). L'agent ne peut opérer qu'une fois inscrit dans REGAFI. L'enregistrement suppose :

une vérification d'honorabilité et de compétence des dirigeants de l'agent (arrêté du 29 octobre 2009, art. 36) ;
un contrôle interne du principal couvrant les activités de l'agent (l'activité d'agent est une prestation essentielle externalisée) ;
un contrat écrit agent-principal détaillé (responsabilités, audit ACPR, fraude, données, LCB-FT), conforme aux orientations EBA sur l'externalisation ;
une mention transparente de la qualité de mandataire côté client ;
une formation LCB-FT des équipes de l'agent.

Le principal reste pleinement responsable des manquements de son agent.

Ce qu'un agent PSP n'est pas

Pas un PSP au sens propre : ni agrément, ni fonds propres réglementaires — il agit sous le mandat d'un autre.
Pas un simple apporteur d'affaires : il opère réellement un service de paiement, pas seulement de la prescription.
Pas un TPP par nature : un TPP a son propre agrément et se branche sur des comptes tiers ; l'agent emprunte l'agrément d'un principal et distribue les produits de ce principal (voir la section dédiée ci-dessus).
Pas un statut figé : beaucoup de fintechs commencent agent, obtiennent leur agrément EP/EME, puis migrent leurs comptes en propre — une phase de rebackbone souvent longue (12 à 18 mois).

Agent de PSP vs distributeur de monnaie électronique

Nuance essentielle quand le principal est un EME (Treezor, Swan…) : le partenaire n'est pas forcément un « agent de PSP », mais souvent un distributeur de monnaie électronique (CMF art. L. 525-8 et s.). Deux régimes voisins mais distincts :

Agent de PSP (L. 523-1) — pour fournir des services de paiement (compte, virement, prélèvement) au nom d'un PSP. Enregistrement REGAFI obligatoire.
Distributeur de monnaie électronique (L. 525-8) — pour mettre en circulation / rembourser l'e-money émise par un EME (typiquement les cartes et wallets). Mandaté en France par un EME français, il n'est pas enregistré à l'ACPR (pas dans REGAFI).

En pratique, une même fintech adossée à un EME peut cumuler les deux casquettes : agent pour la partie « services de paiement », distributeur pour la partie « e-money ». C'est pour ça que Swan communique « aucune licence d'agent n'est requise » : la brique carte/e-money passe par le régime distributeur, plus léger.

IOBSP vs agent PSP

Autre confusion fréquente :

Agent PSP — distribue des services de paiement (compte, carte, virement) au nom d'un PSP.
IOBSP — distribue du crédit ou des services bancaires (prêt immo, conso, regroupement) au nom d'un EC.

Statuts, registres (REGAFI vs ORIAS) et responsabilités distincts.

Dans l'écosystème PSD2

L'agent PSP est le lubrifiant de l'écosystème fintech : depuis 2018, il a porté l'explosion du BaaS, et donc l'arrivée de centaines de néobanques verticales (compte freelance, voyage, ado, enfant) sans multiplier les agréments.

Exemples concrets

Le cas d'école — Qonto / Treezor : Qonto a démarré comme agent de Treezor en 2017 avant d'obtenir son propre agrément EP en 2018. Pendant ces ~18 mois, tous les comptes Qonto étaient juridiquement dans les livres de Treezor ; Qonto ne portait que la marque, l'app et le support. C'est le parcours « agent d'abord, agrément ensuite » dans sa forme la plus pure.
Pixpay / Treezor (compte ado) : lancé comme partenaire de Treezor — le principal porte le risque et la conformité, Pixpay la marque et l'UX. Racheté par GoHenry en juillet 2022. Illustre le BaaS pour une néobanque verticale.
Indy / Swan et Pennylane / Swan (comptes pro) : Indy propose un compte pro gratuit et Pennylane un compte adossé à sa suite compta, tous deux via Swan (EME). Attention à la qualification : Swan étant un EME, ces partenaires relèvent surtout du distributeur de monnaie électronique (carte/e-money), pas de l'« agent de PSP » stricto sensu — d'où le slogan de Swan « aucune licence d'agent n'est requise ». Le principe économique reste le même : la fintech porte l'UX, l'EME porte l'agrément et les fonds (cantonnés chez BNP Paribas pour Swan).
Agent vs TPP dans la vraie vie : Pixpay (distribue son compte via un BaaS) ≠ Bridge ou Tink (TPP agréés, qui se branchent sur les comptes que le client détient déjà dans sa banque). Une même app peut cumuler les deux : compte maison via un BaaS + agrégation des comptes externes via un agrément AISP.
Marché BaaS : Treezor (FR, filiale Société Générale, ~100 partenaires), Swan (FR, EME, plutôt B2B et SaaS verticaux), Modulr (UK), Solaris (DE), Railsr (UK) — chacun héberge des dizaines à des centaines de fintechs, sous statut agent et/ou distributeur d'e-money selon la brique.
Limite du modèle : inadapté à ceux qui veulent internaliser le risque crédit (qui doivent passer EC), d'où la trajectoire de Qonto vers l'EC.
Coût pour la fintech : pas de capital réglementaire, mais un revenue share ou des frais par compte / carte / transaction. Économique au départ, plus cher à l'échelle — d'où la migration vers l'agrément propre.
Risque de rupture : la défaillance d'un BaaS principal (cas Wirecard, 2020) gèle instantanément tous ses partenaires. DORA impose désormais un plan de continuité incluant la sortie du BaaS.