Les plus grandes institutions financières canadiennes investissent depuis des années dans des infrastructures modernes, et nombre d'entre elles ont maintenant des API performantes pour les paiements et les données de compte. L'ambition qui sous-tend cet investissement est claire : offrir de nouveaux services aux clients, établir de nouvelles relations d'affaires et développer de nouvelles façons d'atteindre les entreprises directement sur les plateformes qu'elles utilisent déjà. Lors de mes récents échanges avec les banques, l'accent a été mis sur la suite : quelles fonctionnalités développer grâce à ces API, avec quels partenaires les développer et dans quels délais elles pourront être commercialisées.
Aujourd'hui, Flinks lance des services professionnels et des services gérés, précisément pour répondre à ce besoin. Nous développons de nouvelles fonctionnalités financières en collaboration avec les équipes des institutions et prenons en charge l'infrastructure sous-jacente une fois opérationnelles. C'est là qu'intervient un partenaire technologique, et voici comment ça se traduit concrètement.
Où un partenaire technologique trouve sa place
Les feuilles de route des entreprises sont planifiées très longtemps à l'avance. La plupart de celles que je vois s'étalent sur un an, voire plus, ce qui signifie qu'une idée prometteuse qui émerge au printemps se retrouve en compétition avec tout ce qui est déjà prévu pour l'année suivante.
L'ouverture d'une API à des tiers soulève également des questions : qui y a accès ? Comment sont-ils intégrés ? Qu'arrive-t-il en cas de panne et qui prend la relève ?
Une seule institution contrôle tous les modes de paiement de ses clients, et toutes les transactions sont centralisées sur un seul compte.
Les institutions ont des équipes solides. Développer des compétences financières tournées vers l'extérieur est une spécialité à part entière, et Flinks le fait tous les jours ; un projet comme celui-ci peut donc démarrer pendant que les équipes internes poursuivent leurs propres feuilles de route.
Ce que ça donne en pratique
Voici un exemple récent, sans les noms.
Une banque canadienne nous a contactés avec un ensemble d'API de paiement : virements de compte à compte, paiements de factures et virements Interac. Un de ses clients commerciaux exploite une plateforme logicielle qui recueille les paiements de nombreuses organisations clientes. Pour cette plateforme, la gestion des paiements était catastrophique. Les fonds arrivaient par différents canaux, le rapprochement bancaire était pratiquement impossible et la facturation était beaucoup plus complexe qu'elle ne l'aurait été.
L'idée la plus évidente est celle d'un projet de paiement. Il suffit d'intégrer l'infrastructure bancaire à la plateforme, de simplifier l'encaissement et le rapprochement, et le tour est joué.
L'intérêt principal de la banque résidait dans les dépôts. La plateforme conserve des soldes considérables, et la stratégie commerciale de la banque repose sur l'acquisition et la rétention de ce type de clientèle. L'intégration directe de ses systèmes de paiement à la plateforme a permis à la banque de s'impliquer pleinement dans les opérations quotidiennes de l'entreprise. La plateforme dispose ainsi d'un seul établissement pour gérer tous les modes de paiement de ses clients, avec un seul compte centralisant les transactions et simplifiant le rapprochement bancaire. La banque a ainsi développé une relation d'affaires solide et durable.

La banque savait déjà ce qu'elle voulait : elle avait besoin de quelqu'un capable de rendre accessibles aux utilisateurs externes les API conçues pour un usage interne, de les déployer sur une plateforme tierce et d'en assurer le fonctionnement.
C'est le modèle que je constate constamment. La valeur d'une API réside souvent dans la relation qu'elle permet, et établir cette relation exige un travail spécifique.
Trois types de travail entre une API et les revenus

Savoir quoi construire. La banque mentionnée ci-dessus s'est fixé un objectif commercial : conquérir et fidéliser une clientèle d'entreprises détenant des soldes importants. Ses API de paiement ont été l'outil idéal pour y parvenir. Certaines institutions arrivent avec un objectif précis. D'autres apportent leurs API et nous questionnent sur les retours des fintechs et des plateformes avec lesquelles elles collaborent ; c'est comme ça que le travail commence.
La mise en œuvre est en cours. Dans le cadre de ce projet, la première étape a consisté en une phase de découverte payante afin de définir le fonctionnement des API en dehors des canaux internes de la banque. Une équipe dévouée travaille présentement à la mise en œuvre.
L'exécution a lieu après le lancement. Une fois l'intégration opérationnelle, les API doivent rester disponibles et la plateforme nécessite un support. Lorsque la banque déploie la même configuration chez son prochain client commercial, ce travail recommence pour chaque nouvelle plateforme.
Un partenaire qui couvre ces trois aspects permet à une institution d'évoluer au rythme qu'exige un marché concurrentiel.
Ce même principe s'applique bien au-delà des paiements intégrés. Nous avons mis en place un système de transfert de compte avec l'une des plus grandes banques canadiennes, permettant de transférer les contacts et les bénéficiaires de virements Interac d'un client vers son nouveau compte. Les transferts d'investissement, la gestion de la paie et l'analyse de crédit en marque blanche suivent une démarche similaire : l'établissement définit les objectifs, et nous développons avec lui des solutions conformes et assurons leur bon fonctionnement.
Pourquoi nous lançons des services professionnels et des services gérés
Flinks fait ce genre de travail avec ses clients depuis des années, souvent sans le nommer. Aujourd'hui, l'entreprise propose deux offres : les Services professionnels , pour définir la portée et développer la solution, et les Services gérés , pour l'exploiter une fois en production. L'équipe qui développe la solution est celle qui assure son exploitation. Vous pouvez consulter l' annonce complète ici .
Le principe est simple : si ça permet de connecter des comptes, de rendre les données financières exploitables ou de transférer de l’argent, on peut le créer avec vous.
La question que je poserais à toute institution est d'ordre pratique. Examinez les API dont vous disposez déjà et demandez-vous qui, en dehors de votre organisation, les utiliserait pour développer une partie de son activité. Cette liste pourrait être plus longue que prévu, et l'un des premiers noms pourrait être celui d'un de vos clients actuels.
Avez-vous un projet en tête ? Contactez notre équipe Entreprise.



