Product Admin Configuration
After creating an insurance product in the Product Factory, go to the Product Admin Configuration form to set pricing rules, policy rules, claims, formula mapping, and payment types.
-
In Studio, click the main menu and navigate to Products > Settings > Product Admin Configuration. Click Add Product Configuration and select Insurance Product Admin.
-
Click Save and Reload. The Product Admin Configuration form opens.
-
In the Policy Rules tab, add the Insured Object Form. More details on the Insured Objects page.
-
In the Number of days in advance field, add the maximum number of days for when the coverage starts. This is for future dated policies.
-
Tick the box under the Overlapping Policies to allow a customer to hold multiple policies for the same product.
-
Choose whether policy generation runs asynchronously or synchronously by setting Async Policy Generation to:
- Yes: uses the
FTOS_INS_StartPolicyGenerationFlow_Asyncflow to initiate a full asynchronous policy generation process. This flow validates the request, reserves a policy number, stores the input, and orchestrates the downstream steps to create the policy data, coverages, parties, insured object, payment schedule, invoices, and optionally, update the master policy. It is recommended for high‑volume workloads, as it improves performance, ensures processing continuity, and prevents data loss in case of system interruptions. - No: The
PolicyGenerationAPIperforms the entire policy creation synchronously in a single call, returning the fully generated policy and all related details in the same response.
- Yes: uses the
-
Tick the Backdate policy start date to allow backdating the policy. This expands two additional fields:
-
Number of days: add the maximum number of days for backdating policies. This is calculated as the difference between the system date (the current date) and the policy start date.
-
Security Roles: select the security roles the user needs to have to be allowed to backdate policies.
-
-
Under the Pricing Rules category, tick the box under the MQ Individual Offer to allow only one quote under the Master Quote to be selected as a beneficiary. If left unchecked, all quotes under the MQ policy must be selected.
-
Tick the box under MQ Issuance for Passed Quotes so that quotes that pass the underwriting (UW) rules are generated even if not all rules are satisfied. If left unchecked, if any rule fails, no quotes will be generated.
-
Add the Formula Name For Pro-rata from dailyProrataFormula or monthlyProrataFormula, default Insurance Parameters. This is used for calculation when a mid term adjustment is made.
-
In the Premium Calculation Formula Mapping category, click Insert to add the Insurance Product Item Formula defined for your product.
Mapping Data for Different Scenarios
-
Map Quote Admin Data: Use this when mapping data for renewals with new offers.
-
Go to the Definition screen, select Master Entity, and add the project-developed entity extension.
-
On the Input screen, map the attributes required by the formula.
-
-
Map Policy Data: Required when configuring mid-term adjustments (MTAs).
-
Go to the Definition screen, select Master Entity, and add the project-developed entity extension.
-
On the Input screen, map the attributes needed for MTAs.
-
-
Map Quote & Bind Data: Use this for recalculating quotes in the origination journey.
-
On the Definition screen, select Master Entity and add the relevant entity extension.
-
On the Input screen, map the attributes as per the formula.
-
-
You can configure the due date of any additional installments that might be resulted from an alteration to a fully paid policy. In this use case, the policy is fully paid, which means that all of its attached installments are in status Paid or Statement Generated. The options presented below allow you to configure the flow, i.e. when the due date of additional installments is set, in the case of alterations being made.
-
Under the Payment Schedule Rules category, click the Additional Installment Due Date drop-down and pick one of the available options:
-
Applies to alteration effective date: the installment’s due date is the reference date, which is defined as the later of the alteration effective date or the current system date.
-
Applies to default collection day: the due date is set to the policy’s default collection day in the month and year of the reference date. If the due date is on or before the reference date, then it is moved one month later if that new date is before the policy end; otherwise, the due date is set to the reference date.
-
-
Under the Underwriting Formula Mapping category, click Insert to add the formula required for underwriting as defined in your project.
-
Click Save and reload.
Mapping Data for Underwriting Scenarios
- Map Quote Admin Data: Use this when mapping data for renewals with new offers.
-
Go to the Definition screen, select Master Entity, and add the project-developed entity extension.
-
On the Input screen, map the attributes required by the formula.
-
Map Policy Data: Required when configuring mid-term adjustments (MTAs).
-
Go to the Definition screen, select Master Entity, and add the project-developed entity extension.
-
On the Input screen, map the attributes needed for MTAs.
-
-
Map Quote & Bind Data: Use this for recalculating quotes in the origination journey.
-
On the Definition screen, select Master Entity and add the relevant entity extension.
-
On the Input screen, map the attributes as per the formula.
-
You need to define an audience segment in order to be able to map the attributes.
For Mid-Term Adjustments (MTAs) and Renewals that require pricing and underwriting, the resolve mapping used as input when calling the Product Factory will also be applied to the output. This ensures that the returned values are saved in the configured fields.
Shows the payment type the user selected when they created the insurance product. At product creation, the available options are bank transfer, broker collection, direct debit, card payment, recurring card payment.
Add a grace period for each payment type, if applicable, by clicking the Grace Period column, typing in the number of days and press Enter or click outside the field.
This section displays the configuration for generating invoices. Invoice generation in insurance is the process of creating a document that details the premium amount owed by the policyholder, along with policy information, payment terms, and due dates. It's used to request payment for the insurance coverage provided.
Configure the following settings:
-
Premium Invoice Generation: set the day when the invoice is to be generated. Pick from the following options:
-
Default: uses the value of the insurance parameter No. of Days in Advance (SGDAY). This parameter sets the day for generating the statement (invoice) in advance with a number of days before the payment's due date.
-
Specific SGDAY: when you select this, the No. of Days in Advance (SGDAY) field becomes available, allowing you to set a value for SGDAY only for this product. One that is different from the insurance parameter mentioned in the previous paragraph.
-
Specific Day: when you select this the following mandatory fields becomes available:
-
Specific day of the month: select the day when the invoice is generated. The day is set on the product, meaning it applies only for this specific product.
-
Installments Days in Advance: set the number of days for installments to be included in the invoice. For example, if you have invoices upcoming in the next 10 days, set the number to 10 so they will be included in this invoice.
-
-
-
Invoice Group By: pick one of the options, Policy, MasterPolicy, Product, Payer, to group invoices. Keep in mind that products with different grace periods or write-offs cannot be groupped.
-
Use Working Days for Statement Generation Days: Leave this option unchecked to apply the
UseWorkingDaysForSGDaysinsurance parameter. This parameter determines whether statement generation should consider only working days or all calendar days.
Select the Chronological Alterations option to ensure that all policy changes are recorded and applied in the order they occur. Leave this option unselected to allow non-chronological changes. For more details, see the Configure Mid-Term Adjustment Types page.
-
If you tick the Chronological Alterations option, the Allow add policy on master with pending alterations becomes available. This controls whether new policies can be added to chronological master policies during pending future-dated alterations (including cancellations), ensuring added policies correctly update with alteration changes (payment schedules, status). Policies starting after pending cancellation dates are blocked, and failed alterations now have retry limits to prevent infinite CloneToVersion processing.
The Cancellation Change End Date box establishes whether or not the policy's end date can be changed during the cancellation flow. The default value here is false. For the cancellation flow, you can create your own reason type, other than the ones provided by default. Create your custom business service component with route for the selection of cancellation reason types offered during the cancellation flow. For this you need to add:
-
Business Service Component for Cancellation Reason Selection: the data source for cancellation reasons.
-
Route for Cancellation Reason Selection: the route which determines which reason types, including custom ones, are available during the cancellation flow.
Insurance policy reinstatement refers to the process of restoring a lapsed insurance policy to its original status after it has been canceled or terminated due to non-payment of premiums or other reasons. Configure the following options:
-
Always auto-reinstate option is for telling the system whether or not to automatically reinstate a policy as soon as a payment is made.
-
No: the system auto-reinstates only if the payment date is in grace period;
-
Yes: on payment allocation, the system generates the reinstatement record, approve it and update the policy/ master policy.
Explanations
If the premium was paid on time but the system did not allocate the payment to a master policy installment, a Billing & Collection or Policy Admin user can manually allocate the premium, and the master policy in Suspended status will return to InForce without requiring the Reinstatement process, provided the payment date is earlier than the due date of the unpaid installment.
In the case of an automatic reinstatement, the system generates a reinstatement record that is automatically approved, and if an existing reinstatement is present but not yet approved, it is also automatically approved with updated values such as the payment date. In this scenario, the default request type is “Paid on time but unallocated,” the installment status becomes Paid, and the reinstatement moves to PaidInGracePeriod status. When a suspended master policy installment transitions to Paid and no other installments remain Unpaid, the automaticReinstatement() function is triggered by the FTOS_INS_UpdateDueDateOnPolicyInstallment server automation script.
-
-
Has Approval Step:
-
Yes: the flow for reinstatement follows the steps: Register > Propose Request > Approve.
-
No: the Propose Request step is removed, and only the Approve step and button remains on the form. This makes the reinstatement process faster.
-
-
Waiver Security Roles: pick the security roles for users to have the ability to override back premium collection during the reinstatement of suspended policies.
-
Defer Security Roles: pick the security roles with the capacity to defer back premium collection during the reinstatement of suspended policies.