01KYC et onboarding
La vérification passe avant que le premier euro ne bouge. L'app cadre le document, déroule les étapes d'identité et débloque le compte une fois les contrôles validés. L'onboarding est un flux du cœur, habillé app par app : chaque whitelabel affiche sa propre version des mêmes étapes, et le niveau obtenu suit le client jusque dans la console opérateur. Présenté dans l'app de référence de la plateforme, le build neutre aux couleurs de Protocore dont part chaque whitelabel.
- Capture du document et étapes d'identité dans l'app
- Niveaux décidés dans le core, affichés par chaque front end
- Statut KYC visible des opérateurs dans User 360
02Vérification OTP
Les étapes sensibles demandent un code à usage unique. La démo envoie six chiffres à un numéro +40 masqué, trois sont déjà saisis et le renvoi attend la fin d'un compte à rebours de 24 secondes. Les codes protègent la connexion et les changements à risque, pas chaque tap.
03Déverrouillage biométrique
L'app s'ouvre avec Face ID et bascule sur le PIN en secours. La biométrie protège le wallet, l'affichage des cartes et les changements de confidentialité. Le rapprochement se fait sur l'appareil ; la plateforme n'en voit que le résultat.
04Paiements par chat
L'argent circule dans la conversation. Un paiement est un message : rédigé dans le fil, confirmé dans le fil, puis passé sur le ledger du core comme n'importe quel virement. Présenté ici dans Lumen, l'une des directions d'exemple ; le module s'intègre à toute app que vous concevez sur la plateforme.
05Demandes dans le fil
Une demande est un message avec des boutons. Dans le fil de démo, €120.00 partent sous forme de message et une demande de €75.00 attend dans la bulle avec Payer et Refuser. L'acceptation est réglée sur le ledger du core à la seconde. Présenté dans l'app de référence de la plateforme.
Chaque contact a sa page d'argent. Le profil de démo montre les deux sens entre deux personnes (14 transactions, €340.00 reçus, €195.00 envoyés), avec Envoyer et Demander à un tap et l'historique partagé en dessous. L'unité, c'est la relation, pas la transaction.
07Liens de paiement
Demandez de l'argent avec un lien. Le payeur l'ouvre et paie ; le montant est réglé sur le ledger sans aucune installation d'app de son côté. Les liens portent un état (actif, payé, expiré) et la console opérateur offre un back office complet pour les gérer : 214 liens dans la démo, chacun avec son virement de règlement rattaché. Présenté ici dans Halcyon, l'une des directions d'exemple.
08Le hub des liens de paiement
Les utilisateurs gèrent leurs liens comme une petite entreprise. Le hub propose une page personnelle pay.protocore.io/@handle avec interrupteur on/off, €395.00 en attente sur trois liens ouverts et €1,240.00 encaissés en trente jours. Les liens se filtrent par en attente, payé et annulé ; les liens réutilisables à montant libre expirent à date fixe.
09Détail des transactions et reçus
Chaque transaction s'ouvre sur une fiche complète : statut, catégorie, note, émetteur, destinataire et, dans la démo, la référence 9F21-0716. Le reçu se télécharge en PDF. Ce que voit le client est la même écriture du ledger que celle de l'opérateur dans la console : un seul enregistrement, deux vues.
10Historique unifié
Une seule liste pour tous les rails. L'historique de démo mêle un salaire de €1,250.00, un échange de 540.35 USDC contre €500.00, un envoi P2P, des paiements par carte et une recharge en USDC via Base, groupés par jour, avec recherche et filtres en en-tête. Un paiement refusé garde son motif de refus en ligne au lieu de disparaître.
11Contrôles de carte
Les plafonds et les contrôles se trouvent à côté de la carte, pas dans une file de support. La carte de démo affiche €312.40 dépensés sur un plafond mensuel de €2,000, les paiements supérieurs à €250 confirmés par SMS, et le changement de PIN, le renommage, le remplacement et la résiliation à un tap. Présenté dans l'app de référence de la plateforme ; Lumen affiche les mêmes contrôles à ses couleurs.
- Plafonds mensuels par carte, avec confirmation par SMS au-delà
- Bloquer, renommer, changer le PIN sur place
- La résiliation est une action de l'utilisateur, pas un ticket
12Affichage sécurisé de la carte
Les données complètes de la carte restent masquées tant que l'utilisateur n'a pas prouvé sa présence. L'affichage exige Face ID, les données se masquent seules après 30 secondes et les captures d'écran sont désactivées tant qu'elles sont visibles. Numéro, date d'expiration et CVV se copient séparément : la carte entière n'est jamais exposée à l'écran.
13Contrôle des abonnements
Les prélèvements récurrents deviennent une seule liste maîtrisée : €38.97 par mois dans la démo. Une hausse de prix est signalée dès qu'elle tombe (GymFlex, jusqu'à €24.99), un service probablement en doublon est pointé, et un commerçant indésirable est bloqué au niveau de la carte plutôt que supplié par e-mail. Présenté ici dans Lumen, l'une des directions d'exemple.
- Les dépenses récurrentes en un seul total mensuel
- Hausses de prix et doublons signalés automatiquement
- Bloquer un commerçant sur la carte, sans e-mail de résiliation
14Répartiteur de salaire
Le salaire se répartit tout seul. Un salaire arrive et le répartiteur l'achemine vers les sous-comptes selon des règles définies une fois par l'utilisateur : le loyer ici, l'épargne là, le reste pour les dépenses du quotidien. Pas de rituel du jour de paie, pas de virements manuels. Présenté ici dans Volt, l'une des directions d'exemple.
15Cartes d'équipe
Une entreprise émet des cartes pour son équipe sur un budget commun avec des plafonds par carte : €2,000 par mois pour l'équipe de démo dont €1,240 déjà utilisés, €500 par carte, des barres de dépenses par employé. Quand quelqu'un a besoin de plus, la demande suit le flux : un relèvement de plafond de €500 à €700 attend un approbateur, qui tranche sur place. Présenté ici dans Volt, l'une des directions d'exemple.
- Un budget mensuel, des plafonds par carte en dessous
- Dépenses visibles par employé en temps réel
- Relèvements de plafond demandés et approuvés dans le flux
16Paie et paiements B2B
Les comptes qui paient un ami paient aussi une équipe. Les paiements par lot exécutent la paie et les décaissements B2B depuis un compte professionnel sous forme de virements SEPA : un lot, plusieurs bénéficiaires, chaque opération passée individuellement sur le ledger. Présenté ici dans Fern, l'une des directions d'exemple.
17Règles de conversion automatique
Les utilisateurs fixent des règles de change au lieu de surveiller des graphiques. Dans la démo, €500 sont convertis en USDC quand le taux atteint 1.0150, le taux en direct de 1.0100 et le meilleur des 30 derniers jours s'affichant sur le même écran, avec des frais figés à la création de la règle, pas à l'exécution. Les règles d'alerte seule surveillent le taux sans déplacer d'argent. Présenté ici dans Fern, l'une des directions d'exemple.
18Earn
Les soldes peuvent travailler. La démo montre €1,086.10 rémunérés entre USDC flexible et ETH staké, avec une projection sur douze mois de €40.19 affichée avant que quiconque engage un centime. Intérêts calculés au jour le jour, versés chaque semaine. Présenté ici dans Halcyon, l'une des directions d'exemple.
19Récompenses crypto sur les dépenses
Les dépenses par carte peuvent rapporter des cryptos. Dans Meridian, l'une des directions d'exemple, chaque achat crédite une part de BTC (1.5 % de cashback dans la démo, un paramètre produit défini par tenant, pas un taux de marché), et le hub suit 0.0042 BTC cumulés entre cafés et courses, avec paliers et cumul mensuel en dessous. Les récompenses arrivent sur un compte BTC du même ledger que tout le reste.
- Un crédit BTC à chaque achat, sur chaque transaction par carte
- Le taux de retour est un réglage du tenant, pas une promesse sur les marchés
- Récompenses échangeables vers un compte du ledger, pas un programme de points
20Comptes multidevises
Un client détient plusieurs soldes. Dans Meridian, l'une des directions d'exemple, un compte principal EUR de €842.16 côtoie un compte stablecoin USDC, un solde GBP voyage et le compte BTC où arrivent les récompenses carte, chacun avec sa vue ledger et son historique. La conversion entre eux est toujours explicite : le taux exact s'affiche sur l'écran de vérification avant confirmation, jamais appliqué en silence.
21Notifications
Un seul fil pour l'argent, la sécurité et le produit. La démo montre l'arrivée d'un salaire de €1,250.00, une alerte de nouvelle connexion, un paiement par carte, une récompense de parrainage, un swap terminé, une demande expirée et une invitation à finir la vérification pour débloquer €5,000 par jour. Groupées par jour, avec suivi de lecture, envoyées en push et dans l'app.
22Programme de parrainage
La croissance est intégrée, pas greffée après coup. Chaque utilisateur reçoit un code (AION-4K dans la démo), un QR et une feuille de partage ; le hub compte six inscrits, deux en attente et €60 gagnés. Les récompenses sont créditées sur le ledger comme n'importe quel autre crédit, et la console suit le programme de l'autre côté.
23Stories et engagement
Les temps forts du produit sortent en stories plein écran. La démo annonce un niveau Plus avec douze avantages (plafonds relevés, cartes gratuites, 2 % de cashback sur les paiements par carte) derrière des barres de progression et un seul appel à l'action. Les stories sont du contenu : gérées par tenant et ciblées depuis les campagnes de la console, sans publier de nouvelle version de l'app.
24Contrôles de confidentialité
Les utilisateurs décident à quel point ils sont trouvables. La découverte par numéro de téléphone s'active ou se coupe d'un interrupteur, une fenêtre temporaire de 15 minutes s'ouvre quand deux personnes doivent se connecter, et les soldes se masquent à la demande quand on est observé. La connexion biométrique s'active sur le même écran : la confidentialité est un réglage, pas un ticket de support.
25La console opérateur
Chaque app de la plateforme est livrée avec le même back office. User 360 réunit sur un seul écran les soldes, cartes, appareils, niveau KYC et 184 transactions d'un client ; la vue des transactions couvre 4,912 lignes entre le ledger fiat et les rails crypto. Chaque action privilégiée exige un motif écrit et est consignée dans le journal d'audit. La console existe aussi comme produit à part entière : Protocore Center.
- User 360 : un client, en entier
- Les deux rails dans une seule liste de transactions, sur 4,912 lignes
- Actions avec motif obligatoire, journal d'audit immuable
26Campagnes in-app
Les opérateurs diffusent des messages in-app sans publier de version. La démo liste 14 campagnes aux formats plein écran, bannière et carte, chaque ligne indiquant son audience ciblée et son entonnoir de livraison : une campagne envoyée a ciblé 8,412 utilisateurs, avec 8.1k messages délivrés et 5.2k lus, et les 18 échecs sont comptés, pas cachés. Les campagnes s'envoient, se programment, s'activent et se désactivent depuis la console.
27Crédits manuels avec approbation
L'argent ne se crée jamais d'un simple clic. Chaque crédit manuel enregistre l'opérateur, l'heure, le montant, le motif et le solde avant et après ; la file de démo contient 48 crédits dont deux en attente de co-signature. Un geste commercial de €500.00 attend un second opérateur, une annulation de frais de €40.00 est exécutée et un ajustement promo de €15.00 est rejeté : chaque décision est consignée.
28Alimenter un utilisateur
Alimenter un solde réel commence par en énoncer l'impact. La démo émet €1,000.00, au-dessus du seuil de €500 pour un seul opérateur : la demande part donc vers un second opérateur et ne s'exécute qu'après approbation. La fenêtre montre le wallet passant de €2,458.30 à €3,458.30, exige un motif écrit que l'approbateur lit, et le journal d'audit conserve le tout.
29P2P par @handle ou IBAN
Envoyez à une personne, pas à un numéro de compte. Les destinataires se résolvent par @handle ou IBAN, chacun avec sa propre devise de réception : la démo envoie €120.00 à @andrei instantanément et sans frais, et un envoi multidevise livre 120.70 USDC pour exactement €120.00 envoyés, le taux étant figé pendant 24 heures.
30Groupes et remboursements
Les dépenses partagées ont un ledger partagé. Le groupe de démo (un voyage à Cluj, €480 entre quatre membres) suit qui est créditeur et qui doit, relance ceux qui doivent et se clôt d'un seul Régler les comptes au lieu de quatre virements séparés.
31Crypto et fiat côte à côte
BTC, ETH, Base et Solana cohabitent dans la même app que le compte EUR. €120 achètent 129.93 USDC financés directement depuis le solde EUR ; €500 s'échangent en 540.35 USDC à un taux affiché, avec les frais indiqués avant confirmation. Un seul bilan, deux types d'actifs.
32Virements permanents et paiements programmés
Les paiements peuvent être récurrents. Les virements permanents répètent un transfert selon un calendrier ; les envois programmés déplacent un paiement à une date future. Les deux s'inscrivent comme de simples transactions du ledger, s'annulent depuis l'écran qui les a créés et apparaissent dans l'historique comme le reste.
33Relevés et exports
Chaque compte produit des relevés. PDF mensuels pour les particuliers, exports CSV pour les comptables, reçu PDF sur n'importe quelle transaction. Les opérateurs exportent de la même façon les vues filtrées de la console : ce que vous voyez, vous pouvez l'emporter.
34Plafonds par niveau KYC
Les plafonds suivent la vérification. Chaque niveau a ses propres limites quotidiennes et mensuelles, et l'app indique précisément ce que débloque l'étape suivante : dans la démo, 5 000 € par jour. Les opérateurs voient le niveau, les plafonds et la marge restante dans User 360.
35Gestion des appareils
Les sessions sont visibles et révocables. Toute nouvelle connexion déclenche une notification immédiate ; les utilisateurs passent leurs appareils en revue et terminent n'importe quelle session à distance. Les appareils de confiance se déverrouillent par biométrie ; les nouveaux repartent d'une vérification complète.
36Workflows de filtrage
La plateforme fournit des hooks pour les workflows de filtrage des sanctions et AML. Des événements se déclenchent à l'onboarding et lors des transactions, puis sont routés vers le prestataire de filtrage de votre choix ; les alertes ouvrent des dossiers pour revue humaine, et chaque décision d'opérateur exige un motif et est journalisée. Vous définissez la politique, la plateforme porte le workflow.
37Remboursements, annulations et litiges
Les cas limites ont leur parcours. Les annulations libèrent les blocages d'autorisation avant le règlement ; les remboursements sont passés après, sous forme d'écritures de contrepartie référençant la transaction d'origine. Les rechargements échoués se rapprochent via la console, et révoquer un lien de paiement n'est pas un remboursement : le back-office garde la différence explicite. Rien n'est supprimé ; le ledger ne fait qu'ajouter.
38API, webhooks et sandbox
Tout ce que font les apps passe par l'API de la plateforme, et cette même surface est la vôtre. Les webhooks poussent vers vos systèmes les événements de transaction, de KYC, de carte et de lien de paiement ; un tenant sandbox doté de données de test permet à votre équipe d'intégrer de bout en bout avant qu'un seul vrai euro ne bouge.
39Localisation et accessibilité
La couche applicative est multilingue, avec textes, nombres, dates et formats monétaires localisés par marché. Les écrans comportent des contrôles étiquetés, des palettes dont le contraste est vérifié et un ordre de lecture adapté aux lecteurs d'écran : votre whitelabel part d'une base accessible au lieu d'en subir une après coup.
40Thèmes et pipeline whitelabel
Le whitelabel est un pipeline, pas une couche de peinture. Tokens, typographie, composants et combinaison de fonctionnalités se configurent par tenant et se compilent en votre app à vos couleurs : Halcyon, Lumen, Fern, Volt et Meridian sont sortis du même pipeline, cinq directions parmi une infinité. Vos designers maîtrisent chaque écran ; le cœur en dessous ne se fork jamais.
41Feature flags par tenant
Chaque module est un interrupteur. Paiements par chat, épargne, crypto, stories, parrainage, groupes, cartes d'équipe : chacun s'active par tenant, et les flags se déploient d'abord sur une fraction des utilisateurs avant d'être généralisés. Les opérateurs les basculent depuis le panneau de config de la console, sans déploiement.
42Ops et SLA
Le back-office est pensé pour la réalité de l'astreinte. Des disjoncteurs mettent un prestataire en pause sans déploiement, les files d'erreurs et les logs de webhooks font remonter les défaillances en direct, et le rapprochement suit chaque rail. Disponibilité et conditions de support sont fixées par contrat ; les outils pour les tenir sont livrés avec la plateforme.
