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:
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 |
This section contains the following topics:
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.
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.
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.
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.
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:
When a policy is created and authorized, this EOD process performs the following functions:
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)
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.
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 correction will also not support the reversal/correction of policy switch transactions if it is across AMCs, provided there is no allocation lag..
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.
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.
The system facilitates the revaluation of annuity payments on every Anniversary Date, through this BOD process. It works along the following lines:
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.
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.
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.
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.
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.
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.
See Plan Funding Repayment. This will be a BOD Process.
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.
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:
The Batch Process to trigger Automatic Surrender is as follows:
Same as LEP – Generate Plan Transactions, except, this is a BOD 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.