وقتی یک ربات معامله نمی‌کند، دو نتیجه‌گیری شتاب‌زده ممکن است شکل بگیرد: یا «سیستم خراب است» یا «سیستم هوشمندانه صبر کرده است». بدون بررسی شواهد، هیچ‌کدام کافی نیست. یک سامانه قابل‌ارزیابی باید علت نبود معامله را توضیح دهد.
رد فرصت با خرابی سیستم تفاوت دارد
در یک سناریوی توضیحی، داده معتبر است و تحلیل انجام شده، اما پیشنهاد با محدودیت ریسک حساب سازگار نیست. در این حالت، معامله‌نکردن می‌تواند خروجی مورد انتظار طراحی باشد.
در سناریوی دیگر، داده بازار به‌روز نیست یا بخشی از زنجیره اجرا پاسخ نمی‌دهد. این وضعیت را نباید به‌عنوان موفقیت مدیریت ریسک تبلیغ کرد. حتی اگر توقف مانع یک اقدام نامطمئن شده باشد، علت فنی آن همچنان باید بررسی شود.
ریسک پیش از سفارش معنا پیدا می‌کند
پیشنهاد طراحی ما برای سارا تریدر این است که هر تصمیم پیش از رسیدن به اجرا از قواعد تعریف‌شده حساب عبور کند. سقف‌های مجاز، محدودیت تعداد موقعیت‌ها و شرایط توقف باید متناسب با سیاست همان حساب مشخص شوند؛ این مقاله درصد یا حجم معامله‌ای را برای مخاطب تجویز نمی‌کند.
همچنین نباید حد ضرر را معادل تضمین نتیجه دانست. در مستندات متاتریدر، فعال‌شدن دستورهای توقف و اجرای آن‌ها به قواعد معاملاتی و شرایط اجرای سفارش وابسته است. ۱ بنابراین کنترل ریسک باید کل فرایند را ببیند، نه فقط وجود یک عدد در فرم سفارش.
گزارش توقف باید چه بگوید؟
پیشنهاد ما برای یک گزارش مفید، تفکیک سه پرسش است: آیا سامانه داده معتبر داشت؟ آیا پیشنهادی تولید شد؟ کدام قاعده یا مانع جلوی اجرا را گرفت؟ پاسخ هر سؤال باید به رویداد ثبت‌شده مربوط باشد، نه توضیحی که بعداً برای توجیه نتیجه ساخته شده است.
برای مثال، «پیشنهاد به دلیل عبور از محدودیت تعریف‌شده رد شد» توضیحی متفاوت از «وضعیت حساب قابل‌تأیید نبود» است. این تفکیک کمک می‌کند مسئول سامانه بداند با یک تصمیم عادی روبه‌روست یا مسئله‌ای نیازمند رسیدگی.
هدف سارا تریدر نباید صرفاً افزایش تعداد سفارش‌ها باشد. در طراحی یک سامانه مسئولانه، انجام معامله و انجام‌ندادن آن، هر دو باید قابل‌توضیح و قابل‌بررسی باشند. هیچ‌یک نیز به‌تنهایی مدرک سودآوری محسوب نمی‌شود.
