أمر البيع بحد، ببساطة
أمر البيع بحد هو أمر مُعلّق لبيع أداة بسعر لا يزيد عن حد محدد (من جهة البيع). يصبح الأمر مؤهلاً للتنفيذ فقط عندما تصل تسعيرات السوق إلى مستوى الحد وفقًا لقواعد نظام التداول. وبعبارة أخرى: أنت تحدد ما هو السعر الذي تقبله كحد أقصى، ثم تقرر المنصة لاحقًا ما إذا كان التنفيذ سيحدث وكيف عندما تتحرك الأسعار.
وبما أن النتائج تعتمد على تفاصيل تشغيلية، فإن “تقييم” أمر البيع بحد يعني جمع البيانات الصحيحة لشرح (1) ما الذي يُفترض أن يفعله الأمر، (2) ما القواعد التي تحكم تفعيله وعمليات الملء، و(3) ما الذي قد يمنع تحقيق النتيجة المقصودة.
ما البيانات التي تحتاجها (المدخلات ومصدرها)
لتقييم أمر البيع بحد بشكل مستقل، اجمع أربع مجموعات من المدخلات.
- معلمات الأمر (آليات ثابتة)
- تحديد الأداة (الرمز الدقيق الذي تستخدمه المنصة). قد تكون الأدوات متشابهة لكنها ليست متطابقة (قد تختلف مواصفات العقد واصطلاحات الـ tick).
- سعر الحد (مستوى السعر الرقمي الذي تحدده).
- الكمية أو حجم المركز (كم تنوي بيعَه).
- جهة الأمر (بيع) ونوع الأمر (limit، pending).
- Time-in-force (مدة بقاء الأمر نشطًا).
- سياق الحساب (مثل ما إذا كانت المنصة تصف الأمر باستخدام مفاهيم الهامش/الرافعة) لأن ذلك قد يؤثر على التحقق والقيود.
- بيانات مرجعية للسعر (ما الذي تتم مقارنة الحد به)
- أساس مصدر الاقتباس: ما إذا كانت المنصة تستخدم منطق bid/ask لتفعيل أوامر البيع وكيف تربط سعر الحد باصطلاح الاقتباس الخاص بالأداة.
- قواعد التقريب وحجم الـ tick: كيف يتم تقريب الأسعار أو رفضها إذا لم تكن متوافقة مع الزيادات المسموح بها.
- اصطلاحات عرض العملة/الحساب: تأكد أن سعر الحد الذي تعتقد أنك أدخلته يطابق ما قامت المنصة بتخزينه فعليًا.
- قواعد تنفيذ المزود والمنصة (شروط متغيرة)
- آليات تفعيل الأمر المعلق: القاعدة التي تحدد متى يصبح أمر الحد قابلًا للتنفيذ (مثلًا عند الوصول إلى العتبة، باستخدام آخر سعر تم تداوله مقابل bid/ask، أو باستخدام تغذية تسعير).
- سلوك الملء: ما إذا كانت المنصة تسمح بـ الملء الجزئي، وكيف تُبلغ عن الكمية المتبقية، وكيف تُحدّث حالة الأمر.
- دورة حياة الأمر: انتقالات الحالة مثل placed، accepted، triggered، filled، canceled، أو rejected.
- التكلفة والقيود: الرسوم، والسبريد عند وقت التنفيذ، وأي فحوصات حد أدنى للمسافة/الأهلية قد تمنع الأمر من التصرف كما هو متوقع.
- السياق التشغيلي (الزمنية وجودة البيانات)
- أزمنة الإدخال: متى تم إنشاء الأمر ومتى تغيّر حالته.
- الاتصال وتحديث البيانات: دليل على ما إذا كان نظام الأوامر لديه وصول مستمر إلى الاقتباسات.
- سجل الأحداث أو التأكيدات: رسائل المنصة الخاصة بالقبول/الرفض وأي أسباب يتم تقديمها.
مثال على سير عمل تقييم (مع افتراضات صريحة)
افترض أنك تقوم بتقييم أمر بيع بحد وضعته على منصة وتريد شرح سبب تنفيذه أو عدم تنفيذه.
- الافتراض A (المعلمات المخزنة): استخدم تذكرة الأمر في المنصة للتأكد من الأداة والكمية وtime-in-force وسعر الحد بالقيمة الدقيقة كما تم تسجيله.
- الافتراض B (مقارنة التفعيل): استخدم توثيق المنصة (أو ملاحظات التنفيذ الخاصة بالأمر) للتأكد مما إذا كان تفعيل حد البيع يتم تقييمه مقابل bid أو ask أو اقتباس داخلي آخر.
- الافتراض C (ربط التنفيذ): راجع سجل الأوامر بحثًا عن حالات مثل “triggered” و“filled”، بما في ذلك الطوابع الزمنية وأسعار الملء.
- فحص الجودة: قارن أسعار الملء التي تعرضها المنصة (أو أسعار الملء) والكمية المتبقية بما تتوقعه تفسيراتك وفقًا لقاعدة التفعيل.
إذا لم يتفعّل الأمر أبدًا، يجب أن يركز التقييم على ما إذا كانت أساس تسعير السوق قد وصلت فعليًا إلى العتبة، أو ما إذا كان الأمر فشل في الأهلية بسبب قيود (مثل انتهاء time-in-force، أو أن التقريب/الـ tick منع الحد المقصود، أو أن المنصة لم تكن لديها اقتباسات قابلة للاستخدام في ذلك الوقت).
القيود والمخاطر (حالات فشل جوهرية)
حتى مع توفر بيانات جيدة، قد تمنع عدة قيود أمر البيع بحد من التصرف كما تتوقع.
- الانزلاق وعدم تطابق الاقتباس: قد يختلف السعر الذي تلاحظه عن السعر المستخدم داخليًا في اللحظة التي يتفعّل فيها الأمر أو يتم ملؤه. - الملء الجزئي والبواقي: قد يملأ أمر البيع بحد جزءًا من الكمية ويترك الباقي معلّقًا، لذا فإن “ما إذا كان قد تم تنفيذه” ليس دائمًا ثنائيًا. - الرفض الجزئي أو الكامل: قد ترفض المنصة أمرًا عند لحظة وضعه (معلمات غير صالحة، أو شروط غير مسموح بها) أو قد تلغيه لاحقًا بسبب قواعد دورة الحياة.