Le secteur de l’assurance a numérisé la distribution, la souscription et l’interaction avec les clients, mais le flux d’argent lui-même continue de passer par des canaux obsolètes. Avec Finsurtech.ai, Mirela Dimofte et Andrew Sims souhaitent Redéfinir la manière dont les primes et les sinistres sont payés, réglés, comparés et intégrés dans des écosystèmes.
Depuis des décennies, les assureurs investissent massivement dans des systèmes de gestion des polices, des plateformes CRM et des canaux de distribution numériques. Cependant, l’infrastructure financière sous-jacente – c’est-à-dire la manière dont les primes sont collectées et les sinistres payés – reste largement fragmentée, manuelle et centrée sur les banques. Cette lacune limite de plus en plus l’automatisation, l’expérience client et les modèles d’assurance en temps réel.
Finsurtech.ai se positionne comme une infrastructure de paiement spécialement conçue pour les assurances. Plutôt que d’adapter des outils génériques de fintech, l’entreprise se concentre sur la complexité opérationnelle spécifique du secteur : règlements multipartites, courtiers, MGA, flux de paiement transfrontaliers et paiements de sinistres.
Nous avons parlé avec les fondateurs Mirela Dimofte et Andrew Sims de la raison pour laquelle les assurances ont besoin de leur propre architecture de paiement et de ce qui se passe lorsque l’argent est déplacé aussi rapidement que les décisions d’assurance sont prises.
Le secteur de l’assurance a numérisé de nombreux processus de front-office. Pourquoi les paiements restent-ils l’un des domaines les moins modernisés ?
Mirela Dimofte (MD) : Au cours des dix dernières années, les assureurs ont commencé à numériser avec succès la distribution, la souscription et l’interaction avec les clients. Cependant, les flux financiers sous-jacents ont souvent été laissés sur d’anciens rails. Dans le passé, le traitement des paiements a été considéré comme une fonction technique de back-office plutôt que comme une partie de l’architecture de base des assurances. En conséquence, les demandes d’indemnisation et les paiements de primes passent toujours par des virements bancaires fragmentés, des comptes préfinancés et des rapprochements manuels, souvent répartis entre les TPA, les MGA et différents systèmes internes.
Comme ces mécanismes « fonctionnaient suffisamment bien », les investissements se sont généralement concentrés sur la tarification, les produits et les portails clients, plutôt que sur la manière dont le capital est réellement déplacé lorsqu’un sinistre est réglé ou qu’un courtier est payé. Compte tenu de l’ampleur et des attentes réglementaires actuelles, cette séparation entre la logique de l’assurance et le traitement des paiements entraîne des pertes de capital et des frictions opérationnelles. Finsurtech.ai a été créé pour combler précisément cette lacune en traitant l’architecture de paiement comme un élément de premier ordre du modèle opérationnel de l’assurance.
Qu’est-ce qui ne fonctionne plus au sein d’une compagnie d’assurance si l’infrastructure de paiement n’est pas conçue pour la logique de l’assurance ?
Andrew Sims (AS) Lorsque l’infrastructure de paiement n’est pas conçue pour les assurances, elle reflète davantage les processus de travail des banques ou des prestataires de services de paiement que la logique des sinistres et des polices. Il en résulte un décalage structurel entre ce qui a été approuvé dans le système de gestion des sinistres et l’exécution du paiement lui-même. Les données sont dispersées entre les plates-formes de sinistres, les portails bancaires, les systèmes des fournisseurs et les feuilles de calcul, de sorte que personne n’a une vision en temps réel de l’ensemble du cycle de vie financier d’un sinistre.
Sur le plan opérationnel, cela se traduit par des approbations manuelles, des fichiers batch et des vérifications répétées, juste pour s’assurer que la bonne partie reçoit le bon montant dans les bonnes conditions. Le service financier doit compenser par des préfinancements et des tampons, le service des sinistres est confronté à des pertes et à des reprises, et les équipes de rapprochement passent une grande partie de leur temps à rapprocher des transactions qui auraient pu être « intrinsèquement correctes ». En bref, la discipline d’exécution est en retard sur les intentions de traitement des sinistres, et le traitement des exceptions devient généralement une charge opérationnelle en soi.
Vous positionnez Finsurtech.ai comme une infrastructure et non comme un service de paiement. Quelle est la différence en termes d’architecture ?
AS : Un service de paiement se concentre généralement sur le traitement de transactions individuelles : Transférer de l’argent de A à B, par carte, par virement bancaire ou par portefeuille. Selon notre définition, l’infrastructure est une couche de contrôle intégrée qui relie de bout en bout les décisions relatives aux sinistres, la logique des partenaires et les mécanismes de financement. Au lieu de simplement fournir un canal supplémentaire, Finsurtech.ai intègre les paramètres de règlement directement dans l’ordre de paiement, et dans certains cas dans l’instrument de paiement, et coordonne les opérations entre plusieurs banques, systèmes et partenaires.
D’un point de vue architectural, cela signifie que nous sommes « assis sous les produits et les processus, et non à côté d’eux ».
Nous traduisons une décision de sinistre approuvée en règles exécutables : qui peut être payé, pour quels services, dans quelles limites et nous appliquons ces règles au moment crucial pendant le processus de règlement. La même infrastructure peut prendre en charge les cartes virtuelles, les paiements instantanés, les règlements multipartites et autres. Pour les assureurs, cela crée une base opérationnelle unique pour les primes, les sinistres, les commissions et les opérations des partenaires, sans les obliger à utiliser le produit de paiement propriétaire d’un seul fournisseur.
Où voyez-vous les plus grandes inefficacités aujourd’hui : dans la collecte des primes, le paiement des sinistres, le rapprochement ou la facturation des partenaires ?
MD : Les quatre domaines présentent des inefficacités structurelles, mais l’impact économique le plus important se situe généralement à l’interface entre le paiement des sinistres et le rapprochement, en particulier lorsque des pouvoirs délégués et des écosystèmes complexes sont impliqués. Lors du paiement des sinistres, les décisions deviennent des espèces sonnantes et trébuchantes ; toute faiblesse dans la discipline d’exécution, comme les doubles paiements, les prestations hors du champ d’application des prestations, les retards, a un impact direct sur le ratio de sinistres et l’utilisation du capital.
Le rapprochement absorbe alors les coûts en aval de cette fragmentation. Les équipes rapprochent manuellement les relevés de compte avec les bordereaux, les rapports des partenaires et les grands livres comptables internes, souvent des semaines ou des mois après l’événement. Les relevés de partenaires aggravent le problème, car les fonds sont versés à l’avance aux TPA, MGA ou réseaux pour compenser le contrôle limité lors de l’exécution. Notre approche consiste à traiter ces domaines comme un processus cohérent : Les paiements sont réglés au moment du règlement et les données au niveau des transactions sont générées automatiquement, de sorte que le rapprochement et le règlement des partenaires deviennent des sous-produits de l’exécution et non plus des processus manuels distincts.
En quoi les paiements d’assurance sont-ils structurellement différents des paiements de commerce électronique ou des paiements bancaires ?
AS : Dans le commerce électronique, la plupart des transactions sont uniques et bilatérales : un commerçant, un client, un produit clair et un règlement immédiat. Dans le secteur bancaire, les paiements sont souvent des virements de compte à compte avec une logique commerciale relativement simple. Les paiements d’assurance, en revanche, sont en plusieurs parties, échelonnés dans le temps et étroitement liés aux provisions. Un seul sinistre peut impliquer des assurés, des réparateurs, des prestataires de services médicaux, des partenaires d’assistance, des courtiers et des réassureurs, chacun ayant ses propres contrats et conditions.
En outre, le coût final d’un sinistre n’est pas connu à l’avance. L’étendue et la tarification évoluent au fur et à mesure des réparations ou des modifications des plans de traitement. Les systèmes de paiement traditionnels n’ont jamais été conçus pour prendre en compte cette logique d’assurance dynamique au moment du règlement. Finsurtech.ai résout ce problème en traitant chaque paiement comme un instrument contenant le contexte du sinistre, c’est-à-dire les limites, les prestations autorisées et les contreparties, de sorte que l’exécution puisse suivre l’intention technique de la police et la décision de sinistre.
Comment votre plate-forme gère-t-elle les flux de paiement multipartites ? Par exemple, avec des assureurs, des courtiers, des réassureurs et des assurés dans une chaîne de transactions ?
AS : Nous commençons par modéliser l’intention économique de la chaîne de transactions : qui supporte quelle part des coûts, qui doit être payé, dans quel ordre et sous quelles conditions ? Cette logique est ensuite intégrée dans notre niveau d’orchestration. Au lieu de pousser un gros paiement dans le système et de le « trier » plus tard, nous créons des instructions de paiement structurées pour chaque partie, chacune avec ses propres paramètres et contrôles.
Par exemple, un sinistre automobile pourrait déclencher une série de processus coordonnés : une carte virtuelle pour le réparateur, limitée aux travaux autorisés, un remboursement direct à l’assuré et un ordre de règlement à un réassureur dès que certains seuils sont atteints. Tout cela est basé sur le même sinistre et le même contexte d’approbation. L’assureur conserve une vue unique sur l’ensemble du cycle de vie : statut, montants, calendrier, tandis que chaque partie prenante reçoit un paiement simple et direct. La complexité est gérée dans l’infrastructure, pas dans les processus manuels.
Le paiement des indemnités d’assurance est un moment émotionnellement critique pour les clients. D’un point de vue technique, que requiert en coulisses le « règlement des sinistres en temps réel » ?
MD : Le règlement des sinistres en temps réel n’est pas seulement une question de rapidité, mais aussi de disposer d’un contrôle et d’un contexte suffisants pour pouvoir débloquer des fonds en toute sécurité au moment de la décision. D’un point de vue technique, cela nécessite une intégration entre le système de gestion des sinistres, la couche d’orchestration des paiements et les rails sous-jacents. La plateforme de gestion des sinistres doit transmettre les paramètres de règlement structurés, tels que le montant approuvé, les contreparties et les conditions, à la couche de paiement via des API ou par lots.
Notre infrastructure transforme ensuite ces données en instruments dédiés, tels que les numéros de carte virtuels ou les paiements instantanés, qui font respecter ces paramètres au moment crucial et l’autorisation en cas de VCN ou d’approbation au moment des paiements de compte à compte.
Les décisions en temps réel dépendent également d’un feedback immédiat : chaque autorisation, refus ou approbation partielle renvoie des données structurées à l’assureur. Cela crée une boucle de rétroaction dans laquelle les décisions de couverture, la communication avec le client et l’exécution des paiements sont prises en quelques secondes, mais restent entièrement contrôlées et vérifiables.
Comment s’intègrez-vous aux anciens systèmes de gestion des polices qui n’ont jamais été conçus pour les services financiers gérés par API ?
AS : De nombreux systèmes centraux dans la région DACH et en Europe centrale sont robustes, mais monolithiques. Nous ne demandons pas à nos clients de les remplacer. Au lieu de cela, nous introduisons une couche d’intégration qui peut recevoir des événements ou des fichiers du système central et les importer dans notre plate-forme. Les modèles d’intégration vont des exportations par lots aux API et aux hooks basés sur les événements, selon la volonté et les besoins du client.
Une fois connecté, le système de gestion des polices ou des sinistres reste la « source de vérité » pour la couverture et les décisions, tandis que Finsurtech.ai devient le moteur d’exécution pour les paiements et la logique de facturation. Au fil du temps, les assureurs peuvent passer d’une intégration par lots à une intégration presque en temps réel sans migration radicale. Cette approche respecte les investissements existants tout en ouvrant la voie à des fonctionnalités modernes telles que les cartes virtuelles, les paiements programmables et les rapprochements automatisés.
Le rapprochement est un facteur de coût massif dans le secteur financier de l’assurance. Quelle part peut être automatisée de manière réaliste ?
MD : Notre expérience montre qu’une très grande partie du travail de rapprochement consiste à compenser la mauvaise qualité des données au moment du paiement. Lorsque chaque transaction contient une référence de sinistre unique, une catégorie de service, un identifiant de fournisseur et un contexte de règlement, le rapprochement devient une activité basée sur des règles et non plus un travail de détective manuel. Dans cet environnement, la plupart des lignes de rapprochement peuvent être automatisées, ce qui permet au personnel de se concentrer sur les véritables exceptions.
Finsurtech.ai y parvient en générant des enregistrements structurés au niveau de la transaction dans le cadre du flux de paiement lui-même. L’instrument de paiement est créé à partir du sinistre, de sorte que les identifiants utilisés par le service financier correspondent déjà à ceux utilisés dans la gestion des sinistres et des opérations. Les relevés de compte et les rapports des partenaires sont saisis et automatiquement comparés à ce grand livre canonique. Cela ne supprime pas la nécessité d’une supervision financière, mais le rapprochement passe d’une intervention mensuelle des pompiers à un processus contrôlé et géré par des exceptions.
Qui est votre principal client : le CIO, le CFO, le directeur des opérations ou le directeur commercial ?
MD : Les principaux sponsors sont généralement le directeur financier et le directeur de l’exploitation, souvent avec le directeur des sinistres. Ce sont eux qui ressentent le plus directement l’impact de l’efficacité des paiements dans les ratios de sinistres, l’utilisation du capital et les coûts opérationnels. Parallèlement, le DSI est un partenaire important, car la solution concerne les systèmes de base, les modèles d’intégration et l’architecture de sécurité.
Il existe souvent un groupe de pilotage interfonctionnel : le service financier définit les objectifs en matière de capital et de liquidités, le service des sinistres se concentre sur les délais d’exécution et les pertes, les opérations sur l’évolutivité et l’informatique sur l’adéquation architecturale. Des cadres de la distribution et de la bancassurance s’y ajoutent lorsque les flux de commissions, l’assurance intégrée ou les écosystèmes de partenaires sont au centre des préoccupations. Finsurtech.ai a été conçu pour servir toutes ces parties prenantes via une infrastructure commune, plutôt que d’ajouter un autre outil isolé.
Comment les courtiers et les MGA bénéficient-ils directement d’une infrastructure de paiement moderne ?
AS : Les courtiers et les MGA vivent de la qualité et de la prévisibilité des flux de trésorerie. Lorsque les paiements sont en retard, opaques ou incohérents, cela pèse sur les relations et le fonds de roulement de toutes les parties. Avec une infrastructure moderne, les règlements peuvent être planifiés et exécutés selon des règles claires et programmables, en fonction de l’accord, du portefeuille ou de la transaction, ce qui réduit les litiges et le suivi manuel.
Comme chaque paiement est lié à un sinistre, une police ou une commission, les partenaires bénéficient d’une meilleure visibilité sur ce qui a été payé et pourquoi. Cela réduit les efforts de rapprochement et permet aux courtiers et aux MGA de se concentrer sur la croissance et le service plutôt que de courir après les règlements. Dans certains modèles, ils peuvent également accéder à des paiements basés sur VCN pour les coûts des sinistres qu’ils gèrent, ce qui élimine le besoin de disposer d’importants soldes préfinancés. Cela améliore leurs liquidités tout en donnant à l’assureur un contrôle et une visibilité plus détaillés sur les paiements acheminés par les partenaires.
Les écosystèmes d’assurance intégrés (mobilité, voyages, plateformes) nécessitent-ils une architecture financière fondamentalement différente ?
MD : Les écosystèmes embarqués augmentent la complexité de deux manières : premièrement, ils introduisent des plateformes non assurantielles telles que des applications de mobilité, des portails de voyage ou des places de marché comme points de contact pour la distribution et parfois pour les sinistres.
Deuxièmement, ils fonctionnent souvent avec une fréquence élevée et une petite taille de tickets, ce qui est difficile à gérer efficacement par des modèles de facturation traditionnels basés sur des lots. En ce sens, elles nécessitent effectivement des fonctions financières plus programmables.
Les principes de base restent toutefois les mêmes : des règles claires sur qui doit être payé, quand et dans quelles conditions, une transparence en temps réel et une gouvernance forte au point de paiement. L’architecture du système de base reste également inchangée. Finsurtech.ai est construit comme une couche extensible qui se connecte aux partenaires de la plate-forme, traite les flux de microtransactions et rapproche néanmoins le tout des sinistres et de la logique de la police de l’assureur. Cela permet aux assureurs de participer à des écosystèmes intégrés sans avoir à créer une logique de paiement sur mesure pour chaque partenaire et sans avoir besoin de systèmes distincts pour différents accords de distribution.
Les paiements impliquent des risques réglementaires : mesures de protection, LBC, conformité transfrontalière. Comment structurez-vous la plate-forme pour qu’elle fonctionne dans différentes juridictions ?
AS : Nous concevons l’architecture de manière à ce que les responsabilités réglementaires soient claires et compréhensibles. La plate-forme peut travailler avec des partenaires de paiement (banques, établissements de monnaie électronique, émetteurs de cartes et processeurs) dans n’importe quelle juridiction, tandis que Finsurtech.ai se concentre sur la coordination, l’exécution des règles et l’intégrité des données. Cela nous permet d’utiliser des cadres de conformité locaux pour la LBC, les contrôles de sanction et les mesures de protection, sans obliger les assureurs à avoir une seule relation bancaire.
D’un point de vue technique, nous veillons à ce que chaque transaction contienne les métadonnées requises : Payeur, bénéficiaire, objet, référence du sinistre, localisation géographique, afin que la vérification et le reporting soient précis et vérifiables. Les flux de paiement transfrontaliers peuvent être acheminés via des corridors appropriés, le règlement en devises et les exigences locales étant codés dans le moteur de règles. Pour les assureurs opérant en Suisse, dans l’UE et dans d’autres régions, cela signifie qu’ils peuvent appliquer un système de contrôle uniforme tout en tenant compte des spécificités réglementaires locales.
Au-delà des tâches réglementaires et des modèles de partenariat, nous nous occupons également de la souveraineté des données et de la protection des données par la conception technique. Notre architecture peut être déployée sur des technologies de base de données distribuées qui conservent les données sensibles dans les juridictions requises tout en offrant une vue logique unique à l’assureur. Des compartiments ou des tenants régionaux garantissent que les données suisses, européennes ou autres données locales ne quittent jamais les sites approuvés, ce qui permet de répondre aux exigences nationales en matière de résidence des données et aux attentes réglementaires. Les données personnelles sont traitées en totale conformité avec le RGPD et les cadres associés, y compris la limitation des finalités, la minimisation, un cryptage fort, des contrôles d’accès et des transferts transfrontaliers vérifiables, en utilisant des mesures de sécurité appropriées.
Les données de paiement pourraient-elles finalement fournir des informations pour la souscription et la gestion des fournisseurs ?
MD : Oui, nous pensons que les données de paiement sont une source largement inexploitée d’informations sur la souscription. Aujourd’hui, de nombreux modèles s’appuient sur des informations statiques et des sinistres historiques, mais pas sur les dynamiques de règlement détaillées derrière ces sinistres. Lorsque chaque transaction est liée à des services, des fournisseurs, des calendriers et des comportements spécifiques, il en résulte des modèles qui peuvent influencer à la fois la tarification et la conception des produits.
Par exemple, les fournisseurs ou les réseaux qui génèrent régulièrement des coûts supplémentaires, qui ont des cycles de réparation plus longs ou qui sont fréquemment rouverts, peuvent être identifiés et traités différemment. De même, certains canaux ou configurations de produits peuvent présenter des profils d’évolution des coûts différents au fil du temps. Notre mission est de fournir un ensemble de données propres et structurées que les souscripteurs et les actuaires peuvent utiliser en toute sécurité, sans compromettre la confidentialité, pour affiner les hypothèses sur la fréquence, la gravité et l’inflation des sinistres.
Si les assureurs disposaient de flux financiers entièrement programmables, quels nouveaux produits d’assurance deviendraient soudainement possibles ?
MD : L’argent entièrement programmable permet aux assureurs de passer d’un paiement « après coup » à un financement de résultats bien définis, presque en temps réel. Cela rend les produits paramétriques et basés sur des événements beaucoup plus pratiques à grande échelle, car les paiements peuvent être automatiquement libérés vers des contreparties autorisées dès que les conditions sont remplies. En outre, cela permet de mettre en place des prestations échelonnées, telles que des paquets de réhabilitation ou de réparation, dans lesquels les fonds sont libérés progressivement au fur et à mesure que les prestations sont fournies.
Dans le secteur de la vente au détail, on pourrait imaginer des porte-monnaie liés aux sinistres ou des cartes virtuelles permettant une autorisation immédiate avec une utilisation strictement contrôlée, faisant ainsi du règlement des sinistres une sorte d’achat assisté plutôt qu’un processus de remboursement.
Dans le secteur commercial, des structures complexes impliquant plusieurs parties, telles que des projets de construction ou des plateformes de mobilité, pourraient être financées par des processus basés sur des règles et réagissant aux jalons, à la télémétrie ou aux signaux IoT.
Dans tous les cas, le fil conducteur est le même : le capital se comporte exactement comme le concepteur du produit l’a voulu, car la logique de paiement est directement encodée dans le processus. Ce sont des conversations passionnantes que nous attendons avec impatience au fil du temps avec nos clients.
Les questions ont été posées par Binci Heeb.
Lire aussi : De la compréhension à la mise en œuvre : comment l’intelligence des processus redéfinit la gestion des sinistres
Recherche :
Sponsors :
