Pricing Rules

This is used to select a relationship Pricing Arrangement to assign a financial arrangement. The methods available are:

• AUTOMATIC—rules in this Property determine the Pricing plan to apply.
• MANUAL—users can manually override this by assigning a plan manually.
• AUTOMATIC OR MANUAL—Same as automatic, but allows the user to manually override this by assigning a plan manually. In case a manually assigned plan is no longer available during a plan reset, then the arrangement automatically chooses a plan.
• NO.PRICING—No plan is selected and none could be entered manually. Relationship Pricing is not applied to the arrangement.

This is used to select a plan type.

• Automatic—uses the automatic plan in plan selection method. This attribute denotes the type of automatic selection that done.
• Best—uses the best plan based on a single Interest Property. If there is more than one Pricing arrangement with an identical best benefit, the system chooses the one which was established most recently.

If the user selects Best as the type, then it specifies the arrangement Interest Property (For example, Deposit Interest) compares across eligible arrangements to determine the plan to select (whichever is best) among the following rules:

• Credit Interest—Highest rate increase
• Debit Interest—Highest rate decrease

Currently this is available for Interest Properties. If two or more plans are equal then the system automatically chooses the most recent of the Pricing arrangements.

This indicates the frequency in which the plan has to be reassessed, to apply on the financial arrangement from the customers’ current relationship plans.

This provides the option for the system to periodically check if the client is still on the best plan, taking into account any changes that have been made to any of the relationship plans for which the client may be eligible.

It specifies the Activity to trigger a re-selection of the Pricing plan. For example, when a Make Due Activity happens, it triggers a re-selection of the Pricing plan.

Pricing Plans evaluate the rules on a pre-defined frequency. Based on the results, adjust the Pricing on accrual or on billing or the next time.

Program Rules tab

The following screenshots display the set up and rules or Pricing Programs.

The setup is available for limiting the benefits.

Pricing Programs are defined through the AA.PRICING.PROGRAM virtual table. Rules are defined for each Pricing Program and run on specific Periodic attributes on a Source Property.

• When evaluating Pricing rules against associated arrangements there is a need to do this only on arrangements belonging to certain Products.
• The Pricing program rule defined in the Pricing Rule Property Class considers all the related Product of a Bundle or CRA or as determined by custom API during Pricing Rule evaluation.
  • On top of this, this list of multiple arrangements can be further filtered by defining the Products in Filter by Product.

Users can have 3 options to specify when the rule must be evaluated or triggered in Pricing Rules. This is chosen through the Trigger attribute.

For the AA.ACTIVITY.CLASS that has Pricing Rule evaluation released, the Activity Class used for Pricing is stored as to hold the Pre Assessment and Post Assessment Activities. The system triggers the below Activity Class to evaluate the Pricing Rules based on the trigger selected and they are stored in these attributes.

• <<PL>>-PRE.ASSESSMENT-PRICING.RULES
• <<PL>>-POST.ASSESSMENT-PRICING.RULES
• <<PL>>-ACCRUE.ASSESSMENT-PRICING.RULES

  

• Every time when a Primary Activity is triggered, the system finds out if there is a Pre or Post Activity and accordingly triggers this Activity.
• Pre Activity
  • Before building message for current activity, OFS message is built for pre activity defined.
• Post Activity
  • After building message for current activity, OFS message is built for post activity defined
• All these changes are at AAA level, technically at AA.ACTIVITY.MANAGER level.
• The details of benefits that are qualified or disqualified are stored in AA.EVALUATION.DETAILS and this is used for generating TEC events when required.
• Pre, Post and Accrue assessment Activities are the only Activities that update this table.

• Benefits that are calculated are stored in respective Interest, Charge or Periodic Charge Arrangement Condition in separate set of attributes when there is a Pricing benefit. If benefits remain the same after calculation, then it is not recorded.
• When there is a change in arrangement condition like a Rate Change, then the new Arrangement CONDITION retains the benefit that was applied earlier. If there were no benefits offered, then those attributes are not populated.

  

• During calculation of interest or charge or periodic charge, the benefit calculated is on top of system calculated amount.

• When the bank needs to run multiple rules before passing on a Pricing benefit to a customer, this is handled through PRICING.RULE.NAME attribute which can be sub-valued to define multiple rules.
• If multiple rules are defined for a Pricing Benefit, then the value in Logic field decides whether any one rule or all rule must qualify for the Pricing Benefit to be passed on to customer.
  • Or—Any one of the rules needs to be satisfied to get the Pricing benefit.
  • And—All the rules must be satisfied to get the Pricing benefit.

    

For the above setup, Service charge is waived during assessment if any one of the rules is satisfied.

When the bank needs to define tiered Pricing benefit, the user can duplicate the Pricing Benefit attribute along with Pricing Property and Trigger attributes, that is, different Pricing discounts can be defined for the same Pricing benefit based on different rules.

Program Limit

This section orients the user to configure the system with the program limit to apply for top benefits.

The system can be configured to apply top benefits amongst the qualified benefits. This is based on the setup when the program limit is defined but user has not selected any program. Assuming there are 7 benefits defined and 5 of them are qualified. If program limit is set to 3 then top 3 benefits among the 5 qualified benefits are applied.

When there are multiple definitions for the same Pricing benefit, Pricing Property and Trigger combination, they are grouped together as a Pricing Benefit Group and processed together. When processing a Pricing Benefit Group the discount corresponding to the first rule that passes or satisfied is applied.

Within the same Pricing Benefit group, for different Pricing discounts, if the same Periodic attribute is defined then the system runs the Periodic attribute only once and compares it with different rule values.

Stacked or Limited Number of Benefits

When banks need to limit the number of benefits passed on to customer and allow customers to choose the benefits, these scenarios can be configured using the two attributes below in Pricing Rules Property Class.

• If the Program Limit field is not defined, then the benefits are stacked.
• If the Program Limit field is defined and the Selected Program field is specified, then during rule evaluations all the rules that don’t belong to the selected Pricing Program are ignored, that is, the rule is not executed.
  • AA.EVALUATION.DETAILS is updated with rule result as ‘Limited’.
    • The rule that is limited is considered as ‘Failed’.
  • If the whole Pricing benefit is disqualified because none of the rule was limited, then the evaluation result is updated as No Benefit - Limited.
• If the Program Limit field is defined and the Selected Program field is not specified, then during the Pricing Property assessment when applying discounts, the system selects the best beneficial Pricing program to the customer.
  • In a case where the Program Limit and Selected Program fields are blank, then,
  • Arrangement can have all the Benefit Program run for the rules defined. Based on the results, privileges and discounts are given to the arrangement.
  • In a case where the Program Limit field is defined and the Selected Program field is blank, then,
  • Banks can let the front end users or customers choose the Benefit Program they prefer at the arrangement level. Rules for these programs are run in the arrangement. Based on the results, privileges and discounts are given to the arrangement.
  • In a case where the Program Limit field is defined and the Selected Program field is defined:
  • Banks define the Program Limit and the Benefit Program fields at the Product level. Rules for these programs are run in the arrangement. Based on the results, privileges and discounts are given to the arrangement.

Illustration for Storing Rules and Benefits

AA.EVALUATION.DETAILS

• On evaluation of the rule in the arrangement, the system writes the results in the AA. EVALUATION.DETAILS file
• This record stores the following information
  • Arrangement information
  • Activity that triggered evaluation
  • The date when the Activity triggered the evaluation
  • The Program limit field with selected program information
  • The Property evaluation
  • The trigger with pricing benefit
  • The rule with source balance, actual value
  • Result and adjustment or value override or waiver information.

Record storage and reversal process

• The system builds the evaluation details record based on the evaluation process.
• The records built are passed to the AA.EVALUATION.DETAILS table with the AA.EVALUATION.DETAILS API.
• During the deletion or reversal action, system uses the same API to update the AA.EVALUATION.DETAILS table.

The following example displays how AA.EVALUATION.DETAILS are updated. The setup has two pricing rules, Account Pricing and Relationship Pricing. The Customer has chosen one program.

• The Account Pricing program rule evaluates the 5000 USD Minimum Balance rule and Relationship Pricing evaluates the 25000 USD Total Deposits rule.
• There is one benefit which has two rules, but the system has to evaluate only one rule since the customer has not chosen the other program.
• In order to qualify for Minimum Balance discount, one of the rule should pass.
• When customer has not selected Relationship Pricing, corresponding Total Deposits rule of 25000 USD is not evaluated.

Case 1:

• If the customer selected rule has passed then it is updated as Pass and the other rule is updated as Limited,since the customer did not select the rule , that is, the corresponding program.
• Overall benefit is Qualified since the customer selected rule has Passed and only one rule should pass to qualify for the benefit [Logical operand Or]

Case 2:

• If the customer selected rule has failed then it is updated as Fail and the other rule is updated as Limited since customer did not select the rule, that is, the corresponding program.
• Overall benefit is Disqualified since the customer selected rule has failed. Irrespective of logical operand, the benefit is disqualified.

Case 3:

If the customer selected rule has passed then it is updated as Pass and the other rule is updated as Limited since the customer did not select the rule ,that is, the corresponding program.

Overall benefit is No Benefit - Limited because both the rules have to Pass to qualify for the benefit [Logical operand – And]. The other is not evaluated and hence even though customer selected rule has passed , the overall benefit is not given.

The Program Limit attribute in Pricing Rules Property Class allows the banks to limit the number of benefits that can applied to a property.

If the programs have been selected, then only rules belonging to those programs are run. If, however a limit has been set but programs have not been selected, the Pricing Rules calculates the benefits of each individual program and determines the program or programs (within the limit set) which results in the best benefit to the customer.

Assuming there are seven benefits defined for the same pricing property and five of them are qualified. If program limit is set to three, then top three benefits among the five qualified benefits are applied.

• If Program Limit is not defined, then the benefits are stacked.
• If Program Limit is defined and Selected Program is specified, then during rule evaluations all the rules that doesn’t belong to selected Pricing Program are ignored that is, the rule is not executed.
  • AA.EVALUATION.DETAILS is updated with rule result as Limited.
  • The rule that is limited is considered as Failed.
  • If the whole pricing benefit is disqualified because none of the rule was limited, then the evaluation result is updated as No Benefit – Limited.
• If Program Limit is defined and Selected Program is not specified, then during rule the pricing property assessment when applying discounts, the system selects the best beneficial pricing program to the customer for each pricing property.

• Periodic charges is a container of all Charge Properties.
• These Charge Properties can individually have pricing rules defined.
• While calculating periodic charge amount, each of the individual charge honors the pricing rules.
• If there is a pricing rule for the final periodic charge amount, then this is also applied on the final calculated amount.
• Assessment happens for each charge amount and the new benefits are stored in respective charge conditions
• The rule evaluation results are stored in AA.EVALUATION.DETAILS. The different rules can be run for same benefit group, same benefit set and same benefit name. The results are stored different records.

Temenos Transact business events or alerts framework has been integrated with AA evaluation framework to support alerts based on the result of the rule evaluations.

The existing event management system in Temenos Transact allows raising of events and subscriptions to specific alerts. EB Event Type is the connecting point between an event happening in Temenos Transact and the alerts raised. Event Types are defined by Temenos as they are to be triggered through codes.

Evaluations are completely user-defined. The bank users can create event types to the Pricing Name they wish to raise an event for, using the following method:

• The ID of the event type must be specified in the below format
• <AA.EVALUATION.DETAILS*<Pricing Name>>
• Each time when the evaluation specified in pricing name triggers an update in the AA EVALUATION DETAILS record, Temenos Transact raises an event corresponding to it.
• The alert criteria can be narrowed down by setting up evaluation on records having a specific value in a specific attribute (that is, evaluation equals Failed). The bank defines an event which fine-tunes the nature of the event type through TEC Items. It is to these business events to which the users can subscribe.
• After the configuration of the business events, both customers and account officers can subscribe to the events for which they would want to receive alerts.
• When rules are evaluated, the system stores the evaluation results in AA.EVALUATION.DETAILS table.
• AA evaluation process is integrated to the existing Event Management System in Temenos Transact to allow the Customers and Account officers to get alerted of an evaluation result, that is, raise an event whenever AA.EVALUATION.DETAILS table is updated.
• To choose the pricing benefits for which alerts must be generated, the system raises an event only when a record is defined in the EB.EVENT.TYPE table with ID as <AA.EVALUATION.DETAILS*<Pricing Name>>
• For example, if the event types are the only ones configured, then the events are generated only when evaluation results are updated for Pricing Benefits ‘Minimum Balance Discount’.
• Additionally, through TEC.ITEMS, banks define an event with a qualifying criterion that is, the event qualifies for an alert only if this criteria is met.
• The TEC evaluation is done using the AA.EVALUATION.DETAILS record, which will be passed to TEC.
• In case, if multiple pricing benefits are to be evaluated as part of a rule evaluation, the event types corresponding to all the pricing names are generated. When the event type is generated, system trims the AA.EVALUATION.DETAILS record dynamically, so that the record only has the multi-value information corresponding to the event that is evaluated.
• Customers and Account officers subscribe to these events through the existing EB.ALERT.REQUEST application. Only those events that are subscribed by Customer or Account officer is subject to evaluation and if qualified it is handed off to the subscriber specified in TEC.ITEM record. If alerts are processed by an external system, banks create their own custom subscriber in TEC.SUBSCRIBER table with a local routine that hands-off the information to the external system. The arrangement officer must be included in the event to be properly routed by the external system.