Release documentation - Life - Enhancements and requests

Problem:

The below mentioned objects are based on tables which are not used in Life system these will always come back with NULL information.

• PA Premium Rate on Line 
• PA Premium Deposit currency 
• PA Total Deposit Premium (Orig)
• PA Premium Rate
• PA SUPI/Exposure (Main) 

Solution:

The above-mentioned objects are not relevant to Life and can be hidden in the Life Universe since they are not relevant.

And also, the verification of generating a report of the Non-Prop Premium condition in Life needs to be done to proceed with the solution.

Problem:

Missing three objects in Life universe 23.4.

Solution:

Need to add this three below objects for the coming release:

Outward Cedents Contract ID.
Reserve.
Ceded Percentage.

Problem: Need to make few adjustments in Life & PC Main Universe.

Solution: 

Need to change SQL for the object 'Entry code' to come from BOAC_LF_FACT instead BOAC_DIM_ENTRY_CODE in Life Universe.

Also need to adjust outer join for the table AMD_Booking in PC Main Universe.

Problem:

 Adjustments  to the  joins and some Object definition should change  in Life universe.

Solution:

Need to create the Joins and also need to change the definiton for the object CESSION ID.

Problem:
Need to add the Accounting year+1 condition.

Solution:
Add the accounting year+1 condition to the Timeline Class.
(BOAC_DIM_TIME.AC_YEAR BETWEEN @Prompt('Enter Accounting Year (Start)','N','AYRP - Accounting Period Timeline/Accounting Year',Mono,Free) and @Prompt('Enter Accounting Year (Start)','N','AYRP - Accounting Period Timeline/Accounting Year',Mono,Free) +1

)

Problem:

Various issues in the Unplaced amount field on the cession when there is an increase in transactions after a fully or partially unplaced amounts have been manually placed to facultative retrocessions

Solution:

After the RPO has run the values to the Net Sum Retained, Total Sum Retroceded and Unplaced amount should not be updated when there is any fac retrocessions processed manually

When a cession is retroceded on pure fac basis i.e when the cession has not been picked up by the RPO :

Do not update the Net Sum Retained, Unplaced Amount or the Total Sum Retroceded on the cession benefit
Only update the Fac Total Sum Retroceded with the amounts that have been retroceded to the Fac OCCs and the remaining unplaced amount field

When there is any increase or decrease to the SAR and the remaining unplaced amount is further retroceded through the same fac OCC or different fac OCCs then the fields Fac Total Sum Retroceded and Remaining Unplaced amount fields should be updated

When the SAR is retroceded through an RPO and retroceded to the OCCs linked to the PP

First then calculate the net sum retained, total sum retroceded and the unplaced amount. This unplaced amount should be updated in the Remaining Unplaced amount field also. This is existing functionality

When the remaining unplaced amount is retroceded through the Fac OCC then do not recalculate the Total Sum Retroceded. The Total Sum Retroceded that was calculated through the RPO run should remain as it was and the fac total sum retroceded should not be added to this

When there is any increase to the SAR then update the unplaced amount field based on what the RPO has calculated and , only update the remaining unplaced amount field with the new unplaced amount.

When there is a decrease in the SAR and the RPO recalculates the net sum retained and available capacity the values in the net sum retained and Total Sum Retroceded should be recalculated and the 'released' retention and capacity should be available for any other cession benefit on the same life, benefit. The existing facultative retrocessions should not be adjusted with the decreased amount

Any value in the unplaced amount field should be updated only when the RPO is run. Changes made to a facultative cession should not update the Unplaced amount field

Problem:
FAC retrocession is created on the claims with incorrect benefit sum retroceded amount.

Solution:
Always use the claim event date to reference to the retrocession effective period of the linked retrocession cessions when calculating the claim recovery.

The ceded percentage claim recovery should be based on the retrocession effective period within which the claim event date falls in for all the retros attached to the cession.

Problem:

When on a NB transaction again a NB is loaded via cession loader then system renews the cession and does not reject it

Solution:

 If there is anothertransaction with the transaction code New Business or Old Business that is loaded on the same active cession benefit where the same BC-IP and policy number / cedent ref number and life id referenced then the record should be rejected with the existing confirmation message 'Another cession benefit with the same insurance product already exists. Do you want to continue?' answered as No. The cession benefit should not be renewed

 Problem:

Look-up Table detached from treaty Insured Period is not cleared from the db

Solution:

If a lookup table has been removed from the business section insured period the DB link between the LUT and the business section/ insured period should be removed and the relationship should be deleted
 
The LUT should never be referenced again when calculating or validating anything on the cession benefit once detached

Problem:

Refund ACI not calculated for cancel from inception transaction on a migrated policy

Solution:

 When the flag 'Old Business transaction on risk premium basis' is selected then when there is a termination transaction, then first calculate the full premium and other ACIs for the new business transaction that is linked to the Old Business transaction of the inward cession, then process the refund should be calculated for the termination transaction as per the AC condition

Problem: 

Abend when a lapse is created on a transaction which is not the latest transaction 

Solution:

When there is a termination transaction on the effective period of the inward cession and subsequent transactions are reversed 

When there is a facultative retrocession on the cession that does not have any transaction for the date of termination of the inward, but it has transactions that are linked to one or more effective periods that match the fully reversed transactions on the inward then process the full reversals on those transactions automatically when the inward cession is terminated. Do not create any other transactions on the fac retrocession with an effective date that did not previously exist

Problem:

Incorrect pro rata return premium

Solution:
 
 Include the date of lapse/ termination when calculating the pro rata reversal when the unearned premium return option is pro rata to the day

Problem:

Cession Loader | Single Account having 'Received Date' does not appear in Cession Batch

Solution:
Do not validate any dates (Received, Closed, Run) or the Paid flag on the single accounts on the business when listing the account period values on the cession batch.
 
The Account Period on the Cession Batch should be optional and if not selected it should still be possible to process the batch

Problem:

Claim statuses are not displaying in correct order if we edit the ceded outstanding status on Proportional Standalone Individual claim

Solution:

Do not update the timestamp when a claim status is edited. If the claim status is edited to add expenses or any other additional ACI do not update the time stamp.

When there is more than one claim status with the same payment due date the claim statuses should be displayed in the sequence of the time stamp as per creation of each status

Problem:

RPO run with Multiple PP mode updates incorrect failed assignments.

Solution:

When the RPO is run with multiple PPs and there is atleast one OCC with the matching classifications resulting in the cession being reinsured, do not list this claim in the failed assignments. If the cession was listed as part of the failed assignments due to a mismatch with one of the earlier OCCs then delete this failed assignment once the cession benefit is matched with a valid OCC

Problem:

When claim have more than 1 outstanding transactions, can't upload normally

Solution:

When the system parameter Allow transaction number on cession and claim transactions is selected the transaction number that is entered or mapped for each claim status should be updated as mapped

If no transaction number is mapped then the next status should be created with the previous transaction number + 1

The defaulted claim status/ amendment number should be 0 for the first transaction and incremented by 1 for each subsequent status transaction as per existing functionality

When there is an Adjustement reversal that is created on a specific claim transaction the adjustment reversal transaction should not have any transaction number as per existing functionality

A transaction reversal should reverse the entire claim it will require a unique transaction number

Problem:

Calculation Rule is duplicating & not updating correctly on the (Profit Commission) PC condition through webservices.

Solution:

It should use the defined Calculation rule and update the PC condition and it should not create any duplicate rule. and if the Calculation Rule doesn't exist SOAP should fail to execute. 

Problem:

The retention corridor amount defined on OCC is not being utilized when RPO is run 

Solution:

When there is a retention corridor defined and the SAR for retrocession/ SAR is within the retention corridor the amount should be retained
 

Problem:
System is throwing a validation multiple times while calculating ACI's with Calculation rule in PM condition. 

Solution:

 Any validation or error message related to the PM calculation rule should not be repeated
When this is being executed during the cession loading process or RPO processing or any Renewal order processing the message should be answered as Yes/ OK in the background and not expect user interaction

Problem:
System is not calculating ACI's when in PM condition is defined with a calculation rule having Premium table with more than one version

Solution:

 When there is a premium rate table included in a calculation rule always use the current active version of the table when calculating the premium

Problem:

When a cession Batch is created through API, system abends on closing the created cession batch.

Solution:

If only the business id is part of the soap then always use the latest active insured period of the business on the cession batch as the default value

Problem:

System generates a Walkback file on Webservices when executing an Update Scope of Cover SOAP with NC condition defined.

Solution:

If the update SOAP includes any change to the NC condition then update the NC condition along with any other condition that is part of the Update SOAP. Else ignore the NC condition and update the other conditions that are part of the update SOAP

The system should not abend

Problem:

System Abends when more than 5 Date type is defined on the User Defined Layout for the UD condition.

Solution:

The system should not abend if on a business opening the user defined pages and user defined fields have been setup with more than 5 fields for User Defined Field Type: Date (free text).

Instead, allow 10 user defined date fields per business layout. It should be allowed to be create this when defining the business UDF layout. If more UDFs are have been set up, the system should prevent this at the time of setting up the UDF layout.

This should be applicable to Life and P&C

This is applicable to

Bank

Business - All Layouts

Person

Cession

Benefit

Insurable Object

Claim

Problem:

System abends when loading is 0 for both NB and Other transaction in same file 

Solution:

SCENARIO 1:

When the policy number and cedent cession number and the life id is the same on two records but the insurance product is different, then it should create two cession benefits on the same cession
Each cession benefit can have its own loading factor and they can be the same on both records

So do not validate if the loading factors are duplicates when there are two different cession benefits or cessions being updated OR created in the same load

SCENARIO 2:

On a cession benefit there may be more than one loading of the same type for different reasons. Eg: Flat extra <user defined value eg: Aviation Extra> : 2000, Flat Extra < user defined value eg: Obesity> : 4000
So here the loading type is the same but the reasons are different. Each loading will be created separately on the cession benefit but summed up against the entry code for ACIs. So this should also be allowed.

The above two scenarios work as intended manually

SCENARIO 3:
The record should be rejected ONLY when the policy number, cedent cession number, life id, benefit covered and insurance product are duplicated and
a) the loader attempts to create either another cession benefit on the same cession or
b)attempts to create another new business transaction on an active cession benefit (happens when there is no trans eff date, and trans code mapped OR trans code mapped as OLDBUS/ NEWBUS and/ or the trans effective date mapped references to an existing transaction). This is irrespective of whether there is a loading or not since you don't even reach the stage where you validate loadings here.

Manually when a) happens there is a confirmation message 'Cession benefit with the insurance product already exists do you want to continue' - through the loader this message is always set to be answerd as No
Manually b) is not possible because you cannot create a new bus or old bus on an existing cession benefit and the user is forced to select a trans code and date

Problem:

Cession transaction effective period is showing as 'None' when benefit reinsurance start date is in leap year.

Solution:

When the reinsurance start date is 28th of February, then always default/ force the user to create the benefit reinsurance start date as 29th February when the benefit reinsurance start date falls in a leap year and the user enters/ maps a value of 28th February- leap year 

When the cession reinsurance start date is 28- Feb- non leap year, then if the mapped value for the benefit reinsurance start date is 28th February then default it to 29th February Leap year. 

For any other date combination use the actual mapped/ entered values. 

Problem:

System abends when executing SOAP for updateInsurableObject Operation if UDF IO layout is not defined

Solution:

If a UDF Layout on an Insurable object is not defined and the soap file contains UDF values that need to be updated then ignore those fields and continue to create the IO without the UDF values

Problem:

Getting an error when loading Adjustment Reversal transaction on claim 

Solution:

When the system parameter 'Transaction number on cession and claim is selected'.

When an adjustment reversal transaction is created on a claim and there is no transaction number then always default the transaction number to the last available active transaction number similar to the online functionality.
If the transaction number is input also, always default the transaction for adjustment reversal as the last available active transaction and ignore the mapped value.

There should be no other validations through the loader other than checking if there is at least one active claim status and the option should be available only on a claim linked to a cession with a ceded flag. The loader should behave similar to a manual adj reversal status change on a claim.

If the cession has no ceded flag then throw the error 'Adjustment Reversal is not a valid status'.

Problem:

Full Name Column is not available in view Joint life window.

Solution:

In the Joint Life IO include a new column 'Full Name'.
Populate this column with the value in the individual life IO- 'Full Name' for each individual insurable object that is part of the joint life cession.

Problem:

ACIs got calculated incorrectly for Lapse transaction after reinstatement.

Solution:

When there is a reinstatement transaction done then the cession benefit should be considered reinstated on the date of reinstatement and any reversals of ACIs that were created by the termination transaction that was reinstated should be reversed again. This will set the cession benefit back to the same status as it was before the termination transaction happened.

If another termination transaction is done after this either on the same date of the earlier reinstatement or any other date then the reversal of the ACIs should be done as per the definition on the AC condition of the benefit section and the ACIs for the entire transaction effective period should be taken into consideration when this is calculated.  Do not consider the only the reinstated ACIs for calculation of the unearned premium return. 

Problem:

Errors in ceded percentage on subsequent transactions when the flag 'Fixed ceded percentage throughout the life cycle of the cession' is selected.

Solution:

When the flag 'Fixed ceded percentage throughout the life cycle of the cession' is selected:

As long as the SAR / SAR for retrocession is below the defined retention, retain the entire SAR/ SAR for retrocession
When the SAR/ SAR for retrocession exceeds the defined retention on the Limit condition of the OCC then process that transaction similar to any other new business transaction and calculate the ceded percentage, net sum retained and retro sum at risk. Update the ceded percentage field on the cession and retrocession and placement levels.
Now for any subsequent transaction, use the same ceded percentage when calculating the Retro Sum at Risk.

When the flag 'Defined Fixed ceded percentage throughout the life cycle on retrocession cession' is selected, always use the same ceded percentage that was calculated in the first transaction that created the retrocession cession and apply this value throughout the cession's effective periods.

Problem:

Cession batch is updating with error when two transactions are created with same details when 'Is Ceded Policy' is not mapped

Solution:

With or without the Is Ceded flag switched on:

When there are more than one records that pertain to the same cession and cession benefit with the policy number and/or cedent cession number, benefit covered, insurance product and life id the same in all the records in the input file and the transaction code is mapped, even if the transaction effective dates of all the transactions are the same sequence the transactions as below to create the cession benefit

1. New Business or Old Business (if there is both old business and new business reject the records since it will be attempting to create another NB or first transaction as per existing functionality) 2. Renewal 3. Other/ Increase/ Decrease or any other type of amendment 4. Any Termination 5. Reinstatement / Reinstatement with updates

When there are more  transactions with the transaction codes that fall under sequence number 3 then process these in the order in which they are sequenced in the file

Problem:

Adjustment Reversal is always creating on latest active status on Retro claim

Solution:

 For each adjustment reversal on the inward claim a corresponding adjustment reversal transaction should be created on the linked retro claim and placement claims

Problem:

On Webservices, the cession effective date xsi type is showing as DateTime.

Solution:

ONLY FOR LIFE CESSIONS  : The 'attachmentPeriodFromDate' and 'attachmentPeriodToDate' dataType for the API The effective date for rretrieveCessionsAndAccumulatedSAROfIOR  should be Date instead of DateTime

Problem:

Able to create different statuses with duplicate transaction number on claim through loader

Solution:

It should not be possible to create more than one claim status with the same transaction number. When there are duplicate transaction numbers that are loaded on a claim the records should be rejected with the error message ransaction number already exists similar to online function

Problem:

Original benefit reinsurance start date is increasing in Subsequent transactions

Solution:

The Original Reinsurance Benefit Start date should not be incremented in every subsequent transaction. This field should not be editable. The same date that has been mapped/ entered at the time of creating the new business or old business transaction should remain throughout the life cycle of the cession benefit and should always be copied from the previous transaction. If this field is mapped with another value through the loader then the mapped value should be ignored

When there is no value entered/ mapped to the field Original Benefit Reinsurance Start date then the Benefit Reinsurance start date will default to this field

If there is no value mapped to the Benefit Reinsurance Start Date - then the Reinsurance Start Date will default to the Benefit Reinsurance Start Date and this value will default to the Original Reinsurance Benefit Start Date

Problem: 

Full recapture transaction is not creating in facultative placement's when back dated termination transaction is performed.

Solution:

When there is a termination transaction that is not in the current effective period then the corresponding termination transaction should happen in the same effective period of the linked fac retrocession and placement cessions with the same effective date of termination. All subsequent transactions after the date of the termination that have been reversed on the inward cession should also be reversed on the fac retrocession and placcement cessions

Problem:

System Abends on saving SR condition, when Decrement Basis is not defined. 

Solution:

If the Decrement basis is not defined on the SR condtition then throw the existing validtaion error 'Decrement basis is required...'

The system should not abend

Problem:

Retroceded Date is not updating when we decrease the sum at risk

Solution:

Whenever the RPO picks up any type of cession benefit transaction and either fully retains the transaction SAR or processes a retrocession the retroceded date should be set on the cession benefit transaction and the corresponding retrocession and placement cession benefits

Problem:

On Webservices, System generates a Walkback file, when terminating a Standalone Retrocession.

Solution:

It should be possible to terminate a standalone retrocession through webservices when the operation terminateLfStandaloneIndividualRetrocessionBenefit is processed

Do not check for any linked inward cessions. Terminate the cession with the termination transaction as per the soap and when the mandatory values are available the standalone retrocession should be terminated

All the linked placements should also be terminated in this process

Problem:

Performance issue in cession loader batch.

Solution:

Rollback of code implemented to convert an underwriting cession to an actual cession

Problem:

The close ended protection program is not picked up by the RPO 

Solution:

ALL FUNCTIONALITY IMPLEMENTED ON SE-25859 WILL BE APPLICABLE ONLY WHEN THE SYSTEM PARAMETER Use Cession Original Reinsurance Start Date for Retroprocessing IS SELECTED

The system parameter 'Use Cession Original Reinsurance Start Date for Retroprocessing' should be selectable only if the system parameter 'Use Cession Reinsurance Start Date for Retroprocessing' is NOT selected. This means that when one of the system parameters is selected then the other should be disabled for selection

When the system parameter 'Use Cession Original Reinsurance Start Date for Retroprocessing' is selected:

1. Only if this system parameter is selected the field 'Original Reinsurance Start Date' should be visible and available on the cession benefit
2. If there is no input to this field then the Reinsurance Start Date should default to this field
3. When this system parameter is selected the value in the field 'Original Reinsurance Start Date' should be used to identify the treaty and the amendment to which the cession should reference to

When the system parameter is NOT selected then always use the Reinsurance start date on the cession level to reference the treaty and the amendment on the treaty as per 

When the system parameter Use Cession Reinsurance Start Date for Retroprocessing' - As per SE-11877

When there is a cession that has more than one cession benefit which has a benefit reinsurance start date later than the cession reinsurance start date, then on running the RPO all benefits will be retroceded based on the cession reinsurance start date.

This will mean that even if the OCC has been terminated and the cession benefit start date is beyond the OCC termination date, the benefit will continue to be retroceded based on the cession reinsurance start date (if it falls within the active insured period of the OCC)

All the terms and conditions that the cession benefits will reference to will also be the terms and conditions linked to the insured period/ amendment effective period on the OCCC within with the cession reinsurance start date falls in

Problem:

System is allowing to create Amendment transactions on Cession even when cession is in Provisional Status through web services. 

Solution:

When the cession is in a status of Provisional or Inactive, no amendments should be allowed through webservices.
Throw the validation message 'No Amendments can be performed on a Cession in Provisional status'.

Problem:

On Webservices system generates a Walkback file on operation 'createLfCession' when Main, SAR, ACI elements are defined as true, due to the 'Renewal Frequency' field not updating through SOAP. 

Solution:

If the renewal frequency is not part of the soap input and the PM condition of the linked business is Original then throw the same validation error message as per online functionality when trying to set the cession benefit to active through webservices 'Renewal Frequency is not specified'.

Aim of function
Increase the field size for Group Scheme name and underwriting cession review comments fields

Business value for customers

The increased field size in the underwriting cession review comments field will allow the customers to capture more information related to the life that is underwritten and add more detailed review comments. 

The increased GS name will allow the customers to capture names of the reinsured groups that exceed 100 characters

System Parameters Affected

None

Existing functionality affected

Group Scheme Name on the Cession Level will now allow upto 200 characters

The Underwriting Cession Review Comments will now allow upto 1000 characters from the earlier 60 characters

Aim of function

Ability to automatically terminate the cession benefit when there is a claim created on the cession benefit for specific products based on a reference data dependency

Business value for customers

It will now be possible for the customers to configure products where the cession benefit will also be terminated automatically once a claim such as a death claim is created on the linked cession benefit. This way there can be no further transactions done on the linked cession benefit and also, any recovery or reversals of premiums that might have been paid on the cession benefit after the claim event date can be automatically reversed.

 
System Parameters Affected

None

Existing functionality affected

A new Reference Data value for 'Benefit Behaviour' 'Terminate Cession on Claim' is available
When the Benefit Covered that has been configured is defined with this Benefit Behaviour as a child dependency then when a claim is created on a cession benefit of a cession where the ceded flag is selected, the cession benefit will be automatically terminated with the status 'Automatic Expiry' as on the event date of the claim.
The unearned premiums will be calculated on the cession benefit based on the definition on the AC condition.

Aim of function
The aim of the function is to be able to handle recovery of declined claims for bundled products where the reinsurance premiums less the previous claims paid are recovered

Business value for customers
For products where there are specific rules for recovery of premiums in case of declined claims there are now different options to support various calculation rules.

System Parameters Affected
None

Existing functionality affected
For claims on cessions where the Ceded flag is selected, there is now a new status 'Declined' that is allowed. On a Declined claim the following options are available and selection of each option will result in the claim recovery being calculated based on the reinsurance premium paid.

1) Previous Claim Less Premium Paid : When this option is selected in Decision/ Liability tab the Retro & Placement claim ACI's calculation will use the following rule: The accumulation of all previous CEDED PAID claims of same Insurance product and same IO of all benefits of the same cession - Premiums paid on all linked retrocessions of same Insurance product and same IO of the same cession.

2) Premiums paid on Pro rata basis after the date of claim :

If the claim event date is falling in between any effective period of the linked retrocession then the Retro & Placement claim ACI's calculation will use the following rule: Premium calculated on pro rata basis (similar to how it's happening for Termination transaction) from the claim event date to the end date of that effective period of linked retrocession + remaining premiums of transactions of linked retrocession whose effective period is after the claim event date

Aim of function

Profit commission order to calculate the profit commission per section.
Include Booking Year and Period in the extraction criteria and as calculated values in the Profit Commission Calculation rule.

Business value for customers

Customers will now be able to define profit commission calculation rules to use both booking year and period or accounting year and periods. They will also be able to define and calculate the profit commission on section level. 

System Parameters Affected

Two new calculated amounts for Current Booking Year and Period and Previous Booking Year and Period are now available in the Profit Commission calculation rules.

Existing functionality affected

1. It is now possible to define the Profit Commission Condition on each section of the treaty. When the PC calculation order is run the bookings made on each section of the treaty will be used and the profit commission for each section will be calculated and booked on the technical worksheet

2. The profit commission calculation order now can extract the bookings for the current and previous Booking Year and Period OR current and previous Accounting Year and Period. Based on the selection on the order and the refrenced profit commission calculation rule, the profit commission will be calculated and booked when the order is run

3. The Profit Commission Calculation rule can use parameters for both Booking Year and Period and Accounting Year and Periiod

Aim of function

Several new fields have been introduced on the cession benefit level. These fields are extended to webservices

Business value for customers

All the fields introduced on the cession benefit level are now available for creation through webservices

System Parameters Affected

None

Existing functionality affected

Webservices for Cession and Retrocession handling to include

1. The following elements are available when creating the cessions and standalone retrocessions through webservices
Original Sum Insured
Cedent total SAR.
Ceded Percentage
Deductible
Payment Ratio.
SAR For Retrocession.
SAR Decrement. - Available on createLfCession Operation as element mathematical reserve.
Policy Year.
Preferred Life Classification.
Benefit Reinsurance Start Date.
Original Benefit Reinsurance Start Date.
Other Info 1 to Other Info 36.
Salary
Premium rate
Premium Amount
Currency
Sum At Risk Individual
Free Cover Limit
Female Expiry Age
Male Expiry Age
Short-term - Flag
Premium Calculation Bais
Other Group Info 1
Other Group Info 2
Other Group Info 3
Other Group Info 4

2. 'Allow more than one PP' flag is available for selection on the Retrocession Processing Order xsd
3. On the create Order operation it is possible to create a Retrocession Processing Group Order

Aim of function
Include a set of calculation variables for premium calculation rule that will include Retrocession Placement Cession fields
Add a Retroceded percentage field on the retrocession cessions
Add date variables in the SAR and Premium calculation rules

Business value for customers

Premium Calculation Rules can now be set up to reference to variables on the Retrocession Cession Placement level. So when the PM condition is overridden on the placements, the rules that are defined referencing to the placement level variables will now use the respective fields on the retrocession placement cessions and calculate the ACI on the placements.
It will also be possible to include dates within the calculation rules

System Parameters Affected

Under the Calculation Rules a set of variables under the parent value 'Retrocessionaire Placement' are available. All the fields available on the Retrocessionaire Placement level are listed under this set and can be included in the calculation rules

Existing functionality affected

1. Under System Parameters all Calculation Rules the following set of variables are available. These will reference to the respective fields on the placement cession level and be used for the calculations

2. On the Retrocession Placement cession level a new field 'Retrocessionaire percentage' is available. This will reflect the share of the placement cession from the 100% share

3. The following date values are now available for inclusion in the calculation rules

• Original Reinsurance Benefit Start Date
• Benefit Reinsurance Start Date
• Reinsurance Start Date
• Reporting Date
• Created Date

Aim of function

Further cleanup of various missing functions in the create and update Life business webservices

Business value for customers

Life Business Webservices

System Parameters Affected

None

Existing functionality affected

• Added a New Element for 'Table Name' on the CreateLfSRConditionforLife operation
• Added a New Element 'Old Business transaction on Risk Premium Basis' for the Premium Condition (createProportionalPremiumConditionForLife Operation).
• Added a New Element 'Fixed Ceded Percentage' for the P&L Condition (createProportionalLimitsGeneralTermsConditionForLife Operation).
• Added New elements on the 'CreateProtectionProgram' operation to define the 'Additional Scope' condition on the OCC created through the Add treaty Outline Option.
• Fixed the Issue of OCC identifier not genarting, when OCC is realized on the Protection Program.
• Created a New Operation 'createReinsuarnceProgramTreatypart' & 'updateReinsuarnceProgramTreatypart' to link an Assumed/Inward Business with a Reinsurance Program.

Aim of function

New Unearned Premium Return option where pro rata refunds will be calculated by excluding the date of termination

Business value for customers

In addition to the existing unearned premium return rules, it will now be possible to define the Unearned Premium Return option where the pro rata to the day refund calculations will be done excluding the date of termination

System Parameters Affected

None

Existing functionality affected

A new value for Unearned Premium Return type 'Exact Pro Rata to the Day - Date of Termination +1' is now available
When this value is selected the pro rata return of premium and related ACIs will be calculated from the next date after the date of termination

Aim of function

Include AND operation in the SAR calculation rules and use the entered retroceded percentage on the cession benefit level to calculate the retro SAR when the RPO is run

Business value for customers

It will now be possible to enter a ceded percentage on the cession benefit and use this value to process the retrocessions when the RPO is run
All the calculation rules will now also allow the AND and OR operations

System Parameters Affected

A new variable %useCededPercentageForRPO included in the SAR calculation rules
AND and OR operations available in all Calculation Rules

Existing functionality affected

• On the cession benefit a new boolean flag and an input field 'Ceded Percentage for RPO' is available
• When there is a value entered on this field AND the variable %useCededPercentageForRPO is selected on the SAR calculation rule, then the RPO will use the value available on the cession benefit to process the retrocessions upto the available capacity and retention as defined on the treaty limit condition

• On all calculation rules, the AND and OR operator is available as | and &. These operators can be used within any calculation rule

Aim of function

Automatic defaulting of BP Reference number on the SBG which is the invoice number
'Actual Settlement Date' field for balance pairing
Balance Pairing Order to include 'Invoice number' as part of selection criteria and hide all fields that FWD does not want to see
System parameter driven

Business value for customers

The customer will now be able to automatically update a reference on the Settlement Balance Group and select one or more of these references in the Balance Pairing Group window to process the automatic pairing

System Parameters Affected

A new Life specific System Parameter 'Automatic BP Reference on SBG and selection on Mass Pairing' is now available

Existing functionality affected

When the system parameter Automatic BP Reference on worksheets and selection on Mass Pairing is selected:

• When a Settlement Balance Group is created, on settlement pairing group window Bp Reference is updated as ‘Reinsurer (Payment Partner) Short Name + Accounting Period’ This will use the Expected Partner name. When there is more than one reference id with the same combination of details the automatic reference id will be incremented with a value of +1

• A new field ‘Actual Date of Pairing/ Settlement' on balance paining window and balance pairing group window. This will be open for input

• On the Mass Balance Pairing Order Window the BP reference ids as created for all the settlement balance groups for the selected partners will be available for selection. A field Actual Date of Pairing/ Settlement will be available for input.

• When the Mass Pairing Order is run all the SBGs with the selected BP references will be settled with the linked remittance worksheets and the Actual Date of Pairing will be updated as per the date input on the Order