Policy Administration 24.4.1

October 22nd, 2025

This release introduces backdated cancellations policies and master policies, future-dated alterations and payment recalculation, non-chronological alterations, a new capability that provides greater flexibility when managing mid-term adjustments (MTAs). This new version also comes with API improvements.

What's New

Policy and Master Policy Backdated Cancellation

The policy and master policy cancellation flows now support backdating cancellation requests. Backdated cancellations ensure accurate coverage dates, correct billing, and smoother customer experience. For this to be possible, new calculations accommodate refunds for clients for uncovered periods and compensation amounts to cover costs for insurers. In addition, the business workflow for policy cancellation was modified to support the changes.

It's important to note that a backdated cancellation can’t be revoked, once approved. Only future dated cancellations can be revoked, before the cancellation takes effect on the policy.

If during the policy or master policy cancellation flows, the returned premium is higher than 0, then a premium reimbursement request is created. You can add payment details during the cancellation flow or by using the Premium Reimbursements form. Payment methods available are Bank transfer, direct debit UK or SEPA, or Recurring Card Payment.

For allowing changing the end date upon policy cancellation, when configuring the policy in the Product Admin Configuration form, in the Policy Rules section, make sure to tick the Cancellation Change End Date box and provide the data sources for cancellation reasons. Starting with this version, you can add custom actions when registering or approving a cancellation, and customize the cancellation reason type selection during the cancellation flow.

Non-chronological Alterations

We’re introducing non-chronological alterations, a new capability that provides greater flexibility when managing mid-term adjustments (MTAs). With this enhancement, changes can be applied directly to the active policy based on operational needs, without requiring a strict time sequence.

  • Immediate effect: Alterations take effect as soon as they are applied and cannot be cancelled. However, they can be overridden by creating a new MTA.

  • Revoke Cancellation: If a cancellation has been scheduled for a future date, you can now use the Revoke Cancellation MTA, available for both standard and master policies, to nullify the scheduled cancellation and return the policy to its previous In Force status.

  • Effective dating: Alterations can be set with any effective date within the policy’s validity period. For “same policy” renewals, the MTA date must be on or after the original policy start date.

  • Payment schedules: Recalculations will only apply to installments due on or after the alteration’s effective date.

This update gives clients more control, flexibility, and efficiency when managing policy changes across the policy lifecycle.

Future-Dated Alterations and Payment Recalculation

When a future-dated policy alteration is created and an installment is invoiced before its effective date, the original payment schedule is invalidated and automatically recalculated.

If coverage is increased effective August 1 but the August installment is invoiced on July 20, the August–December installments are recalculated to reflect the new premium.

Extending MTA and Renewal for Multiple Formulas

Previously, the MTA (mid-term adjustment) and Renewal processes only supported a single pricing or underwriting formula per product. When a product has one configured formula, the system resolves data mapping and sends its results directly to the offer/pricing or offer/underwriting flow. With this release, enabling multiple formulas per product significantly boosts pricing flexibility and operational efficiency, leading to faster product launches, more accurate risk assessment, and ultimately increased revenue and customer satisfaction.

Formula Mapping for Alteration and Renewal

For Mid Term Adjustments and Renewal that need to use pricing and underwriting, when using the resolve mapping for input to call the Product Factory, it will also reuse the same resolve mapping for the result to save those values on the configured fields. This helps ensure that the same data structure is used throughout the process, reducing the risk of mismatches or misinterpretations between input and output.

Approval Logic on Alteration

You can now configure an approval step for specific alteration types within the Mid-Term Adjustment (MTA) process. When a request includes at least one alteration that requires approval, it will enter the new Pending Approval status. Only users assigned the appropriate security role, defined per alteration type, can approve, decline, or edit the request. If all alterations are set to bypass approval, the request will move directly from Draft to Registered upon submission. Additionally, if the user submitting the request also holds the necessary approval rights, the approval step is automatically skipped, streamlining the workflow. This enhancement provides greater flexibility and control over policy changes, ensuring that approvals are enforced only where needed.

Lapse and Suspension Improvement

A new field has been added to payment statements to show the exact date when a policy will officially end if payment isn’t made. This date is automatically calculated when the statement is created, based on the due date, any grace period allowed by the payment type, and any suspension time. Also, if a policy is marked as suspended but has a suspension duration of zero, it will now immediately move to lapsed status, meaning the customer loses coverage right away, with no extra time or chance to reinstate. This update helps make payment deadlines and policy status clearer and more consistent.

Coverage Management Enhancements

We are introducing major improvements to coverage management, focusing on validity handling and premium accuracy during mid-term adjustments (MTAs):

  • The coverage validity period and the amount included in the total premium could previously only be found by looking through versions and history. Now, they are displayed directly on each version, so you no longer have to do the calculations yourself. Premium amounts are prorated daily or monthly, ensuring the total policy premium always equals the sum of individual coverage premiums. Earned premiums from previously active coverages are properly reconciled, delivering financial accuracy and auditability.

  • When a coverage or sub-coverage is removed, its end date is automatically set to one day before the MTA effective date. These coverages remain eligible, creating flexibility without losing history. Newly added coverages start on the MTA effective date (or later if a waiting period applies). We've also introduced new insurance parameters, daily and monthly prorata formulas, which are now used to calculate premiums during MTAs.

  • The coverages grid now shows only coverages valid as of the MTA effective date, while the additional coverages grid highlights optional coverages not currently on the policy. This provides a clearer view of what is active versus available.

  • Renewed policies now include only the coverages valid at renewal, each ending precisely on the policy’s end date.

Update to Master Policy Alteration Handling

When you're managing a policy or master policy and initiate an alteration (MTA), it's important to be aware of how changes to the master can affect that draft. Previously, if you added a new policy or cancelled an existing one while an alteration was still in draft status, the system would generate a new version of the master policy. This version mismatch caused unexpected errors when you tried to register the alteration, preventing you from finalizing it.

To resolve this issue, the system now automatically transitions any draft alteration to an inactive state if a new policy is added or an existing policy is cancelled under the master policy. The alteration will be marked with the message: "Inactivated by the system due to changes on master policy." This ensures version alignment and prevents errors during alteration registration.

This update provides a more reliable workflow and clearer guidance for managing alterations in dynamic master policy environments.

Improvements

  • The Alterations Summary section, displayed after updating the due date of master policies, now shows a list of all installments along with their old and new due dates.

  • Refactored views for Policy and Master Policy Payment Types, Insured Objects, and Policy Parties to display their valid from/to dates.

  • Improved reliability and performance by updating the FTOS_PH_ProcessAsyncEvents scheduled job to get all unprocessed events and send them to async. This job now runs every second.

API Improvements

  • FTOS_PYMT_InsertStatementDueDate job is no longer available. At upgrade, you should adopt the new API FTOS_PYMT_GenerateStatementAPI.

  • FTOS_CB_StartLoanSubmissionFlow_AsyncEngine, API for digital process of submitting a loan application into the loan management system, received an update that includes the isSuccess: true or false response, with the message: "Your Request has been received" if true, and an error message if false. In addition, the input nextStage is now optional. If someone doesn't provide it, the system will automatically use createCustomer as the default.

  • The FTOS_INSP_UndoCancellation API, which post is used to Undo(move to status Cancelled) a Cancellation request via API, is now renamed to FTOS_INSP_RevokeCancellation.

  • The FTOS_INSP_RequestCancellation API accomodates the new changes to the cancellation functionality for both policies and master policies. The former FTOS_INSP_RegisterCancellation will be deprecated.

  • The new FTOS_PYMT_GenerateOutgoingPaymentRequest API is used to insert a new outgoing payment request on the new data model.

  • The new FTOS_INSP_ValidateCancellation API is used for approving a cancellation. It supports an optional paymentDetails object with keys: paymentBeneficiaryType, bankCode, and paymentIBAN, inheriting standard interface behavior.

Mandatory Changes

policyStatusChangeAPI, used to change the status of the policy and update, if needed, some details about the policy, received an update, the policyValidityType, policyValidity, and policyBeginDate keys are removed, along with the logic that recalculates policyEndDate. The pricing remains based on the validity, and these changes do not impact the premium amount.