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

Officers 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 <Enter>.
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 dont 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 Cashiers 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 officers ID and click on Send to
Supervisor.
Local Supervisor
If the Officer is in proximity to the Tellers 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