Maker-checker (or Maker and Checker, or 4-Eyes) is one of the central principles of authorization in the information systems of financial organizations. The principle of maker and checker means that for each transaction, there must be at least two individuals necessary for its completion. While one individual may create a transaction, the other individual should be involved in confirmation/authorization of the same. Here the segregation of duties plays an important role. In this way, strict control is kept over system software and data, keeping in mind the functional division of labour between all classes of employees.
Objects covered by the Maker-checker policy:
- Loan Products
- Savings Products
- Term Deposit Product
Operations covered by the Maker-checker policy:
- Loan application disbursement
- Loan repayment
- Loan rollback
There are 8 maker's permissions and 8 checker's.
If an object or an operation is covered by the Maker-checker policy then the following workflow applied:
- A user with related maker permission should create the object or perform the operation. For example, to create a user a maker user should have
- After clicking the Save button the request with type User create will appear in the Maker/Checker tab.
- A user with related checker permission, in this case, CHECKER_FOR_USER should open Maker/Checker tab, find that request and approve or reject it.
- If a checker user has approved it the new user appears in the system. If rejected - the new user won't be created.
The same workflow works for edit operations, e.g. until the checker confirms the request nothing changes.
If an object has active requests, e.g. is modified by maker or loan operation is performed, it can't be changed until a checker handles existing requests. It guarantees that no one won't work with the obsolete state of the object, e.g. the second repayment won't be performed on old data or a user won't be edited the second time.
Some organisations don't need Maker-checker system, e.g. they don't want to do the excessive job working with requests. In this case, it is enough to grant both maker and checker permissions to the role so the current workflow won't change. It means. new objects such a user, a role, an account, etc... will be created just as before, by simply clicking the Save button.