مرجع: Developing High-Frequency Trading Systems

مقدمه

در فصل گذشته، با مبانی و استراتژی‌های معاملات فرکانس بالا (HFT) آشنا شدیم. در این فصل، چگونگی تبدیل این استراتژی‌های تئوریک به یک نرم‌افزار بی‌درنگ (Real-Time Software) را بررسی خواهیم کرد؛ نرم‌افزاری که مستقیماً به بورس و صرافی متصل شده و تئوری‌های آموخته‌شده را در عمل پیاده‌سازی می‌کند. ما عملکرد درونی یک سیستم معاملاتی کامل را که قادر به دادوستد دارایی‌هاست تشریح می‌کنیم.

در این فصل مباحث زیر به طور جامع پوشش داده می‌شوند:

  • شناخت و درک ساختار سیستم معاملاتی (Understanding the trading system)
  • برقراری ارتباط معاملاتی با صرافی‌ها (Making a trading system trade with exchanges)
  • مدیریت و مهندسی دفترچه سفارشات (Order book management)
  • موتور تصمیم‌گیری استراتژی برای معامله (Strategy making decisions on when to trade)

در پایان این فصل، شما قادر خواهید بود معماری یک سیستم معاملاتی را طراحی کنید، آن را به صرافی متصل نمایید و یک دفترچه سفارشات محدود (Limit Order Book) با کارایی بالا بسازید.


۱. شناخت سیستم معاملاتی (Understanding the Trading System)

طراحی یک سیستم معاملاتی برای حوزه HFT نیازمند دانشی بسیار فراتر از برنامه‌نویسی عادی و معامله‌گری سنتی است. یکی از مهم‌ترین گام‌ها در طراحی، داشتن توصیف دقیقی از نیازمندی‌ها (Requirements) است:

  • هدف نهایی سیستم، پشتیبانی فنی از ایده‌های معاملاتی شماست.
  • هر استراتژی معاملاتی با دریافت داده‌های بازار آغاز می‌شود و با اتخاذ یک تصمیم بر مبنای این داده‌ها پایان می‌یابد.
  • سیستم وظیفه جمع‌آوری داده‌های بازار (تغییرات لحظه‌ای قیمت یا Price Updates)، ارسال سفارش‌ها به صرافی و جمع‌آوری پاسخ‌های دریافتی از صرافی را بر عهده دارد.
  • این پاسخ‌ها نشان‌دهنده وضعیت‌های گوناگون سفارش هستند: لغوشده (Canceled)، ردشده (Rejected)، معامله‌شده کامل (Filled) یا معامله‌شده جزئی (Partially Filled).
  • علاوه بر این، سیستم باید سنجه‌های عملکرد سبد دارایی نظیر سود و زیان (PnL)، معیارهای مدیریت ریسک و وضعیت سلامت فرآیندهای نرم‌افزاری را به صورت آنی محاسبه کند.

ملاحظات کلیدی در آغاز طراحی سیستم:

۱. کلاس دارایی (Asset Class)

کلاس دارایی انتخابی، ساختار داده‌ای کل نرم‌افزار شما را تغییر می‌دهد. هر کلاس دارایی ماهیت و ویژگی‌های انحصاری خود را دارد:

  • بازار سهام آمریکا (US Equities): عمدتاً روی دو بورس غول‌پیکر متمرکز است: بورس نیویورک (NYSE) و نزدک (NASDAQ). این دو بورس روی هم حدود ۷٬۰۰۰ شرکت (نماد معاملاتی) را فهرست کرده‌اند.
  • بازار تبادلات ارزی (FX): ساختاری کاملاً متفاوت دارد؛ دارای ۶ جفت‌ارز اصلی (Major)، ۶ جفت‌ارز فرعی (Minor) و ۶ جفت‌ارز نامتعارف (Exotic) است. حتی با احتساب سایر ترکیب‌ها، کل نمادها کمتر از ۱۰۰ جفت‌ارز است؛ اما بر خلاف سهام آمریکا که دو بورس اصلی دارد، در فارکس با صدها صرافی، بانک و شبکه ECN پراکنده در سراسر جهان روبه‌رو هستیم.
  • این تفاوت اساسی میان «تعداد نمادها» و «تعداد بورس‌ها»، معماری سیستم معاملاتی شما را دگرگون می‌کند.

۲. نوع استراتژی معاملاتی (افق فرکانس بالا در برابر پوزیشن بلندمدت)

معماری نرم‌افزار به شدت از سبک معامله‌گری تأثیر می‌پذیرد:

  • تاکتیک‌های HFT نیازمند ارسال سفارش در کسری ناچیز از زمان هستند. در سهام آمریکا، یک سیستم معاملاتی معمولی در مقیاس میکروثانیه تصمیم به ارسال سفارش می‌گیرد؛ اما در بورس مشتقات شیکاگو (CME)، تاخیر رقابتی در مقیاس نانوثانیه سنجیده می‌شود!
  • با چنین سرعتی، زبان‌های برنامه‌نویسی تفسیری مانند پایتون به تنهایی پاسخگوی سرعت نخواهند بود و زبان‌هایی مانند ++C یا Java ترجیح داده می‌شوند.
  • در مقابل، اگر استراتژی شما نگهداری پوزیشن‌های چندروزه یا ماهانه باشد، سرعت دستیابی به نقدینگی در کسری از ثانیه کوچک‌ترین اهمیتی ندارد.

۳. تعداد کاربران و تاکتیک‌های معاملاتی (مقیاس‌پذیری)

با افزایش تعداد معامله‌گران و گوناگونی استراتژی‌ها، ترافیک سفارش‌ها سرسام‌آور می‌شود. سیستم پیش از ارسال هر سفارش به صرافی باید بررسی‌های امنیتی انجام دهد:

  • بررسی اعتبار سفارش (فرمت، قیمت و حجم).
  • اطمینان از اینکه حجم کلی پوزیشن برای آن ابزار از سقف مجاز ریسک فراتر نرود.
  • کنترل‌های انطباق مقرراتی (Compliance Tests) برای پایبندی به قوانین بورس.
  • تمامی این بررسی‌ها زمان محاسباتی را افزایش می‌دهند؛ بنابراین اگر سیستم به اندازه کافی مقیاس‌پذیر و سریع نباشد، سفارش‌ها در صف پردازش معطل شده و فرصت‌های سودآور از دست می‌روند.

معماری کلان سیستم معاملاتی (Trading System Architecture)

شکل زیر معماری پایه‌ای یک سیستم معاملاتی را به تصویر می‌کشد:

شکل ۲.۱: معماری کلان یک سیستم معاملاتی

اجزای تشکیل‌دهنده:

  1. پلتفرم‌های مبادله (Venues): اصطلاحی جامع برای هر سامانه‌ای که سفارش‌های خرید و فروش را جفت می‌کند؛ شامل بورس‌های رسمی (Exchanges)، شبکه‌های ECN، تجمیع‌کننده‌ها (Aggregators) و بانک‌ها.
  2. درگاه‌ها (Gateways): نرم‌افزاری که وظیفه ارتباط با پلتفرم‌ها، دریافت قیمت‌ها و شلیک سفارش‌ها را بر عهده دارد.
  3. دفترچه‌ساز (Book Builder): داده‌های خامی که درگاه‌ها از بورس دریافت کرده‌اند را تجمیع کرده و یک دفترچه سفارشات محدود (Limit Order Book) مرتب و یکپارچه می‌سازد.
  4. استراتژی معاملاتی (Strategy): مغز تحلیل‌گر که سیگنال معامله را بر اساس دیتای دفترچه صادر می‌کند.
  5. مدیریت سفارشات (Order Manager / OMS): تمامی سفارش‌های برآمده از استراتژی‌ها را گردآوری کرده و چرخه حیات سفارش را تا انتها دنبال می‌کند.
  6. مسیر بحرانی (Critical Path): زنجیره میان درگاه، دفترچه‌ساز، استراتژی و OMS در مسیر بحرانی سیستم قرار دارند؛ هر نانوثانیه تاخیر در این مسیر، ضررهای مالی هنگفتی به دنبال خواهد داشت.
  7. سرویس‌های نظارتی (Viewers & Command and Control): نمایشگرهای مانیتورینگ برای پایش سلامت فرآیندها و هشدارهای آنی.

۲. درگاه‌های اتصال به بورس‌ها (Gateways)

درگاه‌ها حریص‌ترین و پرمصرف‌ترین بخش سیستم از حیث منابع پردازشی و زمان اجرا هستند. آن‌ها داده‌ها را از کارت شبکه می‌گیرند و پس از تبدیل، به بدنه سیستم تحویل می‌دهند:

جمع‌آوری داده‌ها (Data Collection)

درگاه وظیفه دارد قیمت‌ها را از بورس‌ها، ECNها و دارک‌پول‌ها گردآوری کند.

شکل ۲.۲: درگاه‌های مسئول جمع‌آوری تغییرات قیمت و ارسال سفارش‌ها

  • پیکان‌های جریان داده دوطرفه هستند؛ دریافت مظنه‌ها از بورس، و ارسال سفارش‌ها به بورس.
  • برای آغاز دریافت قیمت، درگاه ابتدا اتصال شبکه با صرافی برقرار می‌کند، احراز هویت (Authentication) می‌شود و سپس در ابزار مالی مورد نظر مشترک (Subscribe) می‌گردد.

شکل ۲.۳: اجزای عملکردی سیستم معاملاتی و تعامل درگاه با جهان خارج

فرآیند چرخه تبادل در درگاه سفارشات:

  • هنگام ثبت سفارش، درگاه پیام را از طریق شبکه به سمت صرافی ارسال می‌کند.
  • اگر صرافی پیام را دریافت کند، یک پیام تاییدیه (Acknowledgment) بازمی‌گرداند.
  • هنگامی که سفارش با سفارش دیگری در صرافی جفت شد، پیام اجرای معامله ارسال می‌شود.
  • اگر درگاه پاسخی از صرافی دریافت نکند، سیستم باید سفارش را منقضی‌شده (Timed Out) اعلام کند تا معامله‌گر انسانی بتواند سریعاً مداخله کرده و علت نقص شبکه را بررسی نماید.

بسترهای فیزیکی ارتباط و هم‌مکانی (Colocation)

شکل ۲.۴: ارتباط میان صرافی و سیستم معاملاتی

  • سیستم معاملاتی روی رایانه شما و موتور تطبیق صرافی روی رایانه دیگری در مکانی دیگر است.
  • در شرایط هم‌مکانی (Colocation): اگر سرورهای تریدر دقیقاً در دیتاسنتر صرافی مستقر شوند، یک کابل اختصاصی مستقیم میان آن‌ها کشیده می‌شود که تاخیر فیزیکی را به کمترین حد ممکن می‌رساند.
  • در شرایط ابری (Cloud): ارتباط از بستر عمومی اینترنت می‌گذرد که نسبت به اتصال مستقیم به شدت کندتر و متغیر است.

۳. پروتکل‌ها و APIهای ارتباطی

پروتکل‌های شبکه قواعد تعامل میان رایانه‌ها را تعیین می‌کنند. در بازارهای مالی از سطوح زیر استفاده می‌شود:

  • لایه فیزیکی (Physical Media):
    • سیم مسی (Wire): جریان الکتریکی، پهنای باند کم.
    • فیبر نوری (Fiber): سرعت نور و پهنای باند بالا.
    • مایکروویو (Microwave): راه‌اندازی سریع با سرعت انتشار هوایی بالاتر از شیشه فیبر، اما آسیب‌پذیر در برابر شرایط نامساعد جوی و باران.
  • لایه شبکه و انتقال: پروتکل IP برای مسیریابی بسته‌ها، و پروتکل‌های TCP (اتصال مطمئن و بدون خطا) و UDP (ارسال فوق‌سریع بدون بررسی دریافت، ایده‌آل برای پخش زنده دیتای بازار).
  • لایه نرم‌افزاری (Financial APIs): صرافی سندی ارائه می‌دهد که فرمت پیام‌های لیمیت اردر، انصراف، دریافت قیمت و وضعیت‌ها را مشخص می‌کند (مانند پروتکل FIX یا باینری اختصاصی بورس).

۴. مدیریت و مهندسی دفترچه سفارشات (Order Book Management)

دفترچه سفارشات محدود (LOB) تمام به‌روزرسانی‌های قیمتی را دریافت و به شکلی ساختاریافته مرتب می‌کند تا الگوریتم بتواند در کمترین زمان تصمیم بگیرد.

شکل ۲.۵: ساختار دفترچه سفارشات و دریافت داده‌ها از درگاه

شکل ۲.۶: سیستم معاملاتی در حال تجمیع دفترچه از سه بازار مختلف

  • دفترچه دارای دو بخش است: سفارش‌های خرید (Bids) و سفارش‌های فروش (Offers/Asks).
  • برای هر سفارش: نام بازار (Venue)، حجم (Volume) و قیمت (Price) ذخیره می‌شود.
  • وظیفه دفترچه‌ساز (Book Builder): جمع‌آوری سه دفترچه مجزا از سه بورس مختلف و ساخت یک دفترچه ادغام‌شده و واحد.

نحوه دریافت به‌روزرسانی‌های دفترچه از بورس

از آنجا که در بورس‌های بزرگی مانند NYSE و نزدک میلیون‌ها سفارش در هر ثانیه رد و بدل می‌شود، ارسال کل دفترچه (Full Book) با هر سفارش جدید، پهنای باند شبکه را فوراً فلج می‌کند. راهکار صرافی‌ها به این صورت است:

  1. در آغاز اتصال، یک عکس فوری کامل (Full Snapshot) از وضعیت موجود دفترچه فرستاده می‌شود.
  2. سپس، صرافی منحصراً تغییرات افزایشی لحظه‌ای (Incremental Updates) شامل درج سفارش جدید، تغییر حجم یا لغو سفارش را مخابره می‌کند.

سه عملیات بنیادین در دفترچه:

  1. درج (Insertion): افزودن سفارش جدید به دفترچه. نیازمند ساختار داده‌ای با مرتبه پیچیدگی زمانی یا حداکثر .
  2. اصلاح (Amendment): جستجوی سریع سفارش بر اساس شناسه (Order ID) و تغییر حجم یا قیمت.
  3. ابطال (Cancelation): بیرون کشیدن و حذف سفارش از صف بر اساس Order ID.

الزامات طراحی ساختار داده بهینه برای Order Book در HFT

برای دستیابی به بیشترین سرعت، ساختار داده دفترچه باید شرایط زیر را تضمین کند:

  • جستجوی با زمان ثابت () برای شناسه سفارش: به دلیل مواجهه با میلیون‌ها سفارش در ثانیه، جستجوی Order ID برای به‌روزرسانی باید بدون تاخیر باشد.
  • شاخص‌گذاری سریع قیمت‌ها: برای پیمایش در میان سطوح قیمتی باید شاخص‌بندی لگاریتمی باشد تا سطوح بهترین قیمت به سرعت استخراج شوند.
  • دسترسی زمان ثابت به بهترین قیمت (BBO - Best Bid and Offer): الگوریتم‌ها بیش از ۹۰٪ اوقات فقط با لایه اول دفترچه (بهترین خرید و فروش) کار دارند؛ بنابراین بازگرداندن BBO باید زمان ثابت () داشته باشد.

ترفندهای مهندسی سطح پایین در ++C:

  1. آرایه انجمنی عظیم: نگاشت شناسه سفارش به متادیتای آن در یک std::unordered_map یا یک std::vector بزرگ.
  2. ارجاع مستقیم: متادیتای سفارش شامل ارجاع مستقیم به دفترچه و سطح قیمتی مربوطه است؛ بنابراین پیدا کردن سطح قیمت تنها با یک ارجاع ساده (Single Dereference) حافظه انجام می‌شود و عمل کاستن حجم () است.
  3. استفاده از بردار (std::vector) به جای درخت در سطوح قیمت:
    • از آنجا که عمده تغییرات در لایه‌های ابتدایی (نزدیک به داخل دفترچه) رخ می‌دهد، نگهداری سطوح قیمت در یک وکتور و جستجوی خطی (Linear Search) از انتهای وکتور به طور میانگین از جستجوی دودویی (Binary Search) سریع‌تر است!
    • دلیل: جستجوی خطی در حافظه پیوسته برای پیش‌بینی‌کننده انشعاب CPU (Branch Predictor)، بهینه‌ساز کامپایلر و کش پردازنده (CPU Cache & TLB) بسیار سازگارتر است و از Cache Miss جلوگیری می‌کند. در بدترین حالت ممکن یک کپی سریع حافظه (memcpy) رخ می‌دهد، اما رفتار میانگین به شدت به نزدیک است.

۵. تصمیم‌گیری استراتژی برای معامله (Trading Strategy)

استراتژی مغز متفکر سیستم است؛ جایی که الگوریتم معاملاتی شما جان می‌گیرد.

شکل ۲.۷: استراتژی معاملاتی در حال دریافت داده از دفترچه‌ساز برای تصمیم‌گیری ورود به معامله

استراتژی به دو بخش کاملاً مجزا تقسیم می‌شود:

  1. بخش سیگنال (Signal Component): این بخش صرفاً به کشف فرصت‌ها و تولید سیگنال‌های خرید یا فروش می‌پردازد. با این حال، داشتن سیگنال هرگز به معنای تضمین دریافت نقدینگی نیست؛ در سرعت‌های بالای HFT، سفارش‌های شما بارها به دلیل رسیدن دیرتر به صرافی رد می‌شوند.
  2. بخش اجرا (Execution Component): این بخش مدیریت بازخوردها و پاسخ‌های دریافتی از بازار را به دست می‌گیرد. مثلاً اگر سفارش رد شد، فوراً تصمیم می‌گیرد که آیا تلاش برای شکار نقدینگی در قیمت دیگری ادامه یابد یا متوقف شود.

۶. سیستم مدیریت سفارشات (The OMS - Order Management System)

سیستم OMS تمام سفارش‌های تولیدشده توسط استراتژی را جمع‌آوری کرده و کل چرخه حیات آن‌ها را زیر نظر می‌گیرد:

شکل ۲.۸: مدیر سفارشات در حال گردآوری کلیه سفارش‌ها در سیستم معاملاتی

وظایف حیاتی OMS:

  • پایش مراحل سفارش: ایجاد (Creation)، اجرا (Execution)، اصلاح (Amendment)، ابطال (Cancelation) و رد شدن (Rejection).
  • فیلتر و اعتبارسنجی پیش از ارسال (Pre-trade Risk Validation): اگر سفارشی ناقص یا نامعتبر باشد (مثلاً حجم بیش از حد مجاز، جهت معکوس اشتباه، قیمت‌های پرت، انباشت موقعیت فراتر از سقف مجاز، یا نوع سفارشی که توسط صرافی پشتیبانی نمی‌شود)، OMS آن را در همان داخل سیستم فوراً رد می‌کند (Internal Rejection).
  • فایده این رد درون‌سازمانی این است که پیام اصلاً از کارت شبکه خارج نمی‌شود و در نتیجه استراتژی بسیار سریع‌تر از زمانی که سفارش تا صرافی برود و صرافی آن را پس بزند، متوجه خطا شده و واکنش نشان می‌دهد.

۷. اجزای بحرانی در برابر اجزای غیربحرانی سیستم

اجزای بحرانی (Critical Components)

شامل: درگاه‌ها (Gateways)، دفترچه‌ساز (Book Builder)، استراتژی‌ها (Strategies) و سامانه مدیریت سفارش (OMS).
این چهار جزء زنجیره مستقیم تصمیم تا اجرای معامله را تشکیل می‌دهند.

  • معیار سنجش کارایی (Tick-to-Trade):
    از لحظه‌ای که یک تیک به‌روزرسانی قیمت وارد شبکه سیستم معاملاتی می‌شود یک تایمر شروع به کار می‌کند؛ به محض آنکه سفارش ناشی از این قیمت از سیستم خارج شود، تایمر متوقف می‌گردد. به این فاصله زمانی حساس، Tick-to-Trade یا Tick-to-Order می‌گویند.

اجزای غیربحرانی و سرویس‌های پشتیبان (Non-Critical Components)

این اجزا مستقیماً در تصمیم‌گیری میلی‌ثانیه‌ای سفارش دخیل نیستند، بلکه وظیفه تغییر پارامترها، ثبت وقایع و گزارش‌دهی را دارند.

سامانه دستور و کنترل (Command and Control)

پل ارتباطی میان معامله‌گران انسانی و سامانه معاملاتی است؛ این بخش می‌تواند یک واسط خط فرمان (CLI) یا یک رابط گرافیکی (GUI) باشد که دستورات تنظیمی تریدر را به ماژول‌های سیستم می‌رساند:

شکل ۲.۹: رابط کاربری یک سیستم معاملاتی

سایر سرویس‌های جانبی مهم:

  • سرور موقعیت و دارایی (Position Server): ثبت پیوسته تمام معاملات و ارزش اسمی دارایی‌ها. برای مثال، اگر معامله‌ای به حجم ۱۰۰٬۰۰۰ یورو/دلار در نرخ ۱.۲ انجام شود، ارزش اسمی پوزیشن ۱۲۰٬۰۰۰ دلار ثبت می‌شود. اگر سقف موقعیت یک دارایی ۲۰۰٬۰۰۰ دلار تعیین شده باشد، سرور پوزیشن از ارسال سفارش‌های بعدی که سقف را رد کنند ممانعت به عمل می‌آورد.
  • سیستم لاگ‌گیری (Logging System): گردآوری تمامی گزارش‌ها و ثبت در فایل یا پایگاه داده برای خطایابی، بازبینی اتفاقات، کشف علل مشکلات و گزارش‌دهی مالی بدون اینکه سرعت مسیر بحرانی را کُند کند.
  • نمایشگرهای پایش (Viewers): صفحات دیداری فقط‌خواندنی برای نمایش زنده وضعیت سفارش‌ها، پوزیشن‌ها و وظایف سیستم.
  • نمایشگرهای کنترلی (Control Viewers): پنل‌های تعاملی برای شروع/توقف ماژول‌ها و تغییر پارامترهای استراتژی در لحظه.
  • سرور اخبار (News Server): دریافت خوراک اخبار لحظه‌ای از خبرگزاری‌های معتبر (مانند Bloomberg، Reuters و RavenPack) و مخابره آنی آن به سیستم استراتژی.

خلاصه و جمع‌بندی فصل دوم (Summary)

در این فصل، ساختار معماری و کلیه اجزای لازم برای طراحی یک سیستم معاملاتی از ابتدا فراگرفته شد:

  1. درگاه‌ها (Gateways) بار سنگین ارتباط شبکه‌ای و مدیریت پروتکل‌ها را به دوش می‌کشند.
  2. دفترچه‌ساز (Book Builder) با استفاده از ساختارهای داده هماهنگ با سخت‌افزار و کش CPU، وضعیت لحظه‌ای بازار را با کمترین تاخیر بازسازی می‌کند.
  3. استراتژی تصمیم‌گیری کرده و سیستم مدیریت سفارش (OMS) سلامت و اعتبار چرخه حیات سفارشات را تضمین می‌کند.

در فصل بعدی (03 - پویایی صرافی و هسته تطبیق)، با ورود به سمت دیگر بازار، کارکرد درونی صرافی‌ها و موتور تطبیق (Matching Engine) را موشکافی خواهیم کرد.