Delivery versus payment

لا تريد يانا إرسال BTC إلى بيتر قبل أن تتلقى المال، ولا يريد بيتر الدفع قبل استلام بيتكوين. تعالج DvP هذا الغموض من خلال قواعد التسوية، أي الوفاء الفعلي بالالتزامين. وتشترط المبادئ الدولية للبنى التحتية للأسواق المالية، PFMI، أن تكون التسوية النهائية لأحد الطرفين مشروطة بالتسوية النهائية للطرف الآخر. وتعني النهائية هنا حالة للتحويل تحددها قواعد النظام وإطاره القانوني؛ فقبول أمر التحويل وحده لا يكفي. ليست المسألة مجرد مطالبة الناس بأن يثق بعضهم ببعض أكثر. [1]

في مثال من إعدادنا، تتفق يانا وبيتر على ⁦1 BTC⁩ مقابل ⁦60,000 USD⁩؛ وهذا ليس عرض سعر حاليًا. لا يوفر بيتر المال المطلوب. عندئذ تمنع آلية DvP التي تعمل بصورة صحيحة يانا من تسليم بيتكوين تسليمًا لا يمكن الرجوع عنه ثم البقاء بلا مقابل. قد تظل الصفقة غير مسوّاة من دون أن تخسر البائعة الأصل الذي سلّمته. ويجب أن تحمي الآلية المشتري بالطريقة نفسها إذا لم يتوفر بيتكوين. هذه حماية من خسارة أصل المبلغ المتبادل، وليست وعدًا بنجاح كل اتفاق. [1]

عند وجود صفقات كثيرة، لا يلزم أن ينتج عن كل التزام تحويل نقدي منفصل. تعالج التسوية الإجمالية الالتزامات واحدًا واحدًا، بينما تتعامل التسوية الصافية مع الرصيد المتبقي بعد المقاصة بينها. تميّز BIS بين النموذج ⁦1⁩، الذي يسوّي الأصول والنقد بصورة فردية؛ والنموذج ⁦2⁩، الذي يسلّم الأصول فرديًا ويسوّي صافي الالتزام النقدي في نهاية الدورة؛ والنموذج ⁦3⁩، الذي يجري المقاصة على الجانبين. في النموذج الأوسط، يحافظ ضمان الدفع الذي يقدمه المشغّل على هذا الترابط. لذلك لا يعني التسليم المبكر مجرد انتظار المشتري بلا حماية. لكن اسم النموذج لا يغني عن تقييم قواعده وضمانه. [2]

قد يكون مال بيتر محجوزًا للصفقة، بينما لم تتلقّه يانا بعد. يقيّد الحجز استخدام الأموال مؤقتًا؛ ولا يمثل بحد ذاته تحويلًا نهائيًا. يمكن أن تعتمد DvP على تنسيق بين أنظمة أو على دورات للتسوية. تربط PFMI الحماية بالصلة بين الوفاء النهائي للجانبين، لا باشتراط إتمام كل شيء لحظة الضغط على زر. لذلك تهم أيضًا مدة الحجز وشروط رفعه عند تقييم خدمة معينة. [1] [2]

لا يلزم أن يعمل السجلان المترابطان في التطبيق نفسه. درست BIS وBank of England ذلك في Project Meridian عام ⁦2023⁩. ربط النموذج الأولي سجلًا عقاريًا بنظام RTGS، وهو نظام يسوّي المدفوعات فرديًا وبصورة مستمرة باستخدام أموال البنك المركزي. نسّق مشغّل للمزامنة تغيير ملكية العقار وتحويل الأموال بحيث يتوقف كل منهما على الآخر. كان ذلك نموذجًا أوليًا موثقًا وتجربة محددة للبنية التحتية. ولا يثبت أن كل خدمة تستخدم تسمية DvP توفر الحماية نفسها تلقائيًا. [3]

لا تحصل يانا وبيتر على DvP لمجرد الضغط على الإرسال في الوقت نفسه. تنتقل BTC وفق قواعد شبكة Bitcoin، بينما تخضع الأموال التقليدية لقواعد النظام المصرفي. يتعلق تأكيد معاملة Bitcoin بموقعها في السلسلة. تزيد التأكيدات الإضافية الحماية من تغيير هذا السجل، لكنها لا تؤكد الدفعة المصرفية. على الخدمة التي تقدم DvP بين BTC وعملة تقليدية أن تشرح الارتباط الفعلي بين الوفاء بالالتزامين وشروط نهائيتهما. ولا تنشئ صورة لأمر مصرفي أو معرّف لمعاملة Bitcoin هذا الارتباط. [1] [4]

إذا لم تتم الصفقة، فقد تحتفظ يانا ببيتكوين، لكن لا يتوفر لها المال لسداد دفعة مستحقة عليها. وقد تضطر إلى إيجاد مشترٍ آخر بسعر أسوأ. تعالج DvP خطر تسليم أصل المبلغ من دون الحصول على المقابل؛ ولا تزيل تكلفة الصفقة البديلة أو نقص السيولة. وتظل موثوقية التشغيل والقواعد القانونية والجهة التي تحتفظ بالأموال أثناء الانتظار أمورًا مهمة. لذلك لا تعني حماية التبادل ضمان سعر جيد أو إتاحة دائمة للخدمة أو وسيط لا يواجه مشكلات. [1] [2]

عند تقييم خدمة محددة، اعرف من يتحكم في بيتكوين والمال، وما الذي يطلق التحويل، ومتى يصبح الرجوع عنه من جانب واحد غير ممكن وفق القواعد المعمول بها. ثم افحص حالة غياب الدفع أو الأصل: ما الذي يظل محجوزًا، ومن يقرر، ومتى تعود الأموال متاحة لك؟ يشمل التحقق الجاد من DvP فشلًا بين الخطوات واستعادة التشغيل، لا مجرد عرض ناجح. هنا يظهر الفرق بين آلية موثقة وعبارة مطمئنة على الشاشة. [1] [3]