Activity Restriction

• The user can specify either an Activity Class or Activity
  • To be unconditionally restricted or
  • When one or more rules to be evaluated.
• For rules based restriction, the user can specify what should happen when the rule is not satisfied, such as,
  • Override and optionally a Charge or
  • Error

  

  Attribute	Definition
  Activity Class	It allows the user to designate an Activity Class for rule evaluation. When multiple Activity Classes are designated, the rule is evaluated against each Activity Class. It is mutually exclusive with Activity.
  Activity ID	It allows the user to designate an Activity for rule evaluation. It is mutually exclusive with Activity Class.
  Restrict (Y/N)	It allows the user to designate if the Activity Class or Activity has to be restricted unconditionally. The value Yes indicates the Activity Class or Activity has to be restricted.
  Rule ID	It allows the user to designate the rule previously defined in the Rules tab. It is mutually exclusive with the Run Rule Set attribute.
  Run Rule Set	It allows the user to designate the rule previously defined in the Rules Set tab. It is mutually exclusive with the Run Rule attribute and is only allowed for product qualifier type of rules. Read Product Qualifier Rules for more information.
  Restrict Type	This indicates that the result of rule evaluation can be a complete restriction or a partial restriction that is applied using error or override, respectively.
  Override ID	If the transaction is to be allowed after displaying a warning, then the user can state an override message here which appears whenever this activity is triggered on an arrangement. Entry into this attribute is mandatory only when Restrict Type is set to ‘Override’.
  Error Message	If the transaction is completely blocked, the user can state an error message displaying the restriction. Entry into this attribute is mandatory only when Restrict Type is set to ‘Error’.
  Payment Type	When a rule break charge is set to capitalise and account does not have sufficient balance to capitalise the charge, the bank can choose to invoice the pending amount to the customer using the ‘Cap and Inv’ payment method. It is possible to set recycling conditions to retry capitalising these charges using RC Type and RC Condition in the Settlement Condition. It has to be a valid Payment Type record with Alt Payment Method field set as ‘Cap and Inv’. Read the Invoicing Charges that Cannot Be Captialised Due to Insufficient Funds user guide in the Charge Property Class user guide for more information.
  Charge	It defines Charge Property that calculates charge amount when a rule is broken.
  App Method	It indicates the Charge Application method namely Due - Rule break charges are made due. Capitalise - Rule break charges are capitalised. Pay- Rule break charges are paid to the customer. Defer- Rule break charges are calculated but not applied immediately. Charges are deferred and are collected over a period. The user can collect these deferred charges using the Payment Schedule and Periodic Charges Property Classes. Adjust – In case of partial or full withdrawal in a term deposit, it allows the break cost fee to be adjusted against accrued interest if break cost fee is less than accrued interest. If break cost fee is more than accrued interest, break cost fee is adjusted against to the extent of accrued interest (credit balance) and the remaining break cost fee makes the interest accrual to become overdrawn (negative). Adjust cap – In case of partial or full withdrawal in a term deposit, this option allows the break cost fee to be adjusted against accrued interest, if it is less than the accrued interest. If the break cost fee is more than accrued interest, it allows the break cost fee to capitalise against the principal after adjusting to the extent of accrued interest. Charges cannot be deferred if the Property is set as REBATE.UNAMORTISED.
  Application Period	It is used to indicate defer period for the rule break charges.

• The user can specify the Interest or Charge Property for which one or more rules have to be evaluated.
• They can specify if the rule has to be satisfied or broken, and depending on the result, the property has to be applied or waived.
• In the below screenshot, there are two rules to be focused, Total Debits (not more than 6) and Cash Withdrawals (not more than 3).

  

• In the below screenshot, whenever CRINTEREST Property is assessed, if either of the rules is broken, system waives the CRINTEREST.

  

Multiple Rule Sets could be evaluated for an event.

• The evaluation details for all the rule sets are logged but the result of the first qualified rule set will be respected by the system.
• For example, if three rule sets are evaluated, then each set is evaluated as follows:

• Now, for an arrangement event, Rule Set 2 and Rule Set 3 are set as Pass.
• Evaluation details for all the three rule sets are logged in AA.EVALUATION.DETAILS record.
• Only the Action associated with Result 2 is executed.

• The user can either specify an Activity Class or a specific activity for one or more Rule Sets to be evaluated.
• Read Activity-Based Rule Evaluation for more information.
• Run Rule Set attribute: During Proof and Publish of the Product, the system validates any input in this attribute to see if the associated property is of Product Qualifier Type.

  

• The flow of activity-based Product Qualifier Rules is explained in the above flowchart. On occurrence of specific activity, the system can be set to evaluate a Rule or Rule Set and based on the Evaluation Result, the result can raise an event to another arrangement or to perform an activity in the arrangement.
• In this example, when a participant is closed in a Bundle, the Rule Set evaluates the specification of the presence of one current account, one payroll account and one savings account. If the Evaluation Result field has the value Fail, the system has to trigger closure of the bundle arrangement.

• This tab allows the user to define the frequency at which the rules sets are evaluated.
• The user can either specify a frequency for one or more rules to be evaluated.
• The frequency follows standard Temenos Transact recurrence format.

  

• The above flowchart display the flow of Frequency-Based Product Qualifier rules. On a periodic basis, the system can be set to evaluate a Rule or Rule Set, and based on the Evaluation Result, the result can raise an event to another arrangement or perform an activity in the arrangement.
• In this example, on a periodic basis, the Rule Set evaluates the specification of Payroll or Pension or External Source Income credit. If the Evaluation Result field is set as Fail, the system has to trigger a Change Product in the Payroll Account.

AA.ACTION defines the activity that has to be triggered as part of rule evaluation’s decision making.

• The valid activities that can be triggered are as follows:
  • ACCOUNTS-CHANGE.PRODUCT-ARRANGEMENT
  • BUNDLE-CLOSE-ARRANGEMENT
  • ACCOUNTS-RECORD.EVENT-ARRANGEMENT
  • BUNDLE-RECORD.EVENT-ARRANGEMENT
  • ACCOUNTS-AUTO.SETTLE-ARRANGEMENT
  • ACCOUNTS-AUTO.CLOSE-ARRANGEMENT
  • DEPOSITS-AUTO.CLOSE-ARRANGEMENT
  • ACCOUNTS-SETTLE-PAYOFF
  • DEPOSITS-REDEEM-ARRANGEMENT
• When Change Product activity is indicated in the Activity attribute, the Product (to be changed to) is mandatory. Otherwise, this is a no-input attribute.

In this illustration, ,consider Bundle product such as Saving Package that has two participant arrangements, a Payroll account and a Welcome Savings account.

In this Bundle, when the user triggers the activity to change to the Product of one of the arrangement, say Welcome Savings account to Savings product or close the arrangement, the system records an activity to indicate the event of participant arrangement product Changed or Closure, respectively. This activity triggers Rule Set 1 and Rule Set 2.

Rule Set 1 and Rule Set 2 evaluates the Bundle Participants. The system verifies if there is at least one Payroll or Current account, at least one Preference Savings or Welcome Savings account for Rule Set 1 and Rule Set 2, respectively.

In this illustration, when the Welcome Savings account is closed or is changed to a Savings Product, Rule Set 2 fails, which results in Decision.1 to dissolve the Bundle (BUNDLE-CLOSE-ARRANGEMENT).

The Participant arrangement namely Preferred Savings Account is closed:

When the rule is satisfied, system triggers closure of the Bundle arrangement to complete the Decision 1 namely PQ.DISSOLVE.BUNDLE.

The above screenshot displays that the Participant Closed activity triggers the Bundle Close activity.

The below screenshot displays the results of the Product Qualifier rule.

The below screenshot displays that the Rule Name attribute with 1 preferred welcome ac value has an evaluation result ‘Fail’, that is when the system evaluates minimum number of participant arrangements either as Preferred or Welcome Savings account, the rule fails.

The below screenshot displays the corresponding AA.EVALAUTION.DETAILS record.

In this illustration, consider a Savings Package with Participant Arrangements as Payroll account and Welcome Savings account. In the Savings Package Bundle, the user triggers the activity to change to the product of the Welcome Savings account to Savings Product. The Savings account is not a valid product to be a part of the Bundle as per Product Bundle setup, hence the system displays an error message as displayed below.

When the user tries to change the Welcome Savings account to Preferred Savings account, the system allows the same as it satisfies the product qualifier evaluation.

The Rule Set tab under Activity Restriction Property Class is used to setup Product Qualifier Rules.

It allows the user to combine single or multiple rules for evaluation. Each rule set is tied with a result, which is executed by the system based on the evaluation criteria. The evaluation of the Product Qualifier is based on either activity or frequency. The evaluation result can direct to an Action in the account namely ACCOUNTS-CHANGE.PRODUCT-ARRANGEMENT or ACCOUNTS-RECORD.EVENT-ARRANGEMENT

A Product Qualifier rule can be triggered either periodically or based on an activity. The result of the qualifier rule performs an Action or raises an Event.

In the below screenshot, the Product Qualifier rule is defined to trigger a change Product Activity (Current A/C into a Payroll A/C) when an arrangement receives an eligible (salary or pension) credit, that is, more than 900 USD. The system evaluates the rule periodically (say every three days).

Rules Set

Product Qualifier rules set in an account are aimed at assessing the validity of the account against the pre-requisites. The failure of the rules results in Change Product or recording the Event.

Consider Current Account is converted to Payroll Account as part of Product Qualifier evaluation.

Day 1

A new current account is created.

Activity is scheduled for Product Qualifier rule evaluation.The periodic review of Product Qualifier Rules activity is scheduled.

Account has a Pension Credit.Pension is credited to the account. This is a qualified activity for the Periodic Rule.

Day 4

At the end of 3 days, the system completed the periodic review of Qualifier rulesand converted the account to a payroll account. The details are recorded under Qualifier Details section in Account Overview screen.

The Qualifier Rules is displayed below.

The Qualifier Details are shown below.

Account is moved to Payroll Account

Let us consider a DORMANCY condition as follows:

When the dormancy activity is run for Closeready or Unclaimed status, the product qualifiers are triggered for the below rules.

Rules Definitions

• When the arrangement is inactive for 3 years and 7 months, the system triggers the dormancy activity for Closeready status.
• When the arrangement is inactive for 4 years, the system triggers the dormancy activity for unclaimed status.
• When the respective activity is triggered for dormancy, the system is configured to run the corresponding Rule Set.

The Rule Set field with Close Ready Notice value evaluates the rule for Notice Fee, which verifies if account has sufficient balance for triggering the Activity.

The system triggers Decision 1, which is to send the notice for dormancy.

When the system triggers Unclaimed status activity, the Rule set Unclaimed Notice evaluates rule for account balance not in debit, no posting restriction and no locked funds in account. When the conditions are satisfied, the system triggers Decision 2, which is Close the dormant account.

Periodic Attributes Used

Rules are defined based on a Periodic Attribute with a Rule Name for each Rule and are user defined. The Periodic Attribute Classes are:

• POSTING.RESTRICT - Identify the posting restrict if any on the account or deposit which would restrict auto balance transfer and closure.
• LOCKED.AMOUNT - Gets the locked amount from the account to identify if the account or deposit can be considered for auto account closure.

ACTION for the Rules

The activity classes ACCOUNTS-AUTO.SETTLE-ARRANGEMENT and ACCOUNTS-AUTO.CLOSE-ARRANGEMENT are used to capitalize the current period interest and charge accruals to the account and to move the Dormant Account balances to an Internal Account, respectively.

This is the activity that is configured in AA.ACTION called CLOSE.DORMANT.ACCOUNT. This action would trigger the ACCOUNTS-AUTO.CLOSE-ARRANGEMENT as Secondary Activity.

• AA.ACTION defines the Activity that has to be triggered as part of rule evaluation’s decision making.
• The valid Activities that can be given for Auto close dormant accounts are:
  • ACCOUNTS-AUTO.SETTLE-ARRANGEMENT
  • ACCOUNTS-AUTO.CLOSE-ARRANGEMENT
  • DEPOSITS-AUTO.CLOSE-ARRANGEMENT

Events and Allocation Rules

AC.EVENTS are released to allow the configuration of Internal Accounts in Allocation Rules for auto balance transfer from accounts.

• ACCOUNT-DR.MOVEMENT-DUE-DORMANCY*CLOSE: This AC.EVENT is used to debit the Account for auto balance transfer and credit the Internal Account. The ACCOUNT.CLASS U-AAWOF is the Internal Account key for which the accounting credit entry is raised.

  

• ACCOUNT-MOVE.BALANCE-PAY-DORMANCY*CLOSE: This AC.EVENT is used to debit the Deposit for auto balance transfer and credit the Internal Account. The ACCOUNT.CLASS U-AAWOF is the Internal Account key for which the accounting credit entry is raised.

  

• Similarly, the events has been defined for Charges, Interests and the Periodic charges.
  • CHARGE-MOVE.BALANCE-PAY-DORMANCY*CLOSE
  • INTEREST-MOVE.BALANCE-PAY-DORMANCY*CLOSE
  • PERIODIC.CHARGES-MOVE.BALANCE-PAY-DORMANCY*CLOSE
  

• A Product Qualifier rule can be triggered either periodically or based on an activity to perform an action or raise an event.
• The below example shows the product Qualifier rule defined to trigger a change Product activity (Current account to a Payroll account) when an arrangement receives an eligible (salary or pension) credit more than 900 USD. The system periodically (say every three days) evaluates this rule as per the given frequency till the arrangement is in current status (since the No of Cycles field is left blank).

• A current account AA18107GSZHM was created on 17 April 2018.

  

• The account received a pension credit (eligible transaction to trigger change Product Activity) of 1,000 USD on 18 April 2018.

  

• The qualifier rule was run on 20 April 2018. The rule (pension credit of 1,000 USD in Current account) was satisfied to change the product from Current to Payroll account.
• These results are recorded in AA.EVALUATION.DETAILS and can be accessed from arrangement overview.

  

• The below screenshot displays the activity executed for the evaluation date in the AA.ACIVITY.HISTORY record.
  
• The below screenshot displays the convertion of arrangement AA18107GSZHM into a Payroll account.

  

• The evaluation results are stored in the AA.EVALUATION.DETAILS table.

  

• Evaluation Detail stores the Product Qualifier evaluation details in the following set of attributes:
  • PQ.RULE.SET
  • PQ.RULE.EXPRESSION
  • PQ.RULE.NAME
  • PQ.PERIODIC.ATTRIBUTE,
  • PQ.SOURCE
  • PQ.FILTER.BY.PRODUCT
  • PQ.PERIODIC.VALUE
  • PQ.ACTUAL.VALUE
  • PQ.RULE.EVALUATION.RESULT
  • PQ.RULE.SET.EVALUATION.RESULT
  • PQ.DEFINED.EVALUATION.RESULT
  • PQ.DEFAULT.RESULT
  • PQ.RULE.SET.TRIGGER
  The Product Qualifier attributes are different set, independent of the Pricing set of attributes.
• In the below screenshot, we have Payroll Credit or Pension Plan Credit that is expected to Pass. We have Payroll Credit Passing and Pension Plan Failing, the operand being OR the overall result is Pass, against the defined evaluation result is Fail (meaning the action is taken on Failing).