معماری فنی کارگزاری بورس: از مدیریت کاربر تا موتور تطبیق سفارشات

در قلب بازار سرمایه، کارگزاری بورس به‌عنوان واسطی حیاتی میان سرمایه‌گذاران و نهادهای تسویه‌کننده (مانند بورس و شرکت سپرده‌گذاری مرکزی) ایفای نقش می‌کند. یک کارگزاری مدرن، فراتر از یک پلتفرم ساده برای خرید و فروش سهام، سیستمی پیچیده از زیرسیستم‌های هماهنگ است که باید در لحظه، داده‌ها را پردازش، سفارشات را مسیردهی و ریسک را مدیریت کند. در این مقاله، ساختار فنی یک کارگزاری تمام‌عیار را لایه‌به‌لایه تشریح می‌کنیم؛ از درگاه احراز هویت کاربر تا هسته معاملاتی و تسویه ناهمگام.

۱. زیرسیستم مدیریت کاربران، احراز هویت (KYC) و کنترل دسترسی (RBAC)

پیش از هر معامله، هویت مشتری باید با بالاترین استانداردهای قانونی تأیید شود. زیرسیستم KYC (Know Your Customer) وظیفه گردآوری مدارک شناسایی، احراز نشانی و تطابق با لیست‌های نظارتی را بر عهده دارد. معمولاً این فرآیند با دریافت تصاویر کارت ملی و سلفی، تطبیق چهره (Face Matching) و استعلام از سامانه‌های مرجع (مانند سامانه سجام) انجام می‌شود. پس از تأیید، نقش (Role) کاربر در سیستم تعریف می‌گردد: معامله‌گر خرد، معامله‌گر نهادی، یا کارگزار داخلی.

مدیریت دسترسی‌ها بر اساس مدل RBAC (Role-Based Access Control) پیاده‌سازی می‌شود. هر نقش دارای مجموعه‌ای از مجوزها (Permissions) نظیر «مشاهده سفارش»، «ثبت سفارش»، «تغییر حد ریسک» و «دسترسی به گزارشات مالی» است. توکن‌های احراز هویت معمولاً به شکل JWT با زمان انقضای کوتاه (مثلاً ۱۵ دقیقه) و قابلیت چرخش خودکار طراحی می‌شوند. همچنین، ذخیره رمزعبور با الگوریتم‌هایی نظیر bcrypt و اعمال قوانین سخت‌گیرانه (پیچیدگی و تاریخ انقضا) الزامی است. برای دسترسی‌های حساس (مانند تغییر رمز کیف پول یا برداشت وجه)، لایه دوم احراز هویت (OTP یا Google Authenticator) فعال می‌شود.

۲. هسته معاملاتی و سیستم مدیریت سفارشات (OMS)

سیستم مدیریت سفارشات (OMS) قلب تپنده کارگزاری است. سفارشات خرید و فروش از سمت کاربر (از طریق وب، اپلیکیشن موبایل یا API) وارد OMS می‌شوند. هر سفارش حاوی اطلاعاتی نظیر نماد، حجم، قیمت، جهت (خرید/فروش)، نوع سفارش (محدود، بازار، شرطی) و شناسه کاربر است. برخلاف تصور رایج، کارگزاری معمولاً خود موتور تطبیق سفارشات (Matching Engine) را اجرا نمی‌کند؛ این وظیفه به عهده هسته مرکزی بورس است. نقش کارگزاری در اینجا، اعتبارسنجی پیش از معامله، تعیین مسیر سفارش و ارسال بلادرنگ آن به درگاه بورس (معمولاً از طریق پروتکل FIX یا APIهای اختصاصی) است.

OMS باید قادر باشد نرخ ارسال سفارش (Order Rate) بالایی را تحمل کند (مثلاً چند هزار سفارش در ثانیه). به همین دلیل، سفارشات در صف‌های داخلی (با استفاده از Redis یا Kafka) قرار گرفته و سپس به صورت گروهی (Batching) یا انفرادی به بورس ارسال می‌شوند. پس از ارسال، OMS منتظر دریافت شناسه سفارش (Order ID) و وضعیت تأیید اولیه از بورس می‌ماند. در صورت رد شدن سفارش به دلیل مشکلاتی مانند کمبود اعتبار یا محدودیت حجمی، خطای مربوطه بلافاصله به کاربر بازگردانده می‌شود.

۳. زیرسیستم مالی، حسابداری و مدیریت کیف پول (Wallet)

هر کاربر در کارگزاری دارای یک کیف پول (Wallet) است که موجودی نقدی وی را نشان می‌دهد؛ دارایی‌های سهام او نیز در سامانه داخلی کارگزاری (بر اساس استعلام از شرکت سپرده‌گذاری مرکزی) نگهداری می‌شود. زیرسیستم مالی باید دو طرف معامله را به صورت آنی مدیریت کند:

الف) کاهش یا بلوکه کردن موجودی نقد هنگام ثبت سفارش خرید.

ب) بلوکه کردن سهام در سبد دارایی هنگام ثبت سفارش فروش.

چالش اصلی در اینجا تسویه حساب آنی نیست، بلکه تسویه در بازه استاندارد بازار (مثلاً T+2) است. با این حال، کارگزاری‌های مدرن برای ارائه تجربه کاربری بهتر، موجودی قابل معامله (Available Balance) را به صورت «شبه‌آنی» به‌روزرسانی می‌کنند. به این صورت که پس از اجرای معامله (دریافت گزارش اجرا از بورس)، سیستم مالی بلافاصله سهام فروخته‌شده را از پرتفوی کاربر خارج و معادل ریالی آن را به موجودی نقد (با اعمال فرآیند تسویه داخلی) اضافه می‌کند؛ اما تا زمان انجام تسویه نهایی قانونی، کاربر مجاز به برداشت فیزیکی آن مبلغ از حساب نیست.

مدیریت کارمزدها نیز لایه دیگری از پیچیدگی است. کارمزد معاملات (شامل سهم کارگزاری، مالیات و کارمزد سازمان بورس) باید طبق جداول تعرفه‌ای پویا محاسبه و از کیف پول کاربر کسر شود. پلتفرم‌های پیشرفته، موتور محاسبه کارمزد را به صورت یک میکروسرویس جداگانه و با قابلیت تنظیم بر اساس حجم معاملات ماهانه، سطح کاربر (VIP) و تخفیف‌های دوره‌ای طراحی می‌کنند.

۴. سیستم مدیریت ریسک پیش از معامله (Pre-Trade Risk)

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

موجودی نقد کافی برای سفارش خرید (با احتساب کارمزدها).

موجودی سهام کافی برای سفارش فروش (بر اساس پرتفوی واقعی کاربر).

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

قوانین حد ضرر روزانه (مثلاً مسدودسازی معاملات جدید در صورت عبور ضرر روزانه کاربر از یک درصد مشخص).

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

این قوانین باید با تأخیری کمتر از ۵ میلی‌ثانیه پردازش شوند. برای این منظور، وضعیت لحظه‌ای موجودی و پرتفوی هر کاربر در یک حافظه موقت پرسرعت (مانند Redis Cache) نگهداری می‌شود. پس از تأیید ریسک، سفارش به مرحله بعد (OMS) راه پیدا می‌کند و در صورت رد شدن، دلیل دقیق آن بلافاصله به کاربر اعلام می‌شود. برای کاربران اعتباری، این زیرسیستم پیچیده‌تر شده و شامل محاسبه نسبت وثیقه (Collateral Ratio) و فراخوانی مارجین (Margin Call) می‌گردد.

۵. توزیع داده‌های لحظه‌ای بازار (Market Data Feed)

کاربران برای تصمیم‌گیری نیازمند دریافت قیمت‌های لحظه‌ای، عمق بازار (Order Book) و حجم معاملات هستند. کارگزاری خود تولیدکننده داده‌های بازار نیست، بلکه از طریق اتصال مستقیم (Feed) به بورس، داده‌ها را دریافت کرده و پس از نرمال‌سازی، بین کاربران خود توزیع می‌کند.

پروتکل‌های استاندارد برای انتقال داده‌های لایو شامل WebSocket (برای اتصال پایدار و دو‌طرفه در مرورگر و اپلیکیشن) و gRPC Stream (برای ارتباط میان‌سروری با کارایی بالا) است. معماری توزیع داده اغلب به صورت Publisher-Subscriber (مانند Kafka یا Redis Pub/Sub) طراحی می‌شود؛ به این صورت که هر نماد یک Topic اختصاصی دارد. سرور کارگزاری دیتای دریافتی از بورس را روی Topic متناظر منتشر می‌کند و گیت‌وی‌های وب‌ساکت (WebSocket Gateways) که کاربران به آن‌ها متصل هستند، داده‌ها را به صورت فشرده‌سازی شده (مثلاً با فرمت Protobuf یا MessagePack) برای کلاینت‌ها ارسال می‌کنند.

چالش اصلی این بخش، مقیاس‌پذیری برای هندل کردن هزاران اتصال همزمان و نرخ بالای به‌روزرسانی داده‌ها است. استفاده از بافرها و مکانیزم‌های بازیابی پیام‌های از دست رفته (مانند ذخیره آخرین اسنپ‌شات بازار در Redis) در این لایه ضروری است.

۶. نیازمندی‌های غیرعملیاتی معماری: مقیاس‌پذیری، صف‌ها و کش

یک کارگزاری مدرن تحت هیچ شرایطی نمی‌تواند به معماری یکپارچه (Monolithic) بسنده کند. سه نیازمندی کلیدی زیر، زیرساخت این سیستم را شکل می‌دهند:

مقیاس‌پذیری افقی (Horizontal Scalability): تمام سرویس‌ها (OMS، مدیریت ریسک، API Gateway و توزیع داده) باید بدون تغییر در کد و صرفاً با افزودن لایه‌های سخت‌افزاری جدید (Instances)، توان عملیاتی خود را افزایش دهند. این امر مستلزم بی‌حالت (Stateless) بودن لایه پردازش است؛ به طوری که وضعیت کاربران در دیتابیس یا سیستم کش مجزا نگهداری شود.

مدیریت صف‌ها (Message Queues): برای عملیات ناهمگام (Asynchronous) مانند فرآیند نهایی تسویه، ارسال نوتیفیکیشن‌ها، تولید گزارش‌های پایان روز و به‌روزرسانی تاریخچه معاملات، از صف‌های پیام مانند RabbitMQ یا Apache Kafka استفاده می‌شود. به عنوان مثال، به محض دریافت گزارش اجرای معامله از بورس، یک پیام به صف «تسویه» فرستاده می‌شود تا سرویس‌های پشتیبان بدون معطل کردن ترافیک اصلی شبکه، موجودی کاربر را به‌روزرسانی کنند. Kafka به دلیل نگهداری لاگ‌ها و قابلیت پخش مجدد (Replay)، برای بازسازی وضعیت حسابداری در یک نقطه زمانی خاص بسیار مناسب است.

سیستم‌های Caching (مانند Redis): خواندن مداوم وضعیت موجودی و پرتفوی از پایگاه داده‌های رابطه‌ای (مثل PostgreSQL) به دلیل تاخیر بالا غیرممکن است. به همین دلیل، از Redis به عنوان یک کش درون‌حافظه‌ای (In-Memory) توزیع‌شده استفاده می‌شود. ساختار داده مناسب در اینجا، Hash برای نگهداری موجودی هر کاربر (کلید: wallet:userId و فیلد: cashBalance) و Sorted Set برای پیگیری سفارش‌های فعال بر اساس زمان است. همچنین، اعمال مکانیزم‌های پایدارسازی داده (Persistence) در Redis در کنار قابلیت Replication، برای جلوگیری از پریدن دیتا در صورت خاموش شدن ناگهانی سرور الزامی است.

در نهایت، یک دیتابیس تراکنشی قدرتمند (SQL) تمام رویدادهای مالی و سوابق را به صورت دائمی ذخیره می‌کند تا در صورت بروز هرگونه کرش در سیستم، امکان بازسازی کامل وضعیت کش از روی لاگ رویدادها (Event Sourcing) وجود داشته باشد.

طراحی یک کارگزاری مدرن، تلفیقی از دانش مالی، معماری سیستم‌های بلادرنگ (Real-time) و مهندسی زیرساخت است. هر زیرسیستم توضیح‌داده‌شده — از KYC و RBAC گرفته تا موتور ریسک پیش از معامله، توزیع داده لایو با WebSocket و معماری مبتنی بر صف و کش — باید با بالاترین استانداردهای پایداری (99.99%)، ثبات داده و امنیت سایبری ساخته شود. توجه به این جزئیات فنی نه تنها تجربه کاربری روانی را رقم می‌زند، بلکه ثبات پلتفرم را در روزهای پرترافیک بازار تضمین می‌کند.

#معماری_کارگزاری_مدرن #هسته_معاملاتی #سیستم_مدیریت_سفارشات #OMS #احراز_هویت #KYC #کنترل_دسترسی #RBAC #مدیریت_ریسک_پیش_از_معامله #کیف_پول #زیرسیستم_مالی #تسویه_ناهمگام #T+2 #توزیع_داده_لحظه_ای #WebSocket #gRPC #صف_پیام #Kafka #Redis #کش_درون_حافظه #مقیاس_پذیری_افقی #امنیت #bcrypt #JWT #کارمزد_پویا #مارجین #وثیقه #معماری_بی_حالت #EventSourcing #پروتکل_FIX #عمق_بازار #OTP #سبد_دارایی #سامانه_سجام #پایداری_99.99 #مهندسی_بلادرنگ #BrokerageArchitecture #OrderManagementSystem #PreTradeRisk #IdentityVerification #RealTimeMarketData #MessageQueues #HorizontalScalability #WalletAccounting #SettlementCycle #CollateralMargin #DynamicCommission #FIXProtocol #EventSourcing #HighAvailability #LowLatency #APIGateway #Microservices #OrderRouting