Designing four-eyes approval controls for manual changes in financial software

Quick Overview

A product design question about maker-checker controls on a finance platform, where every manual action needs one person to perform it and a different person to approve it. It tests separation of duties, request lifecycle design, the reviewer experience, audit trails, and balancing control against operational speed.

Designing four-eyes approval controls for manual changes in financial software

Company: FundGuard

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

You are a product manager on a finance platform. Design a maker-checker feature: every action a user takes manually must involve two different people, one who executes it and one who approves it. ```hint Start from what can go wrong List the manual actions where one person's mistake or misconduct would cost the firm, then shape the request, review and audit flow around stopping those without stalling daily operations. ``` ### Clarifying Questions - Which manual actions are in scope: data corrections and overrides, payments and transfers, reference-data edits, user-permission changes, or all of them? - Must approval happen before the action takes effect, or may low-risk actions take effect first and be approved afterwards? - Who may approve: any other user, or only someone with a specific role, seniority or team? Is one approval ever not enough, for example for larger amounts? - Is there ever an emergency path where one person can act alone, or does the two-person rule have no exceptions? ### What a Strong Answer Covers - The users involved (makers, checkers, administrators who set policy, auditors) and what each needs from the feature - The end-to-end request lifecycle, including rejection, edits after submission, withdrawal and expiry - Rules that make separation of duties real: no self-approval, role-based eligibility, and a guarantee that what the approver reviewed is what executes - Keeping operations moving (queues, notifications, delegation, deadlines) without encouraging rubber-stamp approvals - An audit trail and success metrics for both control quality and speed ### Follow-up Questions - Checkers approve most requests within seconds. How would you detect rubber-stamping, and what would you change in the product? - A month-end deadline is an hour away and the only eligible approver is out sick. What does the product let the team do? - How would you let each client firm configure its own approval policy without letting it switch the control off?

Overview: A product design question about maker-checker controls on a finance platform, where every manual action needs one person to perform it and a different person to approve it. It tests separation of duties, request lifecycle design, the reviewer experience, audit trails, and balancing control against operational speed.

FundGuard logo
FundGuard
Feb 26, 2025
mediumProduct ManagerOtherProduct Design & Strategy
0
0

You are a product manager on a finance platform. Design a maker-checker feature: every action a user takes manually must involve two different people, one who executes it and one who approves it.

Clarifying Questions Guidance

  • Which manual actions are in scope: data corrections and overrides, payments and transfers, reference-data edits, user-permission changes, or all of them?
  • Must approval happen before the action takes effect, or may low-risk actions take effect first and be approved afterwards?
  • Who may approve: any other user, or only someone with a specific role, seniority or team? Is one approval ever not enough, for example for larger amounts?
  • Is there ever an emergency path where one person can act alone, or does the two-person rule have no exceptions?

What a Strong Answer Covers Guidance

  • The users involved (makers, checkers, administrators who set policy, auditors) and what each needs from the feature
  • The end-to-end request lifecycle, including rejection, edits after submission, withdrawal and expiry
  • Rules that make separation of duties real: no self-approval, role-based eligibility, and a guarantee that what the approver reviewed is what executes
  • Keeping operations moving (queues, notifications, delegation, deadlines) without encouraging rubber-stamp approvals
  • An audit trail and success metrics for both control quality and speed

Follow-up Questions Guidance

  • Checkers approve most requests within seconds. How would you detect rubber-stamping, and what would you change in the product?
  • A month-end deadline is an hour away and the only eligible approver is out sick. What does the product let the team do?
  • How would you let each client firm configure its own approval policy without letting it switch the control off?