14. MAKER/ CHECKER FUNCTIONALITIES Section
Section Description
Page
14.01
Transaction Flow
328
14.02
Cash Transactions
333
14.03
Supervisory Override
344
14. MAKER/ CHECKER FUNCTIONALITIES The function of Maker/ Checker is very obvious to bankers. It is a method of internal check. Maker means the Teller who is entering the transaction viz. Single Window Operator, Senior Assistant etc. Checker is the person authorizing the transaction e.g. Cash Officer, Accountant, Passing Officer, Field Officer, etc. 1. Depending on the passing powers of various functionaries, the core banking system allows or does not allow the posting of transactions to the Host. When we say the system ‘does not allow’ for posting, we mean that it has to be authorized by one or more officials depending on the type of transaction and the amount of transaction. 2. Besides, depending upon whether the transaction will make the relevant account overdrawn or exceed limit etc., a Supervisor Override -- a message conveying the condition of the account as of now or how it will be if the transaction is to be permitted will be shown – asking for a decision by the supervising official whether to allow the transaction to go through or not. Supervisor Override messages come up once the transaction reaches the Host, and before posting. For the purpose of ensuring that proper authorization is provided by supervising officials, (depending on their passing powers), at the branches, we have a facility called Queues. It is a logical location in the server where transaction entered by the Maker resides before being authorized by the Checker. Depending on the validity and accuracy of the details of transaction, which the Checker will first verify by clicking ‘View Item’, the checker will choose to ‘Authorize’ or ‘Decline’ the queue item, i.e. the transaction. Queues are of two types: Personal queue and Group queue. By personal queue we mean the items residing therein can be seen only by the particular Teller. By Group queue we mean any Teller with the minimum capability specified for that Group could access the queue items. At this point of time, it is necessary to define the terminology for reinforcement of the concepts: Maker Checker
The person who does data entry. The person who authorizes (verifies and validates) or rejects the transaction. Capability The passing power required for authorizing the transaction. (Please Level refer to Chapter 1 and Chapter 9). Checker The set of users who are having the minimum capability level Group required for authorizing a transaction. Suppose the passing of a certain transaction requires user with a minimum capability level of 5, then the Checker Group is 5. Any user with capability level of 5 and more can access the queue and authorize the transaction. Group Location where the transactions sent by teller reside waiting for Queue authorization. Personal Location where the transactions sent by a Teller reside whenever he 327
Queue
chooses the option ‘Send to Supervisor’ and gives the particular Officer’s user id. Also, whenever a checker rejects a transaction, it automatically comes to the personal queue of the Maker.
14.01 Transaction Flow: 1. Whenever a transaction is entered in the system by a user, if it is beyond his capability level, or Maker-Checker has been implemented, it shows a message like this: Your transaction has been sent for authorization to queue: xxxx Queue Reference: NNNNN A specimen screenshot is shown below:
2. The User writes the Queue Reference number on the voucher/document so that the officer can pick up the transaction easily for verification. Then he sends the voucher to the passing officer. 3. The Checker clicks the Queue icon:
328
4. The Queue Search screen pops up as shown hereunder:
5. The Checker now keys in the Queue Reference Number against the field ‘Queue Reference From’ and ‘To’. Then clicks ‘Execute’ or presses . 6. If the checker enters only in the field ‘Queue Reference From’, he will see some other transactions also that are pending for authorization within his capability level. A sample output is shown below:
7. The checker now clicks the desired queue item, which he wants to authorize, say item no.91890. After clicking, the selected row is highlighted in blue colour.
329
8. Now the checker will verify the details of the transaction, by clicking ‘View Item’. He can now see the details of the transaction and compare the same with the voucher or other document to confirm they are ok. Please note that the checker cannot modify any details. After viewing the item, he will click ‘Close’.
9. Now, he will again see the Queue Dialog box. The checker will choose to ‘Authorize’ the transaction if all the details are ok, or he will choose to ‘Decline’ the transaction if any details are not ok or for any other valid reason. 10. Suppose the checker decides not to authorize the transaction for any valid reason, he will click ‘Decline’; the system then shows a popup screen where the Checker has to type the reason for Decline (for instance the account
330
number or amount is entered incorrectly), and then click ‘Decline’. also return the voucher to the Maker.
He will
Enter briefly the reason for declining the transaction here 11. The moment a queue item is declined, it goes to the Personal Queue of the Maker. The Maker can now access the queue item by choosing ‘Personal’ from the dropdown menu in the field ‘Queue Type’, and enter the reference number against ‘Queue Reference From’.
12. Now he can see the transaction that was returned by the checker. Please note that under ‘Tran Code’ column, Declined is indicated. The Maker selects the item, and clicks ‘Accept’.
331
Once the Maker clicks ‘Accept’, he will see a popup similar to this:
To make the required editing, the Maker will click ‘Modify Transaction’. The system brings up the transaction. The Maker will now do the required changes and click ‘Transmit’. Again, a queue reference number is generated, which the Officer will access. 13. After viewing the transaction, if the Checker is satisfied with the correctness, he will click ‘Authorize’. Depending on the type of transaction, it will generate a OK message, or show an Account Number or a CIF number, or send it to Group queue in case of a cash payment transaction etc.
332
14.02 Cash Transactions: A typical Cash Payment transaction that is declined, a cash payment transaction that is authorized, and a Cash Receipt Transaction that is authorized are explained below: A. A typical cash payment transaction: 1. Teller enters the transaction; a queue number is generated.
2.Officer clicks the queue icon , enters the Queue Reference number, and then clicks ‘Execute’:
3.Officer selects the item by clicking once on the entry, and then ‘View item’.
333
4.Clicking ‘View Item’ brings up the following screen:
5.Now the officer verifies the correctness and then clicks ‘Close’. He is brought back to the Queue dialog box, and then clicks ‘Authorize’.
6.Suppose the balance in the account is not sufficient, the message that comes up, warning the officer that the account will be overdrawn appears as in the following screenshot:
334
7. If the officer considers that the customer is worthy of permitting overdraft or excess drawings, he will key in his ‘Supervisor ID’ and ‘Password’, and click ‘Local Supervisor’.
8. We don’t know as yet, whether any other restrictions are on the account. If there are any posting restrictions, then the following popup is displayed where the officer has to again authorize the exception by giving his’ Supervisor ID’ and ‘Password’ and then click ‘Local Supervisor’.
9.If the funds available with the Teller are not sufficient to put through the transaction, the error message that appears is shown in the screenshot below and the transaction does not get posted to the Account. 335
B. A typical cash payment transaction that is authorized for payment: Let us see an example where the officer authorizes a payment transaction, and the transaction indeed goes through for the cashier to effect the payment. 01. Teller enters the transaction. A Queue reference number is generated as shown hereunder:
336
2.Officer clicks the queue icon, keys in the ‘Queue Reference’ number, and clicks ‘Execute’.
3.The transaction appears in the list.
4.He selects the item, ‘Views Item’, and then clicks ‘Authorize’.
337
Since there are some posting restrictions on the Account, system asks for authorizing the exception. A specimen screenshot of the relevant screen is shown below:
Now the officer has to give his user id and password. Please note the Officer needs to have the required Capability Level as is displayed on the screen. 5.After the officer authorizes the exception by giving his ‘Supervisor ID’, ‘Password’ and clicks ‘Local Supervisor’, the transaction is posted to the account. 6.A queue reference number is generated which the cashier has to access for effecting the cash payment.
338
7.Now the cashier will click the queue icon on the icon bar, give the ‘Queue Reference’ number & click ‘Execute’.
8.Now, the Cashier selects the entry and clicks ‘Accept’.
339
9.The Cash Dialog Box opens up. Now the cashier will feed the denominations as is shown in the screenshot below and click ‘Transmit’ to effect the payment to the customer.
340
10.A confirmation gets displayed on the Cashier’s terminal as is shown below:
C. A typical cash receipt transaction: (Please see BPR related changes in Chapter 4). 1. Teller enters the transaction.
341
2.The cash dialog box opens:
3.After inputting the right denominations, the Teller clicks ‘Transmit’. A queue reference number is generated for authorization by the officer as shown below:
342
4. Officer clicks the queue icon, keys in ‘Queue Reference’ number, and clicks ‘Execute’.
5. Now, he selects the entry, and clicks ‘View Item’, sees the transaction and closes the view screen. If satisfied, he clicks ‘Authorize’ on the queue search screen shown above. 6. If there are no errors, then you get the confirmation as given below for having posted the credit to the account. A screenshot of the specimen is shown below:
343
14.03 Supervisory Override: Whenever the system encounters an exception condition for posting transaction to an account, it requires an officer of sufficient capability to authorize the exception. When such a supervisory override screen pops up, the options available are, Send to Group, Send to Supervisor and Local Supervisor. The reason for using each of these options is given below: Send to Group If the user wants any of the officers with required capability level to authorize the exception, he can fill the Supervisor ID/Capability field with the capability level required (as displayed in the ‘Minimum capability required to override this error), and click ‘Send to Group’. This is the recommended choice. Send to Supervisor If the user knows that a specific officer is going to authorize this exception then he can fill the Supervisor ID field with the officer’s ID and click on Send to Supervisor. Local Supervisor If the Officer is in proximity to the Teller’s node, or while authorizing the transaction at his terminal, the officer gets the supervisor override message, then the officer will key in his user id and password and then click on Local Supervisor. Some of the occasions a Supervisory Override is required are: If an account becomes dormant If balance in the account is not available or not sufficient to put through the transaction. If an account Restrictions.
has
Posting
Restrictions/
********** 344
Stop
Restrictions/
Account
