Four-eyes escrow: twee operators voor de deposit step
Waarom bevestigen dat een buyer wire ontvangen is een tweede paar ogen vraagt, hoe proposer/approver splitsing werkt en hoe de audit row daarna leest.
De deposit step is waar money voor het eerst echt wordt. De buyer wired funds; iemand op het platform markeert de wire als received; vanaf dat moment kan de seller shippen. Als die "iemand" één operator alleen is, kan één vergissing of één bad actor een deposit-not-yet-arrived flag naar received flippen en goods zonder payment het warehouse uit laten gaan. De four-eyes control sluit die deur.
Twee operators, twee roles
Één operator proposes de deposit confirmation: hij heeft het IBAN reconciliation report of bank statement gezien, de structured reference matcht de escrow ID, en hij legt zijn proposal vast op de escrow detail page. Een tweede operator approves: die verifieert dezelfde evidence onafhankelijk en klikt Approve. De escrow flipt pas na approval naar held; daarvoor blijft hij in “deposit pending” state, ongeacht hoe de proposer het registreerde.
Waarom twee paar ogen
Omdat finance teams het verwachten, auditors ernaar zoeken, en de failure mode zonder dit precies het soort is dat ontdekt wordt nadat een buyer al goods heeft gekregen op een deposit die nooit betaald werd. De four-eyes control is het type compliance feature dat de common case niet traag maakt — proposer en approver kunnen de queue allebei in een paar minuten clearen — maar voorkomt dat de rare case alleen kan gebeuren.
De audit row
De deposit confirmation event in escrow_events registreert beide actors: proposer, approver, timestamps voor elk, evidence references die elk aanhaalde (bank statement file ID, reconciliation row ID), en de resulting state transition. Een auditor die de row een jaar later leest, ziet wie akkoord ging om de deposit confirmed te markeren, met corroborating evidence, in plaats van één user’s say-so.
Same-person guard
Een proposer kan zijn eigen approver niet zijn. De Approve action is gated op user_id ≠ proposer_user_id. De check draait op API layer én database trigger, zodat de second-pair-of-eyes property enforced blijft zelfs als de UI het somehow zou laten slippen. Tenants die te klein zijn voor twee operators (zeldzaam, maar het gebeurt) kunnen de policy configureren om platform-staff approval te vereisen — dezelfde control met een ander tweede paar.
Wat het niet dekt
De four-eyes control zit specifiek op de deposit side. De release side heeft eigen controls: explicit buyer acceptance, dispute paths of auto-release window (zie escrow-auto-release). Beide kanten samen produceren een flow waarin noch deposit noch release afhankelijk is van één menselijke action.