Manage Policy Administration

With increasing digitization, the amount of data and the number of data points is growing faster and faster – and their intelligent and fast use can be a pressure for insurers. When you use Policy Administration for collecting, storing and processing policy data, you also save time for: acquiring new customer segments, tapping into other customer needs, or creating new products and services.

The Policy Administration module keeps a traceability during the lifetime of an insurance contract and its adjustments through time. The module is comprised of the following functionalities:

  • The Policies repository - for storing and managing your digital insurance policies.

    • The Policy Mid Term Adjustments flow - for making various changes on the policy with different impacts such as changes in the existing coverage on the policy, changes in the type of payment, changes in the frequency of payment and more.

    • The Policy Cancellation flow - for managing cancellation processes; from registering and validating policy cancellation requests, to calculating the amount to be returned and approving payments.

    • The Policy Automatic Renewal flow - for generating renewal offer policies for those which are due to expire.

    • The Excess Management flow - for capturing and storing the excess for coverages, sub-coverages and risks.

    • The Policy Claim Data flow - for getting claims data from an external source in order to be used in the views for Policy Claims data and other processes.

    • The Insured Object flow - for saving relevant data for each object that has a policy issued.

  • The Master Policies flow - for creating bundled policy offerings, covering general insurance, healthcare and life protection.

When they satisfy some given conditions for changing their business status, policies can automatically be handled by the solution. Policy Administration has the capability to meet the following policy administration needs, without intervention from an operator:

The Policy issuance process represents the main Policy Administration functionality through which the insurance contracts are generated within the Core system, on the basis of which the other Policy Administration processes are based.

From a business perspective, this functionality involves an end-to-end process that starts from the generation of the initial policy through a specific endpoint, is updated through an update endpoint and then moves to InForce business status, according to the contractual Start Date.

Policy origination endpoint

The policy issuance endpoint brings business value to the Policy Administration component by creating a connection between various external systems and the core system. Thus, once the integration with another system in order to take over the information is achieved, the policy is generated in the system according to the information received with reference to the policy to be created.

Within this endpoint, a policy generation object is structured to contain all the information that must be taken over within an integration with an external system.

Following the made request, the response body populates the system with the new data specific to the policy, in addition to those obtained during the data collection from an external system.

When they satisfy some given conditions for lapsing, policies can automatically be moved from InForce to Lapsed status. Lapsing occurs when there is no payment, for an agreed period of time, of the latest installment on the contracted policy. The lapsing process of a policy represents an automatic process performed by means of configuration items specific to the lapsing process: the DAUDD insurance flow parameter and the FTOS_PA_Policy Lapsed scheduled job.

When they satisfy some given conditions for termination, policies can automatically be moved from InForce to Maturity status. The solution has an automated job in place in order to help with moving the policies to Maturity status.

When they satisfy some given conditions for renewal, policies can automatically be moved from Maturity to Renewed status. The solution has an automated job in place in order to help with moving the policies to ready for renewal procedures.

Workflow stages show the status of a record in the workflow and provide processing that must occur for the record to move to the next phase. The tasks, information or documents are passed from one status to another (from one participant to another for action) either manually or triggered by business rules or actions specified for that specific status.

The Policy Administration management system allows policy operators to achieve efficiency, gain flexibility and organize their insurance policy data for analysis and operational purposes in an easy way.

The Policy Administration module accommodates the following business states for a policy:

Status Name Type Description
Proposal Initial The first status for every policy generated into the system. Can be tailored to apply to policies waiting for their first installment to be paid.
Issued Initial For policies that passed their first Paid premium.
InForce Ongoing For policies passed their Begin Date that also meet all their contract terms - for ex. current date is not the End Date of the policy, payments made on time and so on.
Withdraw Final For policies closed before reaching the Issued status due to the following reasons: first premium not paid in a certain period following the proposal, conflicting parameter configurations between the insurance product and the policy or a system error - for ex. duplicated policy.
Cancelled Final For policies closed by the insurer when the Cancellation reason is chosen. This status is reached through the cancellation flow only.
Suspended Final For policies with unpaid installments when the grace period expires. This only applies for policies with unpaid installments, where at the product configuration level, the Suspension field is set as Yes.
WithdrawClientRequest Final For policies closed following the policy holder request. This status is reached through the cancellation flow only.
ClosedByClaim Final For policies which exhausted their coverage to claims made by the policy holder. This status is reached through the cancellation flow only.
DeclineScreening Final For policies being pursued by a high risk customer. This status is reached through the cancellation flow only.
Lapsed Final For policies on which premiums were not paid, after the Payment Grace Period expired when Product configuration for Suspension = No or after the Suspension period ends for policies where Product configuration for Suspension = Yes.
Maturity Final For policies passed their End Date.

There are cases, like policy renewal when you need to create a new version of a specific policy. To accommodate the versioning functionality, from an insurance business perspective, the Policy Admin solution uses a combination of the FintechOS standard versioning process mechanism and custom development. Consequently, you use the FTOS_VersioningHelper client side library and follow the standard procedure when configuring version settings, version settings items and entity settings. However, for policy versioning, you use the FTOS_VersioningHelper_Edit client side library in order to keep some attributes Read Only, even when the policy is in Version Draft business status, with isEditable option enabled.

The following are intermediary statuses that the policy goes through, during the MTA, cancellation and lapsing processes. These are not visible in the top left corner, you can see these in the History tab:

  • Version Draft: This is the first versioning status when it goes through the MTA/cancellation/lapsing processes. Modifications can be made in this status;

  • Version Unapproved: If the MTA/cancellation/lapsing process is Declined, then the version goes to the Version Unapproved status, and the policy remains in the same status;

  • Pending: When, for example, the MTA is approved, the version of the policy goes to the intermediary Pending status. If the effective date of the modification becomes equal to the system date, then the version transition to the Approved status;

  • Approved: When the version reaches this status, immediately after, the policy goes to the corresponding final status (can be for example InForce or Canceled);

  • Version Closed: The previous version of a policy transitions to Version Closed once it is replaced by a new approved version. You can see the previous and new versions of the policy in the History tab.

The business statuses for a policy mid term adjustment (MTA) flow are the following:

  • Draft (initial): This status applies to those alterations that have been initiated but not Registered yet, or that were Registered and did not reach their effective date and the Edit control has been triggered;

  • Expired: This status applies to the alterations in Draft status where the policy has expired, and also to those in Pending Approval that are not approved until the expiration of the contract;

  • Registered: This status applies to all alterations that have the Register button triggered, and no approval step is in place, or have approval step in place and the alteration has been approved. The Registered status allows the system to update and version the contract once the alteration reaches the effective date;

  • Pending Approval: This status applies to the alterations that have an approval step configured. This status follows Draft, it is triggered by the Register button and is active until the alteration is approved;

  • Cancelled: This status applies when you undo or cancel an alteration before it reaches the effective date;

  • Approved: This status applies after the alteration is approved;

  • Declined: This status applies after the alteration is declined.

The alterations workflow is given in the diagram below:

Here is a description of the policies status transitions managed through the Policy Administration solution:

Transition Description
_Proposal The first status for every policy generated into the system.
Proposal_Issued Automatic transition after policy generation in the system. Mention: This transition is properly used in a delivery project where the first paid installment triggers this status change.
Proposal_Withdraw Automatic transition before reaching the Issued status due to the following reasons: first premium not paid in a certain period following the proposal, conflicting parameter configurations between the insurance product and the policy or a system error - for ex. duplicated policy. This transition is triggered by FTOS_PA_PolicyWithdraw scheduled job using the PWDAY parameter value.
Issued_InForce Triggered when the FTOS_INSPA_Policy_IssuedToEnforced scheduled job moves the policies meeting the conditions for enforcement from Issued to InForce status.
Triggered by a specific PolicyStatusChance API request.
Issued_DeclineScreening Automatic transition triggered by choosing the Decline By Screening reason type, during the Cancellation flow.
Issued_WithdrawClientRequest Automatic transition triggered by choosing the Withdrawal reason type, during the Cancellation flow.
InForce_Withdraw Manual transition that can be made when the insurer decides that the policy needs to be cancelled and a Cancellation flow is not necessary - for example when policy duplication occurs due to operational mistakes.
InForce_WithdrawClientRequest Automatic transition triggered by choosing the Withdrawal reason type, during the Cancellation flow.
InForce_Cancelled Automatic transition triggered by choosing the Cancelled reason type, during the Cancellation flow.
InForce_Maturity Automatic transition for policies that reach their contractual Policy End Date. FTOS_PA_PolicyMaturity scheduled job verifies whether the condition Policy End Date is Current Date applies to the policy and triggers the status transition. After transitioning, the Service Insurance keeps the policy status updated.
InForce_Lapsed Automatic transition for policies on which premiums were not paid for a number of days, after the Payment Grace Period expired, when at configuration level the Suspension = No. FTOS_PA_PolicyLapsed scheduled job verifies each policy having this condition and triggers the status transition.
Suspended_Lapsed For products that have Product config level Suspension = Yes, the policy status transitions sequence becomes InForce → Suspended → Lapsed, taking into account Suspended duration.
Suspended_Maturity Automatic transition, triggered when the policy has unpaid installment and the duration of the grace period is higher than the period of time between the end policy and the unpaid installment's due date. (Unlikely scenario)
Suspended_InForce Automatic transition, after the policy is reinstated.
InForce_DeclineScreening Automatic transition triggered by choosing the Decline By Screening reason type, during the Cancellation flow.
InForce_ClosedByClaim Automatic transition triggered by choosing the Closed By Claim reason type, during the Cancellation flow.
InForce_Suspended This transition is triggered only for policies where at Product configuration level the Suspension = Yes. This is the default configuration.

Here is a diagram with the transitions managed through the Service Insurance module:

The policy reinstatement is the process of restoring an insurance policy back in effect, to the InForce status, after it has been previously terminated due to various reasons, most often scenario being that the insured has missed the premium payments.

When you have requested a reinstatement for a suspended policy, the process follows the statuses below:

Status name Type Description
Draft Initial The first status after choosing Insert or Choose Option from the form subsequent to searching and selecting the policy that is to be reinstated. The policy remains in Suspended status.
In Progress Ongoing Once the reinstatement is registered. The policy remains in Suspended status.
Cancelled Final Once you select to Cancel a reinstatement request. The policy remains in Suspended status.
Approval Ongoing Once you Propose the reinstatement request for approval. The policy remains in Suspended status.
Accepted Final Once you have approved the reinstatement request. The policy transitions to the InForce status.
Declined Final Once you have declined the reinstatement request.The policy remains in Suspended status.

Here is a diagram with the transitions for the polity reinstatement:

  • The first status of the master policy is Draft, after the user clicks the Insert button. A master policy is in Draft status only when no policies are linked to it.

  • The status moves from Draft into Proposal automatically when the associated policies are generated;

  • From Proposal, the status can move to:

    • Issued, through a call from the Quote&Bind module;

    • Version Closed, when you create a new master policy version;

    • Withdraw, automatically if the master policy status does not move from Proposal into Issued within a specific number of days.

  • From Issued, the status can move to:

    • Inforce, when the current date is the same as the start date of the master policy;

    • Version Closed;

  • From Inforce, the status can move to:

    • Cancelled, due to different aspects, such as a duplicated policy, or on a client request but after the cooling off period;

    • Lapsed, when the installments are not paid until the due date;

    • Maturity, when the current date is the same as the end date of the master policy;

    • Suspended; when at least one of the policies belonging to the master policy transitions to the Suspended status;

    • Version Closed;

    • WithdrawClientRequest, on a client request for personal reasons, within the cooling off period.

  • From Suspended, the status can move to:

    • InForce;

    • Lapsed

  • From Version Draft, the status can move to:

    • Version Pending;

    • Version Unapproved.

  • From Version Pending, the status can move to:

    • Version Approved.

Similarly to policies, master policies have intermediary statuses that it goes through, during the MTA, cancellation and lapsing processes. You can see these in the History tab:

  • Version Draft: This is the first versioning status when it goes through the MTA/cancellation/lapsing processes. Modifications can be made in this status;

  • Version Unapproved: If the MTA/cancellation/lapsing process is Declined, then the version goes to the Version Unapproved status, and the master policy remains in the same status;

  • Version Pending: When, for example, the MTA is approved, the version of the master policy goes to the intermediary Pending status. If the effective date of the modification becomes equal to the system date, then the version transition to the Approved status;

  • Version Approved: When the version reaches this status, immediately after, the master policy goes to the corresponding final status (can be for example InForce or Cancelled);

  • Version Closed: The previous version of a master policy transitions to Version Closed once it is replaced by a new approved version. You can see the previous and new versions of the master policy in the History tab.

Here is a description of the master policies status transitions managed through the Policy Administration solution:

Transition Description
_Draft The first status for every master policy generated into the system. A master policy is in Draft status only when no policies are linked to it.
Draft_Proposal Automatic transition after the first policy is added to the master policy.
Proposal_Issued Automatic transition, triggered by a MasterPolicyStatusChangeAPI request.
Issued_InForce Triggered when the FTOS_INS_MasterPolicy_IssuedToInforce scheduled job moves the policies meeting the conditions for enforcement from Issued to InForce status.
Triggered by a MasterPolicyStatusChange specific API request.
InForce_Cancelled Automatic transition triggered by choosing the Cancelled reason type, during the Cancellation flow.
InForce_Maturity Automatic transition for master policies that reach their contractual End Date. FTOS_INS_MasterPolicy_Maturity scheduled job verifies whether the condition Master Policy End Date is Current Date applies to the policy and triggers the status transition. After transitioning, the Policy Administration keeps the policy status updated.
InForce_Suspended This transition is triggered when at least one of the policies belonging to it transitions to the Suspended status.
InForce_WithdrawClientRequest Automatic transition triggered by choosing the Withdraw reason type, during the Cancellation flow.
Suspended_InForce This transition is triggered when the reinstatement request is approved.
Suspended_Lapsed This transition is triggered when one of the policies belonging to it transitions to the Lapsed status.

The trigger for the Master Policy installments status transitions are the installments statuses of the policies associated with said Master Policy.

There is a specific job, for Master Policies, which runs daily and checks the installments statuses of the policies that are included in a Master Policy and have the same due date.

Here is a description of the transitions for the master policy payment schedule.

Transition

Description

_on time

When generated, all the Master Policy installments are generated in this status for the entire period. They are available, but without an issued statement.

on time_statement issued

When the statement is generated, the statement is issued and all the installments are correlated on that statement, if all the installments of the associated policies have the Statement Issued status, then the Master Policy installment status is also Statement Issued.

statement issued_paid

If all the associated policies are paid before the due date, and they have the Paid status, then the Master Policy installment is also Paid.

statement issued_unpaid

If at least one associated policy is not paid before the due date and has the Unpaid status, then the Master Policy installment status is also Unpaid.

paid_statement issued

When a payment for at least an associated policy is deallocated, the statement of that policy is not covered anymore, so it becomes generated instead of closed or paid. The result being the Statement Issued status for the Master Policy installment also.

paid_unpaid

When a payment for at least an associated policy is deallocated, so the installment status for that policy becomes Unpaid, the installment status for the Master Policy also becomes Unpaid.