This module will not be further enhanced. Support is limited to defect fixing only.

Introduction to Account Infrastructure

The Account Infrastructure module manages the status of customers or accounts from active to inactive or dormant and vice versa with appropriate posting restrictions being applied automatically. It includes unclaimed account reports.

Click here to understand the terms and abbreviations used in this module.

Account Freezing-Unclaimed Accounts and Posting Restrictions

The Account Freezing-Unclaimed Accounts and Posting Restrictions functionality allow the user to apply posting restrictions at the customer, account, or deposit level and to monitor the statuses of the customer’s account, as the status of an active account can change sequentially when there are no initiated transactions posted in the customer’s account for a specific period.

Banks and government organizations have the authority to place restrictions on the customer or bank accounts. A restricted account may limit or prevent the customer from using certain facilities. Posting restrictions can be applied at the customer, account, or deposit level. There is a provision to impose multiple posting restrictions to customer, account, or deposit level, based on which an override or error messages will be displayed for the posting restrictions. The posting restrictions apply for all transactions affecting the marked customer or accounts, unless it is specifically parameterized to exclude some transactions.

An account will remain active as long as there are qualified activities running on that account. When there aren’t such qualified activities running on the account for a certain period, the account is deemed dormant and there are certain systematic and business processes that need to be carried out on that account. An example of a systematic process is to flag the account as dormant and to generate reports of dormant accounts. An example of a business process is that the bank is trying to get in touch with the customer (as part of the know your customer process), managing or monitoring such dormant accounts for fraudulent activities or closing the account.

There is a need to configure dormancy conditions for Temenos Transact to monitor and automatically move an account into dormancy. The status of an active account can change sequentially when there are no initiated transactions posted in the customer’s account for a specific period, as defined below:

• Dormant: If there are no customer initiated debit transactions for a period of X months.
• Unclaimed: If there are no customer initiated debit transactions for a period of Y years.
• Abandoned: If no there are no customer initiated debit transactions for a period of Z years.

Once the account is activated, the status reverts from dormant to active.

The benefits of this functionality are:

• Post restrictions are placed based on the status of the account respectively.
• The bank users can amend manually the type of posting restrictions at the customer and account level.

The Account Freezing-Unclaimed Accounts and Posting Restrictions functionality covers the following:

• Auto - Update of Dormant or Unclaimed Posting Restriction: When an account is flagged as Dormant or Unclaimed, the appropriate parameterized posting restrictions will be automatically applied on the accounts. There will be separate posting restriction maintained for each status of Dormant and Unclaimed. The Unclaimed accounts can be viewed from the AA.ACCOUNT.DETAILS application, with the Arr For and Amcy Status set as Unclaimed. The same process applies to deposits.
• Auto - Removal of Dormant Posting Restriction: The customer can perform a transaction (debit) on the dormant account through a branch or channel. The status will be changed from active to dormant and only then the posting restrictions will be applied. The same process applies to deposits.
• Reapply Dormant Posting Restriction: The bank can manually set dormant accounts as active. In case there are no further customer initiated debit transactions for a specified number of days, as defined by the bank, the close of business processing reflags the accounts as Dormant (re-dormancy). This is achieved by auto-change of status from active to dormant and auto-update of dormant related posting restriction. The same process applies to deposits.
• Auto-Update of Abandoned Posting Restriction: If the account dormancy status is abandoned, then, the system locates the arrangement from the concat file and removes the unclaimed or dormant posting restriction. The system will update the abandoned posting restriction, by referring to the related value from the parameter file SAACIN.PARAMETER, where the account status is abandoned and the corresponding posting restriction value in the Posting Restriction field . The same process applies to deposits.
• Removal of Dormancy through Manual Reset Activity: The bank user can manually reset the dormant account to active through a new activity. The AA.ARRANGEMENT.ACTIVITY,AA.RESET.DORMANCY.SA new version is created for the manual reset and it is updated for dual authorisation. The enquiry that lists the unauthorised record and the version details are updated.
• Amending Posting Restriction at the Account Level: The system will check if the posting restriction code applied is available in the SAACIN.PARAMETER application. If the request is manual and the posting restriction code is available in the application, then, an error is thrown stating that the automatic posting restriction cannot be applied manually. If the posting restriction code is not available in the application, then, the bank user can update the posting restriction.

Account Statements

This functionality allows banks to provide account statements that include all the relevant information for the transaction types. Each transaction must contain details related to the delivery channel, debit information in case of debit transactions and credit information in case of credit transactions.

New fields are added to the SABASE.CUSTOMER.PARAM application in order to hold the Arabic language code, or the default language code, if the Arabic language code is absent.

The following versions are introduced as part of this functionality:

• The TELLER,CREDIT.CARD.PAYMENT version is introduced for the credit card bill payments, in order to capture the credit card number.
• The TELLER,ATM.CASHDEP version is introduced to facilitate the cash deposit at the ATM through the Teller module.
• The TELLER,ATM.CASHWD version is introduced to capture the cash withdrawal from the ATM through the Teller module.

The account statements issued to customers contains relevant details of the transactions.

The account statement is comprised of:

• The type of transaction.
• The detailed criteria that must be listed in the current account statement for the types of transactions.
• The fields used in the types of transactions that need to be addressed in the customer account statement are defined as mandatory and optional criteria. In the account statement, the description is dynamically changed based on the input from the channels, time, date etc. The statement description is different for different channels.

Teller Functionality-Blotters and Saudi Arabia Specific Reporting

This functionality allows banks to parameterise the cash retention limits, the maximum and the minimum for each branch and its vault, to view the daily balance of the branch with the cash exceeded %, reported to the upper branch limit, and the cash position of a particular teller, in all currencies supported by the teller.

The cash retention limit is available in the LCY currency. The SAACIN.PARAMETER application stores the retention limits and the category codes.

The teller retention limits are configured in the TELLER application. The teller has the possibility to view the daily balance of the branch with the cash exceeded %, reported to the upper branch limit.

The following items have been released as part of this functionality:

• The SAACIN.TELLER.BLOTTER enquiry is used to list the cash position of a particular teller in all currencies supported by the teller along with the transactions of that teller during the day.
• The SAACIN.BRANCH.POSITION enquiry is used to view a list with the branch, teller, and vault and ATM positions.
• The REPORT.LIST enquiry is used to display past date reports based on the value entered by the user in the selection criteria.

Account Opening Rule 5

This functionality allows banks to adhere to the Account Opening Rule (AOR) 5th edition released by the Saudi Arabian Monetary Agency (SAMA), with the new changes about account opening.

New configuration records and products have been released as part of this functionality to allow banks to handle the account opening conditions for various types of accounts in Saudi Arabia and the methods in which the restrictions have been placed.