Néobanque : de l'idée au MVP avec la bonne stack BaaS
Chaque mois perdu sur la conformité ACPR ou sur une architecture mal choisie est un mois de retard face à N26, Qonto ou Bunq. Nehos integre les briques BaaS (Mambu, Treezor, Swan), gere la conformité ACPR et livre un MVP production-ready — avec l'instant issuance Mastercard incluse.
Nos clients types
Le marche de la neobanque est devenu un terrain de jeu concurrentiel ou la vitesse d'exécution est un avantage stratégique décisif. Les fondateurs de nouvelles fintechs de paiement — souvent issus du monde bancaire ou du conseil — savent exactement quel produit ils veulent construire. Leur problème est double : la complexité réglementaire et le choix de la stack technique. La réglementation est le premier obstacle. En France, distribuer des services de paiement ou émettre de la monnaie électronique necessite un agrément de l'ACPR — soit comme Établissement de Paiement (EP), soit comme Établissement de Monnaie Électronique (EME). Pour un fondateur qui veut valider son marche rapidement, c'est une barrière rédhibitoire. L'alternative — opérer comme agent d'un EME existant — accelere considérablement le go-to-market : Treezor (groupe Société Générale), Swan, Mangopay ou Lemonway proposent des programmes agent qui permettent de distribuer des services de paiement sous leur propre licence, en quelques mois. Mais ce modèle impose des contraintes : partage de la marge avec le BaaS provider, personnalisation limitée du produit, dependance aux roadmaps et aux incidents du fournisseur. La stack technique est le second obstacle. Construire un core banking from scratch pour une neobanque est une erreur que l'industrie a apprise a ses dépens — les cas de Simple Bank (ferme en 2021) ou de Monzo dans ses premières années illustrent les difficultés d'un build integral. L'écosystème BaaS 2025 propose des alternatives matures : Mambu est le core banking cloud-native le plus adopte en Europe avec plus de 200 déploiements actifs, Thought Machine Vault offre une flexibilité de configuration supérieure mais une courbe d'apprentissage plus élevée, et des acteurs comme Modulr ou Clearbank fournissent des IBAN programmatiques via API. Le troisième défi est l'intégration de la carte physique et virtuelle. L'instant issuance — la capacité d'émettre une carte Mastercard virtuelle utilisable immédiatement dans Apple Pay ou Google Pay lors de l'onboarding — est devenue une condition de base pour la satisfaction utilisateur. Son integration technique (Mastercard Issuing Processing API, gestion des PIN, 3DS2) est non triviale et mal documentée pour les newcomers. Enfin, la conformité LCB-FT (Lutte Contre le Blanchiment et le Financement du Terrorisme) est un sujet opérationnel continu, pas un audit ponctuel. Les neobanques sont exposées a des risques de fraude et de blanchiment supérieurs aux banques traditionnelles en raison de leur onboarding entièrement digital et de leur base client plus diverse.
La méthode Nehos pour un MVP neobanque commence par une décision stratégique que nous guidons en amont de toute implementation : le choix du modèle réglementaire et du BaaS partner. Ce choix conditionne toute l'architecture, les marges unitaires et la capacité de croissance — il ne peut pas être défait facilement une fois les contrats signes. Pour une fintech qui veut valider son marche en moins de 12 mois, le modèle agent d'un EME existant est presque toujours le bon choix initial. Treezor et Swan sont les deux options les mieux adaptées au marche français et européen : API modernes, documentation de qualité, SLA contractuels solides et programmes d'accompagnement pour les fintechs en phase de lancement. Pour le core banking BaaS, Mambu est notre recommandation pour la majorité des cas : plateforme cloud-native déployée sur AWS ou GCP, API REST et GraphQL, configuration produit via Product Framework sans développement backend spécifique, écosystème de connectors (Mambu Marketplace) pour les intégrations KYC/scoring/risque. La courbe d'apprentissage est de 4 à 6 semaines pour une equipe de 2 à 3 développeurs. Thought Machine Vault est pertinent pour des cas de figure plus complexes — produits de credit sur mesure, logique comptable non standard — mais exige une equipe plus expérimentée et un budget implementation plus eleve. L'architecture applicative que Nehos livre comprend : API gateway (Kong ou AWS API Gateway), microservice d'onboarding client (KYC documentaire via Onfido ou Veriff, verification identité, scoring LCB-FT), integration Mambu pour la gestion des comptes et du solde, integration Treezor ou Swan pour les IBAN programmatiques et les virements SEPA, integration Mastercard Issuing Processing API pour l'emission et la gestion des cartes physiques et virtuelles (instant issuance, 3DS2, gestion PIN). Le tout est déployé sur AWS ou GCP avec des pipelines CI/CD GitHub Actions, des tests automatises de bout en bout et un monitoring temps réel. La conformité LCB-FT est operationnalisee via une solution de screening temps réel : Feedzai ou Sardine pour la détection de fraude transactionnelle, ComplyAdvantage pour le screening sanctions/PPE (Personnes Politiquement Exposées), et un workflow de revue manuelle pour les cas ambigus. Nehos configure et integre ces outils, documente les procedures de controle interne requises par l'ACPR, et forme l'equipe conformité de la fintech. Nehos anime les sessions de Product Review hebdomadaires pendant la beta pour piloter les iterations avec les equipes produit et engineering de la fintech. La mise en production inclut un runbook de go-live detaille, un plan de communication de crise en cas d'incident technique ou réglementaire, et un tableau de bord de monitoring opérationnel (Datadog ou Grafana) expose en temps réel aux fondateurs et a l'equipe conformité.
Modèle réglementaire
Choix EME ou agent documenté, avec ses conséquences sur le calendrier et la marge
Réversibilité
Coûts de sortie et portabilité des données examinés avant toute signature BaaS
Bêta
Retours de la bêta fermée suivis avant l'ouverture au public
#Le problème : pourquoi neobanque est un enjeu critique
Le marche de la neobanque est devenu un terrain de jeu concurrentiel ou la vitesse d'exécution est un avantage stratégique décisif. Les fondateurs de nouvelles fintechs de paiement — souvent issus du monde bancaire ou du conseil — savent exactement quel produit ils veulent construire. Leur problème est double : la complexité réglementaire et le choix de la stack technique.
La réglementation est le premier obstacle. En France, distribuer des services de paiement ou émettre de la monnaie électronique necessite un agrément de l'ACPR — soit comme Établissement de Paiement (EP), soit comme Établissement de Monnaie Électronique (EME). Pour un fondateur qui veut valider son marche rapidement, c'est une barrière rédhibitoire.
L'alternative — opérer comme agent d'un EME existant — accelere considérablement le go-to-market : Treezor (groupe Société Générale), Swan, Mangopay ou Lemonway proposent des programmes agent qui permettent de distribuer des services de paiement sous leur propre licence, en quelques mois. Mais ce modèle impose des contraintes : partage de la marge avec le BaaS provider, personnalisation limitée du produit, dependance aux roadmaps et aux incidents du fournisseur.
La stack technique est le second obstacle. Construire un core banking from scratch pour une neobanque est une erreur que l'industrie a apprise a ses dépens — les cas de Simple Bank (ferme en 2021) ou de Monzo dans ses premières années illustrent les difficultés d'un build integral.
L'écosystème BaaS 2025 propose des alternatives matures : Mambu est le core banking cloud-native le plus adopte en Europe avec plus de 200 déploiements actifs, Thought Machine Vault offre une flexibilité de configuration supérieure mais une courbe d'apprentissage plus élevée, et des acteurs comme Modulr ou Clearbank fournissent des IBAN programmatiques via API.
Le troisième défi est l'intégration de la carte physique et virtuelle. L'instant issuance — la capacité d'émettre une carte Mastercard virtuelle utilisable immédiatement dans Apple Pay ou Google Pay lors de l'onboarding — est devenue une condition de base pour la satisfaction utilisateur. Son integration technique (Mastercard Issuing Processing API, gestion des PIN, 3DS2) est non triviale et mal documentée pour les newcomers.
#Notre approche en 4 phases
#Phase 1 : Choix du modèle réglementaire et du BaaS partner (mois 1-2)
Definition du modèle de licence : EME (Établissement de Monnaie Électronique) propre, passeport européen ou modèle agent d'un EME existant (Treezor, Swan, Mangopay). Choix du core banking BaaS : Mambu (cloud-native, API-first) ou Thought Machine Vault (config-driven, plus complexe mais plus flexible). Constitution du dossier ACPR si demande de licence propre.
Voir notre expertise : comparatif Mambu vs Thought Machine vs build sur mesure.
#Phase 2 : Architecture technique et intégrations (mois 2-5)
Design de l'architecture : API gateway, microservices KYC/onboarding, core banking BaaS, module cartes Mastercard. Integrations : Onfido ou Veriff pour le KYC documentaire, Openpayd ou Modulr pour les IBAN, Mastercard Issuing Processing API pour l'instant issuance. Pipeline CI/CD, sécurité PCI-DSS Level 1.
Voir notre expertise : conformité LCB-FT neobanque.
#Phase 3 : Conformité et tests ACPR (mois 5-8)
Constitution du dossier de conformité ACPR : politique LCB-FT, plan de continuité d'activité, cartographie des risques opérationnels, politique de sécurité des SI. Tests de penetration (pentest PCI-DSS). Preparation de l'audit ACPR si licence propre, ou validation par le BaaS partner si modèle agent.
Voir notre expertise : architecture microservices fintech.
#Phase 4 : Beta fermée, iteration et go-live (mois 8-9)
Iteration rapide sur les blocages UX. Go-live avec campagne d'acquisition. Monitoring fraude en temps réel (Feedzai ou Sardine). Reporting ACPR mensuel.
Voir notre expertise : simulateur coût MVP neobanque.
#Exemple de situation
Ce qui suit est un exemple de situation pour illustrer la démarche, pas le récit d'un projet livré.
#Contexte
Une fintech de paiement B2B, fondée par d'anciens banquiers, vise une niche de professionnels (par exemple des comptables indépendants) et veut ouvrir des comptes et émettre des cartes rapidement.
#Défi
Choisir le bon modèle réglementaire, assembler les briques BaaS sans être prisonnier d'un fournisseur, tenir les exigences ACPR et livrer un MVP exploitable avec émission de cartes instantanée.
#Approche
Un choix du modèle réglementaire et du partenaire BaaS en amont (coûts de sortie et portabilité des données compris), une architecture reliant cœur bancaire, IBAN et cartes, une phase de conformité et de tests, puis une bêta fermée avant la mise en ligne.
#Ce que nous mesurons
Les indicateurs de réussite sont fixés avec vous avant le lancement et relevés sur l'existant. On les suit pendant le pilote, puis on décide ensemble d'aller plus loin ou non, sur des mesures et non sur des promesses.
#Pourquoi Nehos pour neobanque
Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des architectures sur mesure, calibrées sur vos contraintes métier, réglementaires et techniques. Chaque projet démarre par un audit de faisabilité qui pose les limites avant les promesses — si le ROI ne tient pas, on le dit avant de signer quoi que ce soit.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains projetés avec hypothèses conservatrices, critères de go/no-go factuels. En production, on mesure les résultats réels et on les compare aux projections — transparence totale, y compris quand les chiffres sont en dessous des attentes. Nos expertises connexes : architecture microservices fintech, simulateur coût MVP neobanque, conformité DORA resilience opérationnelle.
Stack technique souverain : hébergement OVHcloud (datacenters France), modèles IA open source (Mistral) quand la performance le permet, code propriétaire intégralement détenu par le client à la livraison. Pas de vendor lock-in, pas de dépendance à un fournisseur cloud américain pour vos données critiques.
#Pour aller plus loin
Cas d'usage connexes :
Questions & réponses
Questions frequentes sur le MVP neobanque
Pas obligatoirement — et certainement pas au stade MVP. Le modèle agent d'un EME (Établissement de Monnaie Électronique) existant — Treezor (filiale Société Générale), Swan, Mangopay ou Lemonway — permet de distribuer des services de paiement sous la licence de l'EME partenaire, sans agrément propre. La contrepartie : partage de la marge avec l'EME, contraintes de personnalisation et dependance contractuelle.
Mambu est un choix courant pour les fintechs en phase de lancement : API mature, documentation de qualité, Product Framework qui permet de configurer la logique produit (comptes, transactions, intérêts) sans code backend spécifique, et un écosystème de partenaires (Mambu Marketplace) riche. Pour un compte professionnel avec carte, c'est un choix cohérent. Thought Machine prend tout son sens pour des fintechs de crédit ou des banques de niche aux produits très différenciés. Voir notre comparatif Mambu vs Thought Machine vs build sur mesure.
L'instant issuance désigne la capacité d'émettre une carte virtuelle Mastercard (ou Visa) utilisable immédiatement dans Apple Pay, Google Pay ou en ligne, au moment même de la fin de l'onboarding, avant la réception de la carte physique. Techniquement, cela demande une intégration avec l'API de traitement d'émission de Mastercard, la gestion de la tokenisation (MDES, Mastercard Digital Enablement Service) et une intégration 3DS2 pour les paiements en ligne. C'est l'une des intégrations les plus techniques d'une stack de néobanque.
La conformité LCB-FT (Lutte Contre le Blanchiment et le Financement du Terrorisme) avec un onboarding digital requiert trois piliers : un KYC documentaire automatise et conforme (Onfido, Veriff ou Jumio — les trois sont homologues par l'ACPR), un screening temps réel des transactions et des clients contre les listes de sanctions et PPE (ComplyAdvantage, Dow Jones Risk & Compliance), et un dispositif de revue manuelle des alertes par une equipe conformité formée. L'ACPR verifie lors de ses examens que le dispositif est proportionnel au profil de risque de la clientèle — une fintech B2B ciblant des comptables est mieux positionee qu'une fintech grand public sans verification d'usage. La documentation des procedures de controle interne et le reporting mensuel a l'ACPR sont non négociables.
Le budget dépend du niveau de personnalisation du produit, de la complexité des intégrations partenaires et de la taille de l'équipe interne. Nous le chiffrons sur devis, en 48 h après un premier échange, à partir d'un périmètre MVP volontairement resserré.
Les quatre risques principaux sont : (1) la fraude a l'onboarding — mitigation via KYC documentaire strict et scoring comportemental ; (2) les sanctions ACPR pour insuffisances LCB-FT — mitigation via un dispositif de conformité documente et une revue indépendante avant go-live ; (3) les incidents de disponibilité du BaaS provider — mitigation via un SLA contractuel fort et un plan de continuité documente ; Ce dernier point est souvent négligés par les equipes fondatrices pressées — et c'est une des raisons pour lesquelles Nehos insiste sur l'isolation de la couche BaaS des le premier sprint d'architecture.