Manage Policy Administration

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.

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 a scheduled job in place in order to help with moving the policies to Maturity status. FTOS_PA_PolicyMaturity transitions the policies and master policies to the Maturity status, when their Current Date is greater than their End Date.

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

An insurance policy suspension is a temporary pause in the insurance coverage, usually requested by the customer or triggered by specific conditions. During the suspension, the policy remains in place but does not provide active coverage. The suspension can be done with the FTOS_PA_PolicySuspended scheduled job. This service transitions the policies with unpaid installments into the Suspended status, after their grace period has ended.

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.

Policy Statuses

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.

Policy Versioning Statuses

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.

Policy Mid Term Adjustments Workflow (Change Engine)

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:

Policy Status Transitions

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:

Policy Reinstatement Workflow

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.

Master Policies Versioning Statuses

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.

Master Policies Status Transitions

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.

Master Policy Payment Schedule Business Workflow

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.