Sunday, November 16, 2014

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.

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.

  1. Checker rejects the transaction.
  2. 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.

5 comments:

  1. Hey Lorenzo, nice post. I was wondering that should there be an ageing logic or exipry on the transactions in "For Checking" state?

    ReplyDelete
  2. What kind of a future is that? :) It has been almost 2 years.

    ReplyDelete
  3. Really amazing and quite crisp and clear.

    ReplyDelete
  4. Nice but if you give code for own maker does not able to check his own transaction....its good

    ReplyDelete
  5. A little late Prawin Reddy, but for that you can just add a maker_id column against the transaction and ensure that if the maker is logged-in and has accessed the transaction, you disable or completely hide the check button

    ReplyDelete