Approval Matrix

Multi Entity Support: Customers can view the dashboard, perform transfers, or view any request summary and submit requests against the entity associated with the customer during login. The feature is enhanced with Experience APIs to retrieve and post based on the Entity ID of the signed-in user.

• The Entity ID selected by the signed-in user flows through the application through the respective Experience API.
• For all fetch (GET) API calls, the system retrieves the results based on the Entity ID of the signed-in user.
• For all add/update/delete calls, the system passes and posts requests against the Entity ID of the signed-in user.

The feature supports the following modules:

• At the time of company creation, an approval matrix is created automatically and associated with the company.
• Each company can define its own approval matrix.
• The matrix does not specify any approver which implies that all transactions will either be automatically approved (if it is within the user’s pre-approval permission) or denied (if it is above the user’s auto denied limit). If a transaction needs approval and the approver information is not found in the approval matrix, the transactions will be stopped from execution. One approval matrix is associated with a company.
• The approval matrix is built around the approval limits associated with the company and for every feature that the company has given access.
• For all the new accounts that are created under a customer ID and added to the contract, the customer ID level rules apply by default. The newly added accounts show under the respective customer ID to which it is added. Authorized users can change these defaults from the banking application.
• As a financial institution, for new opened accounts, approval rules set up at the Customer ID must be applicable on the new accounts by default. Authorized users may change these defaults from the banking application.
• When a new account is linked to the company, the approval matrix is revised and the information for the linked account is added for every feature that the company has been given access with the default values. By default, no approval rules are set for any feature or any account.
• When accounts are unlinked from a company, the approval matrix is revised and the information for the unlinked account is removed.
• Impact of contract level changes on approval rules. If the company limits are revised by the Financial Institution (FI),
  • FI increases the company limits: The rule setup is designed such that the condition is mandatory and holds good for all values beyond the current limit. So, if the company limits are increased, the rules are already present for the increased range.
  • FI decreases the company limits: The maximum transaction limit of the user is revised based on the role and the revised limits of the company. The old approval matrix holds good. However, if a user tries to revise the approval matrix, the application ensures that appropriate validations are in place.
• Turn Approval Matrix on and off at Customer ID level. An authorized user who has access to edit the Approval Matrix for a certain Customer ID can turn off the approvals entirely for a customer from the online banking application. If the Approval Matrix is disabled for an individual customer within the contract, there are no rules for transactions made on accounts under that Customer ID. This would mean straight-through processing of transfers on accounts associated with this Customer ID without having to query the Approvals Engine. Any monetary or non-monetary feature action transaction that is being made by various users who have access to the Customer ID will undergo straight-through processing and will not be subject to the Approvals Engine. See Configuration for more information.
• Approval Matrix per customer with groups or without groups. An authorized user with the access to edit the approval matrix for a certain Customer ID can specify whether the approval rules for the customer ID to be based on Users or Signatory Groups. See Configuration for more information.
  • If the type is User based, the Approval Matrix for the customer ID will have the rules based on the existing implementation where rules can be specified with approver names.
  • If the type is Signatory Group based, the Approval Matrix for the customer ID will have the rules based on the new approval group based rules.
• Rules for each feature action at a customer ID level: A user with the adequate permissions to Create / Edit Approval Policies can add one or more rules at the Customer ID level for each feature action. A user can specify the following information for a new rule:
  • Range of values for which the rule is applicable.
  • Define a Condition.
    • No Approval Required.
    • Simple condition. A simple condition will have a single condition statement. The number of signatories can be as specified by the user. It must be one or more. A signatory group can be selected from amongst the groups associated with the customer ID for which the policy is being created.
    • Compound condition. Multiple simple conditions working with an AND operator. There is no limit on the number of simple conditions that can be joined. A signatory group once added to one simple condition cannot be reused.
    • Complex condition. Multiple simple or compound conditions working with OR operators between them. There is no limit on the number of simple and compound conditions that can be joined together.
• Straight-through processing (STP): For every transaction initiated, whenever the approval matrix is referred to and there are no approval rules available, this is considered as an error scenario and the transaction is not submitted. However, it is possible that businesses would like to have a range of values for which transactions must not be directly processed. In this case, it must be considered that an approval is not required and process the transaction directly. The application has the provision to disallow rule check for a specific range of values. For this range of values, no approvals are required on transactions and such transactions are subject to straight through processing (STP) and is directly submitted for execution. Note that if the no approvals range is only met for per transaction but fails on the daily or weekly limit, then such transactions are subject to appropriate approvals queue for processing and are not processed in a straight-through manner.
• Straight-through Processing - Alerts for transfers, check book request, and approval flows
  • If the initiator is also the approver of the same transaction, the authorization on transaction is implicitly counted. In such cases, the initiator will not receive an Approver type alert. This applies to Euro payment flows as well. The following are the two scenarios for straight-through processing:
    • There are other approvals required on that particular transaction: In such cases, all the other approvers receive the notification of the request and the initiator who is also an approver, receives only the Initiator type alert.
    • There are no other approvals required on that particular transaction: In such cases, the transaction is directly submitted and neither the approver or the initiator (who are the same) receives any Approver type alerts. An alert that the request has been submitted only is triggered.
• Approval Alert Notification for transaction - transfer, bill payment, wire transfer, ACH collection/payment request, or an ACH file
  • The initiator is notified whenever a transaction is submitted for approval through a Global type of alert. Bank agents can configure the Alerts from Spotlight for this specific event.
  • The initiator receives a Global type of alert whenever an approval is received on a transaction that the initiator has initiated and submitted for approvals. The use case is providing an alert notification to the initiator when a user approves a transaction, but transaction is not submitted for execution. Bank agents can configure the Alerts from Spotlight for this specific event.
  • The initiator receives a Global type of alert whenever a transaction that the initiator has initiated has received the requisite number of approvals and it is submitted for execution. All the approvers receive an alert notification indicating that the transaction that was in their bucket for approval has now been authorized and is submitted for execution. Bank agents can configure the Alerts from Spotlight for this specific event.
  • The initiator receives a Global type of alert whenever a transaction that the initiator has initiated has been rejected by any one of the approvers. Bank agents can configure the Alerts from Spotlight for this specific event.
  • A Global type of alert notification is sent to all the approvers of a specific transaction when the transaction has been rejected by any one of the approvers. The approver who has rejected a transaction, receives an alert indicated that the specific transaction has been rejected.
• Chequebook request flow
  • In the banking application, an authorized user with requisite permissions can raise chequebook requests for own accounts. Currently, the bank can decide at the design-time to turn on an approval process for cheque book requests. When a customer submits a request for a new chequebook, the request is queried in the Approvals Engine to check if approval is required. If approvals are required as defined through “Create Cheque Book Requests” rules in the approval matrix, then after the request is submitted, the user is shown a message that the create chequebook request has now been submitted for approval. The request is processed and after the approval of required approvers, the cheque book request is submitted to the bank.
  • Approvals Engine Handling: The application queries the approvals engine to deduce all the number of approvals required to authorize the request and send an approval request to all authorized approvals as set up in the approval matrix. The straight-through processing scenarios are also taken care where the initiator is also the approver on a particular transaction.
  • Action to support approvals on cheque book requests: The surfacing of the cheque request feature on the application is controlled by mandates. Approvals are added to the Create Cheque Book Request Feature action to provide the privileges of approving Create Cheque Book Requests to identified individuals.
  • See the flow diagram at the Configuration section showing the cheque book request process where multiple approvers are involved and scenarios covering the approval and rejection processes.