Four-eyes escrow: deux operators pour l’étape deposit

La deposit step est le moment où l'argent devient réel. Le buyer wired funds ; quelqu'un sur la plateforme marque le wire comme received ; à partir de ce moment, le seller peut ship. Si ce "quelqu'un" est un operator seul, une seule erreur ou un seul bad actor peut flip un flag deposit-not-yet-arrived en received et laisser des goods sortir du warehouse sans paiement. Le four-eyes control ferme cette porte.

Deux operators, deux rôles

Un operator proposes la deposit confirmation : il a vu l'IBAN reconciliation report ou le bank statement, la structured reference match l'escrow ID, et il enregistre sa proposal dans la escrow detail page. Un second operator approves : il vérifie la même evidence indépendamment et clique Approve. L'escrow ne passe à held qu'après approval ; avant cela, il reste en “deposit pending” state, peu importe comment le proposer l'a recorded.

Pourquoi deux paires d'yeux

Parce que les finance teams s'y attendent, les auditors le cherchent, et le failure mode sans cela est le genre de chose découvert après qu'un buyer a déjà reçu des goods sur un deposit jamais payé. Le four-eyes control est le type de compliance feature qui ne ralentit pas le common case — proposer et approver peuvent clear la queue en quelques minutes — mais empêche le rare case d'arriver seul.

L'audit row

Le deposit confirmation event dans escrow_events records les deux actors : proposer, approver, timestamps pour chacun, evidence references citées par chacun (bank statement file ID, reconciliation row ID), et la resulting state transition. Un auditor qui lit la row un an plus tard voit qui a accepté de marquer le deposit confirmed, avec corroborating evidence, plutôt que le say-so d'un seul user.

Same-person guard

Un proposer ne peut pas être son propre approver. L'action Approve est gated sur user_id ≠ proposer_user_id. Le check tourne à l'API layer et au database trigger, donc la propriété second-pair-of-eyes est enforced même si l'UI laissait somehow passer. Les tenants trop petits pour avoir deux operators (rare, mais cela arrive) peuvent configurer la policy pour exiger une platform-staff approval — le même control avec une deuxième paire différente.

Ce que cela ne couvre pas

Le four-eyes control est spécifiquement côté deposit. Le côté release a ses propres controls : explicit buyer acceptance, dispute paths ou auto-release window (voir escrow-auto-release). Les deux côtés combinés produisent un flow où ni deposit ni release ne dépend d'une seule human action.