Vier-Augen-Escrow: zwei Platform Owner für den Deposit-Schritt

Der Deposit-Schritt ist der Moment, in dem Geld zum ersten Mal real wird. Der Käufer überweist; jemand markiert die Überweisung als eingegangen; ab da darf der Verkäufer versenden. Ist dieses „jemand“ eine einzelne Person, kann ein einzelner Fehler oder ein einzelner böser Akteur ein Deposit von „noch nicht angekommen“ auf „eingegangen“ kippen und Ware ohne Zahlung aus dem Lager lassen. Die Vier-Augen-Kontrolle schließt diese Tür.

Zwei Platform Owner, zwei Rollen

Plattformmitarbeiter erfassen den Eingang einer Einzahlung unter /admin/escrow/pending. Sie vergleichen den Kontoauszug selbst mit Escrow-Betrag, Währung und Referenz. Ein Platform Owner trägt die Banktransaktionsreferenz ein und schlägt die Bestätigung vor; das Escrow bleibt ausstehend. Ein zweiter Platform Owner prüft dieselbe Anweisung und genehmigt sie. Erst dann wird die Einzahlung als gehalten erfasst. Diese Aktion importiert keinen Kontoauszug und vergleicht den eingegangenen Betrag nicht automatisch.

Warum zwei Augenpaare

Weil Finanzteams es erwarten, Prüfer danach suchen und der Fehlerfall ohne diese Kontrolle die Sorte ist, die erst auffällt, wenn ein Käufer die Ware auf ein nie gezahltes Deposit hin bereits erhalten hat. Die Kontrolle bremst den Normalfall nicht — zwei Owner räumen eine Warteschlange in Minuten ab — aber sie verhindert, dass der seltene Fall allein passiert.

Die Audit-Zeile

Vorschlag und Genehmigung speichern ihre jeweiligen Akteure und Zeitpunkte. Die Bankreferenz bleibt im Vorschlag und im Escrow-Dossier. Dossierereignisse und das verpflichtende Aktivitätsprotokoll machen die Entscheidung nachvollziehbar; das Protokoll kopiert die Bankreferenz nicht im Klartext. Genehmigung, Statusänderung und verpflichtendes Audit werden gemeinsam gespeichert.

Die Selbst-Sperre

Ein Vorschlagender kann nicht sein eigener Genehmiger sein. Der Server verweigert den zweiten Schritt aus demselben Konto mit einem Fehler „zweiter Owner erforderlich“, ganz gleich, was der Bildschirm gerade zeigte. Kleine Teams bekommen hier keine Ausnahme: Das zweite Augenpaar ist per Definition ein Platform Owner von ReVend, ein Tenant braucht also nie zwei von irgendetwas.

Dieselbe Regel fürs Stornieren

Ein ausstehendes Deposit vom Tisch zu nehmen wirkt ebenfalls auf Gelder, also folgt es demselben zweistufigen Muster mit Pflichtbegründung: Ein Owner schlägt die Stornierung vor, ein anderer genehmigt, und erst dann wird das Escrow storniert. Für den Fall, dass der normale Ablauf nicht zu Ende läuft, gibt es zwei Notfallhebel: eine Übersteuerung auf einer offenen Genehmigung, in einer eigenen Audit-Spalte erfasst, damit sie sich nie als reguläre Genehmigung tarnt, und eine erzwungene Stornierung für ein ausstehendes Deposit, das älter als 7 Tage ist — beide mit einer Begründung, die Teil der Spur wird. Unabhängig davon, ob jemand klickt, wird ein Deposit, das nach 7 Tagen noch aussteht, von einem täglichen Job storniert, und ein Auktionskäufer kassiert dafür einen Strike.

Was sie nicht abdeckt

Das Vieraugenprinzip gilt für die reguläre Bestätigung und Stornierung von Einzahlungen. Eine Freigabe folgt auf die Annahme des Käufers, eine Streitfallentscheidung oder die kontrollierte Ausnahme durch einen Platform Owner. Jede Aktion hat eigene Berechtigungs- und Auditprüfungen. Ein Softwarestatus beweist keine ausgeführte Banküberweisung.