Trading platform risk management development yalnız limitlər cədvəli yaratmaq deyil. Etibarlı həll sifarişi marşrutlaşdırmadan əvvəl bloklayan pre-trade qərar qatını, açıq sifarişləri də nəzərə alan real vaxt ekspozisiya hesablamasını, səlahiyyətli şəxslərin dərhal tətbiq edə bildiyi kill switch mexanizmini və sonradan dəyişdirilməsi aşkarlana bilən audit izini birləşdirir. Bu, Forex, kripto və multi-asset məhsullarında sürət, maliyyə riski və əməliyyat davamlılığı arasında əsas mühəndislik balansıdır.

AB-nin alqoritmik ticarət qaydaları pre-trade nəzarətlərinin sifariş ticarət meydançasına göndərilməzdən əvvəl aparılmasını, qiymət kəmərləri, maksimum sifariş dəyəri, həcm və mesaj limitlərini nəzərdə tutur. Qaydalar həmçinin pre-trade limitlərinin pozulması və nizamsız ticarət əlamətləri üçün real vaxt xəbərdarlıqlarını ayırır. ([eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg_del/2017/589/oj/eng?utm_source=openai)) ABŞ-da SEC Rule 15c3-5 də müəyyən kredit/kapital hədlərini aşan, səhv və ya təkrarlanan sifarişlərin bazara daxil olmasının qarşısını almağa yönəlmiş avtomatlaşdırılmış pre-trade nəzarətlərini tələb edir. ([sec.gov](https://www.sec.gov/rules-regulations/2011/06/risk-management-controls-brokers-or-dealers-market-access?utm_source=openai))

Pre-trade qərarı ilə downstream reconciliation eyni proses deyil

Risk mühərriki sifarişi qəbul etdiyi anda deterministik cavab verməlidir: icazə ver, rədd et və ya səlahiyyətli override tələb et. Bu qərar icra marşrutu başlamazdan əvvəl verilir. Məsələn, müştərinin BTC/USD üzrə maksimum mövqeyi 2 BTC-dirsə, artıq 1.6 BTC long mövqeyi və 0.5 BTC alış sifarişi varsa, yeni 0.2 BTC alış sifarişi icraya göndərilməməlidir. Hesablama yalnız icra olunmuş mövqeyə yox, açıq sifarişlərin mümkün təsirinə də baxmalıdır.

Reconciliation isə sonrakı nəzarətdir: venue cavabları, fill-lər, cancel-lər, wallet/broker balansları və daxili ledger arasında uyğunsuzluqları aşkar edir. O, vacibdir, amma artıq bazara çatmış sifarişi preventiv şəkildə dayandıra bilməz. Reconciliation nəticəsində risk vəziyyəti yenilənə, hesab dondurula və ya insident açıla bilər; lakin pre-trade filtri əvəz etmir.

Risk mühərrikində olmalı əsas nəzarətlər

1. Sifariş səviyyəsində limitlər

  • Miqdar və nominal dəyər: instrument, hesab, müştəri qrupu və kanal üzrə maksimum quantity və notional limitlər.
  • Qiymət kəməri: limit qiymətinin etibarlı referens qiymətdən müəyyən faiz və ya tick aralığından çox uzaq olmasını bloklayın. Referens kimi son trade, mid-price və ya indeks qiymətinin hansı hallarda istifadə ediləcəyini ayrıca müəyyən edin.
  • Leverage və marja yoxlaması: ən pis ssenaridə tələb edilən marjanı, komissiyanı və açıq sifariş rezervlərini nəzərə alın.
  • Duplicate-order prevention: client order ID üçün idempotency yoxlaması; eyni iqtisadi sifarişin qısa zaman pəncərəsində təkrar göndərilməsinə qarşı fingerprint qaydası.

2. Aqreqat mövqe və ekspozisiya limitləri

Risk yalnız bir sifarişin ölçüsü deyil. Hesab, hüquqi şəxs, trader, strategiya, desk, instrument, asset class, venue və ümumi firma üzrə gross/net exposure görünməlidir. Xüsusilə multi-asset platformalarda eyni əsas aktivə dolayı ekspozisiya nəzərə alınmalıdır: spot BTC, perpetual müqavilə və opsion delta-sı ayrı ekranlarda deyil, aydın risk modeli daxilində qiymətləndirilməlidir.

Race condition-dan yayınmaq üçün check-and-reserve modeli tətbiq edin: mühərrik limitin qalan hissəsini atomik rezerv edir, sonra sifarişi marşrutlaşdırır. Cancel, reject və fill hadisələri rezervi idempotent olaraq azaldır və ya mövqeyə çevirir. Sadəcə asinxron cache-dən oxumaqla verilən paralel “approve” qərarları limitin aşılmasına səbəb ola bilər.

3. Sürət, sessiya və səlahiyyət nəzarətləri

  • Hesab, API açarı, IP, strategiya və venue üzrə rate limit və burst limiti.
  • İnstrumentin ticarət sessiyası, planlı maintenance pəncərəsi, hesab statusu və uyğunluq məhdudiyyətləri.
  • Yalnız təsdiqlənmiş rol və scopelar üçün order placement, limit dəyişməsi və kill switch səlahiyyətləri.
  • Override üçün maker-checker axını: səbəb, limitin müddəti, təsdiqləyən şəxs və avtomatik bitmə vaxtı.

Real-time exposure monitoring necə qurulmalıdır

Monitorinq dashboard-u risk qərarının mənbəyi olmamalıdır; o, qərar qatının izlənə bilən görünüşüdür. Hər qəbul, rədd, rezerv, marşrutlaşdırma, fill, cancel və limit dəyişikliyi hadisəsi ardıcıl event stream-ə yazılmalıdır. Risk state ideal halda partition key-lərlə — məsələn account+instrument və ya firm+asset — seriallaşdırılır. Bu yanaşma həm aşağı gecikmə, həm də təkrar emal zamanı eyni nəticə üçün əlverişlidir.

Monitorinqdə ən azı bunları göstərin: limitin istifadəsi və qalan ehtiyat, gross/net mövqelər, açıq sifariş notionalı, marja istifadəsi, reject səbəbləri, market-data age, venue/API sağlamlığı və kill switch statusu. Xəbərdarlıqlar “limitə yaxınlaşma”, “qəfil reject artımı”, “qiymət feed-i köhnəlib”, “cancel təsdiqləri gecikir” və “hesab üzrə mesaj sürəti sıçrayıb” kimi əməliyyat siqnallarını əhatə etməlidir.

Kill switch: düymə deyil, dayandırma protokolu

Trading platform kill switch ən azı üç əhatə səviyyəsini dəstəkləməlidir: müəyyən API açarı/trader, konkret hesab və bütün venue və ya platforma. “Yeni sifarişləri bloklamaq” ilə “açıq sifarişləri ləğv etmək” ayrı hərəkətlərdir; operator interfeysi bunu qarışdırmamalıdır. Kill əməliyyatı kim tərəfindən, hansı səbəblə və hansı scope-da başladıldığı qeydə alınmalı, routing qatına sürətlə yayılmalı, venue cancel cavabları izlənməli və nəticə operatora açıq göstərilməlidir.

Kill switch mərkəzi risk xidmətinin əlçatmazlığına görə işləməz qalmamalıdır. Routing gateway-lərdə yerli, imzalanmış və qısa müddətli policy snapshot saxlamaq məqsədəuyğundur. Mərkəzi idarəetmə itərsə, əvvəlcədən təsdiqlənmiş fail-closed davranış — məsələn yeni risk artıran sifarişləri dayandırmaq — məhsulun risk siyasətinə uyğun seçilməlidir. Bu seçim ticarət, əməliyyat və compliance komandaları ilə əvvəlcədən razılaşdırılmalıdır.

Yük və qismən nasazlıq test planı

  1. Latency spike: risk mühərrikinin p95/p99 gecikməsi yüksələndə timeout, queue limiti və backpressure davranışını yoxlayın. Səssiz “bypass” heç vaxt fallback olmamalıdır.
  2. Stale market data: feed age limiti aşdıqda qiymət kəmərlərinin hansı referensə keçdiyini və ya yeni sifarişlərin bloklandığını test edin. Köhnə qiymətlə yeni risk qəbul etmək açıq siyasət qərarı olmalıdır.
  3. Venue partial failure: submit göndərilib, cavab alınmadıqda retry yalnız idempotent client/venue identifikatorları ilə edilməlidir. Əks halda duplicate exposure yarana bilər.
  4. State-store outage: rezerv state-i əlçatmaz olduqda sistemin fail-closed davranışını, operator bildirişini və sonradan bərpa/reconciliation prosesini sınaqdan keçirin.
  5. Kill-under-load: yüksək order rate zamanı kill switch-in yeni sifarişləri dərhal kəsdiyini, open-order cancel növbəsinin idarə edildiyini və audit izinin tam qaldığını sübut edin.

Audit izi və idarəetmə

Audit qeydi yalnız tətbiq loqu deyil. O, sorğunun identifikatorunu, qəbul edilən parametrləri, istifadə olunan limit/policy versiyasını, referens qiyməti və onun yaşını, qərarı, səbəb kodunu, override məlumatını, operator hərəkətlərini və əlaqəli venue cavablarını birləşdirməlidir. Append-only storage, məhdud yazma səlahiyyəti, vaxt sinxronizasiyası və hash-chain və ya WORM kimi tamlıq nəzarətləri istintaqı daha etibarlı edir. NIST log management rəhbərliyi loqların hadisələrin araşdırılması, əməliyyat problemlərinin tapılması və tələb olunan saxlama üçün vacib olduğunu vurğulayır. ([csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/92/r1/ipd?utm_source=openai))

Platforma sahibi üçün seçim meyarı

Yeni risk qatını qurarkən əsas sual “neçə limitimiz var?” deyil, “hansı risk qərarı hansı state və policy ilə, neçə millisaniyədə və nasazlıq zamanı hansı davranışla verilir?” olmalıdır. POLADO-nun FinTech və trading sistemləri xidməti risk mühərriki, market-data inteqrasiyası, audit yönümlü back-office və əməliyyat monitorinqinin vahid arxitektura kimi planlanmasına kömək edir. Mövcud analitika məhsullarında risk görünürlüğü və inteqrasiya yanaşmalarına ESFX layihəsi kontekstində də baxa bilərsiniz. Arxitekturanızı, limit modelinizi və yük test ssenarilərinizi qiymətləndirmək üçün POLADO ilə əlaqə saxlayın.