Maker-checker

Why it matters

It is a standard safeguard against both error and fraud: a single person acting alone, whether by mistake or with bad intent, cannot complete a sensitive action unilaterally. It is a common requirement in financial systems and increasingly expected in any platform handling meaningful money movement or privileged configuration changes. It also creates a natural audit trail as a side effect: because two distinct people are always involved, there is always a second party who can confirm or dispute what actually happened, which a single-person process cannot offer. It also scales with risk: higher-value or higher-sensitivity actions can require more than one checker, while routine, low-risk actions can skip the control entirely to avoid unnecessary friction.

What goes wrong when it's handled badly

A system that allows one person to both initiate and approve a payment or a permission change has no real control at that step, regardless of what the interface implies. A concrete failure looks like a single compromised account being able to both create and approve a fraudulent payout, something a genuine maker-checker step would have stopped at the approval stage even after the initiating account was compromised. A concrete example is a finance team member with the ability to both add a new vendor bank account and approve a payment to it, a combination that has been used in real invoice-fraud schemes specifically because no second person was required to catch it. Enforcing the separation at the system level, so the interface itself will not allow one account to complete both roles, rather than relying on a policy nobody is technically prevented from ignoring, is what makes the control real.