Un établissement de paiement agréé n’est pas une entreprise comme les autres. Son bilan coexiste avec des fonds clients qu’il ne possède pas. Son reporting trimestriel répond à l’ACPR, pas seulement à un commissaire aux comptes. Et depuis janvier 2025, DORA lui impose un cadre de résilience numérique que peu de DSI de fintechs avaient anticipé.
Résultat : quand un CFO ou CTO d’une fintech réglementée cherche un ERP ou un SI financier, il ne peut pas appliquer les mêmes critères qu’une PME industrielle. Les besoins en comptabilité de ségrégation, en traçabilité réglementaire et en auditabilité des fonds transforment radicalement le cahier des charges.
Ce guide est écrit pour les équipes dirigeantes d’établissements de paiement (EP), d’établissements de monnaie électronique (EME), d’intermédiaires en financement participatif (IFP) et de conseillers en investissement financier (CIF) agréés par l’ACPR — des entités qui doivent concilier une comptabilité rigoureuse, des obligations prudentielles contraignantes et une architecture SI capable de tenir la cadence à mesure que les volumes progressent.
Le SI d’une fintech réglementée : un cas à part
Ce qui distingue un EP/EME d’une entreprise classique côté SI
Une entreprise industrielle ou une société de services utilise son ERP pour gérer les achats, les ventes, la production et la comptabilité. Les fonds transitent entre un compte fournisseurs et un compte clients, et le bilan reflète la réalité économique de l’entité.
Un établissement de paiement fonctionne différemment. Il reçoit des fonds de ses clients, les conserve temporairement, les achemine vers des bénéficiaires et prélève une commission sur ce flux. Ces fonds clients ne lui appartiennent pas — ils constituent une dette envers les utilisateurs et doivent être maintenus séparés de ses propres actifs. Cette ségrégation obligatoire, appelée cantonnement, est le pivot de toute l’architecture comptable et SI d’un EP.
Sans un SI conçu pour refléter cette dualité — fonds propres de l’entité d’un côté, fonds clients cantonnés de l’autre — la conformité quotidienne devient impossible à tenir. Un simple ERP standard paramétré à la va-vite ne suffit pas.
Quelles entités sont concernées par ce guide
En France, les entités soumises à ces contraintes recouvrent plusieurs statuts réglementaires distincts :
- Établissements de paiement (EP) — agréés pour exécuter des virements, prélèvements, paiements par carte, services d’initiation de paiement ou services d’information sur les comptes (DSP2 / PSR)
- Établissements de monnaie électronique (EME) — émettent de la monnaie électronique (portefeuilles numériques, cartes prépayées)
- Établissements de crédit spécialisés — sociétés de financement agréées pour certaines opérations de crédit
- IFP et CIF — intermédiaires en financement participatif et conseillers en investissements, sous régime d’enregistrement ou d’agrément allégé mais avec des obligations de conformité analogues
Tous ces acteurs figurent dans le registre public REGAFI — désormais intégré à regafi.fr, le nouveau portail unique banque et assurance lancé par l’ACPR en juillet 2026 — et sont placés sous la supervision de l’Autorité de contrôle prudentiel et de résolution (ACPR).
Les 4 contraintes réglementaires qui structurent le choix ERP
Cantonnement des fonds clients (obligation Article L. 522-17 CMF)
Le cantonnement est l’exigence qui distingue le plus radicalement le SI d’un établissement de paiement de celui d’une entreprise ordinaire. L’article L. 522-17 du Code monétaire et financier impose que les fonds reçus des clients restent séparés des actifs propres de l’établissement.
Concrètement, cela signifie que dès la fin du jour ouvré suivant la réception des fonds, le montant correspondant doit être déposé sur un compte ouvert auprès d’un établissement de crédit autorisé, clairement identifié comme compte de cantonnement dans la convention d’ouverture. Il ne peut pas être utilisé pour financer les opérations courantes de la fintech.
Pour le SI, cela implique :
- Un plan de comptes capable de distinguer à tout moment “fonds propres de la fintech” et “fonds clients cantonnés”
- Un rapprochement quotidien entre le solde du ou des comptes cantonnés et la somme des engagements envers les clients (ce que l’ERP doit calculer automatiquement)
- Des journaux d’audit permettant de reconstituer chaque mouvement de fonds en cas de contrôle ACPR ou d’insolvabilité
L’ACPR vérifie la correspondance entre les montants cantonnés et les fonds réellement dus aux clients à travers ses contrôles périodiques. Un écart persistant peut déclencher une mise en demeure. La traçabilité des IBAN virtuels (un IBAN par client ou par wallet) est devenue une bonne pratique fortement recommandée, car elle permet un rapprochement automatisé ligne à ligne.
Reporting prudentiel ACPR : fonds propres, ratios, rapport annuel
Au-delà de la comptabilité quotidienne, l’ACPR exige un reporting prudentiel régulier. Pour un EP, ce reporting porte sur :
- Les fonds propres réglementaires, qui doivent être supérieurs au plus élevé entre le capital initial minimum et le capital calculé selon l’une des trois méthodes de l’annexe I de la directive (méthode A, B ou C selon le type de services)
- Le ratio de couverture des fonds propres par rapport au volume de paiements traités (TPO — volume total des opérations de paiement)
- Le rapport annuel de contrôle interne transmis à l’ACPR
L’ERP ou le SI comptable doit permettre de calculer et d’exporter ces indicateurs selon les formats exigés. La plupart des EP s’appuient sur un module comptable standard augmenté de tableaux de bord spécifiques, développés en interne ou par leur intégrateur. Il n’existe pas encore d’ERP du marché PME qui couvre nativement ce reporting sans paramétrage dédié.
LCB-FT et sanctions : KYC/KYB connecté à l’ERP
La lutte contre le blanchiment et le financement du terrorisme (LCB-FT) impose aux EP et EME des obligations de vérification de l’identité des clients (KYC pour les particuliers, KYB pour les entreprises) et de surveillance des transactions. Ces obligations s’appliquent dès l’entrée en relation et tout au long du cycle de vie du client.
Le SI de la fintech doit intégrer ou se connecter à un moteur KYC/KYB (Sumsub, Ondato, ComplyCube, ou développement interne), et l’ERP doit être capable de bloquer ou de suspendre des flux de paiement en cas d’alerte. La traçabilité des décisions de conformité doit être enregistrée et archivée.
L’ACPR attend également une cartographie des risques LCB-FT formalisée et un dispositif de gel des avoirs conforme aux listes de sanctions européennes (consolidées par l’OFAC et l’UE). L’ERP ou le middleware financier doit vérifier en temps réel chaque contrepartie contre ces listes.
Conformité DORA : résilience numérique depuis janvier 2025
Le règlement DORA (Digital Operational Resilience Act, UE 2022/2554) s’applique depuis le 17 janvier 2025 aux EP et EME, au même titre qu’aux banques et compagnies d’assurance. Il impose un cadre de gestion des risques TIC qui couvre quatre obligations principales :
- Cartographie des systèmes TIC critiques — l’ERP comptable, le ledger interne, les connecteurs bancaires et les interfaces de paiement doivent être documentés comme actifs critiques
- Plan de continuité et de reprise — RTO (Recovery Time Objective) et RPO (Recovery Point Objective) formalisés pour chaque système
- Tests de résilience — les entités significatives (volume de transactions élevé) doivent réaliser des tests TLPT (Threat-Led Penetration Testing) tous les 3 ans
- Gestion des risques tiers — contrats avec les éditeurs ERP et hébergeurs cloud révisés pour inclure les clauses DORA
Les fintechs de petite taille bénéficient du principe de proportionnalité de DORA, mais l’obligation de documenter et de tester la résilience de leur SI s’applique à toutes les entités, sans seuil d’exemption totale.
Quelle architecture SI pour une fintech en 2026 ?
Core banking ou ERP standard : comprendre la distinction
La question du SI pour une fintech réglementée oppose deux logiques.
Un ERP standard (Odoo, NetSuite, Sage Intacct, SAP) gère les achats, les ventes, la comptabilité générale et analytique, la paie et les immobilisations. Il répond bien aux besoins financiers internes de la fintech — facturer les clients, payer les fournisseurs, produire les bilans, consolider les entités.
Un core banking ou ledger de paiement (Mambu, Thought Machine, Railsr, Module Finance) gère les comptes des utilisateurs, les flux de paiement, les soldes en temps réel, les wallets multidevises et la réconciliation à haute fréquence. C’est la couche qui porte les fonds cantonnés et les transactions de paiement.
Ces deux couches ne s’excluent pas — la plupart des EP de taille intermédiaire les font coexister : un core banking ou un ledger interne pour l’opérationnel de paiement, un ERP pour le back-office financier et la comptabilité générale. L’enjeu est l’intégration entre les deux.
Stacks courants observés dans les fintechs françaises
Pour une fintech de moins de 50 salariés et en dessous de 5 millions d’euros de volume mensuel traité, la stack la plus fréquente est légère :
- Odoo 17/18 pour la comptabilité générale, la facturation B2B, la gestion des fournisseurs et les notes de frais
- Stripe ou un PSP tiers pour les flux de paiement entrants/sortants, avec une API qui alimente Odoo via des connecteurs
- Pennylane pour certaines fintechs très petites ou en phase pré-agrément, avant que la volumétrie ne justifie un vrai ERP
Cette stack présente des limites importantes pour une entité agréée : Odoo ne gère pas nativement le cantonnement ni le reporting ACPR. Il faut développer des modules spécifiques ou intégrer des outils complémentaires, ce qui génère une dette technique significative si elle n’est pas anticipée dès le départ.
Pour les fintechs qui ont passé le cap de la Série A (10-100 millions d’euros de volume mensuel) :
- Oracle NetSuite Financial Services ou Sage Intacct pour la comptabilité multi-entités, la réconciliation bancaire et les rapports financiers investisseurs. Oracle NetSuite couvre nativement la reconnaissance de revenus (ASC 606/IFRS 15) et les consolidations multi-devises, indispensables pour les fintechs à structure internationale.
- Un ledger de paiement séparé (Mambu, Thought Machine, ou développement sur Postgres/Redis) pour les comptes utilisateurs et la réconciliation temps réel
Quand faut-il un vrai core banking ?
Un core banking dédié devient nécessaire quand trois signaux apparaissent simultanément :
- Le volume de transactions dépasse 100 000 opérations par jour
- La réconciliation en fin de journée ne peut plus être faite manuellement ou via un export Excel
- L’EP opère dans plusieurs pays avec des exigences de ségrégation distinctes (comptes cantonnés séparés par juridiction)
En dessous de ces seuils, un ERP bien paramétré avec des connecteurs API vers le PSP suffit pour la grande majorité des fintechs agréées. L’investissement dans un core banking comme Mambu représente des coûts de licence et d’intégration significatifs qui ne sont justifiés qu’à partir d’une certaine volumétrie.
Gestion des fonds cantonnés : la brique SI critique
Principes comptables de ségrégation
Comptablement, les fonds cantonnés n’apparaissent pas dans le bilan de la fintech comme des actifs disponibles. Ils sont enregistrés dans un compte de tiers (dette envers les clients) côté passif, et leur contrepartie actif est le solde du compte de cantonnement ouvert auprès de la banque partenaire.
Le schéma d’écriture est simple mais son automatisation est complexe à grande échelle. Chaque réception de fonds génère une écriture en crédit du compte client (passif) et en débit du compte de cantonnement (actif). Chaque paiement sortant inverse le schéma. La clôture quotidienne doit vérifier que le solde actif du compte de cantonnement est toujours supérieur ou égal à la somme des soldes créditeurs clients.
L’ERP doit produire cet état de cantonnement quotidiennement, de façon automatique, et l’archiver pour les contrôles ACPR.
Ce que l’ERP doit restituer au quotidien
La direction financière d’un EP a besoin de visualiser en permanence quatre indicateurs :
- Solde global cantonné — montant total des fonds clients détenus, par devise et par compte bancaire
- Détail par client ou wallet — capacité à décomposer le global en soldes individuels pour reconstituer les engagements en cas de défaillance
- Rapport de couverture — ratio fonds cantonnés / engagements clients, idéalement proche de 100 % avec une marge de sécurité
- Journal de mouvements — historique horodaté de chaque entrée et sortie, avec identification de la contrepartie et du motif
Ces données doivent être exportables en formats standardisés pour les audits annuels et les contrôles ACPR. L’absence de ce reporting automatisé est la principale lacune des ERP généralistes non configurés pour ce secteur.
Le cycle audit et levée de fonds : préparer son SI pour les investisseurs
KPIs investisseurs dans l’ERP
Une fintech réglementée en croissance passe régulièrement par des cycles de levée de fonds. Les investisseurs (VC, fonds de dette, family offices) demandent lors de la due diligence financière des métriques qui doivent sortir directement de l’ERP ou du CRM :
- MRR et ARR — revenus mensuels et annuels récurrents
- NRR (Net Revenue Retention) — taux de rétention des revenus hors nouveaux clients
- CAC (Customer Acquisition Cost) et LTV (Lifetime Value) par segment
- Churn brut et net par cohorte
- TPO (Total Payment Volume) traité par mois et par trimestre
Ces métriques doivent être calculables automatiquement depuis le SI, sans reconstruction manuelle sur Excel. Un ERP configuré pour les produire en quelques clics simplifie considérablement le processus de data room et accélère les cycles de closing.
Auditabilité du SI pour les investisseurs et l’ACPR
La data room d’une levée de fonds Série A/B et le dossier de renouvellement d’agrément ACPR partagent une exigence commune : la traçabilité complète des transactions et des décisions financières.
Un SI auditable pour une fintech réglementée doit satisfaire trois critères :
- Piste d’audit immuable — chaque transaction, chaque modification de compte, chaque validation de paiement doit être enregistrée avec un horodatage et l’identifiant de l’utilisateur ou du processus automatique
- Exports normalisés — les transactions doivent pouvoir être exportées en formats structurés (CSV, XML, JSON) compatibles avec les outils d’analyse des auditeurs
- Conservation pendant 5 ans minimum — conformément aux obligations légales du CMF et à la politique LCB-FT
Les ERP cloud modernes (NetSuite, Sage Intacct) intègrent ces fonctionnalités nativement. Les solutions open source (Odoo) les proposent via des modules tiers ou des développements spécifiques qui doivent être validés avant la mise en production.
Recommandations pratiques pour les fintechs de 5 à 100 salariés
Voici les quatre décisions SI les plus structurantes à prendre tôt :
1. Séparer la couche opérationnelle de paiement et la couche comptable dès le départ. Ne pas essayer de faire gérer les wallets clients par un module ERP standard — c’est une voie d’impasse. Utiliser un PSP ou un ledger pour les transactions, et réserver l’ERP à la comptabilité générale et aux reportings.
2. Modéliser le plan de comptes pour le cantonnement avant toute implémentation ERP. Le plan de comptes doit distinguer les comptes de cantonnement (actif) des comptes propres de la fintech, et permettre un rapprochement automatique quotidien.
3. Intégrer le sujet DORA dans le cahier des charges de l’ERP. Les clauses contractuelles avec l’éditeur ERP, le RTO/RPO documenté et le plan de test de résilience sont des livrables DORA, pas des options. Les intégrateurs ERP spécialisés secteur financier connaissent ces exigences — les généralistes ne les anticipent pas.
4. Préparer le SI pour les investisseurs dès la Série A. Les métriques SaaS/fintech (MRR, NRR, churn) doivent sortir de l’ERP en quelques clics — pas d’un tableur reconstitué. Un ERP mal paramétré peut ralentir un cycle de levée de plusieurs semaines.
Pour approfondir les sujets adjacents, consultez notre guide DORA et ERP pour le secteur financier, notre analyse ERP et open banking PSD2 et notre guide ERP assurance et Solvabilité II.
