Maker-Checker Workflow

The maker checker workflow — called the four-eyes principle in finance and in international regulatory frameworks — is a segregation of duties control and division of labor mechanism embedded in operational workflows. The maker initiates or enters a change, and the checker independently reviews and either approves or rejects it before the system applies it. No single operator can both initiate and authorize the same action.

Regulators distinguish between procedural controls — where a firm's policy states that two people should review an action — and systemic controls, where the software physically prevents single-user completion regardless of the operator's permission level. Only systemic enforcement satisfies examiner expectations. A maker-checker policy that a sufficiently privileged user can bypass is not a control; it is documentation of an intent.

The four-eyes principle addresses two distinct risks simultaneously: operational risk from unintentional errors, where a second reviewer catches mistakes and reduces human error before they take effect; and the risk of fraudulent activities, where the requirement for a second approver prevents a single operator from making consequential changes without oversight. Both risks are amplified in high value transactions and high-risk operational actions such as standing settlement instruction changes and compliance rule modifications.

FINRA Rule 3110 requires broker-dealers to establish and maintain written supervisory procedures, and maker-checker enforcement is a standard component of those procedures for controlled operational actions. SEC guidance on internal controls for broker-dealers, OCC guidance, and Federal Reserve supervisory letters all reference dual-control and dual-authorization requirements explicitly. Maker-checker is a universal institutional standard, not a regional one.

The maker-checker pattern originates in banking operations and has been a standard internal control in securities back offices for decades. Any action consequential enough to require an audit trail is also consequential enough to require a second pair of eyes before execution.

The workflow follows a consistent pattern regardless of the action type:

• The maker creates or modifies a record and submits it for review. The system places the record in a pending state — visible to authorized reviewers but not yet active.
• The checker, who must be a different user with appropriate authorization, reviews the change in context — seeing both what is being changed and the current state it would replace.
• The checker either approves the change, moving it to active status, or rejects it, returning it to the maker with a documented reason and any required supporting documentation.
• The full sequence — who made the change, when, who checked it, what decision was made, and the reason for any rejection — is preserved in the audit log and cannot be altered.
• Role-based authorization: the checker must typically possess a specific authorization level or distinct departmental role from the maker. A trade support analyst makes the change; a middle office manager or compliance officer checks it. For certain broker-dealer actions, the checker must hold a specific principal license such as a Series 24.

Standing settlement instructions are the highest-priority maker-checker target in securities operations. An unauthorized SSI change to a fraudulent account could redirect securities or cash without triggering any other control. All SSI creation and modification requires checker approval as a primary defense against this class of fraudulent activities.

Compliance rule modifications — changes to net capital limit thresholds, concentration limits, or counterparty exposure limits — require maker-checker enforcement because a unilateral change in high value transactions could create an undisclosed exposure or circumvent a regulatory control. The checker role typically requires a compliance officer or senior risk manager with the authority to approve changes to the firm's control framework.

AI-assisted operations and maker-checker: as AI agents perform operational actions — drafting settlement instructions, flagging position breaks, initiating corporate action elections — maker-checker obligations extend to AI-initiated transactions. A human checker must remain in the approval chain for all controlled actions regardless of whether the maker step was AI-assisted. An AI that can both initiate and approve its own actions is not operating under maker-checker controls.

A concrete SSI change workflow illustrates the control in practice:

1. Operations analyst (maker) identifies a custodian account number change for a counterparty and creates an SSI modification
2. System flags the record as pending and routes it to the SSI approval queue
3. Senior operations officer (checker) receives notification, reviews the new account details against the counterparty's official supporting documentation, and approves
4. SSI becomes active and available for settlement instruction generation
5. Audit log records both steps with actor, timestamp, and decision — available to FINRA examiners on request

Benefits of maker-checker enforcement in institutional operations: reduced human error through systematic second review before changes take effect; prevention of fraudulent activities through mandatory division of labor on consequential actions; a complete and tamper-evident audit trail that satisfies FINRA examination requirements without additional documentation effort; and clear accountability for every controlled operational change across the firm.