10.1 Sequence of Batch Functions

This topic provides information on sequence of batch functions.

Sequence of Batch Functions

The following table gives you the sequence of the Batch Functions, the Activity and whether the Activity is an EOD or BOD function.

Table 10-1 Sequence of Batch Functions

Activity EOD/BOD
LEP - Plan Funding Repayment EOD
LEP - Generate Plan Transactions EOD
LEP - Update Product Fiscal Year EOD
LEP - Update Plan Transaction Allotted Status EOD
LEP - Plan Financial Bucket Adjustment EOD
LEP - Plan Annuity 5/20 Validation Process EOD
LEP - 120% Rule Support EOD
LEP - NAV Correction EOD
LEP - Set Latest Rule for Product BOD
LEP - Set Latest Rule for Plan BOD
LEP - Plan Anniversary Value Computation BOD
LEP - Plan Annuity Escalations BOD
LEP - Plan Recurring Switch Escalations BOD
LEP - Plan Premium Escalations BOD
LEP - Recurring Plan Annuity Processing BOD
LEP - Recurring Plan Switch Processing BOD
LEP - Recurring Plan Premium Processing BOD
LEP - Plan Funding Repayment BOD
LEP - Generate Plan Redemption Transactions for Periodic Fees BOD
LEP - Process Plan Surrender BOD
LEP - BOD Plan Transaction Generations BOD

Table 10-2 Sequence of Activity

Activity Description
LEP - Plan Funding Repayment

Funding is a feature where a part of the initial investment and subsequent top ups, if any, is retained by the Life Company and then paid back to the customers in equal installments. The customer receives the principal amount and not the interest earned on the same.

The Funding Factor, which is the percentage of the initial contribution or top ups which is retained by Life Company, and the Funding Frequency, which is the frequency at which the installment is paid back to the customer, are specified for the product. The Repayment Period, which is the period within which the entire amount is to be paid back to the customer, is also specified.

This EOD Process carries out the funding repayment for the policies marked for the same.

This is also a BOD Process.
LEP - Generate Plan Transactions

A policy transaction might involve one or more funds. This process generates one transaction per fund. The process will pick up all policy transactions that do not have underlying UT transactions generated.

The system intimates the user upon completion of the activity and the successful generation of underlying transactions.

This process is also scheduled as a BOD process to take care of all the system generated policy transactions that might have occurred as a result of other Batch Activities.

Note: If a policy transaction triggers a number of underlying subscription transactions at the fund level, the process of generation must be successful for each of these underlying transactions at the fund level. If not, the generation is aborted for all underlying transactions for that policy.

LEP - Update Product Fiscal Year

This process updates the fiscal year dates for all products for which the fiscal year end date is the next working day, on the application date.

The fiscal year is updated to the next fiscal year.
LEP - Update Plan Transaction Allotted Status

A policy transaction is considered allotted only if all the underlying Unit Trust (UT) transactions are allotted. This batch process checks if all the underlying UT transactions are allotted and if they are, it marks the policy transactions as allotted.
LEP - Plan Financial Bucket Adjustment

This process facilitates the adjustment of investment in the funding bucket in the event of repayment of the funded amount. The process will also adjust the funded units if there is a reversal of a surrender or top up transaction.

The process works as follows:
  • On the application date, the process identifies the funding amount repayment transactions at a policy level for funded endowment products.
  • The units repaid for these transactions are identified.
  • The funding units in the funded bucket are reduced for each of the funds by subtracting the funding units with the funding repaid units.
LEP - Plan Annuity 5/20 Validation Process
When a policy is created and authorized, this EOD process performs the following functions:
  • The policy amount is allotted into the underlying portfolio and the Net Invested Amount (NIA) is validated against the minimum and the maximum annuity ratio specified at the policy level. The adhoc (top up) contribution is marked as Inclusive even if it is Exclusive if it violates the minimum/maximum annuity ratio specified.
  • A procedure is then used to validate the 5/20 rule, using the annuity amount specified and the NIA as parameters and an error report is logged if the 5/20 Rule is violated on any on any of the following events:
    • Saving of a policy
    • Amendment of a policy
    • Top Up transaction
    • On the Anniversary Date
    • Anniversary Escalations

5/20 Rule

The annuity amount that is paid to the policyholder must be within the range of the Minimum Annuity Ratio (5%) and the Maximum Annuity Ratio (20%) of the Net Investible amount (NIA). The Net Investible Amount is the investment amount minus the initial fees and charges. The annuity should not be accepted if the annuity amount either falls below the 5% threshold of the NIA, or exceeds the 20% threshold of the NIA and all inclusive top up transactions.

Consider the example given below:

Case A:

Let us consider a Policy Holder who buys a policy in an ELLA product. He initially contributes 60000 currency units, net of initial charges on 1st January 2005. On 1st January 2005 (EOD), the 5/20 Rule batch checks the annuity amount, which has been specified as 3000 currency units, against the NIA (60,000 currency units). This amounts to 5% of the NIA, per month for a period of 5 years. There is no violation of the rule here. Now let us suppose the Policy Holder tops up (transaction T1) his investment in the policy by 40000 currency units (top up being ‘Inclusive) on 1st April 2005. The total contribution has now increased to 100,000 currency units.

On 1st April 2005 (EOD), the 5/20 Rule batch checks the annuity amount specified as 3000 currency units against total contribution amount (100,000 currency units), which amounts to less than 5% of the total contribution amount, thus violating the 5/20 Rule and logs an entry into the error report with the reason for failure of the 5/20 check. Subsequent to above, for any of the other top up transactions, the system considers the same NIA, initial top up amount and the latest top up amount for the 5/20 validation in the policy year.

Case B:

Let us consider a Policy Holder who buys a policy in an ELLA product. He initially contributes 60000 currency units, net of initial charges on 1st January 2005. On 1st January 2005 (EOD), the 5/20 Rule batch checks the annuity amount, which has been specified as 3000 currency units, against the NIA (60,000 currency units), which amounts to 5% of the NIA, per month for a period of 5 years. There is no violation of the rule here. Now let us suppose the Policy Holder tops up (transaction T1) his investment in the policy by 40000 currency units (top up being ‘Exclusive’) on 1st April 2005. The total contribution has now increased to 100,000 currency units.

On 1st April 2005 (EOD), the 5/20 Rule batch checks the annuity amount, which is specified as 3000 currency units, against total contribution amount (100,000 currency units). This amounts to less than 5% of the total contribution amount and hence violates the 5/20 Rule. The system marks the Exclusive top up transaction (T1) as Inclusive and logs an entry into the error report with the reason for failure of the 5/20 check. For any subsequent top up transactions, the system considers the same NIA, initial top up amount and the latest top up amount for the 5/20 validation in the policy year.

Note: As seen in the case above, the initial top up amount T1 was made Inclusive. This amount will be considered for any subsequent validation as an Inclusive top up and not an Exclusive top up.

The logging in of the error report and the change/adjustment in annuity details are operationally controlled.

Note: The system considers the following formulae while calculating the annuity amount.

Case 1: When top up is Inclusive

Annuity Amount >= Minimum Annuity Percentage * (Latest Anniversary Value + All Inclusive Net contributions made during the year

The current top up amount will be included in the contribution

Annuity Amount <= Maximum Annuity Percentage * (Latest Anniversary Value + All Inclusive Net contributions made during the year

The current top up amount will be included in the contribution

Case 2: When top up is Exclusive

Annuity Amount >= Minimum Annuity Percentage * (Latest Anniversary Value + All Inclusive Net contributions made during the year + Current Exclusive Net top up)

Annuity Amount <= Maximum Annuity Percentage * (Latest Anniversary Value + All Inclusive Net contributions made during the year + Current Exclusive Net top up)

LEP - 120% Rule Support
This is an EOD activity which checks all the policies that come under Endowment Products and have a Top Up, Premium Transaction or a Premium Escalation on the particular day. This process is carried out for each policy. The 120% Rule triggers on the following events:
  • Top Up Transactions
  • Premium/Premium Escalation Due Date

If the date happens to be less than the Policy Anniversary Date, the projected premiums for the rest of the policy year will be considered for the 120% Rule validation. The system will sum up all the contributions (Initial Investment, if any + Top Ups, if any + Premiums, both, paid and projected) in the current policy year.

Say, for example, the contribution amount sums up to ‘X’ Rands. This process will sum up the contributions (Initial Investment, if any + Top Ups, if any +Premiums paid) in the two policy years.

Note: A policy year is a year between two Policy Anniversary Dates.

Let us say the contribution amount sums up to ‘Y’ Rands in the first policy year and ‘Z’ Rands in the second year. The system will compare the higher contribution amount of the two years, against the amount ‘X’ Rands.

If ‘X’ exceeds the higher, say ‘Y’, by more than 120%, the Policy Maturity Date will be reset (New Maturity Date = Current Application Date + Minimum Term). The existing rule will not be changed, but there will be a remark stating the Policy was amended by the system as a result of the 120% Rule. The minimum term/tenor considered here will be the one you have saved during Policy creation which might not be same as the default Product tenor.

The system will run the batch activity for 120 % rule irrespective of client country code OMIA120RULE enabled or disabled. The system will check if there is a deviation in 120% rule. If the 120% rule is breached, then the system will extend the maturity date. If the 120% rule is not breached, then the system will not extend the maturity date.

The system will perform the batch check purely based on the EOD scheduling. During the Batch activity, if policy is in breach of 120% rule, policy will be amended for new maturity date.
LEP - Set Latest Rule for Product

When a new Product is setup, or after a Product has been amended, if the System Date is equal to the Rule Effective Date of the Product, this BOD Batch Process will set the current rule as the latest rule. The new rule will be considered for all the validation processes.
LEP - Set Latest Rule for Plan

When a new Plan/Policy is setup, or after a Plan/Policy has been amended, if the System Date is equal to the Rule Effective Date of the Plan/Policy, this BOD Batch Process will set the current rule as the latest rule. The new rule will be considered for all the validation processes.
LEP - Plan Anniversary Value Computation
The system facilitates the revaluation of annuity payments on every Anniversary Date, through this BOD process. It works along the following lines:
  1. The process checks if the Application Date is an Anniversary Date.
  2. If so, the anniversary revaluation is done for all ELLA policies, and the computed values updated in the system.
  3. The process then performs the 5/20 validation for the new anniversary values.
LEP - Plan Annuity Escalations

This process works in much the same way as the 5/20 validation process, but takes into account any changes that are made to the annuity amount either by way of amendment or escalation, in the Policy Maintenance screen. The 5/20 validation is also performed for this BOD process.
LEP - Plan Recurring Switch Escalations

If recurring switch escalation details are specified for a Policy, this BOD Batch Process will amend the policy rule and create a new rule with the new escalated recurring switch value on the specified/calculated Escalation Date, for the specified funds.
LEP - Plan Premium Escalations

If premium escalation details are specified for a Policy, this EOD Batch Process will amend the policy rule and create a new rule with the new escalated premium value on the specified/ calculated Escalation Date, for the specified funds.
LEP - Recurring Plan Annuity Processing

This BOD Batch Process generates periodic annuities for the Policies for which annuity is applicable. This transaction is generated using the annuity setup corresponding to the latest rule for the Policy.
LEP - Recurring Plan Switch Processing

This BOD Batch Process generates periodic recurring switch transactions for the Policies for which recurring switch is applicable. This transaction is generated using the recurring switch setup corresponding to the latest rule for the policy.
LEP - Recurring Plan Premium Processing

This BOD Batch Process generates periodic premium transactions for the Policies for which premium is applicable. This transaction is generated using the premium setup corresponding to the latest rule for the Policy.

Note: For Premium transactions, only Self payment is supported.

LEP - Plan Funding Repayment

See Plan Funding Repayment. This will be a BOD Process.
LEP - Generate Plan Redemption Transactions for Periodic Fees

After the periodic fee has been calculated for a Product by the system, this BOD Batch Process generates a redemption transaction in policyholder’s account for the calculated Periodic Fees.
LEP - Process Plan Surrender
This process reduces the funded units in the underlying portfolio for a Policy, in the event of a surrender transaction initiated by the policyholder. It functions as follows:
  • On the Application Date, this process identifies the surrender transactions that have been effected at a policy level for funded endowment products, and checks for the existence of funded units for these policies.
  • The funded units are then reduced in proportion to the surrender transaction.
  • The value of the reduced funded units is moved to the suspense bank account maintained for the product, using the same policy transaction number corresponding to the surrender transaction. The value is arrived at using the redemption price for each fund.
LEP - Batch Process to trigger Automatic Surrender
The Batch Process to trigger Automatic Surrender is as follows:
  1. The Batch process first checks the value of Process Automatic Surrender at Product level.
  2. The system fetches the Threshold Policy Market Value, whether Process Automatic Surrender at Product level is correct.
  3. The system identifies all the policies for which market values have gone below the threshold amount.
  4. The system then triggers an automatic surrender transaction with following parameters:
    • Asset allocation with all funds having balances and percentage applied as 100%.
    • Portfolio Surrender flag as True.
    • Payment Mode as Transfer.
    • Payment Type as Product.
LEP - BOD Plan Transaction Generations

Same as LEP – Generate Plan Transactions, except, this is a BOD Process.
LEP – Cash Management Switch Process

This process ensures that the Cash Management Account has sufficient balance to meet all the forthcoming annuity payments as well as the periodic fee redemptions. This can be run either as part of EOD operations or be manually triggered.

It works as follows:
  • The system checks the Cash Management Account Applicability and Redeem Periodic Fee from CMA Fund options maintained at the product level.
  • If both the parameters are applicable,
    • The system computes the Projected Periodic Fee for all the policies under such products (Projected Periodic Fee is the sum of admin and broker periodic fee computed in the last batch run for the policy)
    • The system computes Projected Annuity Payment for all policies where the Cash Management Account fund forms a part of the annuity asset allocations
    • The system computes the Projected Outflow from CMA (Projected Outflow is the sum of Projected Annuity Payment and Projected Periodic Fee)
  • The system then compares the Projected Outflow from CMA with the market value of the Cash Management Account.
  • If the Projected Outflow from CMA is greater than the market value of the CMA, the system switches funds (equal to the Switch Amount) to the Cash Management Account from other policy funds. (Switch Amount is the difference between Projected Outflow from CMA and the Cash Management Account Market Value).

The switch amount is generated proportionately from the available funds and directed into the CMA fund.
LEP – NAV Correction Refer to the topic Process NAV Correction Policy Transaction Reversal for details.

Parent topic: Batch Activities