Most finance and operations teams agree on the basic idea: a sensitive action should not be executed by one person alone. The disagreement starts when they name the control. Some call it the four-eyes principle. Others call it maker-checker. Governance teams call it segregation of duties. The words are not interchangeable. The difference changes how the workflow is built.
Four-Eyes Principle Requires Independent Review Before Sensitive Action
Two-person review (also called the four-eyes principle) means a sensitive decision must be independently reviewed before it moves. No single person should be able to advance the action alone.
The pattern:
- One operator prepares or advances the work.
- Another operator reviews it independently.
- The action proceeds only when that boundary is respected.
The purpose is error detection, fraud resistance, and better judgment under pressure. It is not bureaucracy.
The control matters most when a mistake is costly:
- payment reversals
- vendor bank-detail changes
- customer account corrections
- write-offs and adjustments
- production configuration changes
- actions that are hard to undo or explain
The word that matters is independent. A reviewer who cannot see the evidence is not independent. Neither is one who lacks the right role or rubber-stamps every request.
Maker-Checker Is the Operational Finance Pattern That Needs a Record
Maker-checker is the finance and operations version of the same idea. The maker prepares the request. The checker reviews it before the action runs.
The vocabulary change makes the workflow more concrete. Maker-checker implies a record that answers:
- who prepared the case
- what evidence they attached
- what action they proposed
- who checked it
- whether the checker was independent
- what happened after approval
Maker-checker becomes an auditability question. Knowing that two people were involved is not enough. The system must preserve what each person did and why the second person had enough context to review.
Role Separation (Segregation of Duties) Draws the Structural Boundary
Role separation (often called segregation of duties) is broader than one approval step. It asks whether incompatible powers are separated across roles, teams, or systems.
Examples:
- the person who creates a vendor should not also approve payment to that vendor
- the person who writes a policy should not be the only person who can bypass it
- the person who prepares a sensitive case should not be able to approve and execute it alone
- the person who deploys a model should not be the only person approving production use
Role separation is the design foundation. Two-person review and maker-checker are workflow patterns that enforce that foundation at a specific moment.
If role separation is weak, a workflow can look controlled while concentrating too much authority in one operator.
Dual Control and Two Signatures Need an Exact Rule
Dual control is a useful phrase. It is too broad to implement on its own.
It can mean:
- two people must approve an action
- one person prepares and another executes
- two roles must participate in different parts of a process
- two systems must agree before the action runs
"Two signatures" has the same problem. It signals that more than one authorisation is expected. It does not define the operating boundary.
Before implementing dual control, define the exact rule:
- What action is controlled?
- Who can prepare it?
- Who can review it?
- Can the maker approve their own work?
- What evidence must be present before approval?
- What happens when the action is rejected?
- What gets recorded after execution?
These details determine whether the control is real.
Inbox Approvals Fail Because the Evidence Disappears
Many teams say they have two-person review when they actually have a forwarded email. That is not a durable control model. It is a coordination habit.
Email can be part of intake or notification. It should not be the control surface for high-risk execution. The problem is not that another person was involved. The problem is that the role boundary, the denied paths, and the execution result disappear into a thread. That thread is hard to reconstruct later.
The detailed case for moving away from inbox-based approval is in How to Run Four-Eyes Control Without Inbox Approvals. The rule: the language a team uses to describe a control shapes whether the system enforces it.
Good Two-Person Review Workflow Leaves a Complete Record
A strong workflow usually has a few concrete properties:
- one case record that holds the request, notes, evidence, and status
- clear role boundaries around sensitive actions
- permission checks at the point of use
- self-approval blocked by the system
- rejected and returned cases recorded, not overwritten
- downstream execution captured on the same case
- audit history that shows who prepared, who checked, and what happened
This is where the four-eyes principle becomes operational, not ceremonial. The control is not that another person saw the request. The control is that the system kept the action from running until an independent reviewer acted inside the workflow, and recorded the entire sequence.
AI Supports Review but Must Not Replace the Boundary
AI can assist two-person review by summarising evidence and highlighting missing context. It can also flag unusual patterns. It should not quietly replace the approval boundary.
If AI proposes a decision, the record should show the recommendation, the information it used, and the human decision that followed. If a reviewer changes the recommendation, the change should be visible. If an action crosses a threshold and needs human approval, the workflow should enforce that boundary before execution.
The goal is not "AI approved it." The goal is a faster review path with a clearer, provable record.
Latch Keeps the Control Story on the Case
Latch is the case workflow layer around this control problem. It gives teams:
- one case record for notes, attachments, and issue context
- role-based restrictions around sensitive actions
- maker-checker workflows where the preparer cannot approve their own case
- denied-attempt visibility when an action is blocked
- plugin execution history when the downstream action runs
- audit trail that keeps the control story attached to the case
A control is only as credible as the record it leaves behind. If a team wants four-eyes discipline in a finance exception path, Latch can hold the case and expose the action in context. It enforces the review boundary and preserves the result in one place.
Start with maker-checker in Latch or finance controls.