11. Batch Activities

For the purpose of processing transactions in the LEP products, the system provides a number of processes that must be initiated by the user during either the End of Day Processes (EOD) or Beginning of Day Processes (BOD). These processes and their functioning are explained below.

This chapter contains the following sections:

11.1 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.

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

11.2 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.

11.3 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 transac­tions at the fund level. If not, the generation is aborted for all underlying transactions for that policy.

11.4 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.

11.5 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.

11.6 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:

11.7 LEP - Plan Annuity 5/20 Validation Process

When a policy is created and authorized, this EOD process performs the following functions:

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 ‘Ex­clusive’ 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)

11.8 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:

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.

11.9 LEP – NAV Correction

This section contains the following topics:

11.9.1 Invoking NAV Correction Policy Transaction Reversal Screen

When an NAV correction is made, the system reverses all relevant policy transactions and generates new transactions. If the original transaction has been allocated, the new transaction will also be allocated. This will be an EOD Batch Process.

You have the option of executing this process manually, through the ‘NAV Correction Policy Transaction Reversal’ screen. You can invoke this screen by typing ‘UTDPLREV’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

This helps when you want to allocate transactions that have undergone NAV correction, prior to the EOD Batch Process.

Click ‘Execute’ button to execute the process online. Click ‘Submit’ button to submit a job for the same.

Note

NAV Correction does not support the correction of an initial investment if the transaction has been allotted or if any underlying policy transactions have been generated. NAV cor­rection will also not support the reversal/correction of policy switch transactions if it is across AMCs, provided there is no allocation lag..

11.10 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.

11.11 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.

11.12 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.

11.13 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.

11.14 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.

11.15 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.

11.16 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.

11.17 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.

11.18 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.

11.19 LEP - Plan Funding Repayment

See Plan Funding Repayment. This will be a BOD Process.

11.20 LEP - Generate Plan Redemption Transactions for Pe­riodic 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.

11.21 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:

11.22 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.

11.23 LEP - BOD Plan Transaction Generations

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

11.24 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 switch amount is generated proportionately from the available funds and directed into the CMA fund.