Four-eyes Escrow: zwei Operators fuer den Deposit Step
Warum die Bestaetigung eines Buyer Wire ein zweites Augenpaar braucht, wie Proposer/Approver getrennt sind und wie die Audit Row danach liest.
Der Deposit Step ist, wo Money zum ersten Mal real wird. Der Buyer wired Funds; jemand auf der Plattform markiert den Wire als received; ab diesem Moment kann der Seller shippen. Wenn dieser "jemand" ein einzelner Operator ist, kann ein einziger Fehler oder ein einzelner Bad Actor eine deposit-not-yet-arrived Flag auf received flippen und Goods ohne Payment aus dem Warehouse lassen. Der Four-eyes Control schließt diese Tür.
Zwei Operators, zwei Roles
Ein Operator proposes die Deposit Confirmation: Er hat den IBAN Reconciliation Report oder das Bank Statement gesehen, die Structured Reference matcht die Escrow ID, und er recorded seinen Proposal in der Escrow Detail Page. Ein zweiter Operator approves: Er verifiziert dieselbe Evidence unabhängig und klickt Approve. Das Escrow flippt erst nach Approval auf held; davor bleibt es im “deposit pending” state, egal wie der Proposer es recorded hat.
Warum zwei Augenpaare
Weil Finance Teams es erwarten, Auditors danach suchen, und der Failure Mode ohne es genau die Art ist, die entdeckt wird, nachdem ein Buyer bereits Goods auf einen Deposit bekommen hat, der nie bezahlt wurde. Der Four-eyes Control ist eine Compliance Feature, die den Common Case nicht langsam macht — Proposer und Approver können die Queue beide in ein paar Minuten clearen — aber verhindert, dass der Rare Case allein passieren kann.
Die Audit Row
Das Deposit Confirmation Event in escrow_events records beide Actors: Proposer, Approver, Timestamps für beide, Evidence References, die beide zitierten (Bank Statement File ID, Reconciliation Row ID), und die resulting state transition. Ein Auditor, der die Row ein Jahr später liest, sieht, wer zugestimmt hat, den Deposit confirmed zu markieren, mit corroborating evidence, statt dem Say-so eines einzelnen Users.
Same-person guard
Ein Proposer kann nicht sein eigener Approver sein. Die Approve Action ist gated auf user_id ≠ proposer_user_id. Der Check läuft auf API Layer und im Database Trigger, sodass die Second-pair-of-eyes Property enforced bleibt, selbst wenn die UI es somehow durchlassen würde. Tenants, die zu klein für zwei Operators sind (selten, aber passiert), können die Policy so konfigurieren, dass platform-staff approval required ist — derselbe Control mit einem anderen zweiten Paar.
Was es nicht abdeckt
Der Four-eyes Control liegt spezifisch auf der Deposit Side. Die Release Side hat eigene Controls: explicit buyer acceptance, dispute paths oder das auto-release window (siehe escrow-auto-release). Beide Seiten zusammen erzeugen einen Flow, in dem weder Deposit noch Release von einer einzelnen Human Action abhängt.