Un marketplace bancaire est une vitrine de produits et de services au sein de la banque en ligne et de l'application mobile, et non un agrégateur séparé comme une vitrine de comparaisons. Le client choisit une assurance, une connexion, des billets ou un paiement échelonné là où se trouvent sa carte et son compte, et paie dans le cadre de la banque. Self Cube rassemble une telle vitrine comme un module de l'écosystème, et non comme une bannière sur un site tiers. Il est important de le distinguer de « la banque pour les vendeurs de marketplaces » : ici, la banque maintient une étagère pour son client, et non un compte de règlement pour le magasin. Si le paiement fait sortir la personne de l'application, ce n'est plus un marketplace intégré.

Le client ne part pas payer ailleurs, la banque gagne de l'argent sur des services non financiers et para-financiers et maintient la fréquence d'accès à l'application — pas seulement pour « vérifier le solde ». L'écosystème dans le canal DBO réduit le départ vers des services tiers et fournit des données pour l'étagère personnelle. Il est pertinent de considérer non seulement la commission sur la commande, mais aussi le coût de la fidélisation du client dans le canal. Si la vitrine vit séparément de la carte et du compte, l'effet est généralement faible : la personne part quand même. Le paiement intégré et les recommandations sur les transactions lient justement cela.

Pas seulement des produits. Sur l'étagère se trouvent également des assurances, des connexions, des voyages, des billets, des abonnements, des certificats, des paiements échelonnés et des produits bancaires. L'assortiment est rassemblé en fonction du scénario client, et non d'un seul type de SKU. Il est pertinent de décider à l'avance ce que la banque est prête à vendre en tant que principal, ce qui est vendu comme vitrine du partenaire, et quelles données sont visibles pour le partenaire. Si cela est mélangé sans bureau et règles, la conformité et le support se désintègrent. Self Cube sépare justement la vitrine, le paiement dans le cadre de la banque et le bureau du partenaire.

Le paiement se fait par carte et compte du client dans le cadre de la banque, sans caisse obligatoire du partenaire comme étape séparée et sans exportation du noyau client à l'extérieur. Le partenaire voit l'assortiment, les promotions, la conversion et les ventes, mais pas le profil complet et l'historique des transactions. Il est pertinent de vérifier où le scénario de paiement est stocké et qui est le marchand. Si le client saisit des informations sur un domaine tiers, ce n'est plus un paiement intégré. Pour la banque, c'est aussi une question de fréquence de fraude : plus le chemin est court, moins il y a de points de substitution.

Le client confirme l'achat avec la même carte et le même compte qu'il utilise déjà dans le DBO. Un acquéreur séparé du partenaire comme étape obligatoire n'est pas nécessaire — sinon, la personne quitte à nouveau l'application. Les paiements échelonnés et les produits bancaires sur cette même étagère peuvent être réglés par le même cadre, et non par une seconde caisse. Il est pertinent de décrire à l'avance les retours, annulations et opérations contestées : elles doivent suivre les règles bancaires, et non « comme cela se passe chez le partenaire ». Si ce cadre n'existe pas, la vitrine a l'air belle, mais le support se noie dans des vérifications manuelles.

L'étagère est constituée en fonction du comportement transactionnel et du profil du client, et non comme une bannière aléatoire « tout le monde a la même chose ». La couche intelligente examine ce que la personne utilise déjà et propose des services connexes dans la même application. Il est pertinent de limiter quels événements peuvent être utilisés pour la recommandation et comment le client peut les désactiver. Si les recommandations sont uniquement basées sur les clics de la bannière, il n'y a pas de personnalisation. Le lien avec les opérations réelles distingue justement la vitrine bancaire d'un réseau publicitaire ordinaire.

Le cabinet partenaire montre l'assortiment, les promotions, la conversion et les ventes de son étagère. Le cœur du client, le profil complet et les produits d'autres banques ne sont pas divulgués. C'est une condition sans laquelle le marketplace se transforme en exportation de base de données. Il est judicieux de spécifier séparément quels agrégats peuvent être fournis pour vérification et avec quel délai. Si le partenaire demande des transactions brutes « pour l'analyse », c'est déjà un autre contrat et un autre risque. Self Cube maintient la frontière : le partenaire gère la vitrine, la banque — le client.

Les connecteurs prêts à l'emploi pour le commerce électronique, la logistique, l'assurance et les télécommunications réduisent le délai à quelques semaines, et non à une année entière pour une vitrine à partir de zéro. Le délai augmente si le partenaire n'a pas de catalogue stable, de prix et de statut de commande via API. Il est judicieux de vérifier à l'entrée non pas si le « logo est prêt », mais le contrat : assortiment, paiement, retours, cabinet. Les bannières sans API ne sont pas acceptées dans le contour — ce n'est pas une intégration. Il est préférable de commencer le pilote avec une seule catégorie, où le flux et la vérification sont clairs.