Maker-Checker Design Concept

We've seen the maker-checker concept pop-up several times in our software development experiences with banks. In this post, let me share a possible re-usable design approach. Thanks to Tin, Richie, Tina, Val, and their team, for adding their insights.

What is Maker-Checker?

According to Wikipedia:

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 functional division of labor between all classes of employees.

By transaction, we're referring to a business transaction (e.g. sale, purchase, remittance request), and not a database transaction.

Here are some business rules we can derive from the above definition:

1. For any transaction entry, there must be at least two individuals necessary for its completion.
2. The one who makes the transaction entry (i.e. maker) cannot be the same one who checks (i.e. checker) it.
3. A transaction entry is only considered completed if it has been checked.

Upon further clarification with the domain experts, we've learned the following:

1. The checker cannot make modifications to the transaction entry. Modifications can only be done by maker.
2. If the checker rejects the transaction entry, it should be returned back to maker (with possible comments or suggested changes). The maker can then resubmit changes later.
3. There can be cases when the transaction entry needs another level of checking (after the first one). This would result into three individuals necessary for completion.

A typical user story for this would be something like: As a <manager>, I want to apply maker-checker policy for each <transaction> being entered, so that I can prevent fraud (or improve quality).

Possible usage scenario(s) would be something like this:

For maker:

1. Maker submits a transaction to the system.
2. System determines submitted transaction to be under the maker-checker policy.
3. System stores submitted transaction as "for checking".
4. System displays list of "for checking", "accepted", and "rejected" transactions.

For checker:

1. Checker retrieves list of transactions "for checking".
2. System displays list of transactions "for checking".
3. Checker selects a transaction.
4. System shows the transaction.
5. Checker accepts the transaction.
6. System records "accepted" transaction.

The alternative flow is when the checker rejects the transaction.

5. Checker rejects the transaction.
6. System records "rejected" transaction.

Our analysis shows that the transaction entry can have the following states:

1. for checking,
2. verified,
3. and rejected.

The checker can either accept or reject the entry.

In a future post, I'll share one possible design approach for maker-checker.