2.9.5 System Validations
This topic provides information on system validations.
Table 2-32 System Validations
| Type of Transaction | System Validation |
|---|---|
| Policy Capture |
If Initial Investment is available within the KYC Redemption Period, then warning message will be displayed, else the conditions specified below should be checked:
|
| Policy Top Up |
If the client is not KYC compliant and Product is KYC applicable, Top Up Investment ≤ KYC Purchase Limit. |
| Policy SI Generation |
No Validation and premium/ annuities would generate irrespective of the KYC checks. |
| Subscription |
If client is not KYC compliant, Subscription Amount ≤ KYC Purchase Limit. |
| Switch |
No Validation |
| Transfer |
This mode will follow Redemption validation for the From Unit Holder and Subscription for the To Unit Holder. |
| Subscription Debit Order Generation |
No Validation |
| Policy surrender |
If Client is KYC compliant, no validation will take place. If Client is not KYC Compliant and Product Level if KYC is applicable, validation is true. If any initial investment is applicable within the KYC Redemption period, the transaction capture is not allowed; else the following conditions will be checked:
|
| Redemption |
Pseudo switch transactions to be ignored for validation Flow of validations: Clients is KYC compliant – No validation Client is not KYC compliant If any Initial Investment (Identified by Transaction Sub Type) is available within the KYC Redemption Period, then a warning message will be displayed, else the conditions specified below should be checked:
|
Example
Let, KYC Purchase Limit = R 50000
KYC Annual Debit Order Limit = R 25000
KYC Redemption Period (In months) = 12
Assuming UH1 is not KYC Compliant and Product OMPR1 is KYC Applicable.
-
Case 1:
User tries to capture policy with initial investment of R 55000 for UH1 in OMPR1 – System would restrict this as it breaches the limit of R 50000
-
Case 2:
User tries to capture initial investment of R 45000 for UH1 in OMPR1 with premium amount as R 2500 per month – System would restrict this as the annualized premium amount i.e. R 2500 * 12 = R 30000 exceeds the KYC Annual Debit Order Limit.
-
Case 3:
UH1 is KYC compliant and below are the transaction details:Table 2-33 Transaction details
Date Transaction Type Product Amount 1/1/2007 Initial Investment OMGR1 45000 1/4/2007 Top Up OMGR1 55000 On 1st Jun 2007 user changes clients name which makes the client KYC Non compliant.
User tries to capture surrender transaction on 1/Sep/2007 for UH1 in OMPR1 for R 40000. This operation would fail as there is a Top Up transaction within the KYC Redemption Period of 12 months that breaches the limit of R 50000.
-
Case 4:
UH1 is KYC compliant and below are the transaction details:Table 2-34 Transaction details
Date Transaction Type Product Amount 1/1/2007 Initial Investment OMGR1 45000 There is a monthly premium starting from 1st Feb 2007 and ending on 1st Feb 2009 for R 3000.
On 1st Jun 2007 user changes clients name which makes the client KYC Non compliant.
User tries to capture surrender transaction on 1/Sep/2007 for UH1 in OMPR1 for R 40000. This operation would fail as there is a policy premium that is captured within the KYC Redemption Period for which annualized amount is R 36000 and this exceeds the KYC Annual Debit Order Limit.
-
Case 5:
UH1 is KYC compliant and below are the transaction details:Table 2-35 Transaction details
Date Transaction Type Product Amount 1/1/2006 Initial Investment OMGR1 45000 There is a monthly premium starting from 1st Feb 2006 and ending on 1st Feb 2009 for R 3000.
On 1st Jun 2007 user changes clients name which makes the client KYC Non compliant.
User tries to capture surrender transaction on 1/Sep/2007 for UH1 in OMPR1 for R 40000. This operation would be allowed as there is no Top Up or Policy Premium captured within the KYC Redemption Period i.e. 1st Sep 2006 onwards.
Basis date for the validations would be transaction date.
Parent topic: Financial Intelligence Centre Act (FICA)