فحوص المخاطر قبل التداول داخل مسار الأوامر

يصل أمر إلى البوابة. وقبل خروجه إلى المنصة، لا بد لشيء ما أن يقرر هل يُسمح للحساب بإرساله. وهذا القرار يجري على كل أمر، بما في ذلك الغالبية العظمى السليمة تمامًا، فتدفع كلفتَه كل حركة المرور العادية لا الرفوض وحدها.

هذا هو القيد الذي يُسمّى أولًا. ففحص المخاطر الموضوع في مسار الأوامر ضريبة على إدخال الأوامر. والسؤال الهندسي ليس كيف نجعل الفحص ذكيًا، بل كيف نجعله صغيرًا بما يكفي ألا يشعر به المتداولون، وأمينًا بما يكفي ليظل يرفض الأوامر التي يجب رفضها.

ما ينتمي فعلًا إلى مسار الأوامر

المسار الساخن يجيب على سؤال واحد بالضبط: هل يجوز إرسال هذا الأمر الآن، بحسب ما نعرفه حاليًا عن هذا الحساب. والفحوص التي تجيب على هذا السؤال تبقى داخله. والفحوص التي تجيب على سؤال آخر تخرج منه.

• حدود المراكز والانكشاف - المركز الناتج في الأداة والمجموعة والحساب، مقارنًا بالحدود المعدَّة
• الهامش أو القوة الشرائية - هل لدى الحساب متسع للأمر وفق نموذج الهامش الحالي
• حدود fat-finger - حجم الأمر والقيمة الاسمية وبُعد السعر عن مرجع، لالتقاط الخطأ المطبعي قبل أن تلتقطه المنصة
• حالة الأداة والحساب - تداول موقوف، حساب مقيَّد، إغلاق فقط، منتج غير مفعَّل لهذا الحساب
• حالة الـ kill switch - راية واحدة تتجاوز كل ما سبق
• حواجز التكرار والتداول الذاتي حيث لا توفرها المنصة

كل ما عدا ذلك يعمل بجانب المسار، على الحالة نفسها، دون احتجاز الأمر. فهو يغذي الحدود التي يفرضها المسار الساخن، لكنه لا يقف بين المتداول والمنصة.

• تحليلات مخاطر المحفظة - تشغيل السيناريوهات، واختبارات الضغط، والانكشاف المترابط عبر الحسابات
• إعادة تسعير نموذج الهامش عند تغير المعاملات، وأي إعادة حساب تمسّ الدفتر كله
• المراقبة وكشف الأنماط، وهما يحتاجان تاريخًا لا يحمله المسار الساخن عمدًا
• التقارير والمطابقة وكل ما يخاطب قاعدة بيانات أو خدمة خارجية
• مراجعة الائتمان والطرف المقابل، وهي تعمل بطبعها على إيقاع أبطأ

أين تسكن حالة المركز، ولماذا قاعدة البيانات ليست على المسار

الحالة التي يحتاجها فحص ما قبل التداول - المراكز الحالية، والأوامر العاملة، والهامش المستخدم والمتاح، وإعداد الحدود - تسكن في ذاكرة العملية التي تتخذ القرار. لا في ذاكرة مؤقتة أمام قاعدة بيانات، ولا خلف نداء شبكي. في العملية نفسها.

السبب ليس السرعة وحدها، وإن كان الاستعلام أغلى بمراتب من بحث في مصفوفة محلية. السبب هو الصحة. فقاعدة البيانات تحفظ المركز كما كُتب. وفحص المخاطر يحتاج المركز شاملًا أوامر أُرسلت قبل لحظة ولم تُنفَّذ ولم يُقَرّ بها ولم تُخزَّن بعد. وإن قرأت من التخزين، فأنت تفحص مقابل ماضٍ تجاوزه تدفقك أنت.

عمليًا، يشكّل ذلك العملية كما يُشكَّل أي مكوّن منخفض الـ latency:

• كاتب واحد لكل حساب. تُوزَّع الحسابات على نسخ المخاطر بحيث لا تتنازع حالة الحساب أبدًا، ولا يُؤخذ أي قفل على مسار الأوامر
• بنى مسطحة مخصَّصة مسبقًا - مصفوفات ثابتة الحجم مفهرسة بمعرّف الحساب والأداة، تُحسم عند بدء الجلسة، لا عمليات بحث hash على نصوص تُبنى لكل أمر
• لا تخصيص ولا إدخال/إخراج ولا تسجيل يحجب على مسار القرار؛ ويُسلَّم سجل التدقيق إلى خيط آخر عبر طابور
• الإعدادات التي تتغير دون إعادة تشغيل تُستبدل كلقطة كاملة غير قابلة للتغيير، فلا يقرأ الفحص أبدًا حدًا محدَّثًا نصف تحديث

قاعدة البيانات هي حيث يُسجَّل المركز. وليست حيث يُعرَف المركز.

إعادة حساب تزايدية، لا تمريرة كاملة

إعادة الحساب الكاملة لانكشاف الحساب وهامشه تمرّ على كل مركز وكل أمر عامل. وتنمو هذه الكلفة مع حجم الدفتر، ما يعني أن فحص المخاطر يصبح أبطأ تحديدًا لدى العملاء الأكثر تداولًا. لذلك لا يعيد المسار الساخن الحساب، بل يطبّق فرقًا تزايديًا.

يحمل الحساب مجاميع جارية - الانكشاف الصافي والإجمالي لكل أداة ولكل مجموعة، والهامش المستخدم، والقيمة الاسمية في الطريق. والأمر الوارد ينتج تغيرًا صغيرًا في تلك المجاميع، فتُقارن القيم المتغيرة بالحدود، ويُقبل الأمر أو يُرفض. والعمل يتناسب مع الأمر، لا مع المحفظة.

• عند الإرسال، يُحجز أسوأ أثر ممكن للأمر مقابل المجاميع، فلا يمكن لأمرين في الطريق أن يتسعا معًا في المتسع المتبقي نفسه
• عند الرفض أو الإلغاء أو الانتهاء، يُحرَّر الحجز؛ وعند التنفيذ، يحل محل الحجز التغير الفعلي في المركز
• التنفيذات الجزئية تعدّل الجانبين في خطوة واحدة، وهنا تسكن فعليًا معظم علل هذا النوع من المحركات
• قواعد المقاصة والتجميع تُحسم عند تحميل الأداة، لا لكل أمر، فيصير الفرق حفنة عمليات حسابية

إعادة الحساب الكاملة تظل تحدث - وفق جدول، وعند تغير معاملات الهامش، وكفحص ذاتي دوري مقابل النتيجة التزايدية. تعمل خارج المسار، على نسخة، ونتيجتها إما تُستبدل أو تُرفع كتباين. فالحالة التزايدية التي تنحرف بصمت عن الحالة الحقيقية أسوأ من غياب الفحص أصلًا، لذا فالمقارنة ليست اختيارية.

الـ kill switch مسار منفصل

يُستخدم الـ kill switch تحديدًا حين يكون شيء ما معطلًا بالفعل. وهذا يمنع بناءه فوق الآلية التي قد تكون هي نفسها المعطلة. إنه مسار منفصل بقواعده الخاصة.

• إنه راية ذرية واحدة تُقرأ في رأس الفحص، قبل مسّ حالة المركز أو الهامش أو بيانات الأداة - فيعمل حتى حين تكون تلك قديمة أو مفقودة أو معطلة
• يُفعَّل من عدة مُطلِقات مستقلة: إجراء مشغّل، أو شرط آلي، أو فقدان تغذية بيانات السوق أو التنفيذات التي تعتمد عليها حالة المخاطر
• يفشل مغلقًا. فإن لم تستطع عملية المخاطر إثبات أن حالتها صالحة، تتصرف البوابة كأن المفتاح مفعَّل
• له نطاقات - الشركة كلها، أو مكتب واحد، أو حساب واحد، أو استراتيجية واحدة - لأن مفتاحًا لا يوقف إلا كل شيء يُستخدم متأخرًا جدًا
• تفعيله إجراء واحد وتأكيد واحد، لا نشر إعدادات؛ وإلغاء تفعيله متعمد ويُسجَّل دائمًا

إيقاف الأوامر الجديدة هو النصف السهل. أما النصف الأصعب فما يفعله المفتاح بالأوامر الراكدة أصلًا لدى المنصة: سحب التسعيرات وإلغاء الأوامر العاملة يجب أن يظل ممكنًا بينما مسار الإرسال معطّل. ويستحق مسار الإلغاء ذاك اختبارًا خاصًا به، لأنه يُستخدم في أسوأ يوم لا في يوم عادي.

إعادة التشغيل، وكيف تعود الحالة

الحالة في الذاكرة رؤية مشتقة من سجل دائم. وهذا ما يجعل إعادة التشغيل قابلة للنجاة. فكل حدث يغيّر حالة المخاطر - قبول أمر، أو تحرير حجز، أو تطبيق تنفيذ، أو تغيير حد، أو تفعيل المفتاح - يُلحَق بسجل على الجهاز المحلي قبل التصرف بناءً عليه في اتجاه المصب.

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

عندئذ يعتمد زمن الاسترداد على طول السجل وتوافر نسخة الـ drop copy، لا على حجم الدفتر، ونمط الفشل عند كل مجهول واحد: رفض التداول على الحساب.

ما لا يمنحك إياه هذا التصميم

الحدود الأمينة تستحق أن تُقال بصراحة، لأنها تقرر هل تناسب هذه البنية أصلًا:

• الفحص صحيح بقدر صحة تغذية التنفيذات. فإن تأخرت الـ drop copy أو تقارير التنفيذ، صار الانكشاف مبخوسًا، والاستجابة الصحيحة هي النزول إلى حدود متحفظة أو تفعيل المفتاح بدل مواصلة التداول على حالة قديمة
• نماذج هامش المحفظة غير الجمعية فعلًا تقاوم التقييم التزايدي. وما ينفع هو حد تزايدي متحفظ على المسار مع نموذج كامل خارجه؛ والثمن أن تُرفض بعض الأوامر التي كان النموذج الكامل ليسمح بها
• المفتاح يحمي من تدفقك أنت، لا من السوق. ولا يمكنه منع فجوة أو انزلاق على مراكز تملكها أصلًا
• الحالة داخل العملية تعني أن محرك المخاطر وبوابة الأوامر يتشاركان المصير. وهذا يشتري latency ويكلفك القدرة على توسيعهما بشكل مستقل
• التقسيم بكاتب واحد لكل حساب يصعّب الحدود العابرة للحسابات، وتحتاج فحوص مستوى الشركة طبقة تجميع أبطأ بقِدَمها الخاص
• إنه عمل تشغيلي أكثر من فحص مدعوم بقاعدة بيانات: سجلات، ومطابقة، وتمارين ترقية النسخة الاحتياطية. وإن لم يكن إدخال الأوامر حساسًا للـ latency، فهذا التعقيد لا يستحق الشراء

تبني amBrain هذا النوع من مسارات المخاطر قبل التداول للوسطاء وشركات التداول الخاص، بمسارات ساخنة مكتوبة بلغة Rust. ويعمل الفريق على بنية التداول التحتية من يريفان، أرمينيا منذ 2019.