Trading platform dealing desk development brokerin və ya FinTech komandasının icra əməliyyatlarında insan qərarlarını idarə olunan, izah edilə bilən və izlənilə bilən iş axınına çevirir. Bu, sadəcə treyder terminalı və ya “order list” deyil. Dealing desk qatı əmrin niyə növbəyə düşdüyünü, kim tərəfindən hansı kontekstdə nəzərdən keçirildiyini, routinq qərarının necə verildiyini, kotirovkanın qüvvədə olub-olmadığını və istisna qərarının necə təsdiqləndiyini saxlamalıdır.
Bu tip məhsul xüsusilə manual terminal, e-poçt və cədvəllərlə işləyən, lakin həcm artdıqca əməliyyatları standartlaşdırmaq istəyən brokerlər üçün uyğundur. POLADO bu qatı daha geniş FinTech və trading sistemləri xidmətinin tərkibində, mövcud platforma və inteqrasiyalara uyğun şəkildə hazırlaya bilər.
Dealing desk sistemi nəyi idarə etməlidir?
Əsas məqsəd bütün əmrləri avtomatik icra etmək deyil; uyğun hallarda səlahiyyətli əməkdaşın müdaxilə etməsinə şərait yaratmaq, eyni zamanda müdaxiləni sərbəst və sənədsiz etməməkdir. Sistem hər order üçün vahid əməliyyat konteksti təqdim etməlidir:
- əmr, hesab, alət, tərəf, həcm, istiqamət və vaxt məlumatı;
- cari və sorğu anındakı qiymət, qiymətin mənbəyi, yaş göstəricisi və spread vəziyyəti;
- açıq orderlər, mövqelər, istifadə edilmiş limitlər və hesab/qrup ekspozisiyası;
- mümkün routinq variantları, liquidity venue statusu və əvvəlki cəhdlər;
- risk və ya sessiya qaydalarının yaratdığı bloklar;
- qərar verən şəxs, səbəb kodu, qeydlər və tələb olunan ikinci təsdiq.
Bu ekranın məqsədi “dealer nə gördü?” sualına sonradan cavab verməkdir. Buna görə UI yalnız sürətli görünməməli, qərar üçün vacib konteksti vaxtında göstərməlidir. Sıx əməliyyat ekranları üçün axınların və informasiya iyerarxiyasının ayrıca məhsul dizaynı ilə hazırlanması vacibdir.
OMS, pricing engine, risk sistemi və liquidity bridge-dən fərqi
Dealing desk bir sistemin digərinin yerinə qurulması deyil. OMS orderin həyat dövrünü, statuslarını, dəyişikliklərini və fill-ləri idarə edən əsas qeydiyyat qatıdır. Pricing engine market-data feed-lərini normallaşdırır, mark-up və kotirovkaları formalaşdırır. Risk sistemi pre-trade yoxlamaları, limitləri, margin və kill-switch qaydalarını hesablayır. Liquidity bridge isə xarici liquidity provider və venue-lara mesaj ötürür, cavabları/fill-ləri normallaşdırır.
Dealing desk bu mənbələrdən gələn siqnalları əməliyyat qərarı üçün birləşdirir. Məsələn, sistem orderi dealer review-a yönləndirə bilər, çünki qiymət köhnəlib, exposure həddi yaxınlaşıb, provider cavab vermir və ya hesab qrupu üçün xüsusi qayda mövcuddur. Lakin dealer ekranı margin hesablamasının və ya qiymət istehsalının sahibi olmamalıdır. Bu sərhəd sonradan iki fərqli ekranın eyni qaydanı fərqli tətbiq etməsinin qarşısını alır.
Əgər order və execution inteqrasiyası artıq mövcuddursa, POLADO onu ayrıca FT10 və ESFX kimi FinTech yönümlü işlərin arxitektura yanaşmalarından əldə olunan təcrübə ilə qiymətləndirə, yeni dealing desk qatının kanonik event modelinə uyğunluğunu yoxlaya bilər.
Dealer queue və icra nəzarətlərinin dizaynı
Növbələr qayda əsasında olmalıdır
“Manual review” vahid, qarışıq siyahı olmamalıdır. Növbələr səbəb, təcililik və məsuliyyət üzrə ayrılmalıdır: stale quote review, large notional, limit warning, provider rejection, partial-fill handling, trade amendment, market-close exception və s. Hər növbə üçün SLA timer, prioritet, sahiblik, eskalasiya səviyyəsi və növbədən çıxma şərti müəyyənləşdirilməlidir.
Orderi iki dealer eyni anda işləməməlidir. Bunun üçün qısa müddətli claim/lease mexanizmi, sahiblik dəyişikliyinin jurnalı və müddəti bitən claim üçün geri qaytarma davranışı lazımdır. Bununla yanaşı, supervisor işçinin orderi üzərində nəzarəti yalnız açıq və audit olunan override kimi həyata keçirməlidir.
Müdaxilə səlahiyyətləri rol və kontekst üzrə verilməlidir
“Dealer” rolu hərəkətlərin hamısına giriş demək deyil. Məsələn, bəzi istifadəçilər orderi routinqə göndərə, digərləri reject səbəbi seçə, yalnız supervisor isə quote override və ya istisna limit qərarını təsdiqləyə bilər. Səlahiyyətlər alət qrupu, hesab qrupu, notional intervalı, sessiya və region kimi atributlarla məhdudlaşdırıla bilər.
Müdaxilə əməliyyatı sistemin öz qaydalarını keçməməlidir. Əgər order risk yoxlamasında bloklanıbsa, dealing desk yalnız “approve” düyməsi verməməlidir; hansı qaydanın pozulduğunu, override-in icazəli olub-olmadığını və əlavə təsdiqin tələb ediləcəyini açıq göstərməlidir.
Kotirovka nəzarəti və stale-price qoruması
Dealerin qiymət üzərində qərarı qiymətin nə vaxt və hansı mənbədən alındığını bilmədən etibarlı deyil. Hər qiymət snapshot-ı mənbə, receive timestamp, quote timestamp, bid/ask, liquidity vəziyyəti və konfiqurasiya versiyası ilə saxlanmalıdır. Sistem maksimum quote age, market-data gecikməsi, spread genişlənməsi, session statusu və provider health əsasında orderi avtomatik dayandıra və ya alternativ axına yönləndirə bilər.
Stale-price qoruması yalnız köhnə qiyməti rədd etməkdən ibarət deyil. Məhsul qaydası əvvəlcədən müəyyən etməlidir: order yenidən kotirovka ediləcəkmi, dealer review-a keçəcəkmi, yoxsa avtomatik ləğv olunacaq? Müştəriyə və downstream sistemlərə göndərilən statuslar bu qərardan ardıcıl yaranmalıdır.
Maker-checker və dəyişdirilə bilməyən audit izi
Yüksək təsirli hərəkətlər üçün maker-checker modeli tətbiq edilməlidir. Məsələn, dealer xüsusi routinq istisnası yaradır, supervisor onu təsdiqləyir; ya da quote override təklifi ikinci səlahiyyətli istifadəçi tərəfindən yoxlanır. Təsdiq edən şəxs eyni əməliyyatın müəllifi olmamalıdır və təsdiq zamanı orderin dəyişmədiyi yoxlanmalıdır. Əgər order və ya quote snapshot-ı dəyişibsə, köhnə təklif etibarsızlaşmalıdır.
Dealing desk audit trail sadəcə “istifadəçi statusu dəyişdi” logu deyil. O, append-only event jurnalı kimi aşağıdakıları saxlamalıdır:
- hərəkətin əvvəlki və sonrakı vəziyyəti;
- istifadəçi, rol, autentifikasiya konteksti və iş stansiyası məlumatı;
- qərar səbəb kodu, sərbəst qeyd və əlavələr;
- istifadə olunan quote, risk nəticəsi, exposure snapshot-ı və qayda versiyası;
- request və cavab identifikatorları, provider/venue mesajları və zaman ardıcıllığı;
- təsdiq, rədd, eskalasiya və sonrakı düzəliş event-ləri.
Hadisələri sonradan səssizcə redaktə etmək əvəzinə düzəliş yeni event yaratmalıdır. Bu yanaşma əməliyyat araşdırması, müştəri şikayətinin analizi, reconciliation və daxili nəzarət üçün daha etibarlı tarixçə yaradır.
İnteqrasiya arxitekturası: nəyi kim idarə edir?
Sağlam arxitekturada dealing desk sinxron qərarlar və asinxron event-lərlə işləyir. Order qəbul edilərkən OMS-dən kanonik order snapshot alınır; risk servisindən yoxlama nəticəsi; pricing servisindən quote snapshot; bridge-dən routinq və execution nəticələri; account servisindən isə status və icazələr alınır. Bütün xarici çağırışlar correlation ID ilə bağlanmalı, timeout, retry və idempotency qaydaları ayrıca dizayn edilməlidir.
Əsas texniki qayda budur: UI-dakı düymə birbaşa venue-ya mesaj göndərməməlidir. İstifadəçi əməliyyatı niyyət kimi göndərir, server səlahiyyəti və orderin son vəziyyətini yoxlayır, lazımdırsa maker-checker mərhələsini yaradır, yalnız sonra icra komandası formalaşır. Bu, köhnəlmiş ekran məlumatı ilə verilən qərarın və təkrarlanan kliklərin yaratdığı problemləri azaldır.
Başlamazdan əvvəl suallar
- Hansı orderlər avtomatik, hansı hallarda manual review-a gedəcək?
- Hər növbənin sahibi, SLA-sı və eskalasiya marşrutu nədir?
- Dealer hansı action-ları edə bilər, hansıları yalnız supervisor təsdiqləyir?
- Quote freshness, session və provider-health qaydalarının sahibi hansı sistemdir?
- Hansı məlumat order qərarı anında snapshot kimi saxlanmalıdır?
- Routinq cəhdi, reject və partial fill-lər necə modelləşdiriləcək?
- Audit event-ləri necə qorunacaq, axtarılacaq və export ediləcək?
- UAT ssenarilərinə provider kəsilməsi, stale quote, ikiqat klik, gecikmiş fill və failover daxildirmi?
POLADO ilə dealing desk qurulması
Doğru dealing desk layihəsi ekranlardan əvvəl qərar modelləri, event sərhədləri, səlahiyyət matrisi və istisna ssenarilərini dəqiqləşdirir. POLADO mövcud OMS, pricing, risk və bridge komponentlərini əvəz etmək məcburiyyəti olmadan onların üzərində nəzarətli əməliyyat qatı qura bilər. Məqsəd dealer komandasına daha çox düymə vermək deyil; hər icra qərarını daha aydın, təhlükəsiz və araşdırıla bilən etməkdir.
Əgər əməliyyatlarınız hələ terminal, mesajlaşma və spreadsheet arasında parçalanıbsa, FinTech və trading sistemləri komandamızla konsultasiya planlaşdırın. Birgə olaraq qərar axınlarını, inteqrasiya asılılıqlarını və ilk mərhələdə qurulmalı olan nəzarətləri xəritələndirə bilərik.