Dormancy

Dormancy is an optional Property Class.

• This can be set to Tracking at the Product Level so that it cannot be negotiated at an individual arrangement level.
• This Dormancy Processing functionality does not respect the company level setting, if the Product Condition is available for a particular Product.
• The definition of Account Dormancy is absence of any Customer Initiated Transaction or Activity on the account, for a certain period, where the period can vary according to local regulations or a bank’s own internal policy. This same reasoning is extensible for Loans, Deposits and Safety Deposit Boxes as well.

  

The below attributes allow the user to define different stages of inactivity and their conditions.

Status

It is soft-coded using EB Lookup (AA.DORMANCY.STATUS).

Period

It is the period of inactivity when the account reaches the corresponding status.

• It accepts the period in months, days or years
• Subsequent periods are periods since the last dormant Status date

Auto Reset

It is to enable automatic reset of the dormancy status of an account.

When an account is in dormancy status, while initiating any financial transaction (assume a qualifying dormancy auto reset), the system raises an override highlighting that the account can be reset to normal active status. If the transaction qualifies as an activity for dormancy auto reset, it has to be set at account status level.

Notice Days

It indicates the number of days that the system requires, after reaching the corresponding status, for generating an Advice.

Frequency

It is the frequency in which Chasers need to be sent out, so long as the account remains in the corresponding status.

Charge Frequency

It defines the periodicity in which charges for Dormancy are collected from the arrangement. This charge is collected as long as it remains in this Dormancy status.

If the Frequency is not specified, there is no periodic charge collection defined for the corresponding Dormancy status.

Cdm Handoff

This field indicates that the system should hand-off to CDM the Dormancy Status (as DORMANT or Null) along with the Dormancy Date and Last Activity Date of the arrangement.

This field indicates if the dormancy status must be handed off to Customer Dormancy Monitor (CDM) when the arrangement reaches that specific dormancy status. This field can be set for one of the dormancy statuses which has to be considered for the customer level dormancy processing. The system hands-off the values in Dormancy Date and the Last Activity Date stored in AA.ACCOUNT.DETAILS of the arrangement.

When the condition doesn’t have a CDM handoff configured for any of their statuses, then the very first status of dormancy condition is considered for the CDM handoff.

Once a CDM handoff triggered for an arrangement, the CDM requests for the details of the other arrangements held by this particular customer.

The CDM system evaluates the dormancy status of the customer based on this information and marks the customer as dormant if all the related accounts and contracts (within Transact including AA framework and outside Transact) are already dormant.

During this evaluation of other arrangements of the same customer in the AA framework, when the dormancy status of an arrangement in AA:

• Has already reached the status indicated for the CDM handoff - The arrangement details are handed off as Dormant to the CDM system.
• Has not reached the status indicated for the CDM handoff - The arrangement details are handed off as Not Dormant to the CDM system.

When the arrangement doesn’t have a CDM handoff, then the very first status of dormancy condition is considered for the CDM handoff.

• The user can specify a Rule (Temenos Transact Rules Engine) or an API (jBC Subroutine) that the system calls to setting a Dormancy status in an arrangement.
  • It is possible to attach more than 1 Rule or API per status and it is also possible to attach both a Rule and an API to the same status.
  • When there is more than one Rule or API attached, the system invokes both of them and respects the most restrictive answers of them.
  If the Rule did not return No but the API did, then the API’s answer is respected. If the Rule returned No but the API did not, then the Rule’s answer is respected.
  Exception Rule or API validation is applicable for both when automatically setting a certain Dormancy status and when the user tries to manually set an account to be dormant.
• During automatic processing, if the Dormancy Rule or the API returns No, then the system is able to log this information with details of the validations and the results (in this case, it is a failure and that reason is recorded).
  • It schedules the next ‘Check for Dormancy’ as Current Temenos Transact Date + Dormancy Period.
• During manual Set Dormancy, if the Dormancy Rule or the API returns No, then any message supplied by the Rule or API returns an override back to the user.
  • The system raises a standard override message stating, Dormancy Exception Rules Failed.
  • This override can be configured as an error to meet the bank’s requirements.

• There is a facility to define which of the AA Activities are qualified as Last Activity for Dormancy purposes.
  • If these Activities have been executed on the arrangement, then the arrangement is considered as Active for Dormancy purposes.
• AA Activities can be identified at the below hierarchical levels:
  • Initiation Type (highest level)
    • User—Update Officer Activity
    • Transaction—Cash Deposit or Withdrawal
    For all Transaction type Activities (unless Dormancy configuration is at the individual activity level), the system still looks at the Initiation in the corresponding TRANSACTION to cross-check against Dormancy configuration.
  • Activity Classes are released by Temenos, with purpose built actions or business logic.
  • Activities:
    • Each Activity belongs to one Activity Class.
    • There is at least one Activity for each Activity Class, automatically created by the system.
    • However, any number of Activities can be configurable under a given Activity Class.
    • Such Activities are created under the same Activity Class to differentiate the operations for purposes of Activity Restrictions, Activity Charges, Scheduled Charges based on Activities and Activity narrative. Within a transaction, there is a classification such as customer, bank and auto.
• A set of associated multivalue attributes is used to configure Initiation Type, Class or individual Activity have to be included or excluded from considering as a qualified Activity.
  • The Type of Activity that could be considered as a qualified activity for Dormancy Processing is indicated at the top level.
  • Within that Activity type, if there is only a sub-set of Activity Classes that have to be respected, then they are explicitly specified.
  • Alternately, the user can specify the Activity Classes that have to be excluded.
  • Within the excluded or included Activity Classes, if there are individual Activities that have to be included or excluded, they can be explicitly specified.
  • The column ‘Include or Exclude’ specifies if Activity, Class or Type is qualified to keep an Arrangement from becoming Inactive.
  • Whenever there is a conflict, the order of precedence is bottom up sequencing.
    • Include or exclude definition of the specific Activities takes the top precedence, followed by the Activity Class level definition and then the Activity Type level definition.
      A definition such as ‘Exclude User Initiation Type’ + ‘Include Accounts-Update-Customer Activity Class’ means that all User Activity types are excluded except the Activities under the ‘Accounts-Update-Customer’ class.
• This illustration displays certain control values in Dormancy Property Class for configuration of the Activities that have to be considered as qualified for Dormancy Processing.

  

• The setup above results in the following Activities being qualified as Last Activity for Dormancy processing.
  • Exclude all User Type Activities
    • Include any Activity of Class, such as ACCOUNTS-UPDATE-CUSTOMER, ACCOUNTS-CHANGE-SCHEDULE and ACCOUNTS-CHANGE.PRIMARY-ARRANGEMENT
    • Include Specific Activities, such as ACCOUNTS-PRINT.STATEMENT, ACCOUNTS-LOCK.FUNDS and ACCOUNTS-PAYMENT.STOP
  • Include all Transaction Type Activities initiated by Customer
    • Exclude ACCOUNTS-DEPLIQ (of ACCOUNTS-CREDIT-ARRANGEMENT Class)
    • Exclude all ACCOUNTS-DEBIT-ARRANGEMENT Class but include ACCOUNTS-ATM.WDRAW as a Qualified Activity.
    • Except any Activity of the Activity Classes, such as ACCOUNTS-CREDIT.SETTLE and ACCOUNTS-DEBIT.SETTLE

• Any TRANSACTION in Temenos Transact has three Initiation types (for financial transactions)—Auto, Bank and Customer.
• The Initiation Type attribute in Dormancy condition allows four values—User (for Non-Financial Activities), Customer, Auto and Bank.
  • When a financial transaction happens, the system looks up for the Initiation in the underlying TRANSACTION and stores it in AA.ACTIVITY.HISTORY, along with other details such as the Effective date, etc. When the system has to determine the last qualifying activity date, it cross-checks the Initiation type associated with each of those Activities against the Initiation Type setup of Dormancy Condition.
  • Currently, only those transactions done by the user on customer’s request are marked as CUSTOMER initiated.
• The difference between the four values is shown below:
  • User—Used for non-financial changes such as customer address change, etc.
  • Customer—Used for transactions that can be done by the user on customer’s request.
  • Auto—Used for the transactions done by the system such as accruals, etc.
  • Bank—Used for the transactions that are done by the bank without going back to customer such as specific charge recovery, etc.
• Auto Reset defines if the qualifying Initiation Type, Activity Class or Activity is eligible for auto resetting dormancy. Dormancy auto reset configuration function is applicable only for the account status that are allowed for auto reset, that is, Dormancy auto reset function is triggered only for the account statuses, where the Auto Reset Attribute is set as YES.
  • The qualifying activity for dormancy processing or dormancy auto reset could be either a financial or a non-financial Activity.