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.

Surrendered

Final

For policies closed by the insurer for reasons other than those exposed in the cancellation reasons. 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.

The business statuses for a change policy request are described below:

  • Draft: This is the initial status when inserting a new change policy request. In this status, all fields are editable, with a few exceptions.

  • Registered: This is the intermediary status for an MTA request when the user clicks the Register button. In this status, all the fields become read-only. In this situation, from a business perspective, is the decision of the MTA user if continues with the MTA request or not.

  • Cancelled: This is the final status if the user clicks the Cancel button in the interface. In this status, all the fields become read-only. In this situation, from a business perspective, is the decision of the MTA user if they continue with the MTA request or not.

  • Accepted: This is the final status if the user clicks the Accepted button. In this status, all the fields become read-only. In this situation, from a business perspective, is the decision of the MTA user if they continue with the MTA request or not.

  • Declined: This is the final status if the user clicks the Declined button. In this status, all the fields become read-only. In this situation, from a business perspective, is the decision of the MTA user if they continue with the MTA request or not.

Here is a description of the transitions managed through the Policy Administration module:

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_INSPA_Policy_AutomaticallyWithdraw scheduled job using the PWDAY parameter value.

Issued_InForce This transition can be triggered in 2 different ways:

Automatically - when the policy includes an insurance Product on which Automatic InForce is set to True, at product level, the FTOS_INSPA_Policy_IssuedToEnforced scheduled job moves the policies meeting the conditions for enforcement from Issued to InForce status.

Manually - triggered by a specific request - for example Policy related endpoints, on policies that include Products with Automatic InForce set to False, at Product level.
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_Surrender Automatic transition triggered by choosing the Surrender reason type, during the Cancellation flow.
InForce_Maturity Automatic transition for policies that reach their contractual Policy End Date. FTOS_PA_PolicyTerminationProcess 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.
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 Policy Administration 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.
Canceled 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.

  • 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.

    • 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.

  • 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.

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

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.