Trading platform margin engine development yalnız “marja faizi”ni hesablayan funksiya deyil. Etibarlı həll hər hesab üzrə açıq mövqeləri, qiymət snapshot-larını, valyuta çevirmələrini, uyğun girovu, haircut-ları, bloklanmış vəsaitləri və qayda versiyasını eyni hesablama kontekstində birləşdirir. Nəticə həm yeni sifarişlərə nəzarət, həm maintenance margin monitorinqi, həm margin call, həm də nəzarətli likvidasiya üçün izah edilə bilən qərar yaratmalıdır.

Broker, prop-trading və ya FinTech məhsulu üçün əsas məqsəd ticarət nəticəsini vəd etmək deyil; hər marja qərarının hansı data, qayda və vaxt əsasında verildiyini bərpa edilə bilən şəkildə göstərməkdir. POLADO komandası FinTech və trading sistemləri çərçivəsində bu cür qayda-yönlü hesablama və əməliyyat workflow-larını mövcud platformanıza uyğun layihələndirə bilər.

Margin mühərriki hansı suallara ardıcıl cavab verməlidir?

Hər qiymətləndirmə dövründə mühərrik hesab, sub-hesab və ya hüquqi portfel üzrə aşağıdakıları eyni qayda seti ilə çıxarmalıdır:

  • Initial margin: yeni mövqeni açmaq və ya artırmaq üçün tələb olunan təminat;
  • Maintenance margin: mövqe açıq qalarkən qorunmalı minimal hədd;
  • Eligible collateral value: qəbul edilən girovun haircut, FX qaydası və konsentrasiya limiti tətbiq olunmuş dəyəri;
  • Available margin və excess/shortfall: istifadə oluna bilən təminat və çatışmazlıq;
  • Account status: normal, buffer zonasında, margin call gözləyir, yalnız-risk-azaldan rejim, likvidasiya üçün uyğun və ya aktiv likvidasiya.

Sadə modeldə available margin belə ifadə oluna bilər: uyğunlaşdırılmış girov dəyəri + hesablanmış P&L − rezervlər − tələb olunan marja. Lakin istehsal sistemində bu, universal formula deyil. Məsələn, unrealiszed P&L-nin daxil edilməsi, kredit limitləri, settlement statusu, netting qrupları və daxili transferlərin tanınması məhsul və müqavilə qaydalarından asılıdır. Ona görə bütün anlayışlar konfiqurasiya edilə bilən, versiyalanan data kontraktları ilə müəyyən edilməlidir.

Initial və maintenance margin modellərini ayırın

Initial margin adətən yeni riskin yaradılması üçün giriş tələbi, maintenance margin isə mövcud riskin davamlı izlənməsi üçün hədddir. Bu iki dəyəri eyni etmək bəzən məhsul siyasəti ola bilər, amma onları arxitekturada eyni sahəyə çevirmək sonradan dəyişiklik, audit və sınağı çətinləşdirir.

Sadə leveraged spot və ya CFD məhsullarında initial requirement mövqe notionalı × margin rate kimi başlaya bilər. Daha mürəkkəb portfellərdə isə tələbin hesablanması risk qrupları, hedge tanınması, option ssenariləri, konsentrasiya əlavələri və likvidlik parametrlərini nəzərə ala bilər. Məsələn, CME-nin SPAN yanaşması portfel üzrə müxtəlif qiymət və volatillik ssenarilərində potensial zərəri təhlil edir; bu, “hər simvol üçün tək faiz” yanaşmasının bütün məhsullar üçün kifayət etmədiyini göstərən faydalı referensdir. ([cmegroup.com](https://www.cmegroup.com/solutions/risk-management/performance-bonds-margins/span-methodology-overview.html?utm_source=openai))

Qayda paketini ayrıca domen obyekti edin

Margin qaydası kod daxilində səpələnmiş sabitlər toplusu olmamalıdır. Versiyalanan qayda paketi ən azı instrument qrupu, leverage/margin rate, maintenance rate, offset qaydası, konsentrasiya əlavəsi, haircut schedule, qiymət mənbə prioriteti, freshness limiti, hesab valyutası və qüvvəyə minmə vaxtını saxlamalıdır.

Hesablama cavabı da “yalnız rəqəm” olmamalıdır. Məsələn, nəticədə calculation ID, rule version, position snapshot ID, price snapshot ID, collateral snapshot ID, FX source, timestamp və səbəb kodları saxlanmalıdır. Bu yanaşma support komandası ilə risk operatorunun eyni çatışmazlığı yenidən hesablaya bilməsinə kömək edir.

Collateral valuation: nominal dəyər yox, istifadə oluna bilən dəyər

Trading collateral management system dizaynında qəbul edilən aktiv siyahısı və onun qiymətləndirilməsi ayrı komponentlərdir. Cash, token, fond payı və ya digər aktiv qəbul oluna bilər, lakin hər aktivin marja üçün tanınan dəyəri eyni deyil. Praktik hesablamada aşağıdakı addımlar açıq görünməlidir:

  1. Aktivin eligibility statusunu yoxlayın: aktiv növü, issuer, custody, settlement və hüquqi məhdudiyyət.
  2. Etibarlı qiymət və FX kursunu seçin.
  3. Price freshness və bazar sessiyası qaydasını yoxlayın.
  4. Haircut tətbiq edin.
  5. Issuer, aktiv sinfi və ya korrelyasiya üzrə concentration limiti tətbiq edin.
  6. Pending withdrawal, order reserve, pledge və ya dispute səbəbilə bloklanmış hissəni çıxın.

Haircut-lar şəffaf, risk-əsaslı və asan izah oluna bilən olmalıdır; beynəlxalq prudensial prinsiplər qiymət volatilliyi, likvidlik, kredit və FX riskini nəzərə almağı, həmçinin stress şəraitində də işləyən konservativ kalibrasiyanı vurğulayır. ([bis.org](https://www.bis.org/committees/bcbs/basel-framework/standard/mgn/20/inforce/2019-12-15/published/2019-12-15?utm_source=openai))

Ən vacib dizayn qaydası budur: girov qiyməti köhnəlibsə, mühərrik onunla sakitcə “son məlum dəyər” kimi normal rejimdə işləməməlidir. Məhsul siyasətinə görə yeni risk bloklana, daha konservativ qiymət/haircut tətbiq oluna və ya hesab manual review vəziyyətinə keçirilə bilər. Hansı davranış seçilirsə seçilsin, səbəb operator və audit üçün görünməlidir.

Qiymət freshness-i marja modelinin tərkib hissəsidir

Margin calculation engine development qiymət mühərrikindən sadəcə son qiyməti qəbul etməklə bitmir. Hər mark üçün mənbə, event time, receive time, market state, bid/ask/mid seçimi, FX marşrutu və freshness statusu saxlanmalıdır. Əks halda düzgün formula köhnə qiymətlə yanlış nəticə verə bilər.

Praktik freshness siyasəti alət sinfi üzrə fərqli ola bilər: likvid, fasiləsiz ticarət olunan alət üçün saniyələr; az likvid alət və ya bağlanmış sessiya üçün ayrıca valuation policy. Bu siyasəti trading platforması və bazar-data inteqrasiyası dizaynının hissəsi edin; marja mühərriki qiymət keyfiyyətinin sahibinə çevrilməməli, amma ondan gələn statusu qərara daxil etməlidir.

Margin call və likvidasiya workflow-u state machine kimi qurulmalıdır

Maintenance margin pozulması avtomatik və izahsız “close all” əmri demək deyil. Nəzarətli workflow hesab statuslarını və keçid şərtlərini açıq model edir:

  • Healthy: tələblər ödənir.
  • Warning/buffer: həddə yaxınlaşma var; bildiriş və ya risk görünürlüğü tətbiq olunur.
  • Margin call open: çatışmazlıq, deadline, tələb olunan məbləğ və notification evidence qeydə alınır.
  • Restricted: yalnız mövcud riski azaltmağa yönələn sifarişlərə icazə verilə bilər.
  • Liquidation eligible: grace period, müqavilə şərtləri və əməliyyat nəzarətləri yoxlanıb.
  • Liquidation active/resolved: hər action, fill, retry, operator müdaxiləsi və yekun reconciliation qeyd edilir.

Likvidasiya orkestratoru margin kalkulyatorundan ayrılmalıdır. Kalkulyator shortfall və səbəbi verir; orkestrator isə hansı mövqenin hansı prioritetlə bağlanacağını, order limitlərini, hissəli icranı, market-data itkisini, venue reject-lərini və retry siyasətini idarə edir. Bu ayrılıq hesablamanı deterministik, icranı isə idarə olunan edir.

Operator override nəzarətsiz istisna olmamalıdır

Manual override lazım ola bilər: feed incident, hüquqi hold, mübahisəli transfer və ya xüsusi account arrangement zamanı. Lakin override minimum olaraq reason code, ikiqat təsdiq tələb olunan səlahiyyət səviyyəsi, müddət, təsir dairəsi və dəyişdirilə bilməyən audit event-i ilə saxlanmalıdır. Basel Committee margin şərtlərindən kənarlaşmalar üçün aydın escalation və approval tələbləri olan formal çərçivəni tövsiyə edir. ([bis.org](https://www.bis.org/committees/bcbs/basel-consolidated-guidelines/module/cri/40?utm_source=openai))

Reconciliation və sınaq: “düzgün görünür” kifayət deyil

Margin mühərriki üçün acceptance criteria yalnız UI-da görünən rəqəmlər olmamalıdır. Aşağıdakı test qatlarını planlayın:

  • Formula və rounding üçün unit testlər;
  • Qayda versiyası, haircut və FX ssenariləri üçün golden test portfelləri;
  • Qiymət sıçrayışı, stale quote, partial fill, corporate event və delayed transfer üçün event-replay testləri;
  • Margin call deadline və liquidation state keçidləri üçün end-to-end testlər;
  • İcra, ledger, custody/balance və margin snapshot-ları arasında gündəlik və intraday reconciliation;
  • Stress ssenarilərində queue həcmi, hesablama gecikməsi və operator yükü üçün performans testləri.

Model və parametrlərin müntəzəm validasiyası, intraday margin call qabiliyyəti və girovun yenidən qiymətləndirilməsi maliyyə infrastrukturu prinsiplərində əsas nəzarətlər kimi göstərilir. ([iosco.org](https://www.iosco.org/library/pubdocs/pdf/ioscopd176.pdf?utm_source=openai))

Delivery partnyorunu seçərkən verilməli suallar

  • Hesablama nəticəsini eyni input snapshot-ları ilə bit-for-bit yenidən yaratmaq mümkündürmü?
  • Qayda, haircut və leverage dəyişiklikləri effective time ilə versiyalanırmı?
  • Stale və ya ziddiyyətli qiymət zamanı platforma konkret olaraq nə edir?
  • Margin call, restriction və liquidation arasında kim, hansı səlahiyyətlə keçid edir?
  • Partial fill, cancel/reject, outage və duplicate event zamanı workflow idempotent qalırmı?
  • Operator override-ları sonradan kim, niyə və nə qədər müddətə tətbiq etdiyini göstərə bilirmi?

POLADO FT10 və ESFX kimi FinTech/analitika yönümlü işlərin təcrübəsindən istifadə edərək marja domeninin discovery-sini, qayda kataloqunu, inteqrasiya kontraktlarını, test planını və mərhələli delivery roadmap-ını hazırlaya bilər. Mövcud trading stack-inizi, hesab növlərinizi və collateral siyasətinizi müzakirə etmək üçün bizimlə əlaqə saxlayın.