Four-Eyes Escrow: Two Platform Owners for the Deposit Step

The deposit step is where money first becomes real. The buyer wires funds; somebody marks the wire as received; from that moment the seller can ship. If the “somebody” is one person 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 platform owners, two roles

Platform staff record deposit receipt in /admin/escrow/pending. They compare the bank statement with the escrow amount, currency and reference themselves. One platform owner enters the bank transaction reference and proposes confirmation; the escrow remains pending. A second platform owner checks the same instruction and approves it. Only then is the deposit marked held. ReVend does not import the bank statement or automatically compare the received amount in this action.

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 control doesn’t slow the common case — two owners can clear a queue in minutes — but it does stop the rare case from happening alone.

The audit row

The proposal and approval record their separate actors and times. The bank reference remains in the proposal and escrow record. Dossier events and the required activity log identify the decision; the activity log does not copy the raw bank reference. An approval, its status change and required audit are saved together.

Same-person guard

A proposer cannot be their own approver. The server refuses the second step from the same account with a second-owner-required error, whatever the screen was showing. Small teams do not get an exception here: the second pair of eyes is a ReVend platform owner by definition, so a tenant never needs two of anything.

The same rule for cancelling

Taking a pending deposit off the table is fund-impacting too, so it follows the same two-step pattern with a mandatory reason: one owner proposes the cancellation, another approves, and only then does the escrow become cancelled. Two break-glass actions exist for when the normal flow cannot complete: an override on a pending approval, recorded in its own audit column so it never masquerades as a regular approval, and a force-cancel for a pending deposit that has aged past 7 days — both with a reason that becomes part of the trail. Independently of anyone clicking, a deposit that is still pending after 7 days is cancelled by a daily job, and an auction buyer collects a strike for it.

What it doesn’t cover

The four-eyes rule applies to normal deposit confirmation and cancellation. Release follows buyer acceptance, a dispute decision or the controlled platform-owner exception. Each action has its own authorization and audit checks. A software status is not proof that a bank transfer was carried out.