ما البيانات المطلوبة لتقييم سعر التنفيذ؟

التعريف وما الذي تقوم بتقييمه فعليًا

سعر التنفيذ هو السعر الفعّال الذي يتم عنده تنفيذ الأمر. في الواقع، غالبًا ما تهتم به باعتباره ما دفعته/ما استلمته مقابل الكمية المتداولة، بعد احتساب اصطلاح تسعير السوق وأي تكاليف مرتبطة بالتنفيذ يتم تحديدها نتيجة التنفيذ.

لتقييم سعر التنفيذ بدقة دون افتراض أي بيانات لحظية، تحتاج إلى مجموعة واضحة من المدخلات، ومصدرها (من أين جاءت)، ومدى حداثتها أو قدمها.

المدخلات التي تحتاجها (قائمة البيانات الأساسية)

آليات الأمر (مدخلات ثابتة)

تحديد الأداة: زوج العملات (مثل EUR/USD) بحيث يكون اصطلاح التسعير واضحًا بلا لبس.
جهة الأمر ونوعه: شراء مقابل بيع، وما إذا كان الأمر مُعدًا للتنفيذ عند السعر السائد في السوق أو تحت قيود محددة.
الكمية المطلوبة: مقدار محاولة الأمر للتداول، لأن الـ partial fills يمكن أن تغيّر النتيجة الفعّالة.
الاتجاه المتوقع للتسعير: في FX، تعتمد نتائج التنفيذ على ما إذا كنت تدفع ask (عند الشراء) أو تستلم bid (عند البيع). حدّد هذا قبل دمج أي أرقام.

بيانات مرجعية للسوق (مدخلات متغيرة)

اقتباسات bid/ask المستخدمة لاستدلال التنفيذ: إما تيار الاقتباس الذي ستتعامل معه كمرجع، أو حقول “تقرير التنفيذ” الخاصة بالوسيط/المنصة التي تصف أي اقتباس استخدمه النظام.
مرجع الوقت: الطابع الزمني المرتبط بالتنفيذ (أو بالاقتباس الذي تقوم بنمذجته). سعر التنفيذ يعتمد على الزمن، لذا فإن لحظة الإسناد الدقيقة مهمة.
سياق السيولة والتقلب (كمدخلات، لا كتنبؤات): لا تحتاج إلى التنبؤ، لكن تحتاج إلى معرفة أن الفترة ذات الصلة قد تكون شهدت سبريدًا أوسع أو عمقًا أقل.

تكاليف مرتبطة بالتنفيذ (غالبًا ما تُفهم بشكل خاطئ)

مكوّن السبريد: الفرق بين bid وask في اللحظة ذات الصلة.
العمولات/الرسوم: أي تكاليف ثابتة أو لكل صفقة تؤثر على السعر الفعّال الذي يجب أن تقارنه بمرجعك.
التمويل/التعديلات (فقط إذا كانت قابلة للتطبيق على مقارنتك): إذا كنت تقيم “سعرًا اقتصاديًا فعّالًا” عبر فترة احتفاظ، دوّن مجموعة القواعد التي تستخدمها؛ وإلا ركّز على سعر التنفيذ نفسه.

المصدرية: من أين جاء كل مدخل

بالنسبة لكل عنصر بيانات أعلاه، سجّل مصدرية البيانات:

مصدر حقول الأمر: سجل تذكرة الأمر/طلب الأمر مقابل عرض ملخص.
مصدر bid/ask أو اقتباس التنفيذ: ما إذا كان جاء من موجّه بيانات سوق تتحكم فيه، أو من تقارير التنفيذ المقدمة من مزوّد/منصة.
مصدر الطوابع الزمنية: تأكد من المنطقة الزمنية/الصيغة وما إذا كانت الطوابع الزمنية تعكس “متى تم توليد الاقتباس” أو “متى تم تسجيل التنفيذ”.

إذا قمت بخلط مصادر ذات اصطلاحات مختلفة (على سبيل المثال، مصدر يضع الطوابع الزمنية في UTC ومصدر آخر في وقت محلي)، يمكنك ما زال حساب شيء ما، لكن قد لا يتوافق ذلك مع لحظة التنفيذ الحقيقية.

فحوصات التوقيت والجودة (كيفية التحقق من المدخلات)

على الأقل، طبّق هذه الفحوصات:

فحص الاكتمال: يجب أن يكون لديك (أ) الأداة، (ب) الجهة، (ج) كمية التنفيذ، (د) أساس الاقتباس (bid أو ask)، و(هـ) الطابع الزمني ذي الصلة.
فحص الاتساق: تحقّق أن منطق الشراء/البيع يتوافق مع استخدام bid/ask. إذا كانت الجهة “buy”، فتأكد أن مرجعك يستخدم ask؛ وإذا كانت الجهة “sell”، فتأكد أن مرجعك يستخدم bid.
فحص التقادم: إذا كانت الاقتباسات مأخوذة من وقت أقدم من طابع التنفيذ الزمني، اعتبر ذلك افتراضًا ووسم سعر التنفيذ الناتج بأنه تقدير مبني على بيانات قديمة.
فحص التجميع: إذا كانت هناك عمليات تنفيذ متعددة (partial fills)، احسب سعر التنفيذ كنتاج موزون بالكمية، واذكر ما إذا كانت مقارنتك تستخدم إجمالي الكمية المنفذة.

دليل أو مثال (مع افتراضات صريحة)

افترض سيناريو مبسط مع عمليتي تنفيذ لنفس الأداة والأمر:

التنفيذ 1: شراء كمية 1,000 وحدة بسعر ask مرجعي قدره 1.0950.
التنفيذ 2: شراء كمية 2,000 وحدة بسعر ask مرجعي قدره 1.0960.
افترض عدم وجود عمولات وحدد سعر التنفيذ على أنه المتوسط المرجّح بالكمية للكمية المنفذة باستخدام ask للعمليات الشرائية.

عندها يكون سعر التنفيذ الموزون بالكمية:

(1,000 × 1.0950 + 2,000 × 1.0960) / 3,000
= (1.0950 + 2 × 1.0960) / 3
= (1.0950 + 2.1920) / 3
= 3.2870 / 3
= 1.095666…

النقطة الأساسية: هذا المثال صحيح فقط في ظل الافتراضات المذكورة حول اصطلاح bid/ask، ومعالجة الرسوم، واستخدام مستويات الاقتباس المرتبطة بكل لحظة تنفيذ.

DOCUMENT END