DIE ZAHLUNG WAR ECHT.
DER BELEG WAR ECHT.
TROTZDEM WÜRDE ICH DIE BESTELLUNG NICHT FREIGEBEN.
So kann eine P2P-Situation aussehen, die auf den ersten Blick komplett sauber wirkt.
Ein Verkäufer hat zwei USDT-Bestellungen offen, die ungefähr zur gleichen Zeit laufen.
Bestellung A wartet auf die Zahlung.
Bestellung B ist ebenfalls aktiv.
Dann schickt ein Käufer eine Banküberweisung und postet den Beleg im Binance-P2P-Chat.
Nichts wirkt gefälscht.
Das Geld ist wirklich beim Bankkonto des Verkäufers eingetroffen.
Der Beleg stammt wirklich von einer erfolgreichen Überweisung.
Sogar der Betrag wirkte angemessen.
Es wäre sehr leicht zu denken:
„Zahlung bestätigt. Freigeben.“
Aber bevor man Freigeben antippt, gibt es noch eine Frage:
Zu welcher Bestellung gehört diese Zahlung tatsächlich?
An genau diesem Punkt ändert sich die Situation.
Wenn der Verkäufer den Absender, den Betrag, die Order-ID und die beiden aktiven Bestellungen vergleicht, passt die Zahlungszeile zu der anderen Transaktion.
Die Zahlung ist echt.
Der Nachweis ist echt.
Aber zusammen werden sie benutzt, um die falsche Bestellung so aussehen zu lassen, als sei sie bezahlt.
Also stoppt der Verkäufer.
Kein Raten.
Keine Freigabe zuerst und dann später sortieren.
Beide Gespräche bleiben innerhalb von Binance P2P. Der Verkäufer behält die zwei Order-IDs, die Banktransaktion und den Chatverlauf zusammen, während die Krypto durch den Bestellprozess geschützt bleibt.
Wenn die Zuordnung immer noch nicht eindeutig geklärt werden kann, ist dafür Appeal/Support da.
Was ich an Fällen wie diesem interessant finde, ist, dass „gefälscht vs. echt“ in P2P nicht immer die schwerste Frage ist.
Manchmal kann jedes einzelne Beweisstück echt sein.
Der Fehler besteht darin anzunehmen, dass diese Teile zu derselben Transaktion gehören.
Bevor ich Release mache, würde ich lieber eine zusätzliche Frage beantworten:
Nicht nur „Ist das Geld angekommen?“
Sondern:
„Welche ganz genaue Bestellung hat dieses Geld ausgeglichen?“
@Binance Vietnam #BinanceP2PAnToan
DER BELEG WAR ECHT.
TROTZDEM WÜRDE ICH DIE BESTELLUNG NICHT FREIGEBEN.
So kann eine P2P-Situation aussehen, die auf den ersten Blick komplett sauber wirkt.
Ein Verkäufer hat zwei USDT-Bestellungen offen, die ungefähr zur gleichen Zeit laufen.
Bestellung A wartet auf die Zahlung.
Bestellung B ist ebenfalls aktiv.
Dann schickt ein Käufer eine Banküberweisung und postet den Beleg im Binance-P2P-Chat.
Nichts wirkt gefälscht.
Das Geld ist wirklich beim Bankkonto des Verkäufers eingetroffen.
Der Beleg stammt wirklich von einer erfolgreichen Überweisung.
Sogar der Betrag wirkte angemessen.
Es wäre sehr leicht zu denken:
„Zahlung bestätigt. Freigeben.“
Aber bevor man Freigeben antippt, gibt es noch eine Frage:
Zu welcher Bestellung gehört diese Zahlung tatsächlich?
An genau diesem Punkt ändert sich die Situation.
Wenn der Verkäufer den Absender, den Betrag, die Order-ID und die beiden aktiven Bestellungen vergleicht, passt die Zahlungszeile zu der anderen Transaktion.
Die Zahlung ist echt.
Der Nachweis ist echt.
Aber zusammen werden sie benutzt, um die falsche Bestellung so aussehen zu lassen, als sei sie bezahlt.
Also stoppt der Verkäufer.
Kein Raten.
Keine Freigabe zuerst und dann später sortieren.
Beide Gespräche bleiben innerhalb von Binance P2P. Der Verkäufer behält die zwei Order-IDs, die Banktransaktion und den Chatverlauf zusammen, während die Krypto durch den Bestellprozess geschützt bleibt.
Wenn die Zuordnung immer noch nicht eindeutig geklärt werden kann, ist dafür Appeal/Support da.
Was ich an Fällen wie diesem interessant finde, ist, dass „gefälscht vs. echt“ in P2P nicht immer die schwerste Frage ist.
Manchmal kann jedes einzelne Beweisstück echt sein.
Der Fehler besteht darin anzunehmen, dass diese Teile zu derselben Transaktion gehören.
Bevor ich Release mache, würde ich lieber eine zusätzliche Frage beantworten:
Nicht nur „Ist das Geld angekommen?“
Sondern:
„Welche ganz genaue Bestellung hat dieses Geld ausgeglichen?“
@Binance Vietnam #BinanceP2PAnToan