What is the Maker-Checker Workflow?
In the fight against financial crime, fraud prevention, and compliance operations, allowing certain processes to proceed based on the decision of a single person can pose serious risks. A second control point is essential for steps such as deploying a new rule, closing a high-risk case, or executing a critical action.
Maker-Checker Workflow, is a control mechanism that ensures the person who prepares a critical action cannot approve it on their own.
The logic is simple:
The Maker prepares the action. The Checker reviews, approves, or sends it back for revision.
This structure ensures segregation of duties, reduces errors, and makes decisions easier to track, especially in AML, Fraud Detection, Rule Engine, and Case Management processes.
How Does the Maker-Checker Workflow Work?
Let's consider a compliance specialist preparing a new Transaction Monitoring rule.
The specialist determines which behavior will be considered risky, enters the threshold values, and defines which customer or transaction segments the rule will apply to.
At this stage, the specialist is in the Maker role.
Instead of being deployed directly to production, the rule is sent to the Checker. The Checker reviews the rule's conditions, thresholds, and potential impact on operations.
If necessary, simulation results can also be reviewed to see how the rule would perform on historical data.
If the Checker finds the rule appropriate, they approve it. If they believe changes are needed, they send it back to the Maker with a justification.
Thus, a critical change is never deployed based on a single person's decision.
Why is a Second Control Needed?
A minor change made to a rule can have major consequences on the operational side.
For example, if the threshold of a scenario that normally flags customers making 10 transactions within the last 24 hours is accidentally entered as 2, a very high volume of alerts can be generated in a short time.
In this case, the compliance team might have to investigate unnecessary alerts instead of focusing on real risks.
The reverse is also possible. If the threshold is raised too high, certain behaviors requiring investigation might be missed.
The Maker-Checker structure creates a second layer of control here.
The goal is not to slow down the process, but to ensure that critical changes progress in a controlled manner.
How is it Used in Case Management Processes?
One of the key use cases of the Maker-Checker approach is in Case Management processes.
When an alert is investigated, the analyst does not just look at a single transaction. Customer history, screening results, connected accounts, previous cases, and other risk signals can be evaluated together.
After completing the investigation, the analyst makes a decision on the case.
This decision could be, for example:
- closing the case,
- putting it under further investigation,
- routing it to a different team,
- evaluating it at a higher risk level,
- preparing it for the reporting process.
Depending on the workflow defined by the organization, critical decisions can be sent to the Checker for approval.
The Checker reviews not only the outcome but also the evidence and justifications on which the decision is based.
This makes it easier to answer the following questions later on:
Who made the decision? Who checked it? On what information was it approved?
Maker-Checker on the Rule Engine Side
Changes made to the Rule Engine directly affect which behaviors the system will deem risky.
For example:
> Generate an alert if multiple accounts are logged into from the same device within a short period.
When the number of accounts, time interval, or customer segment in this scenario is changed, the outcome generated by the rule also changes.
Therefore, having different individuals for creating the rule and approving its deployment is an important control mechanism.
The Maker prepares the rule.
The rule can then be tested on historical data. The expected alert volume and the results of different thresholds are evaluated.
The Checker can review this data to approve the rule or request revisions.
Thanks to this structure, rule changes can be evaluated based on measurable results as much as possible, rather than just guesswork.
Why is Segregation of Duties Important?
At the core of the Maker-Checker approach lies the segregation of duties.
Allowing a single user to both create and approve the same action on their own can weaken the control mechanism.
Therefore, critical permissions can be separated into different roles.
For example, in an organization:
The Analyst can investigate the case. The Compliance Manager can check the decision. The Authorized User can approve specific actions.
Since every organization has a different organizational structure, the same Maker-Checker model does not have to apply to every institution.
What matters is clearly defining which user can perform which action and which actions require a second approval.
Why is the Audit Trail Part of This Structure?
A second person's approval is not enough on its own. The actions taken must also be recorded so they can be reviewed later.
This is where the Immutable Audit Log comes into play.
For example, the system can record:
- who created the action,
- which fields were modified,
- when the change was made,
- who approved it,
- whether the action was sent back,
- the justification on which the decision was based.
This structure makes it particularly easy for compliance and internal audit teams to review the decision history.
What Does Truvali Provide in Maker-Checker Processes?
In Truvali, the Maker-Checker approach is not treated merely as an approval screen. It works in tandem with platform capabilities such as Rule Engine, Case Management, authorization, and Audit Trail to support the controlled progression of critical decisions.
For example, in a new AML or fraud scenario, the process can proceed as follows:
- The Maker creates the draft rule.
- Thresholds and conditions are defined.
- The rule can be tested via simulation on historical data.
- The expected alert volume and operational impact are evaluated.
- The rule is sent to the Checker for approval.
- The Checker approves or sends it back for revision.
- Changes and approvals in the process are recorded in the Audit Trail.
A similar structure can be used on the Case Management side. While the analyst makes a decision on a case, critical actions can be tied to the control of a second authorized user.
Thanks to Truvali's Role-Based Access Control structure, the actions users can perform can be segregated on a role basis. Thus, for example, a user may have the authority to create a rule but not to approve the same rule on their own.
The same approach can be maintained in AI-powered processes. Truvali can support the preparation of case summaries, draft rules, or draft reports; however, critical outputs can be tied to the review and approval processes of authorized users.
The goal here is not to replace human control with automation, but to bring automation and organizational control together in the same workflow.
Frequently Asked Questions About the Maker-Checker Workflow
Can the Maker and Checker be the same person?
The primary purpose of the structure is the segregation of duties. Therefore, for critical actions, it is preferred that the Maker and Checker roles belong to different users.
Does every action require Checker approval?
No. Which actions require a second approval can be determined based on the organization's risk policies and authorization model.
Is Maker-Checker only used for AML?
No. It can also be used in Fraud Detection, Case Management, Rule Engine, user authorization, and other critical operational processes.
Are drafts generated by AI applied automatically?
This depends on the workflow defined by the organization. Critical outputs can be tied to authorized user review and Maker-Checker approval.