Four-Eyes Escrow: Two Operators For The Deposit Step

The deposit step is where money first becomes real. The buyer wires funds; somebody at the platform marks the wire as received; from that moment the seller can ship. If the “somebody” is one operator alone, a single mistake or a single bad actor can flip a deposit-not-yet-arrived flag to received and let goods leave the warehouse on no payment. The four-eyes control closes that door.

Two operators, two roles

One operator proposes the deposit confirmation: they’ve seen the IBAN reconciliation report or the bank statement, the structured reference matches the escrow ID, and they record their proposal in the escrow detail page. A second operator approves: they verify the same evidence independently and click Approve. The escrow flips to held only after the approval; before that, it stays in the “deposit pending” state regardless of how the proposer recorded it.

Why two pairs of eyes

Because finance teams expect it, auditors look for it, and the failure mode without it is the kind that gets discovered after a buyer has already received goods on a deposit that was never paid. The four-eyes control is the kind of compliance feature that doesn’t prevent the common case from happening fast — proposer and approver can both clear the queue in a few minutes — but does prevent the rare case from happening alone.

The audit row

The deposit confirmation event in escrow_events records both actors: the proposer, the approver, the timestamps for each, the evidence references each cited (the bank statement file ID, the reconciliation row ID), and the resulting state transition. An auditor reading the row a year later sees who agreed to mark the deposit confirmed, with corroborating evidence, instead of one user’s say-so.

Same-person guard

A proposer cannot be their own approver. The Approve action is gated on user_id ≠ proposer_user_id. The check runs at the API layer and at the database trigger, so the second-pair-of-eyes property is enforced even if the UI somehow let it slip. Tenants too small to have two operators (rare but it happens) can configure the policy to require platform-staff approval instead — the same control with a different second pair.

What it doesn’t cover

The four-eyes control is on the deposit side specifically. The release side has its own controls: explicit buyer acceptance, dispute paths, or the auto-release window (see escrow-auto-release). Both sides combined produce a flow where neither the deposit nor the release relies on a single human action.