Trading platform margin management development yalnız “mövcud vəsait × leverage” hesablaması deyil. Etibarlı sistem hər hesablamanın hansı mövqe, qiymət, girov, məzənnə, maliyyələşdirmə və qayda versiyası ilə yarandığını sonradan dəqiq izah etməlidir. Bu, xüsusilə sürətli qiymət hərəkətində margin call, yeni orderin bloklanması və məcburi likvidasiya qərarlarının ardıcıl qalması üçün vacibdir.

Margin modulunu order xidmətinin içində ikinci dərəcəli funksiya kimi qurmaq əvəzinə, onu ayrıca deterministik risk domeni kimi dizayn edin. O, icralar, order rezervasiyaları, depozit və çıxarışlar, korporativ hadisələr, mark qiymətləri, funding və ya borrow faizləri kimi giriş hadisələrini emal edir; nəticədə isə hesabın kapitalını, tələb olunan marjanı, istifadə olunan marjanı, ehtiyatı və risk vəziyyətini hesablayır.

Margin modelinin dəyişməyən əsasları

İlk qərar məhsulun iqtisadi modelidir. Səhm marjası, futures, CFD, perpetual futures və opsionlar eyni düsturlarla idarə olunmur. Məsələn, futures-də margin adətən performans təminatı kimi işləyir və mövqelər mark-to-market prinsipi ilə yenidən qiymətləndirilir; broker və ya platforma isə məhsul və volatilliyə görə daha sərt “house” tələbi qoya bilər.

Texniki spesifikasiya ən azı aşağıdakı anlayışları bir-birindən ayırmalıdır:

  • Initial margin: yeni mövqe açmaq və ya ekspozisiyanı artırmaq üçün tələb olunan məbləğ.
  • Maintenance margin: açıq mövqeni saxlamaq üçün minimum tələb.
  • Equity: uyğun girovun diskontlaşdırılmış dəyəri, reallaşmış balans, reallaşmamış P&L və yığılmış xərclərin kombinasiyası.
  • Available margin: equity-dən saxlanmalı marja və digər rezervlərin çıxılması.
  • Margin ratio: məhsul qaydasına uyğun olaraq equity / maintenance margin və ya digər açıq tərifli nisbət.

Sadə linear perpetual nümunəsində sistem bu ardıcıllığı sənədləşdirə bilər: notional = müqavilə sayı × müqavilə ölçüsü × mark price; initial requirement = notional × initial rate; maintenance requirement = notional × maintenance rate. Lakin real tətbiqdə tiered dərəcələr, istiqamət, hedcləmə krediti, müqavilə valyutası, FX çevirməsi, açıq order rezervləri və məhsula məxsus risk əlavələri də eyni qayda paketinin hissəsidir.

Cross və isolated margin: sadəcə UI seçimi deyil

Isolated margin hər mövqeni və ya mövqe qrupunu ayrılmış girov hovuzu ilə məhdudlaşdırır. Bir mövqenin itkisi digər balanslara keçməməlidir; transfer qaydası və həmin hovuzun likvidasiya həddi açıq göstərilməlidir. Cross margin isə hesab və ya portfel səviyyəsində uyğun girovu və bəzi hallarda ofsetləşən riskləri birlikdə qiymətləndirir. Bu, kapital istifadəsini yaxşılaşdıra bilər, lakin risk mənbələrini və likvidasiya təsirini genişləndirir.

Hər iki model üçün sistem “scope” anlayışını sabit saxlamalıdır: hansı hesablar, sub-account-lar, valyutalar, mövqelər və pending order-lər eyni risk hovuzundadır? Müxtəlif müştərilərin mövqelərini bir-birinə qarşı netləşdirmək olmaz. Həmçinin cross hesablamasında verilən offset krediti risk siyasəti ilə əsaslandırılmalı, yalnız UI-də görünən “hedged” etiketi ilə verilməməlidir.

Girov dəyərləndirməsi və P&L

Collateral management for trading platforms üçün nominal balans heç vaxt tək həqiqət mənbəyi olmamalıdır. Hər girov aktivi üzrə eligibility, saxlanma yeri, lock status, valuation currency, haircut, qiymət mənbəyi və son etibarlı qiymət vaxtı saxlanmalıdır. Məsələn, hesabda 100 000 vahid token olması onun 100 000 vahid risk kapitalı olduğu anlamına gəlmir: sistem eligible collateral value = quantity × valuation price × (1 − haircut) yanaşmasını tətbiq edə bilər.

Haircut cədvəli likvidlik, qiymət dəyişkənliyi, kredit riski və girov valyutası ilə öhdəlik valyutası arasındakı FX riski kimi faktorları nəzərə almalıdır. Dəyərləndirmə qiyməti də ayrıca qaydadır: last trade, index, mark, bid/ask və ya konservativ tərəf seçimi məhsula görə fərqlənə bilər. “Son qiymət” gəlmədikdə sistem avtomatik olaraq onu yeni və etibarlı qiymət kimi istifadə etməməlidir.

Unrealized P&L üçün entry price, contract multiplier, side, mark price və settlement modeli eyni hesablayıcıda versiyalanmalıdır. Funding, borrow faizi, komissiya, vergi və ya digər yığılmış borclar ayrıca journal hadisələri kimi daxil edilməlidir; yalnız ekran üzərində P&L-ə əlavə olunan gizli düzəliş olmamalıdır. Bu yanaşma POLADO-nun FinTech və trading sistemləri xidmətində ledger, market data və risk qaydalarının bir məhsul arxitekturasında əlaqələndirilməsinə uyğundur.

Margin call və liquidation engine necə işləməlidir?

Risk vəziyyətlərini sadə və məhsula uyğun state machine ilə müəyyənləşdirin: healthy, warning, margin-call, liquidation-eligible, liquidating, bankrupt/deficit və reconciled. Hər keçid üçün səbəb kodu, hesablamanın snapshot ID-si və qayda versiyası qeydə alınmalıdır.

Likvidasiya həddi “equity maintenance margin-dən aşağıdır” kimi ümumi cümlə ilə bitməməlidir. Qayda aşağıdakı suallara cavab verməlidir:

  1. Qiymət hansı mənbədən və hansı timestamp ilə götürülür?
  2. Açıq order-lər əvvəl ləğv olunurmu və onların rezervi nə vaxt azad edilir?
  3. Hansı mövqe əvvəl bağlanır: ən böyük risk, ən likvid alət, yoxsa konfiqurasiya edilmiş prioritet?
  4. Qismən likvidasiya hədəf nisbətə qədər davam edirmi?
  5. İcra qiyməti gözləniləndən pis olarsa, hesab yenidən hesablanırmı?
  6. Market order uğursuz, qismən icra və ya gecikmiş olduqda hansı fallback tətbiq edilir?

Praktik olaraq, liquidation worker bir snapshot üzərində qərar verir, icra nəticəsi gəldikdə isə yeni snapshot yaradır. Köhnə qərar yeni mövqe vəziyyətinə kor-koranə tətbiq edilə bilməz. İcra mesajları duplicate gələ bildiyi üçün liquidation əmrləri idempotency key daşımalı, broker və ya matching engine cavabları ardıcıllıq nömrəsi ilə emal edilməlidir.

Gecikmiş qiymətlər və volatile bazar üçün təhlükəsizlik rejimi

Mark price vaxtı keçibsə, sistemin hesabladığı margin ratio zahirən dəqiq görünə, amma real riskdən uzaq ola bilər. Buna görə market-data keyfiyyəti margin modelinin girişidir: feed status, source priority, staleness limiti, cross-source fərq limiti, trading halt və fallback qiymət siyasəti ayrıca saxlanmalıdır.

Stale qiymət aşkar ediləndə yeni leverage artıran order-ləri bloklamaq, riskli collateral üçün əlavə haircut tətbiq etmək və ya hesabı manual review vəziyyətinə keçirmək uyğun ola bilər. Hansı tədbirin seçilməsi məhsulun hüquqi və əməliyyat qaydalarından asılıdır; vacib olan həmin qərarın avtomatik, audit edilə bilən və istifadəçiyə izah olunan qayda olmasıdır. Operatorların risk konsolunda price age, son mark source, hesablamaya daxil olan haircuts və likvidasiya növbəsi görünməlidir. Bu cür əməliyyat ekranlarının dizaynı üçün UI/UX və məhsul dizaynı xidməti kritik alarmları dekorativ dashboard-dan ayırmağa kömək edir.

Deterministik replay və müstəqil test

Margin qərarının etibarlılığı onu sonradan yenidən istehsal edə bilməyinizlə ölçülür. Hər hesablamaya immutable input snapshot əlavə edin: ledger balansları, mövqelər, rezervlər, qiymətlər, FX rates, funding accrual, rule version və processing timestamp. Sonra eyni hadisə ardıcıllığını test mühitində replay etdikdə eyni nəticə alınmalıdır.

  • Qiymətin 5%, 20% və gap hərəkəti ilə property və ssenari testləri.
  • Gecikmiş, out-of-order və təkrarlanan fill, depozit və price event-ləri.
  • Cross və isolated hovuzlar arasında transfer sərhədləri.
  • Margin parametrinin dəyişdiyi anda açıq mövqelərin yenidən hesablanması.
  • Likvidasiya zamanı qismən fill, rədd cavabı və xidmət yenidən başlaması.
  • Hesablayıcının nəticəsinin ledger və broker/exchange statement ilə müntəzəm reconciliation-u.

Bu iş yalnız unit test deyil. Müstəqil risk calculator, event replay aləti və gündəlik reconciliation prosesi istehsal sisteminin nə etdiyini yoxlamağa imkan verir. Trading məhsulunun növbəti mərhələsini planlaşdırırsınızsa, FT10 FinTech layihəsi kimi məhsul işlərindən və texniki dəstək və konsaltinq xidmətindən yararlanaraq mövcud qaydaların auditini, margin spesifikasiyasını, test strategiyasını və təhlükəsiz mərhələli tətbiq planını müzakirə edə bilərsiniz.