Constraint
AA allows backdated processing through its reverse and replay mechanism and there are no restrictions to it. Constraint Property Class allows definition of restriction on backdated activities and alerts the user with an error or override. The restriction is defined at the arrangement level. It indicates the maximum period an arrangement could be backdated along with an error or override message.
Product Lines
The following Product Lines use the Constraint Property Class:
- Accounts
- Asset Finance
- Bundle
- Deposits
- Facility
- Lending
- Relationship Pricing
- Rewards
- Safe Deposit Box
Property Class Type
The Constraint Property Class uses the following Property Class types:
- Dated
- Enable External
- Enable External Financial
- Enabled For Memo
- Tracking
Property Type
The Constraint Bundle Property Class is not associated with any Properties.
Balance Prefix and Suffix
The Constraint Property Class does not hold any balances due to which there is no associated balance prefix.
Attributes
The fields in the Constraint Property Class are used to define different types of periods and the restriction methods. These fields can be set at Product level and can be negotiated at the arrangement level.
Type
The Type field indicates the constraint type. The options allowed are:
- DATE - Indicates a date prior to which back dating is restricted.
- FINANCIAL.YEAR - When this option is chosen, any activity prior to the last year end date is restricted. The last date of the previous financial year is determined by the value stored in the Last Year End field of the COMPANY table pertaining to the arrangement. The financial year frequency is defined in the Financial Year End field.
- INTEREST.PERIOD - Activity is restricted and governed by the Interest period of the arrangement. For example, to restrict any activity past the billing period, this option is used.
- Interest period check is done only for interest properties defined in the payment schedule conditions. If there are multiple interest properties defined in the payment schedule, then the latest interest ending period is considered as the allowed date.
- In case of retail accounts, if Debit and Credit interest are defined in the schedule and capitalisation date is on different frequencies, then the latest interest ending period is checked for restricting backdated activity.
- PERIOD - The user can state a specific period (e.g, 1M, 6M, etc.) to indicate specific periods before which the activity is restricted. The system calculates the allowed date based on the period defined and validates the effective date of the backdated activity.
- RENEWAL - When this option is chosen, any activity prior to the last renewal date is restricted. When an arrangement is set to change product or reset or rollover, then the last renewal date gets updated in AA.ACCOUNT.DETAILS. If the backdated activity is prior to this date, then it can be restricted.
- STATEMENT.PERIOD - Constraint is based on when the statement was last generated for this account. If multiple statements are generated (including special ones), then the latest statement date is taken and any date prior to that gets restricted.
Period
The Period field indicates the actual period of constraint and allows the user to enter a valid numerical value or a period allowed based on the option selected in the Type field. The options are:
- If Type is STATEMENT.PERIOD, DATE, FINANCIAL.YEAR, or RENEWAL, then no input is allowed in this field.
- If Type is INTEREST.PERIOD, then a numeric value is allowed in this field (for example, no backdating prior to three interest periods). If nothing is stated, system allows any backdating prior to current interest period by default.
- If Type is PERIOD, then a valid IN2PERIOD value should be stated in this field. The field is mandatory with this option.
- If Type is NULL, then the Period field cannot be updated.
Date
The Date field indicates a hard date prior to which backdating is restricted. The field may be used when the user wants to restrict backdating from a specific date. This field is allowed only if DATE option is selected in the Type field.
Detail
The Detail field indicates further details to support the value selected from the Type field. This is to be used only when the Type field has the value INTEREST.PERIOD.
If INTEREST.PERIOD is selected, then a valid Interest property with associated billing consideration needs to be stated here. If the Property Type is set as Accrue by Bills for Penalty Interest Property, then the interest property is not allowed in the Detail field.
Function
The Function field indicates the type of activity function for which the constraint restrictions need to be applied. This field is not allowed for input if the Type field in the corresponding multivalue set is NULL. The options available for this field are:
- INPUT- The restrictions are applied only if current activity is Input of new transaction.
- REVERSE - The restrictions are applied only if current activity is reversal of an authorized transaction.
- NULL- The restrictions are applied to any activity irrespective of action.
Result
The Result field indicates the outcome of the restriction. This field is mandatory only when the Type field is chosen. The options are:
- ERROR - Any violation of constraint results in an error and stops the activity.
- OVERRIDE - Any violation of constraint results in override and requires approval to proceed with the activity. The override could be converted to an error if need be in OVERRIDE application.
Error Message
The Error Message field is used to differentiate one error from other when the different options are chosen from the Type field. If the option selected from the Result field is Error, then a user defined EB.ERROR may be stated in theError Message field. If no message is stated, a default generic error message from AA.CONSTRAINT.VIOLATED is used.
Override Message
The Override Message field is used to differentiate one error from other when the different options are chosen from the Type field. If the option selected from the Result field is Override, then a user defined override message may be stated here. If no message is stated, a default generic override message from AA.CONSTRAINT.VIOLATED is used.
Back Value Dated Activity
Whenever a backdated activity is performed, the system does the following:
- Checks the restriction period defined in the Constraint Property Conditions, calculates the maximum back value date that is allowed and compares the current Activity effective with the allowed date. If the effective date of the activity is prior to the allowed date, then the restriction type defined is triggered.
- Depending on the type of restriction, the users might be allowed or restricted to proceed with the back dated activity.
- During COB, if backdated activities are triggered (due to basic rate change or Periodic rate change done backdated) instead of allowing the system to put the record on Hold, the following actions happen:
- Evaluates if the transaction could be triggered by AA.EVALUATE.CONSTRAINT for “backdated service dates only”.
- If the backdating activity could be allowed that is, No error), then the activity could be triggered normally.
- If the backdating evaluation fails (Error constraint), COMO is recorded, indicating that the process is skipped due to constraint failure with details of error message and skips the backdating of rate change.
- Controls can be either on reversal of old transaction or posting of new transaction with back value date.
- Constraints can be setup to completely reject the back value dated activity or to accept them with suitable override messages. It is possible to exclude some specific activities from having Constraints.
- Exclude Activity field of AA.ACTIVITY is used to exempt that particular activity from the constraints evaluation. The options are:
- YES - The system exempts the specific activity from constraints evaluation.
- NULL - The system performs the constraints check for that activity, as usual.
- Exclude Activity field of AA.ACTIVITY is used to exempt that particular activity from the constraints evaluation. The options are:
Multiple Constraints
The multivalue fields can be used to specify multiple constraints in addition to the hard date. AA processing enforces backdating constraint based on the most restrictive constraint defined.
In case of multiple constraints defined with different values in the Result fields, the constraints with RESULT defined as Error take precedence over the constraints with RESULT defined as Override.
In the above definition, the Error related constraints based on Period and Financial Year are evaluated first.
- If one of the two constraints is violated, error message pertaining to that constraint is displayed.
- If more than one constraint is violated, error message pertaining to the most restrictive constraint is displayed.
If none of the Error related constraints are breached then the constraints based on Interest and Statement period are processed.
- If one of the two constraints is violated, then override message pertaining to that constraint is displayed.
- If more than one constraint is violated, then override messages pertaining to all the violated constraints are presented.
Illustration
- A personal loan arrangement is created, which has the constraint property restricting the back dating activity based on period.
- The constraint period is changed to 3D and Result is given as Override. The effective date is 27 March 2013. A user could do a back dated activity 3 days prior to this date. If it goes beyond 3 days, then an override message is displayed.
- As the activity is triggered prior to 5 days of the effective date, the system triggers the override message for breaking the restricted backdated activity of 3 days.
Scenario 1: Multiple Constraints with Override
Two different overrides (pertaining to two different constraint types) that are displayed by the system, when a back value dated activity (new arrangement activity in this case) is being attempted by the user, are given below.
Current Date: 17 Apr 2017
Arrangement Effective Date: 28 Dec 2016
Financial Year End (for the related Company record in Company table): 31 Dec 2016
- The first override displayed pertains to the constraint type – ‘Period’ (90D or 90 days). The number of days between the above mentioned current date (17 Apr 2017) and the activity effective date (28 Dec 2016) is 110 days which is over and above the 90 days constraint that is set. The below override is displayed to the user:Activity should not be backdated past the ‘PERIOD’ constraint.
- The second override displayed pertains to the constraint type – ‘Financial Year’ (Current Financial Year, since Period field is left blank). The below override is displayed to the user:Activity should not be backdated past the ‘FINANCIAL.YEAR’ constraint.
Scenario 2a: Multiple Constraints with Error
Consider that the two constraints as mentioned in Scenario 1 are configured with the Result ‘Error’.
When the user tries to create a new arrangement, the system displays the most restrictive constraint that is the period constraint of 90 days when the Effective date is entered as 17 Apr 2016. The below error is displayed to the user:
Scenario 2b: Multiple Constraints with Error
Consider the Period constraint = 180 days and the two constraints as mentioned in Scenario 1 are configured with the Result ‘Error’.
The more restrictive of the two constraints in this case is the ‘Financial Year’ constraint and hence the system displays the related error message. The below error is displayed to the user:
Add Constraint Property to Existing Arrangements
The financial institutions can add the Constraint property to the existing arrangements of the Accounts, Deposits, Lending, and Multi-Currency Accounts product lines using the Add New Property, New Prop Avl, and New Prop Avl Date fields in AA.PRODUCT.MANAGER.
Read Add New Property for more information on the configuration.
Periodic Attribute Classes
There are no periodic attribute classes associated with Constraint Property Class.
Actions
The Constraint Property Class supports the following actions:
| Action Name | Description |
|---|---|
| UPDATE | The Constraint Property Class only has UPDATE action for it to record the definition. The CONSTRAINT>UPDATE action is available for the below Product Lines: Accounts, Deposits, Lending, Bundle, Facility, Relationship Pricing, Rewards and Safe Depost Box. |
Accounting Events
The Constraint Property Class does not perform any actions that generate accounting events.
Limits Interaction
The Constraint Property Class does not perform any actions that impact the limits system.
In this topic