ZarSignal Options Intelligence Engine

۱ خلاصه مدیریتی

۱.۱ تعریف مسئله

بازار اختیار معامله سهام و صندوق‌های ETF در بورس ایران از ۱۳۹۷ به‌صورت جدی فعال شده و امروز صدها قرارداد فعال دارد. اما ابزار تحلیل این بازار برای کاربر خرد و حتی حرفه‌ای، ناهمگن، پراکنده و اغلب مبتنی بر اکسل دستی است.

کاربر برای ارزیابی یک قرارداد باید:

1. زنجیره قراردادها را در TSETMC یا سامانه کارگزاری پیدا کند.
2. قیمت اعمال، سررسید و ضریب را دستی وارد اکسل کند.
3. ارزش ذاتی و زمانی را خودش محاسبه کند.
4. نقطه سربه‌سر را حدس بزند.
5. نقدشوندگی را با نگاه به تابلو ارزیابی کند.
6. در نهایت تصمیم بگیرد.

این فرایند ۲۰ تا ۴۰ دقیقه برای یک قرارداد زمان می‌برد و برای غربال ۲۰۰ قرارداد فعال، عملاً غیرممکن است.

۱.۲ هدف محصول

ساخت یک تابلوی زنده و ساده که:

• به‌صورت خودکار قراردادهای مستعد بررسی را شناسایی کند.
• برای هر قرارداد، یک پروپوزال سرمایه‌گذاری اختصاصی با محاسبات قابل بازبینی تولید کند.
• تفاوت میان «داده واقعی»، «محاسبه قطعی»، «برآورد» و «پیشنهاد» را شفاف نگه دارد.
• در نبود فرصت معتبر، هیچ سیگنالی ندهد.

۱.۳ ارزش پیشنهادی

۱.۴ فرضیه‌های اصلی (که باید آزمون شوند)

1. فرضیه داده: داده لحظه‌ای اختیار معامله با کیفیت و تأخیر قابل‌قبول از یک منبع پایدار قابل تهیه است.
2. فرضیه تقاضا: حداقل ۵۰۰ کاربر فعال در ماه حاضر به پرداخت برای پروپوزال اختصاصی باشند.
3. فرضیه تمایز: کاربران بیشتر از «توضیح دلیل انتخاب» و «شفافیت ریسک» ارزش می‌گیرند تا از «تعداد امکانات».
4. فرضیه فنی: موتور محاسباتی می‌تواند در کمتر از ۲۰۰ میلی‌ثانیه برای هر قرارداد، پروپوزال کامل تولید کند.
5. فرضیه اقتصادی: هزینه داده و زیرساخت در ماه‌های اول از ۳۰٪ درآمد فراتر نمی‌رود.

۱.۵ مهم‌ترین فرصت‌ها

• شکاف واقعی در بازار: هیچ محصول ایرانی‌ای امروز ترکیب «تابلوی زنده غربال‌شده + پروپوزال اختصاصی با ذکر مفروضات» را ارائه نمی‌دهد.
• رشد بازار اختیار: تعداد قراردادهای فعال و حجم معاملات در سه سال اخیر رشد قابل‌توجهی داشته است.
• نیاز به سواد مالی: کاربران به ابزار تصمیم‌یار نیاز دارند، نه صرفاً داده خام.

۱.۶ مهم‌ترین ریسک‌ها

۱.۷ تصمیم‌های ضروری پیش از توسعه

1. انتخاب منبع اصلی داده و عقد قرارداد یا تأیید مجوز استفاده تجاری.
2. تصمیم درباره معماری: موتور محاسبات در وردپرس یا سرویس مستقل.
3. تعیین حداقل مجموعه قراردادهای پوشش‌داده‌شده در نسخه اول.
4. تصویب مدل درآمدی و سیاست نسخه رایگان.
5. تهیه متن حقوقی سلب مسئولیت و افشای ریسک.

۲ بررسی امکان‌پذیری داده در بازار ایران

۲.۱ منابع قابل بررسی داده اختیار معامله

منبع ۱: TSETMC — سایت رسمی مدیریت فناوری بورس تهران

• وضعیت دسترسی: ⚠️ عمومی برای مشاهده، نامشخص برای استفاده تجاری
• داده قابل دریافت: زنجیره قراردادها، قیمت آخرین معامله، حجم، ارزش، مظنه خرید/فروش، مشخصات قرارداد
• تناوب: به‌روزرسانی در طول ساعات بازار (هر چند ثانیه تا یک دقیقه)
• تأخیر: ⚠️ در عمل بین ۱۰ تا ۶۰ ثانیه، ولی مستند رسمی ندارد
• API رسمی: ❌ وجود API عمومی مستند و پایدار برای استفاده تجاری تأیید نشده
• مجوز استفاده تجاری: ❓ نامشخص
• ریسک وابستگی: بالا — تغییر ساختار صفحه، تغییر endpoint، محدودیت IP

منبع ۲: شرکت بورس اوراق بهادار تهران

• وضعیت: ✅ مشخصات رسمی قراردادها منتشر می‌شود
• داده: مشخصات ثابت قراردادها (ضریب، اندازه، نحوه اعمال و تسویه)
• اهمیت: منبع مرجع برای اعتبارسنجی ضرایب و مشخصات

منبع ۳: ره‌آورد ۳۶۵ (rahavard365.com)

• وضعیت دسترسی: ⚠️ تجاری — نیازمند اشتراک برای API
• داده: تاریخی قیمت‌ها، شاخص‌ها، برخی داده‌های اختیار
• مجوز: ✅ تجاری در دسترس از طریق قرارداد
• ریسک: متوسط — پایداری خوب، اما هزینه قابل‌توجه

منبع ۴: APIهای کارگزاری‌ها (مفید تریدر، آسا تریدر، فارابی و...)

• وضعیت: ⚠️ فقط برای مشتریان همان کارگزاری
• داده: لحظه‌ای، مظنه، عمق سفارش
• محدودیت: ❌ استفاده خارج از پلتفرم کارگزاری معمولاً خلاف شرایط استفاده است

منبع ۵: شرکت‌های ارائه‌دهنده داده مالی (Data Vendors)

مانند تدبیرپرداز، یارن، سامانه‌های Dataservice — ⚠️ نیازمند بررسی موردی قرارداد تجاری.

۲.۲ جدول خلاصه منابع داده

۲.۳ واقعیت‌های کلیدی درباره داده اختیار معامله ایران

1. نقدشوندگی نابرابر: بخش بزرگی از قراردادها نقدشوندگی بسیار پایینی دارند. فاصله خرید/فروش در بسیاری از قراردادها بیش از ۱۰ تا ۳۰ درصد است.
2. مظنه‌های غیرقابل اجرا: بسیاری از مظنه‌ها صرفاً سفارش‌هایی با حجم بسیار کم (مثلاً یک قرارداد) هستند.
3. ضریب قرارداد متغیر: ضریب (Contract Multiplier) در قراردادهای مختلف متفاوت است (۱۰۰۰، ۱۰۰۰۰ و...).
4. تسویه فیزیکی و نقدی: برخی قراردادها تسویه فیزیکی و برخی نقدی دارند.
5. کارمزد پیچیده: کارمزد شامل چند جزء است (معامله، عوارض، مالیات).
6. وجه تضمین برای فروشندگان: ریسک موقعیت فروش با خرید کاملاً متفاوت است.
7. داده تاریخی محدود: پوشش تاریخی مظنه‌های خرید/فروش برای بک‌تست محدود است.

۲.۴ توصیه راهبردی درباره داده

 # گام صفر (۲ هفته) پیش از هر توسعه: # مذاکره با ارائه‌دهندگان داده تجاری # عقد قرارداد رسمی یا MoU برای استفاده آزمایشی # نمونه‌برداری از داده واقعی # گام یک طراحی سیستم چندمنبعی (multi-source): # دریافت از ۲ تا ۳ منبع # تطبیق و اعتبارسنجی متقابل # گام دو ذخیره‌سازی محلی داده خام: # با timestamp دقیق # برای ممیزی و بک‌تست # گام سه طراحی لایه اعتبارسنجی: # حذف داده مشکوک قبل از ورود به موتور محاسبات 

۳ نقشه رقبا

۳.۱ گروه A — ابزارهای بازار سرمایه ایران

۳.۲ گروه B — ابزارهای تخصصی اختیار معامله در ایران

۳.۳ گروه D — پلتفرم‌های بین‌المللی (برای الگوبرداری)

۳.۴ ماتریس مقایسه استراتژیک

۳.۵ نتیجه‌گیری مقایسه

• استاندارد ضروری محصول: داده لحظه‌ای معتبر، محاسبات صحیح ارزش ذاتی/زمانی، نقطه سربه‌سر، ذکر ضریب قرارداد.
• تمایز واقعی: پروپوزال ساختاریافته با ذکر مفروضات، شفافیت در عدم قطعیت، خروجی «بدون سیگنال».
• هزینه‌بر و کم‌ارزش در نسخه اول: استراتژی‌های چندپا، تحلیل نوسان‌پذیری پیشرفته، ML برای پیش‌بینی قیمت.
• فرضیه‌های نیازمند آزمون با کاربر: آیا کاربر حاضر است برای پروپوزال اختصاصی اشتراک بپردازد؟ آیا سادگی تابلو برای کاربر حرفه‌ای کافی است؟

۴ مشخصات محصول

۴.۱ طراحی مفهومی تابلو

تابلو باید در یک نگاه پاسخ دهد:

• چه چیزی برای بررسی ارزشمند است؟
• چرا این مورد انتخاب شده؟
• داده‌ها چقدر معتبرند؟
• چه ریسکی باید پیش از ورود بدانم؟

۴.۲ فیلدهای پیشنهادی هر ردیف

۴.۳ معیارهای ورود و خروج از تابلو

ورود به تابلو (همه باید برقرار باشند)

 def should_display(contract): # ۱. قرارداد فعال و منقضی‌نشده if not (contract.is_active and contract.expiry > today): return False, "منقضی یا غیرفعال" # ۲. حداقل یک معامله در ۳ روز کاری گذشته if contract.trades_last_3_days == 0: return False, "عدم فعالیت اخیر" # ۳. مظنه خرید و فروش معتبر if not (contract.best_bid > 0 and contract.best_ask > contract.best_bid): return False, "مظنه نامعتبر" # ۴. فاصله خرید/فروش کمتر از ۱۵٪ mid = (contract.best_bid + contract.best_ask) / 2 spread_pct = (contract.best_ask - contract.best_bid) / mid if spread_pct > 0.15: return False, "فاصله خرید/فروش بیش از حد" # ۵. ارزش ذاتی یا ارزش زمانی قابل محاسبه if not can_compute_intrinsic(contract): return False, "محاسبات ناممکن" # ۶. ضریب قرارداد و مشخصات اعمال تأیید شده if contract.multiplier is None: return False, "مشخصات ناقص" return True, "مجاز به نمایش" 

خروج از تابلو

• نقض هر یک از معیارهای بالا
• گذشت بیش از ۵ دقیقه از آخرین به‌روزرسانی مظنه
• ورود به روز پایانی سررسید (حالت خاص)
• تعلیق نماد پایه

۴.۴ وضعیت‌های تحلیلی

۵ معماری نرم‌افزار

۵.۱ دو سناریوی اجرایی

سناریوی ۱: توسعه در بستر وردپرس فعلی

سناریوی ۲: موتور محاسبات به‌عنوان سرویس مستقل

۵.۲ توصیه راهبردی

۵.۳ معماری پیشنهادی — جزئیات لایه‌ها

۵.۴ مدل داده — موجودیت‌های اصلی

 Contract # مشخصات قرارداد - id, symbol, underlying_symbol, type (call/put) - strike_price, expiry_date, multiplier - settlement_type (cash/physical) - contract_size, is_active - source_contract_id # برای ردیابی منبع MarketSnapshot # لحظه‌ای بازار - contract_id, timestamp - last_price, last_volume - best_bid, best_ask, bid_size, ask_size - data_quality_score ComputedMetrics # محاسبات - contract_id, snapshot_id - intrinsic_value, time_value - breakeven, moneyness - greeks (delta, gamma, theta, vega, rho) - model_used, model_version OpportunityScore # امتیاز فرصت - contract_id, snapshot_id - total_score, liquidity_score - economic_score, market_context_score - reason_tags (JSON) Proposal # پروپوزال - contract_id, snapshot_id - generated_at, algorithm_version - sections (JSON) - status, assumptions_hash 

۶ موتور شناسایی فرصت‌ها

۶.۱ تعریف «فرصت مستعد»

فرصت مستعد قراردادی است که:

• از نظر اقتصادی قابل تحلیل باشد (ارزش ذاتی/زمانی معنادار)
• از نظر اجرایی قابل معامله باشد (نقدشوندگی کافی)
• از نظر زمینه بازاری، فرضیه قابل بررسی داشته باشد (دارایی پایه در وضعیت معنادار)

۶.۲ چارچوب پنج‌مرحله‌ای

مرحله ۱: کنترل کیفیت داده

 def validate_data_quality(contract): errors = [] # فعال بودن و عدم انقضا if not (contract.is_active and contract.expiry > today): errors.append("منقضی یا غیرفعال") # اعتبار مظنه‌ها if not (contract.last_price > 0 and contract.best_bid > 0 and contract.best_ask > contract.best_bid): errors.append("مظنه نامعتبر") # فاصله خرید/فروش mid = (contract.best_bid + contract.best_ask) / 2 if (contract.best_ask - contract.best_bid) / mid > 0.15: errors.append("فاصله خرید/فروش بیش از حد") # تازگی داده if (now - contract.timestamp).seconds > 300: errors.append("داده قدیمی") # مشخصات قرارداد if contract.multiplier is None or contract.strike_price is None: errors.append("مشخصات ناقص") return len(errors) == 0, errors 

مرحله ۲: ارزیابی امکان معامله

 def compute_liquidity_score(contract): # فاصله خرید/فروش (وزن ۴۰٪) mid = (contract.best_bid + contract.best_ask) / 2 spread_ratio = (contract.best_ask - contract.best_bid) / mid spread_score = max(0, 1 - spread_ratio / 0.15) * 0.40 # حجم معاملات روز (وزن ۳۰٪) volume_score = min(contract.daily_volume / 1000, 1) * 0.30 # عمق مظنه (وزن ۳۰٪) depth_score = min((contract.bid_size + contract.ask_size) / 100, 1) * 0.30 return spread_score + volume_score + depth_score 

مرحله ۳: ارزیابی اقتصادی

• محاسبه ارزش ذاتی و زمانی
• محاسبه moneyness (در/از/بی‌پول)
• محاسبه سربه‌سر
• مقایسه با قراردادهای هم‌گروه (همان پایه، سررسیدهای مختلف)
• شناسایی ناکارآمدی‌های نسبی (مثلاً ارزش زمانی غیرعادی)

مرحله ۴: ارزیابی زمینه بازار

• روند دارایی پایه (۲۰ روزه، ۵۰ روزه)
• نوسان تاریخی
• رویدادهای اثرگذار (مجامع، گزارش‌ها) — ⚠️ فقط در صورت دسترسی به داده قابل اتکا
• شرایط نقض فرضیه

مرحله ۵: رتبه‌بندی و توضیح

 { "contract_id": "ضکس۵۰۰-۲۰۰۰-۱۴۰۵/۹/۱۵", "status": "suitable_for_review", "score": 72, "reasons": [ "ارزش زمانی پایین‌تر از میانگین هم‌گروه", "نقدشوندگی مناسب (فاصله ۴٪)", "دارایی پایه در حمایت معتبر" ], "limitations": [ "حجم معاملات روز کمتر از میانگین ماه" ], "data_quality": "high", "last_updated": "2026-10-29T10:32:15+03:30" } 

۶.۳ اصل «نبود فرصت معتبر»

اگر هیچ قراردادی معیارها را پاس نکرد، تابلو باید پیام واضح نمایش دهد:

۷ موتور محاسبات مالی

۷.۱ محاسبات پایه (نسخه اول)

ارزش ذاتی

 # فرمول Call Intrinsic = max(S - K, 0) × multiplier Put Intrinsic = max(K - S, 0) × multiplier # پیاده‌سازی def intrinsic_value(S, K, multiplier, option_type): if option_type == 'call': return max(S - K, 0) * multiplier elif option_type == 'put': return max(K - S, 0) * multiplier else: raise ValueError("نوع اختیار نامعتبر") 

ارزش زمانی

 # فرمول Time Value = (Market Price × multiplier) - Intrinsic Value # پیاده‌سازی def time_value(market_price, S, K, multiplier, option_type): intrinsic = intrinsic_value(S, K, multiplier, option_type) return (market_price * multiplier) - intrinsic 

نقطه سربه‌سر در سررسید

 # فرمول Long Call BE = K + (Premium / multiplier) Long Put BE = K - (Premium / multiplier) # پیاده‌سازی def breakeven(K, premium, multiplier, option_type): if option_type == 'call': return K + (premium / multiplier) elif option_type == 'put': return K - (premium / multiplier) 

هزینه واقعی ورود

 # فرمول Total Cost = (Premium × multiplier × contracts) + commission + fees + taxes # پیاده‌سازی def total_entry_cost(premium, multiplier, contracts, commission_rate, fees, taxes): gross = premium * multiplier * contracts commission = gross * commission_rate return gross + commission + fees + taxes 

سناریوهای سود/زیان در سررسید

 # فرمول Long Call P/L(S_T) = max(S_T - K, 0) × multiplier - Total Cost Long Put P/L(S_T) = max(K - S_T, 0) × multiplier - Total Cost # پیاده‌سازی def payoff_at_expiry(S_T, K, multiplier, total_cost, option_type): if option_type == 'call': gross = max(S_T - K, 0) * multiplier else: gross = max(K - S_T, 0) * multiplier return gross - total_cost # سناریوها scenarios = [-0.15, -0.05, 0, +0.05, +0.15] for delta in scenarios: S_T = S * (1 + delta) pl = payoff_at_expiry(S_T, K, multiplier, total_cost, option_type) print(f"Δ={delta:+.0%} → P/L={pl:,.0f}") 

۷.۲ محاسبات پیشرفته (نسخه دوم)

• مدل Black-Scholes برای ارزش نظری
• نوسان‌پذیری ضمنی (Implied Volatility) با روش Newton-Raphson
• یونانی‌ها (Delta, Gamma, Theta, Vega, Rho)
• Put-Call Parity برای شناسایی ناکارآمدی
• مدل دوجمله‌ای برای اختیار آمریکایی (در صورت لزوم)

۷.۳ الزامات اجرایی

• تمام محاسبات باید قابل بازتولید باشند.
• نسخه الگوریتم و مفروضات در هر گزارش ثبت شود.
• هیچ مقداری بدون ذکر واحد و مبنا نمایش داده نشود.
• آزمون واحد (unit test) برای هر محاسبه با مقادیر مرجع الزامی است.

۸ قالب پروپوزال سرمایه‌گذاری

۸.۱ ساختار کامل پروپوزال

G. جمع‌بندی تصمیم‌یار

یکی از چهار وضعیت با دلیل:

• ✅ مناسب برای بررسی بیشتر
• ⚠️ نیازمند اطلاعات تکمیلی
• ❌ نامناسب بر اساس معیارهای فعلی
• ⚫ بدون سیگنال

۸.۲ اصل شفافیت — چهار لایه

۹ امنیت، اعتماد و کنترل کیفیت

۹.۱ الزامات امنیتی

• احراز هویت دو مرحله‌ای برای کاربران حرفه‌ای
• رمزنگاری داده‌های حساس در حالت استراحت و انتقال
• محافظت از کلیدهای API با vault (مثل HashiCorp Vault یا AWS Secrets Manager)
• rate limiting و محافظت در برابر سوءاستفاده
• ثبت لاگ تمام عملیات حساس

۹.۲ کنترل کیفیت محاسبات

• ممیزی کامل: هر گزارش با timestamp، نسخه الگوریتم، hash مفروضات
• بازتولیدپذیری: امکان بازسازی گزارش قبلی با داده تاریخی
• تفکیک خطا: خطای داده ≠ خطای محاسبه ≠ خطای مدل
• آزمون مرجع: حداقل ۵۰ مورد آزمون واحد با پاسخ‌های از پیش محاسبه‌شده
• توقف خودکار: در صورت تعارض جدی داده، تحلیل تولید نشود

۹.۳ اصول استفاده از هوش مصنوعی

 # جریان صحیح [داده بازار] → [موتور محاسبات قطعی] → [اعداد تأییدشده] ↓ [مدل زبانی — فقط توضیح] ↓ [متن نهایی برای کاربر] # موارد مجاز برای AI ✅ خلاصه‌سازی شرایط بازار (با ذکر منبع) ✅ تولید متن توضیحی از خروجی‌های عددی ✅ شخصی‌سازی سطح نمایش بر اساس دانش کاربر # موارد ممنوع ❌ پیش‌بینی قیمت دارایی پایه ❌ اختراع ضریب قرارداد، کارمزد، تاریخ سررسید ❌ تولید اعداد مالی بدون محاسبه قطعی 

۱۰ ارزیابی نیاز به هوش مصنوعی

۱۱ برنامه توسعه فازبندی‌شده

۱۲ ده راهکار فنی پیشرفته

۱۳ برنامه اعتبارسنجی

۱۳.۷ شاخص‌های عملکرد

۱۴ برنامه ۳۰/۶۰/۹۰ روزه

۱۵ مدل کسب‌وکار

۱۵.۱ مدل‌های درآمدی قابل بررسی

۱۵.۲ توصیه

۱۵.۳ ساختار هزینه

۱۵.۴ فرضیات درآمدی (نیازمند آزمون)

فرضیات برای آزمون:

• ۵۰۰ کاربر فعال ماهانه در ۶ ماه اول
• ۵٪ نرخ تبدیل به اشتراک
• میانگین ۵۰۰ هزار تومان اشتراک ماهانه
• درآمد ماهانه هدف: ۱۲.۵ میلیون تومان

این اعداد فقط برای آزمون هستند و باید با آزمایش واقعی جایگزین شوند.

۱۶ تصمیم‌نامه نهایی

۱۶.۱ آیا اجرای پروژه توجیه دارد؟

• شکاف بازار واقعی است ✅
• تمایز محصول قابل دفاع است ✅
• تقاضای بالقوه وجود دارد ✅
• اما دسترسی به داده لحظه‌ای معتبر، پیش‌شرط حیاتی است ⚠️

۱۶.۲ مهم‌ترین پیش‌نیاز

دسترسی پایدار و قانونی به داده لحظه‌ای اختیار معامله با:

• تأخیر کمتر از ۶۰ ثانیه
• مظنه خرید/فروش
• مجوز استفاده تجاری
• SLA قابل اتکا

۱۶.۳ کوچک‌ترین نسخه ارزشمند (MVP)

 MVP پیشنهادی: ✅ تابلوی زنده با ۳ فیلتر اصلی (نقدشوندگی، ارزش زمانی، سربه‌سر) ✅ پروپوزال ساده برای ۱۰ قرارداد برتر روز ✅ فقط اختیار خرید روی صندوق‌های ETF (کاهش پیچیدگی) ✅ داده پایان روز + به‌روزرسانی لحظه‌ای محدود زمان: ۶۰ روز تیم: ۲ نفر 

۱۶.۴ قابلیت‌های قابل انتقال به نسخه بعد

• استراتژی‌های چندپا
• تحلیل نوسان‌پذیری پیشرفته
• Put-Call Parity Monitor
• ML برای رتبه‌بندی
• API عمومی
• B2B

۱۶.۵ ریسک‌های توقف پروژه

1. ❌ عدم دسترسی به داده لحظه‌ای معتبر
2. ❌ تغییر ناگهانی مقررات بازار اختیار
3. ❌ رقابت مستقیم کارگزاری‌های بزرگ با محصول مشابه
4. ❌ عدم پذیرش کاربر در ۶ ماه اول

۱۶.۶ فرضیه‌های نیازمند اثبات

1. آیا کاربران حاضرند برای پروپوزال اختصاصی اشتراک بپردازند؟
2. آیا سادگی تابلو برای کاربر حرفه‌ای کافی است؟
3. آیا موتور غربال می‌تواند فرصت‌های واقعاً ارزشمند شناسایی کند؟
4. آیا پروپوزال‌ها از نظر کاربران، قابل فهم و قابل اعتماد هستند؟

۱۶.۷ سه اقدام اول برای شروع

📎 پیوست — پرسش‌های باز و نیازمند پاسخ

این پرسش‌ها قبل از شروع فاز اجرایی باید پاسخ داده شوند:

1. زیرساخت فعلی زرسیگنال دقیقاً چیست؟ (نوع سرور، وردپرس، پلاگین‌های فعال)
2. بودجه ماهانه برای داده و زیرساخت چقدر است؟
3. تیم توسعه فعلی چند نفر و با چه تخصص‌هایی؟
4. آیا کاربران فعلی زرسیگنال در حوزه اختیار معامله فعال هستند؟
5. آیا مجوز ارائه خدمات تحلیلی مالی از سازمان بورس نیاز است؟
6. زمان‌بندی دلخواه برای رسیدن به نسخه عمومی چیست؟