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 say maker-checker. Governance teams talk about segregation of duties. The words are not interchangeable, and the difference changes how the workflow is built.
Four-Eyes Principle: 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 is:
- one operator prepares or advances the work
- another operator reviews it independently
- the action proceeds only when that boundary is respected
The purpose is not bureaucracy. It is error detection, fraud resistance, and better judgment under pressure.
This control matters most where the consequence of a mistake is high:
- payment reversals
- vendor bank-detail changes
- customer account corrections
- write-offs and adjustments
- production configuration changes
- actions that are difficult to undo or explain later
The critical word is independent. A second click from someone who cannot see the evidence, does not hold the right role, or habitually rubber-stamps every request is not a meaningful two-person review.
Maker-Checker: The Operational Finance Pattern
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.
That small vocabulary change makes the workflow more concrete. Maker-checker usually 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
That is why maker-checker quickly becomes an auditability question. It is not enough to know that two people were involved. The system has to preserve what each person did and why the second person had enough context to review.
Role Separation (Segregation of Duties): 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 critical 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 still concentrating too much authority in one operator.
Dual Control And Two Signatures
Dual control is a useful phrase, but it is often 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 tells the team that more than one authorization is expected, but it does not specify 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?
Those details determine whether the control is real.
Why Inbox Approvals Fail
Many teams say they have two-person review when what they actually have is 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 - it is that the role boundary, the denied paths, and the execution result all disappear into a thread that 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 principle here is simpler: the language you use to describe the control shapes whether the system actually enforces it.
What Good Two-Person Review Workflow Looks Like
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 rather than ceremonial. The control is not just 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 it recorded the entire sequence.
Where AI Fits
AI can assist two-person review workflows by summarizing evidence, highlighting missing context, or flagging 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, that 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.
Where Latch Fits
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 logs that keep the control story attached to the case
A control is only as credible as the record it leaves behind. If your team wants four-eyes discipline in a finance exception path, Latch can hold the case, expose the action in context, enforce the review boundary, and preserve the result in one place.
Start with maker-checker in Latch or finance controls.