Sinistres Vie et IARD

Des sinistres que vous pouvez prouver, pas seulement traiter.

De la déclaration de sinistre au règlement, au provisionnement, au paiement et au recours sur un même moteur — garanties vérifiées contre le contrat en vigueur à la date du sinistre, provisions toujours conformes à leur registre, paiements contrôlés contre les plafonds réels et délais légaux calculés sur de vrais calendriers de jours ouvrés.

Réserver une démoVoir la plateformeDémo interactive
app.aegisnow.ai/claims

Centre de pilotage des sinistres

En direct

Garanties vérifiées

100 %

Délai moyen de traitement

4,1 j

↓-2,3 j

Écart du registre

0

Délais sur règles de calendrier

448

Sinistres traités, 8 dernières semaines

Tendance

AegisNow Smart Claims est une plateforme de gestion de sinistres de bout en bout pour les assureurs Vie et IARD, couvrant la déclaration, le règlement, le provisionnement, le paiement et le recours. Les garanties sont vérifiées dès la déclaration contre l'édition de produit en vigueur à la date du sinistre et le contrôle est conservé ; chaque mouvement de provision est inscrit dans un registre auquel le sinistre doit se conformer ; un paiement qui dépasserait un plafond est refusé ; et une décision défavorable influencée par l'IA ne peut être écrite sans une revue humaine nommée, réalisée par une personne détenant l'autorité qu'exigeait la décision.

0 %des mouvements de provision inscrits au registre

Résultat illustratif. Lors d'une démo de travail, nous adapterons Smart Claims à vos propres données, référentiels et objectifs.

Pourquoi les équipes le choisissent

Les arguments pour Smart Claims

Chaque décision du dossier a un auteur, une règle et une trace.

Les garanties tranchées sur les conditions en vigueur

La version de contrat et l'édition de produit en vigueur à la date du sinistre régissent le dossier — une condition modifiée après coup ne peut donc pas changer rétroactivement ce qui était garanti.

Des provisions conformes à leur registre

Un seul rédacteur, des mouvements typés et un invariant vérifié sur tout le portefeuille : la provision du sinistre est toujours égale à son dernier mouvement enregistré.

Des paiements contrôlés contre les plafonds réels

Chaque paiement est confronté au plafond et à la sous-limite nets des règlements antérieurs, et refusé s'il les dépassait — avec les chiffres qui fondent le refus.

Les décisions défavorables portent un relecteur nommé

L'influence de l'IA est détectée et non déclarée, et un refus qu'elle a touché exige une revue humaine par une personne détenant la même autorité que la décision elle-même.

Des délais calculés, pas estimés

Jours ouvrés sur les calendriers de jours fériés par juridiction, règles à date d'effet rapprochées par date de sinistre, et un marqueur explicite partout où le point de départ légal est substitué.

Une preuve qui résiste à l'examen

Les documents portent une empreinte de contenu, un verdict d'analyse explicite et une horloge de conservation qui supprime réellement — et rien qui n'ait été analysé n'est présenté comme sain.

Dans le module

Des capacités disponibles dès le premier jour

Chaque capacité s'appuie sur le socle de données partagé, le cerveau Cortex gouverné et le registre de preuves : Smart Claims se cumule avec le reste de la plateforme.

Déclaration de sinistre et vérification des garanties

Les garanties sont contrôlées contre le contrat en vigueur à la date du sinistre, et le contrôle est conservé.

En savoir plus

Règlement sous autorité enregistrée

Qui peut décider relève d'une échelle d'habilitations, et un refus influencé par l'IA exige une revue humaine nommée avant d'être inscrit.

En savoir plus

Le registre des provisions

Un rédacteur, un registre : la provision du sinistre est toujours égale à son dernier mouvement enregistré.

En savoir plus

Des paiements face aux plafonds réels

Un seul registre de paiements, et un paiement qui dépasserait le plafond de garantie est refusé plutôt qu'enregistré.

En savoir plus
app.aegisnow.ai/claims

Centre de pilotage des sinistres

En direct

Garanties vérifiées

100 %

Délai moyen de traitement

4,1 j

↓-2,3 j

Écart du registre

0

Délais sur règles de calendrier

448

Sinistres traités, 8 dernières semaines

Tendance

Une preuve documentaire opposable

De vrais octets, une empreinte de contenu, un verdict d'analyse explicite et une horloge de conservation qui supprime réellement.

En savoir plus

Des délais légaux sur de vrais calendriers

Jours ouvrés contre les calendriers de jours fériés par juridiction, règles à date d'effet et un point de départ honnête.

En savoir plus

Recours : subrogation, sauvetage et réassurance

Les récupérations comme positions suivies contre le sinistre, y compris les cessions au programme de réassurance.

En savoir plus

Correspondance, recours et ce qui a réellement été envoyé

L'état d'acheminement vit sur l'enregistrement, de sorte qu'un courrier rédigé ne peut jamais se lire comme un courrier remis.

En savoir plus
Détail des capacités

Ce que chaque capacité fait vraiment

Chaque section ci-dessous dispose de son propre lien : une réponse précise peut être citée telle quelle, sans être noyée dans la page.

Capacité 01

Déclaration de sinistre et vérification des garanties

Les garanties sont contrôlées contre le contrat en vigueur à la date du sinistre, et le contrôle est conservé.

Un sinistre s'ouvre avec une référence attribuée par une séquence propre à chaque organisation et une clé d'idempotence, de sorte qu'une déclaration relancée depuis le portail après une expiration ne peut pas ouvrir deux fois le même sinistre. La date de survenance, la cause, la juridiction, le canal de déclaration et l'identité de l'assuré et du réclamant sont saisies à la déclaration plutôt que complétées ensuite, car chaque contrôle en aval s'appuie sur l'une d'elles : les garanties sur la date de survenance, l'horloge des délais sur la juridiction et la date de déclaration, le niveau d'autorité sur l'exposition.

Les garanties sont vérifiées dès la déclaration au lieu d'être présumées. La plateforme résout la version de contrat en vigueur à la DATE DU SINISTRE — et non celle en vigueur aujourd'hui — puis lit plafonds, sous-limites, franchises, exclusions et conditions dans l'édition de produit à date d'effet sur laquelle ce contrat a été souscrit. Les éditions de produit sont immuables une fois écrites : une condition modifiée après le sinistre ne peut donc pas changer rétroactivement les droits du dossier.

Le contrôle est conservé, pas seulement appliqué. Chaque vérification est une ligne en ajout seul consignant ce qui a été testé, ce qui a été trouvé et pourquoi la garantie a été retenue ou refusée, contrôle par contrôle. C'est ce qui permet à la plateforme de refuser un trop-perçu des mois plus tard en montrant son raisonnement, et c'est toute la différence entre une position de garantie que l'on affirme et une que l'on peut produire.

Ce qu'elle fait

  • Attribuer la référence du sinistre depuis une séquence propre à l'organisation et rejeter une déclaration en double par clé d'idempotence.
  • Résoudre la version de contrat en vigueur à la date du sinistre plutôt que celle en vigueur aujourd'hui.
  • Lire plafonds, sous-limites, franchises, exclusions et conditions dans l'édition de produit à date d'effet sur laquelle le contrat a été souscrit.
  • Consigner chaque décision de garantie comme une ligne en ajout seul nommant le contrôle, le constat et le motif.
  • Saisir dès la déclaration la juridiction et le canal, sur lesquels s'ancre le moteur de délais légaux.
  • Ouvrir la piste d'événements du sinistre à la déclaration, pour que le dossier commence comme une trace et non comme un état.

Met en œuvre

  • Conditions de contrat et de produit à date d'effet
  • Éditions de produit immuables
  • Registre en ajout seul des décisions de garantie

À voir dans le produit

Ouvrez un sinistre dans Sinistres et regardez son volet garanties. Les plafonds affichés sont lus dans l'édition de produit en vigueur à la date du sinistre, et l'historique de vérification énumère chaque contrôle avec son constat — pas un simple indicateur « garanti ».

Capacité 02

Règlement sous autorité enregistrée

Qui peut décider relève d'une échelle d'habilitations, et un refus influencé par l'IA exige une revue humaine nommée avant d'être inscrit.

Le règlement est l'acte d'une personne identifiée sous une autorité enregistrée, non le franchissement d'un seuil par un score. La décision — accepter, refuser ou partiel — est prise par un utilisateur détenant l'habilitation correspondante, et le niveau requis s'élève avec le dossier : l'exposition, le contentieux, le rattachement à un événement catastrophique et l'indicateur SIU font chacun monter la décision d'un cran. Un utilisateur sans le niveau requis est refusé, et le refus nomme le facteur qui l'a élevé.

Lorsqu'un système d'IA a influencé une décision défavorable, la plateforme le détecte au lieu de s'en remettre à la déclaration de l'appelant. Omettre l'identifiant d'exécution ne rend pas la décision étrangère à l'IA : les exécutions gouvernées citant ce sinistre sont retrouvées de toute façon. Un refus, une réduction partielle ou un signalement SIU influencé par l'IA ne peut être écrit sans revue humaine enregistrée, et le relecteur doit détenir la même habilitation qu'exigeait la décision — une sortie de modèle déterminante élève la revue au niveau superviseur. Il n'existe pas de seconde échelle d'approbation, plus faible, pour l'IA.

Ce qui s'inscrit, c'est une entrée au registre des décisions défavorables et, à côté, un dossier de voies de recours ouvert dans la même transaction : ce qui a été communiqué au consommateur, par quel canal, et s'il l'a contesté. Ses champs de notification démarrent vides à dessein. Une ligne de notification interne ne prouve pas que quiconque a été informé, et le dossier refuse de laisser croire le contraire.

Ce qu'elle fait

  • Élever le niveau d'autorité requis selon l'exposition du sinistre, le contentieux, le rattachement catastrophique et l'indicateur SIU, et nommer le facteur qui l'a élevé.
  • Refuser la décision d'un utilisateur ne détenant pas l'habilitation, au lieu de journaliser un avertissement et de poursuivre.
  • Détecter l'influence de l'IA à partir des exécutions gouvernées citant le sinistre, pour qu'un identifiant omis ne blanchisse pas la décision.
  • Bloquer un refus, un règlement partiel ou un signalement SIU influencé par l'IA sans revue humaine enregistrée.
  • Exiger que le relecteur détienne la même habilitation que la décision, avec escalade au superviseur pour une sortie de modèle déterminante.
  • Ouvrir le dossier de voies de recours dans la même transaction que la décision défavorable, champs de notification vides tant qu'aucune notification réelle n'est consignée.
  • Écrire la décision, l'événement et l'entrée au registre en une seule transaction, ou aucun des trois.

Met en œuvre

  • Bulletin type de la NAIC sur l'usage de l'IA par les assureurs (alignement, non certification)
  • Registre de décision défavorable avec voies de recours
  • Autorité de décision limitée par habilitation

À voir dans le produit

Tentez un refus influencé par l'IA sans revue humaine enregistrée : l'API renvoie 403 adverse_decision_review_missing et le sinistre reste inchangé. Faites approuver la revue par un utilisateur sans autorité sinistres et elle renvoie 403 adverse_decision_reviewer_unauthorised.

Capacité 03

Le registre des provisions

Un rédacteur, un registre : la provision du sinistre est toujours égale à son dernier mouvement enregistré.

Toute modification d'une provision est un mouvement inscrit dans un registre, et le registre est le seul chemin par lequel une provision bouge. Une fonction unique ajoute le mouvement et met à jour le sinistre dans la même transaction ; rien d'autre ne peut fixer le montant. L'invariant — la provision du sinistre égale le montant final de son dernier mouvement — est vérifié par un test qui parcourt tout le portefeuille, et non énoncé dans un commentaire.

Les mouvements sont typés, de sorte que l'historique répond au pourquoi et pas seulement au combien : dotation initiale, majoration sur aggravation, réduction, consommation par un paiement, et clôture. Une consommation porte l'identifiant du paiement qui l'a causée, ce qui rend la cause et l'effet reliables plutôt que déduits d'horodatages. Chaque mouvement enregistre le montant de part et d'autre, lu sur le sinistre et non sur la ligne précédente — ainsi une lacune de l'historique ne peut pas se propager silencieusement dans l'arithmétique du mouvement suivant.

Tout ceci existe parce que l'invariant était silencieusement faux. Le chemin de paiement calculait la nouvelle provision et l'écrivait sur le sinistre sans rien ajouter : la provision bougeait et le registre n'en savait rien. Le rapprochement s'est fait vers le sinistre, pas vers le registre : le montant en cache était celui sur lequel le métier avait agi, la correction ajoute donc le mouvement manquant au lieu de réécrire l'histoire pour la faire coïncider avec la trace. Les mouvements reconstruits portent une marque de reconstruction et se distinguent de ceux saisis sur le moment.

Ce qu'elle fait

  • Ajouter le mouvement et faire bouger le sinistre en une seule transaction, via l'unique rédacteur de provisions.
  • Typer chaque mouvement en dotation, majoration, réduction, consommation par paiement ou clôture.
  • Relier une consommation au paiement qui l'a causée.
  • Enregistrer le montant de part et d'autre de chaque mouvement, lu sur le sinistre pour qu'une lacune du registre ne se propage pas.
  • Maintenir la charge encourue égale au payé plus la provision au fil des mouvements.
  • Empêcher une provision de passer sous zéro.
  • Signaler tout sinistre dont la provision en cache diverge de son dernier mouvement, comme requête vérifiable et non comme affirmation en prose.
  • Distinguer l'historique reconstruit des mouvements saisis sur le moment.

Met en œuvre

  • Registre des mouvements de provision dossier par dossier
  • Charge encourue = payé + provision
  • Historique reconstruit à provenance marquée

À voir dans le produit

Ouvrez Provisionnement et prenez un sinistre ayant un historique de paiements. Chaque montant affiché a un mouvement derrière lui, typé et daté, et une consommation par paiement nomme le paiement qui l'a causée.

Capacité 04

Des paiements face aux plafonds réels

Un seul registre de paiements, et un paiement qui dépasserait le plafond de garantie est refusé plutôt qu'enregistré.

Les paiements de sinistres passent par un registre canonique unique qui produit également les écritures comptables et l'ordre de règlement : le mouvement de fonds, l'écriture et l'instruction au bénéficiaire proviennent d'une seule écriture plutôt que de trois systèmes qui se mettent d'accord après coup. Un paiement consomme la provision sous forme de mouvement typé dans le registre, au sein de la même transaction.

Les paiements sont confrontés à la garantie vérifiée dès la déclaration — le plafond et la sous-limite de l'édition de produit en vigueur à la date du sinistre, déduction faite des règlements déjà effectués. Ce n'est pas une question d'affichage. Lors de sa mise en place, ce contrôle a trouvé deux sinistres déjà payés au-delà de leur plafond par sinistre, et les plafonds dérivés au dossier avaient été relevés pour coller aux paiements, au lieu que les paiements soient bornés par les plafonds.

Le recours revient par le même registre. Les récupérations par subrogation, sauvetage et réassurance sont enregistrées contre le sinistre auquel elles se rapportent, de sorte que la charge nette est une position calculée et non un chiffre entretenu à côté du brut.

Ce qu'elle fait

  • Écrire le paiement, l'écriture comptable et l'ordre de règlement en une seule transaction.
  • Consommer la provision par un mouvement typé relié au paiement.
  • Confronter chaque paiement au plafond et à la sous-limite de l'édition de produit en vigueur à la date du sinistre, nets des règlements antérieurs.
  • Refuser un paiement qui dépasserait le plafond au lieu de l'enregistrer et de signaler le dépassement ensuite.
  • Enregistrer les récupérations par subrogation, sauvetage et réassurance contre le sinistre pour que la charge nette soit calculée.
  • Conserver l'historique des paiements immuable et imputable à l'utilisateur qui les a autorisés.

Met en œuvre

  • Registre canonique des paiements avec écritures comptables
  • Contrôle des plafonds par sinistre et en agrégé
  • Application des sous-limites et des franchises

À voir dans le produit

Tentez un paiement qui porterait un sinistre au-delà de son plafond par sinistre. Il est refusé avec le plafond, le payé à ce jour et le dépassement — les chiffres qui fondent le refus, pas une erreur générique.

Capacité 05

Une preuve documentaire opposable

De vrais octets, une empreinte de contenu, un verdict d'analyse explicite et une horloge de conservation qui supprime réellement.

Un document de sinistre est un contenu stocké, pas un nom de fichier. Les dépôts passent par une couche de stockage d'objets qui renvoie l'empreinte SHA-256 de ce qui a réellement été enregistré, la taille mesurée sur les octets plutôt que déclarée par le client, et le type de contenu déduit du fichier lui-même — un PNG déposé en text/plain est consigné comme l'incohérence qu'il est. Les téléchargements sont délivrés par URL signées de courte durée et non par des chemins ouverts.

Chaque document porte son état de preuve explicitement, et l'interface refuse de l'arrondir par le haut. Un enregistrement sans objet stocké s'affiche comme « aucun fichier joint », sans bouton de téléchargement — pas un bouton qui échoue. Un statut d'analyse « ignoré » s'affiche comme « non analysé », jamais comme sain, car l'absence de verdict n'est pas un feu vert. Une taille déclarée et non mesurée est étiquetée comme déclarée. Aucun de ces états ne se déduit d'un autre : une empreinte prouve que l'objet n'a pas changé, ce qui n'est pas prouver que le contenu est bien ce qu'il prétend être.

La conservation est appliquée, pas décrite. Chaque document porte une classe de conservation, une date de conservation jusqu'à et un indicateur de conservation judiciaire ; un balayage purge les documents échus, supprime les octets, annule le pointeur de stockage et ajoute un événement d'audit nommant ce qui a été supprimé. L'empreinte de contenu survit délibérément à la purge — la ligne devient une pierre tombale capable d'identifier encore le document si une copie refait surface. Un document sous conservation judiciaire n'est jamais purgé, et le garde-fou est revérifié au point de suppression plutôt que confié à la requête de sélection.

Ce qu'elle fait

  • Calculer l'empreinte SHA-256 du contenu stocké et mesurer taille et type de contenu sur les octets, non sur la déclaration du client.
  • Délivrer les téléchargements par URL signées de courte durée plutôt que par des chemins de stockage ouverts.
  • Afficher un enregistrement sans objet stocké comme « aucun fichier joint », sans aucun contrôle de téléchargement.
  • Afficher un document non analysé comme « non analysé » et non comme sain, et ne jamais dériver un badge de sécurité de l'empreinte.
  • Purger les documents échus de façon planifiée, supprimer les octets et ajouter un événement d'audit nommant ce qui a été supprimé.
  • Conserver l'empreinte après la purge pour que la ligne reste identifiable comme pierre tombale.
  • Refuser de purger un document sous conservation judiciaire, vérifié au point de suppression et pas seulement dans la requête de sélection.
  • Consigner comme déclarée une taille déclarée et non mesurée, pour qu'elle ne puisse pas passer pour une mesure.

Met en œuvre

  • Adressage par contenu SHA-256
  • Classes de conservation avec conservation judiciaire
  • URL de téléchargement signées et expirantes

À voir dans le produit

Déposez un fichier sur la page Documents d'un sinistre, puis demandez son téléchargement : vous obtenez une URL signée et des octets dont l'empreinte correspond à celle de la ligne. Demandez un enregistrement ancien sans objet stocké et l'API renvoie 409 avec le motif, la page affichant « aucun fichier joint » plutôt qu'un téléchargement cassé.

Capacité 06

Des délais légaux sur de vrais calendriers

Jours ouvrés contre les calendriers de jours fériés par juridiction, règles à date d'effet et un point de départ honnête.

Les délais de gestion sont calculés, pas estimés. Les règles portent une date d'effet et sont rapprochées par date de sinistre ; chacune porte sa juridiction, l'événement du dossier qui la déclenche, le nombre de jours, le caractère ouvré ou calendaire de ces jours, et la règle de report d'une échéance tombant un week-end ou un jour férié. Neuf calendriers totalisant plus de 1 200 jours fériés soutiennent l'arithmétique, le traitement des jours fériés reportés étant vérifié contre l'historique et non supposé.

La distinction entre jours ouvrés et calendaires est l'essentiel. Quinze jours ouvrés à partir d'un lundi font vingt et un jours calendaires : une règle dont le texte même dit « jours ouvrés » mais mesurée en jours calendaires soumet donc le dossier à une fenêtre plus courte d'une semaine que ce que la loi accorde. Les délais sont en outre liés à l'obligation que la règle décrit, et non déduits par correspondance avec son libellé — renommer une règle dans un écran d'administration ne doit pas changer silencieusement ce que mesure le rapport de conformité.

Lorsque le fait servant de point de départ légal n'est pas détenu, la plateforme le dit sur la ligne au lieu de substituer en silence. L'acceptation ou le refus court légalement à compter de la réception de la preuve du sinistre ; à défaut de cette donnée, la déclaration lui est substituée et chaque délai concerné est marqué comme substitué — ce qui fait du décompte de manquements une borne supérieure, et il est présenté comme telle.

Ce qu'elle fait

  • Rapprocher par date de sinistre les règles de délais à date d'effet, par juridiction et par événement du dossier.
  • Compter les jours ouvrés contre le calendrier de jours fériés de la juridiction, avec les règles de report pour les fériés adjacents au week-end.
  • Reporter une échéance tombant un jour non ouvré selon la règle de report propre à la règle.
  • Lier chaque règle à l'obligation qu'elle décrit plutôt que de la déduire de son libellé.
  • Marquer tout délai calculé sur un point de départ substitué, et présenter les décomptes obtenus comme des bornes supérieures.
  • Persister le statut calculé pour que la vue conformité et le dossier ne puissent pas diverger.
  • Consigner la référence légale d'une règle, ou la laisser vide plutôt que de stocker la description d'un corpus juridique comme s'il s'agissait d'une référence.

Met en œuvre

  • Délais de gestion du Modèle 900 de la NAIC
  • Délais de paiement rapide et pratiques déloyales des États
  • Arithmétique en jours ouvrés avec jours fériés reportés

À voir dans le produit

Ouvrez le Moniteur de conformité. Chaque délai affiche la règle, sa juridiction, s'il compte en jours ouvrés ou calendaires, le calendrier utilisé et — lorsque le point de départ légal n'est pas détenu — un marqueur explicite de substitution.

Capacité 07

Recours : subrogation, sauvetage et réassurance

Les récupérations comme positions suivies contre le sinistre, y compris les cessions au programme de réassurance.

Le recours est traité comme une partie du sinistre et non comme une tâche ultérieure. Les dossiers de subrogation et de sauvetage s'ouvrent contre le sinistre auquel ils se rattachent, portent leur propre statut et leurs événements, et reversent les récupérations au registre du sinistre : la charge brute et la charge nette se déduisent ainsi toutes deux du même enregistrement.

Le recours en réassurance s'exécute contre le véritable programme de traités, et non contre un tableur de crédits attendus. Les cessions sont calculées à partir de la structure du traité — quote-part, excédent de sinistre et stop-loss agrégé — et les récupérations progressent selon un graphe d'états qui refuse les transitions illégales : une récupération à l'état de brouillon ne peut pas être facturée sans avoir d'abord été notifiée et acceptée, et chaque transition laisse une trace.

Le moteur tient une identité stricte : sinistre brut égal cédé plus net, testée et non affirmée. Ce test existe parce que le moteur a un jour déclaré tout le portefeuille brut comme cédé et une charge nette conservée nulle — un stop-loss agrégé sans point d'attachement avait été ramené à un attachement à zéro. Un traité auquel manque la condition qui le rend calculable est désormais écarté et déclaré comme écarté, plutôt qu'attaché à une valeur par défaut.

Ce qu'elle fait

  • Ouvrir des dossiers de subrogation et de sauvetage contre le sinistre, avec leur propre statut, leurs événements et leurs récupérations.
  • Reverser les récupérations au registre du sinistre pour que la charge brute et la charge nette se déduisent d'un même enregistrement.
  • Calculer les cessions à partir des structures de quote-part, d'excédent de sinistre et de stop-loss agrégé.
  • Appliquer le graphe d'états du recours — brouillon, notifiée, acceptée, facturée, encaissée — et refuser les transitions qui sautent une étape.
  • Laisser une trace à chaque transition d'une récupération.
  • Écarter et déclarer un traité dont les conditions le rendent incalculable, au lieu de l'attacher à une valeur par défaut.

Met en œuvre

  • Quote-part, excédent de sinistre et stop-loss agrégé
  • Identité brut = cédé + net
  • Graphe d'états du recours avec piste d'audit

À voir dans le produit

Lancez l'étape d'application de la réassurance et vérifiez les totaux : le sinistre brut moins le cédé égale le net, au centime près. Ajoutez un stop-loss sans point d'attachement et il apparaît dans la liste des écartés au lieu d'absorber le portefeuille.

Capacité 08

Correspondance, recours et ce qui a réellement été envoyé

L'état d'acheminement vit sur l'enregistrement, de sorte qu'un courrier rédigé ne peut jamais se lire comme un courrier remis.

La correspondance est rédigée à partir de modèles et composée dans un objet stocké, et son état d'acheminement est consigné sur la ligne plutôt que déduit de son existence. La machine à états comprend un état « enregistré mais non transmis », et c'est celui qui compte : sans lui, un courrier composé localement et un courrier accepté par un prestataire devraient partager le mot « envoyé », et c'est exactement ainsi que le défaut remplacé ici avait été écrit.

Seule l'acceptation d'un prestataire peut faire passer un enregistrement à « envoyé », et une contrainte de base de données rend l'alternative inexprimable — un état transmis sans référence de prestataire est rejeté par le schéma, non par un chemin de code contournable. Les échecs consignent l'erreur réelle du prestataire, les relances incrémentent un compteur de tentatives, et c'est un rappel d'acheminement qui fait passer un enregistrement à « remis ».

Cela porte bien au-delà de la boîte d'envoi. Le moteur de conformité lit la correspondance pour décider si un accusé de réception légal a été donné, et il comptait auparavant toute ligne sortante — créditant des dossiers d'un accusé sur la foi d'un horodatage que le code avait lui-même écrit. L'accusé exige désormais une transmission effective, et les recours et saisines du médiateur s'exécutent sur le même enregistrement : le dossier montre ce qui a été communiqué au réclamant et quand il l'a contesté.

Ce qu'elle fait

  • Composer la correspondance depuis des modèles vers un objet stocké portant son empreinte de contenu.
  • Consigner l'état d'acheminement sur la ligne, dont un état explicite de non-transmission pour tout ce qu'aucun prestataire n'a accepté.
  • Rejeter au niveau de la base un état transmis sans référence de prestataire.
  • Consigner l'erreur réelle du prestataire en cas d'échec et incrémenter le compteur de tentatives à chaque relance.
  • Ne faire passer un enregistrement à « remis » que sur rappel d'acheminement, jamais sur une action locale.
  • Ne compter que la correspondance réellement transmise au titre d'un accusé de réception légal.
  • Traiter recours et saisines du médiateur sur le même enregistrement, avec la contestation du réclamant consignée.

Met en œuvre

  • Accusé de réception du Modèle 900 § 4(B) de la NAIC
  • États d'acheminement confirmés par le prestataire
  • Piste des recours et saisines du médiateur

À voir dans le produit

Envoyez un courrier sans prestataire configuré. Il est consigné comme non transmis avec son motif — et non comme envoyé — et la règle d'accusé refuse de le compter au titre du délai légal.

Conçu pour ceux qui portent le risque

Pensé pour vos équipes, aligné sur vos référentiels.

Les agents spécialisés de Cortex préparent le travail, citent leurs sources et inscrivent chaque action au registre de preuves : Smart Claims accélère les personnes qui en répondent, sans fragiliser votre position en audit.

À qui cela s'adresse

  • Directeurs des sinistres
  • Gestionnaires et experts sinistres
  • Enquêteurs fraude et SIU
  • Responsables des opérations sinistres
  • Actuaires provisionnement

Aligné sur

  • Pratiques déloyales en gestion de sinistres
  • Réglementation type NAIC sur les sinistres
  • HIPAA
  • Règles de paiement rapide des États
  • RGPD
CortexCopilote de raisonnement IA
Sourcé

Empreinte d'appareil partagée avec le réseau94
Garage lié à un dossier SIU antérieur87
Le profil de sinistres correspond au groupe clos81
SourcesRegistre des contratsGraphe des sinistresDossiers SIU
Confiance94%
Encore mieux ensemble

S'associe au reste de la plateforme

Smart Claims partage le même socle que tous les autres modules : combinez-les pour étendre la couverture sans accumuler de dette d'intégration.

Poste de Souscription

Tarifer, décider et référer depuis un poste de souscription gouverné.

Gestion des contrats

Gérez le portefeuille, lancez des produits et pilotez des programmes en délégation de souscription (MGA) sur un socle unique.

Client 360

Toute la relation sur un écran, conduite comprise.

Cortex AI

L'IA propose ; les personnes et les politiques décident.

Pour votre secteurDécouvrez comment Smart Claims fonctionne dans les secteurs régulés.
Assureurs vie, rentes et retraite

Vie et rentes

De la souscription accélérée au règlement automatisé des capitaux décès.

Découvrir Vie et rentesAssureurs particuliers et entreprises

Assurance IARD

Du devis au sinistre sur un socle unique, avec le ratio combiné en ligne de mire.

Découvrir Assurance IARDAssureurs santé, arrêt de travail et collectives

Santé et prévoyance collectives

Gestion des contrats collectifs, sinistres rapides et traitement équitable, à grande échelle.

Découvrir Santé et prévoyance collectives
Questions fréquentes

Questions fréquentes sur Smart Claims

Ce que les équipes d'évaluation veulent savoir avant une démo, expliqué simplement.

Un utilisateur identifié détenant l'habilitation pour cette décision. Le niveau d'autorité requis s'élève avec l'exposition du dossier, le contentieux, le rattachement catastrophique et l'indicateur SIU, et un utilisateur sans ce niveau est refusé — le refus nommant le facteur qui l'a élevé, au lieu qu'un avertissement soit journalisé pendant que l'écriture se poursuit.

La plateforme détecte l'influence au lieu de s'en remettre à la déclaration de l'appelant — omettre l'identifiant d'exécution n'y change rien, car les exécutions gouvernées citant le sinistre sont retrouvées de toute façon. Le refus ne peut être écrit sans revue humaine enregistrée, et le relecteur doit détenir la même habilitation qu'exigeait la décision ; une sortie de modèle déterminante élève la revue au niveau superviseur.

Parce qu'elle doit être égale au montant final de son dernier mouvement au registre, et cet invariant est vérifié par un test sur tout le portefeuille. Une fonction unique ajoute le mouvement et fait bouger le sinistre dans la même transaction ; rien d'autre ne peut fixer le montant. Tout sinistre divergeant de son registre est signalable par requête.

Non. Chaque paiement est confronté au plafond et à la sous-limite de l'édition de produit en vigueur à la date du sinistre, nets des règlements antérieurs, et un paiement qui les dépasserait est refusé avec le plafond, le payé à ce jour et le dépassement. Lors de sa mise en place, ce contrôle a trouvé deux sinistres déjà payés au-delà de leur plafond par sinistre.

À partir de règles à date d'effet rapprochées par date de sinistre, en comptant les jours ouvrés contre le calendrier de jours fériés de la juridiction et avec traitement des fériés reportés — car quinze jours ouvrés à partir d'un lundi font vingt et un jours calendaires. Lorsqu'un point de départ légal tel que la réception de la preuve du sinistre n'est pas consigné, la déclaration lui est substituée et le délai est marqué comme substitué plutôt que présenté comme mesuré.

Elle la rédige et la compose, et consigne ce qui lui est réellement arrivé. L'état d'acheminement vit sur l'enregistrement et comprend un état explicite de non-transmission ; seule l'acceptation d'un prestataire peut faire passer un enregistrement à « envoyé », imposée par une contrainte de base de données et non par un chemin de code. Une correspondance jamais transmise ne compte pas au titre d'un accusé de réception légal.

Les délais de gestion du Modèle 900 de la NAIC et les règles étatiques de paiement rapide et de pratiques déloyales sont calculés par juridiction ; les décisions défavorables sont consignées sous une forme alignée sur le bulletin type de la NAIC relatif à l'usage de l'IA par les assureurs. L'alignement n'est pas une certification — le bulletin est adopté État par État, et l'analyse d'adoption comme le programme écrit de systèmes d'IA restent à la charge de l'assureur.

Voyez Smart Claims sur vos données

Réservez une session de travail : nous projetterons vos sources, workflows et référentiels sur Smart Claims — et vous verrez Cortex raisonner dessus en direct.

Réserver une démoDécouvrir la plateformeDémo interactive
Smart Claims — Chaque décision du dossier a un auteur, une règle et une trace. | AegisNow Insurance