logo
Documentation Seyna
/
Gestion des polices

Concepts de la gestion de police

Pour l’ensemble des courtiers, la plateforme Seyna permet de bénéficier :
  • d’une solution de souscription
  • d’un back office de gestion de police
  • d’une solution de conformité LCB-FT
Pour le client Seyna Insurance, la plateforme Seyna permet de bénéficier :
  • du dépôt de bordereaux digitalisé
  • du suivi de l’amélioration des performances
Dans cette section, nous vous présentons tous les concepts clés utilisés dans notre plateforme, en mettant l'accent sur la solution de souscription et la solution de gestion de police. Ces deux solutions de Seyna étant intimement liées dans leur fonctionnement, nous avons fait le choix de toujours vous les présenter ensemble. Grâce à cette présentation détaillée, vous comprendrez mieux les différentes fonctionnalités de notre plateforme et vous pourrez ainsi tirer le meilleur parti de nos services.

Les concepts utilisés

La solution de souscription s'appuie sur les notions suivantes :
  • Un parcours (Journey et une Execution) qui permet la souscription
  • Un produit d’assurance (Insurance Product) regroupant :
    • Une version de produit (Version Id)
    • Des paramétres d’automatisation
    • Des schemas de donnée (Dataschema)
    • Un tarificateur (Pricer)
    • Une documentation et des templates de document
    • Des configurations d’échéance (Period configuration)
    • Des garanties
    • des configurations de paiement (Stripe)
  • Une demande de devis (Quote Request)
  • une liste des personnes (person)
    • Personne physique
    • Personne morale
  • Des devis (Quote) avec des prix par garanties (Price item)
  • Des échéanciers (Period)
  • Une comptabilité (Ledger) et moyen de paiement (Payment Method)
  • Des polices (Policy)
  • Des actes de gestion d’une police (Policy act)
    • Souscription initial
    • Renonciation
    • Résiliation
    • Avenant
    • Renouvellement (à venir)
Image without caption

Les parcours de souscription

Le parcours est personnalisable depuis l'espace Paramètres. Il permet d'orchestrer les différentes étapes telles que :
  • récupérer les besoins du client
  • présenter un devis
  • signature de la documentation pré-contractuelle
  • récupérer le moyen de paiement
Le parcours de souscription est construit par notre équipe de services de solution. Il est partiellement développé et peut être configuré dans l'application.
L’exécution d’un parcours (Execution) correspond à l’exécution du parcours par un client (une souscription en cours)
Image without caption

Version de parcours de souscription

Afin de pouvoir faire les évolutions de parcours de souscirption sans impacts le parcours en production, des versions de parcours sont disponibles. Le parcours en production est donc le parcours dit “Publié”. Les autres parcours sont en brouillon.
à noter que chaque parcours sont testé et seul les parcours qui se déroule bien peuvent etre publié.

Un produit d’assurance (Insurance Product)

Un produit d’assurance dans la plateforme correspond au produit d’assurance avec l’ensemble des contrats. Il permet de centraliser l’ensemble des paramètres necessaires à la souscription et à la gestion des devis et des polices.
Un produit d’assurance possède :
  • un nom
  • une version
Image without caption

Version d’un produit d’assurance (Version)

Sur une version de produit d’assurance, nous retrouverons tous les paramètres suivant :
  • Id de version
  • Type de début d’échéance
  • Le temps de validité d’une quote
  • Les automatisations possibles permettant de déterminer les actions manuelles à faire par l’agent ou le système :
    • automaticPayment
    • automaticPolicyApprove
    • automaticPolicyFinalize
    • automaticQuoteApprove
    • automaticQuoteCreate
    • automaticQuoteFinalize
    • automaticQuotePriceUpdate
    • automaticQuoteValidate
    • automaticRenewal
  • La présence d’un tarificateur (Pricer)
  • les paramètres de retractation
    • Le délai
    • Les justifications
  • Les noms de domaine associés pour l’envoi d’email automatique

Le tarificateur (Pricer)

Coming soon

Les schémas de donnée (Dataschema)

Les schémas de données permettent de référencer l'ensemble des données d'une police. Afin de rester flexibles, données sont réparties en 4 catégories :
  • QuoteRequestDataSchema
  • QuoteDataSchema
  • PolicyDataSchema
  • PriceDataSchema

Les documents (Document)

Il existe deux types de documents liés à un produit :
  • Documents
  • Modèles de document
Les documents sont des documents statiques, tandis que les modèles de document sont personnalisés avec les données du client.
Il existe différents types de document :
  • FIC
  • NI
  • IPID
En ce qui concerne les modèles de document, ils peuvent être personnalisés à différents moments :
  • À la création du devis (DRAFT)
  • Pour la signature (CREATED)
  • À la validation de la police (APPROVED)

Les emails (Email template)

Les emails peuvent être personnalisés par produit. Il est donc possible d'associer un modèle d'e-mail à une étape du parcours :
  • Demande de prix
  • Demande de devis
  • Certification (validation de la police)
  • Renonciation

Les garanties (guarantee)

Les garanties d’un produit d’assurance sont un engagement à fournir une couverture ou indemnisation dans les conditions prévues en cas de survenance d’un événement déclencheur de la garantie.
Les garanties possede :
  • un id
  • un nom
  • des informations comptables (Lob, Cat min, tax)

Les configurations de paiement

Pour les paiements, la plateforme Seyna fonctionne avec Stripe en utilisant le service Stripe connect.
ℹ️
Stripe connect est un moyen simple et rapide d'intégrer les paiements à notre plateforme. Vous gardez la main sur votre compte Stripe et vous gardez la main sur le KYB de Stripe afin de réaliser votre onboarding.
Il est possible de configurer les éléments suivants :
  • Cancel URL
  • Success URL
  • ID compte stripe
  • Secret key stripe
  • Publishable key stripe
  • Currency (ex: EUR)
  • Country (ex: FR)
  • InsurerId
  • insurerName
  • Moyens de paiement autorisés
La plateforme Seyna permet d’accepter les règlements par :
  • CB
  • Prélèvement IBAN

Demande de devis (Quote Request)

Quote Request est le terme employé pour désigner une demande de devis. Tout parcours de souscription commence par une Quote Request rassemblant l’ensemble des éléments pour définir un devis (une “Quote”). C’est le recueil du besoin du client. La demande de devis contient :
  • l’id
  • La date de création
  • La date de mise à jour
  • le portefeuille
  • La Policy Sequence (Numéro de suivi des polices)
  • Un Ledger (Suivi comptable)
  • Une configuration de period (échéancier)
  • Le produit d’assurance
  • La liste des personnes associées avec leurs rôles
  • Une date de début
  • Une date de fin
  • Les données (custom properties)
ℹ️
Les custom properties sont les données recueillies lors du parcours et les données utilisées pour la réalisation du devis. Elles peuvent être utilisées par le tarificateur.

Personnes (person)

Les personnes sont les personnes physiques ou morales qui ont un rôle sur le contrat.
Pour les personnes physiques, il est possible de récupérer les données suivantes :
  • Nom
  • Prénom
  • Date de naissance
  • Email
  • Téléphone
  • Adresse postale
Pour les personnes morales, les données sont :
  • Raison social
  • Nom du représentant
  • Prénom du représentant
  • Identification de la personne morale
  • Email
  • Téléphone
  • Adresse postale Les personnes peuvent avoir un ou plusieurs rôles. Les rôles possibles sont :
  • Contact : la personne à contacter sur ce devis et la police
  • Le bénéficiaire (benefiary)
  • L’assuré (insured)
  • Les membres (member)
  • Le souscripteur (subscriber)

Devis (Quote) avec des prix par garanties (Price item)

Le devis porte la proposition tarifaire vis à vis de la demande de devis.
ℹ️
À une demande de devis, nous pouvons associer plusieurs devis. Cependant, dans le parcours, seul un devis est présenté. Le multi-devis est une fonctionnalité à venir dans la plateforme Seyna.
Le devis contient les mêmes éléments que la demande de devis:
  • l’id
  • La date de création
  • La date de mise à jour
  • le portefeuille
  • La Policy Sequence (Numéro de suivi des polices)
  • Un Ledger (Suivi comptable)
  • Une configuration de period (échéancier)
  • Le produit d’assurance
  • La liste des personnes associées avec leurs rôles
  • Une date de début
  • Une date de fin
  • Les données (custom properties)
mais également :
  • L’id de demande de devis
  • le prix (PriceItem) qui est reparti par garantie
  • Le statut (détails ci dessous)
  • La date d’approbation de la quote
  • La date d’expiration

Les prix d’un devis

Les prix d’un devis sont une liste de prix par garanties. Les prix sont calculés par le tarificateur. Celui-ci renvoie en fonction des données la liste de prix correspondant. Le prix comprend alors :
  • Une garantie
  • Une commission
  • Une taxe (tax)
  • Un taux de taxe (tax rate)
  • La prime
Pour les prix, vous pouvez donc répartir le prix suivant les garanties :
  • Prix 1 : Garantie Vol - 5€
  • Prix 2 : Garantie Casse - 10€

Les stades d’une demande de devis (une opportunité)

Les stades des opportunités en fonction de l’avancement des éléments remplies en back office ou du parcours de souscriptions.
  • Brouillon J’ai eu un contact mais je ne connais pas encore le besoin
  • Opportunité Acceptée J’ai le besoin, je n’ai pas encore envoyé les devis
  • Devis présenté Un email avec le devis est parti et mais le client n’a pas encore accepté le devis
  • Devis approuvé Le prospect accepte, mais n’est pas encore arrivé à la signature
  • Devis signé le prospect a signé, mais n’a pas payé
  • Police crée le prospect devient client, il a payé, fin de l’opport
  • En echec
Image without caption

Les status d’un devis

Les statuts d’un devis sont :
  • Créé - CREATED
  • Prix mis à jour - PRICE_UPDATED
  • Finalisé - FINALIZED
  • Documents génerés - DOCUMENTS_GENERATED
  • Validé - VALIDATED
  • Documentation envoyée - EMAIL_PROSPECT_SENT
  • Approuvé - APPROVED
Les statuts de rejet, d’erreur ou d’expiration :
  • REJECTED_BY_PROSPECT
  • ABANDONED_BY_PROSPECT
  • REJECTED_BY_BROKER
  • ERROR_APPROVED
  • ERROR_DOCUMENT_GENERATED
  • ERROR_EMAIL_PROSPECT_SENT
  • ERROR_REJECTED
  • ERROR_PRICE_UPDATED
  • ERROR_FINALIZED
  • EXPIRED

Echéanciers (Period)

L’échéancier est construit dés la création de la quote.
Une échéance contient les informations suivantes :
  • un id
  • un prix par garantie
    • Garanties
    • commission
    • tax
    • tax rate
    • prime
    • montant
  • Date de création
  • Montant
  • Commission
  • Prime
  • Date d’échéance (Déclenchement du paiement)
  • Date de début
  • Date de fin
  • Référence
L’échéancier peut être modifié à plusieurs moments :
  • à la mise à jour du prix d’un devis
  • par modification manuelle dans le devis (à venir)
  • par modification dans la police pour des facilités de paiements
La période possède également :
  • Statut
    • Planifiée : toute période future qui sera émise.
    • Émise : toutes les périodes dont le montant a été émis dans le compte du grand livre.
    • Annulée : toutes les périodes qui n'ont pas été appelées et qui sont annulées pour éviter d'être émises. (Exemple : dans une résiliation, toutes les périodes futures de l'ancienne police.act, sont passées à "annulées" (au lieu de simplement changer leur valeur à 0€)).
  • Référence à d'autres périodes
    • Toutes les polices annulées auront une référence à la période initiale.
Une période Planifiée peut passer à Émise (à la date d'échéance) ou peut être Ouvrée.
Une "période" "émise" ne peut pas être modifiée.
Un statut Annulée ne peut pas être modifié. Le statut d'annulation est là pour annuler toutes les périodes futures, de sorte que la période initiale n'a pas été émise.

Balance comptable (Ledger)

Lorsqu'une demande de devis est initiée, une balance comptable est créée. Cette balance permet de suivre la comptabilité de la police. Elle enregistre toutes les transactions financières et permet de garantir la transparence des opérations.
La balance porte les informations suivantes :
  • Un id
  • Un solde
  • Une date de création
  • Une date de mise à jour
Ceci permet de renseigner les moyens de paiement associés.
Ensuite, dans les balances, nous avons des entrées ou transactions. Les transactions contiennent les informations suivantes :
  • Un id
  • Un type
  • Une date de création
  • Un label (description)
  • Une date d’opération (OrderedAt)
  • Un statut
  • Un Type
    • Débit
    • Crédit
  • Une date de mise à jour

Les types de transactions (business type)

Les types de transactions sont les suivants :
  • Annulation de paiement (PAYMENT_CANCELLATION)
  • Échéance échue (PERIOD_CHARGE)
  • Paiement de l'assuré (POLICY_HOLDER_PAYMENT)
  • Remboursement à un assuré (POLICY_HOLDER_REFUND)
  • Fin d'une police (POLICY_SUSPENSION)

Les moyens de paiements (PaiementMethod)

Les moyens de paiement sont ceux renseignés par les clients via nos PSP. Actuellement, nous ne prenons en charge que Stripe. Les informations bancaires ne sont pas accessibles via nos API ; elles sont sécurisées directement au sein de Stripe.

Polices (Policy)

La police porte le contrat d’assurance vis à vis d’un devis et donc la signature et le paiement de celle ci.
ℹ️
À un devis, nous pouvons associer qu’une seule police.
Une police possede :
  • des actes de gestions
  • des échéances (Period)
  • Une comptabilité avec des entrées comptables
  • une timeline
Un "acte de gestion" est un acte qui a un impact sur une police d'assurance, qu'il s'agisse des données de la police, de sa durée, de ses échéances ou de son solde.
Un acte de gestion peut être
  • la souscription initiale
  • la renonciation
  • la résiliation
  • l'avenant
  • le renouvellement
  • Suspension
Exemple :
Une police a été souscrite le 15/12/2022 (date d'agrément) pour une durée de 1 an, composée de 12 périodes, commençant le 01/01/2023.
Le premier acte de police est la souscription initiale, qui commence le 01/01/2023 et se termine le 31/12/2023.
  • Il y a 12 périodes, chacune coûtant 10 €.
Un avenant a été signé le 05/08/2023 et prendra effet le 15/08/2023.
  • L'amendement fait passer le prix de 10 € à 15 € par mois, avec une date d'expiration en avril 2024.
Le deuxième "acte de gestion" est un "amendement" avec 14 périodes. 5 périodes sont destinées à annuler les 5 périodes initiales du 15/08/2023 au 31/12/2023, et 9 périodes sont destinées à initier le nouveau prix du 15/08/2023 au 31/04/2024.
  • Ensuite, une résiliation a été signée le 01/02/2024.
Le troisième "acte de politique" est une "résiliation" avec 3 périodes pour annuler les 3 dernières périodes de l'amendement.

Acte de gestion d’une police (Policy Act)

Un acte de gestion contient les mêmes éléments que le devis:
  • l’id
  • La date de création
  • La date de mise à jour
  • le portefeuille
  • La Policy Sequence (Numéro de suivi des polices)
  • Un Ledger (Suivi comptable)
  • Une configuration de period (échéancier)
  • Le produit d’assurance
  • La liste des personnes associées avec leurs rôles
  • Une date de début
  • Une date de fin
  • Les données (custom properties)
  • L’id de demande de devis
  • le prix (PriceItem) qui est reparti par garantie
  • Le statut (détails ci dessous)
Avec en plus :
  • une date de souscription

Les statuts d'une Police et d’un acte de gestion

Il existe 4 statuts pour une police et pour les actes de gestion.
Le statut de la police a un nouveau statu calculé appelé Couverture (Cover_status).
  • Le Policy n'a pas d'actes de gestion "actifs", ce qui signifie que la police n'a pas encore été confirmée par le titulaire de la police. Dans ce cas, le Cover_status est Non confirmé
  • La Police sera effective dans le futur A venir
  • La Police est effective à la date / heure actuelle En cours
  • La Policy end date is in the past Terminée (date de fin de la police)
Une police a également un status calculé complémentaire sur la fin de contrat (Termination_statut) concernant la présence d’une résiliation ou d’une renonciation :
  • La Police a été résilié à la date / heure actuelle Résiliée
  • La Politique a été renoncé à la date / heure actuelle Renoncée
  • La Policy sera annulée dans le futur Résiliation à venir
Un acte de gestion a un statut sur sa souscription Subscription_status :
  • L'Acte a un statut détaillé ci dessous
Un acte de gestion a une dernier calculé sur sa couverture (Cover_status)
  • L'Acte dont la sosucrition n’est pas fini est Non confirmé
  • L'Acte sera effectif dans le futur A venir
  • L'Acte est effectif à la date / heure actuelle En cours
  • La date de fin de l'Acte est dans le passé Terminée
Les Subscription_status d'un acte de gestion sont les suivants :
  • Créé - CREATED
  • Bulletin d'adhésion généré - SUBSCRIPTION_FORM_GENERATED
  • En attente de signature - SIGN_SUBMITTED
  • Signé - SIGNED
  • En attente de paiement - PAYMENT_METHODS_PENDING
  • Certificat envoyé - SENT_EMAIL
  • Approuvé - APPROVED
Dans certains cas, vous pouvez avoir les statuts suivants :
  • PAYMENT_METHODS_NOT_REQUIRED
  • ESIGN_NOT_REQUIRED
  • REJECTED
Et éventuellement, vous pouvez rencontrer des statuts d'erreurs :
  • ERROR_SENT_EMAIL
  • ERROR_PAYMENT_METHODS_GENERATED
  • ERROR_CERTIFICATE_GENERATED

Précisions sur les dates des demandes de devis, devis et police

▶️
Voir le detail :
Les Dates de demande de devis, devis et police

AML

Concernant les concepts utilisés sur la solution de conformité LCB-FT, nous avons dédié une page spécifique :
Gestion des polices
La validation d’une police
Powered by Notaku
Share