Configure Alteration Types

Chronological alterations allow changes in the exact order they occur over time. When a mid-term adjustment (MTA) is made, the system generates a cloned version of the policy, which stays in a Pending state until its effective date, at which point it transitions to In Force. These adjustments must be processed in chronological sequence. If a future adjustment has been scheduled but hasn't yet taken effect, it can still be cancelled. For instance, if there's an MTA scheduled to take effect on October 1st, but a change is required today, the process involves first cancelling the October 1st MTA, implementing the 2nd modification registered, and then reapplying the original MTA with its October effective date. 

Non-chronological alterations allow changes to be applied based on operational necessity rather than strict time order. Mid-term adjustments (MTAs) under this structure are made directly on the active policy and take effect immediately. These adjustments cannot be reversed or cancelled once applied. However, a subsequent MTA can be used to counteract or override the previous change. If a cancellation is scheduled for a future date and needs to be undone, the Revoke Cancellation MTA must be used. This action nullifies the effects of the original cancellation and restores the prior version of the policy to InForce status.

The Revoke Cancellation mid-term adjustment type takes effect immediately and can't be cancelled, any changes must be made through a new alteration.

Alterations can be set with any effective date, provided it falls within the policy’s validity period and the chronology setting. If the policy renews as same policy, the MTA date must be on or after the original start date. Payment schedule updates only affect installments due on or after the alteration’s effective date.

The Change Start Date alteration type is applicable for both policies and master policies, and can be used for modifying the start date of a policy, particularly in backdating scenarios. Backdated insurance policies refer to insurance contracts that are issued with an effective date earlier than the actual date the policy is written or signed. In other words, the coverage is retroactively applied to a date in the past.

If the policy start date is in the past (before today's date, systemDate), and the payment schedule is set to apply the first installment to the start date, the system will overwrite this setting. It will then adjust the first payment to be due on the system date (today), instead of the past start date, ensuring the payment schedule is aligned with the current date.

Changes are also triggered for the payment schedule, this is generated based on the configured payment schedule type and any installments with a due date earlier than today's date will be updated to a new due date that’s equal to or later than today. The new due date will be adjusted monthly for monthly, quarterly, or annual payment frequencies, and weekly for weekly payments. The number of installments is kept, the due date is updated.

Use the Update Coverages alteration type to perform an alteration with an effective date that is earlier than existing alterations on the same policy. This option is available only for policies. After initializing the alteration, if the effective date is earlier than the system date (i.e., backdated), the system generates the clone from the currently enforced policy. This process bypasses all previous alterations that are still in In Progress status.

The following conditions must be met before registering the alteration:

• No clones should exist in the system for the policy being changed;

• All alterations with an effective date later than the system date must be cancelled;

• A clone of the policy version is created, its status updated to Enforced, and the currently Enforced policy version is marked as Closed;

• No changes are made on versions closed between effective date and system date;

• The price is calculated based on the effective date, policy changes take effect from the system date. The payment schedule is regenerated for on time details affected by the change on the coverage start date;

• A backdated alteration can be added on any type of product, if the chronology rule is met.

For backdated alterations on an insured object use the existing Update Insured Object alteration type. When backdating, the effective date is before the system date or another alteration’s effective date, and on or after the policy start date. Clicking Register creates a cloned policy version with status Enforced, which cannot be cancelled; further changes require a new alteration. Adding a new alteration is blocked if one is in progress and must be cancelled or finalized first. Clicking Validate recalculates the premium with the policy validity, then prorates the result depending on the selected effective date.

The following conditions must be met before registering the alteration:

• No clones should exist in the system for the policy being changed;

• All alterations with an effective date later than the system date must be cancelled;

• A clone of the policy version is created, its status updated to Enforced, and the currently Enforced policy version is marked as Closed;

• No changes are made on versions closed between effective date and system date;

• The price is calculated on effective date, the changes on the policy are starting from the system date and the payment schedule is regenerated (only payment schedule details with the status OnTime are updated).

The Change Start Date alteration type is applicable for both policies and masterpolicies, and can be used for modifying the start date of a policy, in future dating scenarios. This means modifying the start date of a policy or masterpolicy to be greater than the system date. This is available for Proposal and Issued statuses, and not for InForce status.

For an independent policy, the end date is calculated as the new start date plus policy validity, with no amount updates, but updates are made to the policy’s coverage start date and payment schedule, regenerating if no invoice is issued or adjusting due dates for On Time payment statuses.

For a policy under a master policy, the new start date must be greater than or equal to the master policy’s start date, the end date remains unchanged (based on the master policy), the policy validity is recalculated, total premiums are adjusted based on new validity, and the coverage premium is updated, with final premiums reflecting any commercial discount; payment schedules are updated accordingly, and a new version of the master policy is created with the revised amounts and schedule.

For an alteration with effective date in the future, if an installment is invoiced between the clone generation and the effective date of that change, then the payment schedule attached to that clone is no longer valid and needs to be recalculated. The alterations that allow changing the effective date are: Update due date , Coverage, Insured Object, Mentions, Update Policy Party, Update Master Policy Party, Start Date , Payment Type, Payment Frequency, Renewal Type, Revoke Cancellation.

If you make a future-dated change to your policy, but an installment is already invoiced before the change becomes effective, then the payment plan must be recalculated to reflect the updated policy and premium.

A real life example of this would be if you have a home insurance policy with a $1,200 annual premium, paid in $100 monthly installments. On July 15, the customer asks to increase the coverage, starting August 1. You create a future version (clone) of your policy with higher premium, starting from that date. But on July 20, the August installment is invoiced—based on the old premium. The payment schedule in the cloned (future) policy is now outdated, because an installment was already issued before the change took effect. The payment schedule is recalculated to reflect the new premium from August onward.

This is done with the PolicyCloneBecomePolicyVersion, which calculates the premium due based on the current version of the policy, using the due date minus statement generation days (SGDays) to determine when to generate the bill.

Use the Update Coverage alteration type to update the content card on the policy. These cards represent the plans for insurance products and are generated when creating Offers. These may contain coverages with different insured sums, start or end date, effective dates, etc.

After picking a new card, the list of coverages is updated. The begin and end date are system driven. The begin date equals the sum of the alteration effective date and the waiting period. The end date equals the policy end date. You can only chose the effective date of the alteration.

When making changes, an update to the payment schedule is triggered. In case the policy is paid, a new payment schedule detail is generated with due date min(AlterationEffectiveDate+1, EndDate) and the amount resulted as difference. Otherwise, the on time installments are updated.

The system ensures that each policy coverage reflects its correct validity period (start and end dates) and associated premium amount. Policy coverages and sub-coverages are stored, with updates managed through MTAs. Historical values are only accessible in closed policy versions.

When a coverage or sub-coverage is removed, its end date is set to one day before the effective removal date. If re-added, a new record is created. Premiums for changes (additions, removals, or modifications) are prorated based on the coverage’s actual period of validity. This ensures that earned premium for the active period is included, even if the coverage is later removed, preventing discrepancies between total policy premium and the sum of individual coverage premiums.

Risks can be reported and linked to claims using the product Id tied to the policy’s product version.