Trading platform instrument master development hər bir ticarət aləti üçün simvolu, identifikatorları, müqavilə şərtlərini, ticarət qaydalarını və qüvvədəolma tarixçəsini bir idarə olunan mənbədə toplamaq deməkdir. Bu, sadəcə admin panelində “yeni simvol əlavə et” funksiyası deyil. Düzgün qurulduqda instrument master qiymət mühərriki, order idarəetməsi, marja, komissiya, risk, hesabat, mobil tətbiq və marketinq kataloqu üçün eyni həqiqət mənbəyinə çevrilir.

Əks halda eyni alət müxtəlif sistemlərdə fərqli lot ölçüsü, tick size, valyuta və ya ticarət statusu ilə görünə bilər. Nəticə yalnız yanlış UI deyil: səhv marja hesablaması, rədd edilmiş orderlər, uyğunsuz statement-lər və bahalı əməliyyat müdaxilələridir. POLADO FinTech və trading sistemləri xidməti çərçivəsində instrument master-i ayrıca konfiqurasiya ekranı kimi yox, platformanın idarə olunan domeni və inteqrasiya müqaviləsi kimi layihələndirir.

Instrument master nəyi idarə etməlidir?

Bir instrument record yalnız görünən ticker-dən ibarət olmamalıdır. “XAUUSD”, “EURUSD” və ya “AAPL” istifadəçi üçün qısa addır; sistem üçün isə bu adın hansı provider, venue, müqavilə və qaydalarla əlaqəli olduğu dəqiq müəyyən edilməlidir.

1. Sabit kimlik və vendor simvol xəritəsi

Hər alət üçün dəyişməyən daxili instrument ID yaradın. Ekrandakı simvol, LP və ya market-data vendorunun simvolu, FIX SecurityID-si, ISIN, CFI, MIC və digər xarici kodlar ayrıca identifikator xəritəsində saxlanmalıdır. ISO 10962 CFI təsnifatı maliyyə alətlərinin xüsusiyyətlərini strukturlaşdırmaq üçün istifadə olunan beynəlxalq standartdır; lakin CFI platformadakı daxili ID-ni əvəz etmir.

Bir alətin eyni anda bir neçə vendor simvolu ola bilər. Məsələn, daxili “US_TECH_CFD” məhsulu bir price feed-də başqa kodla, icra venue-sunda isə fərqli kodla tanına bilər. Xəritə ən azı mənbə, xarici kod, etibarlılıq intervalı, prioritet, mapping statusu və yoxlama nəticəsini saxlamalıdır. Beləliklə, simvol dəyişimi və ya vendor miqrasiyası tarixçəsiz “find-and-replace” əməliyyatına çevrilmir.

2. Aktiv sinfinə uyğun atributlar

Universal əsas model qurun, sonra aktiv sinfinə görə genişləndirin. Bütün alətlər üçün ad, qısa ad, aktiv sinfi, quote və settlement valyutası, status, venue və zaman zonası faydalıdır. Lakin forex, spot metal, CFD, səhm, fyuçers və opsion eyni atributlara malik deyil.

  • FX və spot: base/quote currency, pip precision, settlement qaydası, rollover və swap qrupu.
  • CFD: underlying reference, contract size, dividend və korporativ hadisə davranışı, financing qaydası.
  • Fyuçers: expiry, last trade date, delivery/settlement tipi, contract multiplier, month code və continuous-symbol qaydası.
  • Opsion: underlying, call/put, strike, expiry, exercise üslubu və multiplier.
  • Səhm və ETF: ISIN kimi identifikatorlar, əsas listing venue, lot qaydaları, korporativ hadisələr üçün münasiblik.

Bu fərqləri çoxlu sərbəst mətn sahəsi ilə gizlətmək əvəzinə, tipli sahələr, məcburi validasiyalar və aktiv sinfi üzrə schema istifadə edin.

Müqavilə spesifikasiyası icra və marja ilə eyni mənanı daşımalıdır

Contract specification management-də ən təhlükəli səhv eyni parametri bir neçə sistemdə ayrıca saxlamaqdır. Minimum qiymət addımı, minimum order həcmi, həcm addımı, maksimum həcm, contract size, multiplier, price precision, quantity precision, quote currency və settlement currency bir-biri ilə əlaqəlidir. Onlardan hər hansı biri qiymət ekranında, order gateway-də və ya marja servisində fərqli olduqda məhsul faktiki olaraq üç fərqli alət təqdim edir.

Məsələn, minimum qiymət addımı 0.01, contract multiplier 100 və istifadəçinin 2 müqaviləlik mövqeyi varsa, bir tick-lik P&L dəyişimi hesablamada həmin vahidlərdən irəli gəlməlidir. FIX spesifikasiyası da listinqli törəmə alətlər üçün minimum qiymət addımı ilə contract value factor arasındakı əlaqəni ayrıca qeyd edir. Parametrləri yalnız display metadata kimi deyil, hesablamalarda istifadə edilən versiyalı qaydalar kimi model edin.

Ticarət qaydalarını ayrıca və təkrar istifadə edilən obyekt kimi qurun

Instrument record birbaşa hər qaydanı təkrarlamamalıdır. Məsələn, “US equities regular session”, “metals holiday calendar” və “retail FX execution profile” kimi rule set-lər yaradın və instrument-ləri onlara bağlayın. Bu yanaşma ticarət cədvəli, trading halt, order tipi icazələri, short-selling məhdudiyyəti, leverage tier və ya region üzrə uyğunluq kimi qaydaların idarəsini asanlaşdırır.

Bu məqalə bazar sessiyalarının detallı modelindən fərqlidir: sessiya xidməti “bazar indi açıqdırmı?” sualına cavab verir, instrument master isə həmin sessiya və təqvimin hansı alət versiyasına aid olduğunu müəyyən edir. Risk və marja servisi də instrument master-dən özünə lazım olan təsdiqlənmiş parametrləri almalı, onları əl ilə kopyalamamalıdır.

Lifecycle: draft-dan arxivə qədər idarə olunan vəziyyətlər

Instrument statusu təkcə enabled/disabled flag olmamalıdır. Praktik lifecycle aşağıdakı vəziyyətləri ayırır:

  1. Draft: record hazırlanır, lakin heç bir downstream sistemə yayımlanmır.
  2. Pending approval: maker dəyişiklik təklifini tamamlayıb; checker yoxlamalıdır.
  3. Scheduled: təsdiqlənib, amma effective-from tarixini gözləyir.
  4. Active: yeni orderlər, qiymətlər və istifadəçi görünüşü üçün qüvvədədir.
  5. Close-only / reduce-only: açılış məhdudlaşdırılır, mövcud mövqelər isə idarə olunur.
  6. Suspended: müvəqqəti olaraq ticarət və ya qiymət dayandırılıb.
  7. Expired / delisted / archived: yeni fəaliyyətə bağlı deyil, lakin audit və tarixi hesabatlar üçün saxlanılır.

Fyuçersin expiry-si, CFD-nin rollover-i, vendor mapping dəyişikliyi və ya marja parametrinin yenilənməsi eyni lifecycle mexanizmindən istifadə edə bilər, lakin müxtəlif business impact və təsdiq siyasəti tələb edir. “Active” record üzərində overwrite etmək əvəzinə yeni versiya hazırlayın; keçmiş trade, statement və risk qərarları öz tarixində qüvvədə olan versiyaya istinad etməlidir.

Maker-checker, effective date və audit trail

Yüksək təsirli dəyişikliklər üçün dörd prinsip vacibdir: vəzifələrin ayrılması, təsdiq edilə bilən diff, planlı qüvvəyə minmə və geri qaytarma. Maker yeni versiyanı yaradır. Checker dəyişən sahələri, bağlı sistemləri və gözlənilən təsiri görür. Təsdiq zamanı sistem immutable audit event yazır: kim, nəyi, nə vaxt, hansı səbəblə dəyişdi; hansı köhnə və yeni dəyərlər var idi; hansı approval verildi.

Effective-from timestamp UTC-də saxlanmalı, biznes ekranında isə əməliyyatçı üçün uyğun zaman zonası ilə göstərilməlidir. Effective-to intervalı əlavə etdikdə iki aktiv versiyanın eyni alət və eyni parametr üçün üst-üstə düşməsini bloklayın. Təcili düzəliş üçün ayrıca break-glass rolu, səbəb kodu, ikinci şəxsin sonrakı təsdiqi və avtomatik incident qeydi istifadə edin.

İnstrument konfiqurasiyası deploy edilən kod kimi idarə olunmalıdır: nəzərdən keçirilən dəyişiklik, versiya, planlı tətbiq, müşahidə və təhlükəsiz rollback.

Downstream yayım və uzlaşma necə işləməlidir?

Master record-u database-dən birbaşa oxutmaq bütün sistemlər üçün həmişə uyğun deyil. Qiymət, execution, risk və mobil tətbiq fərqli gecikmə, availability və cache tələblərinə malikdir. Daha etibarlı model təsdiqlənmiş instrument versiyasını canonical event kimi yayımlamaqdır: məsələn, InstrumentVersionActivated və InstrumentTradingStatusChanged.

Hər consumer öz “applied version” vəziyyətini qaytarmalıdır. Back-office yalnız “event göndərildi” deyil, “pricing v184 tətbiq etdi, margin v184 tətbiq etdi, client API v184 tətbiq etdi” nəticəsini görməlidir. İdempotent consumer-lər, versiya nömrəsi, checksum və retry/dead-letter mexanizmi eyni dəyişikliyin iki dəfə tətbiqinin və ya səssiz itkisinin qarşısını alır.

Yayım qapısından əvvəl yoxlama siyahısı

  • Required atributlar aktiv sinfinə və ticarət modelinə uyğun doldurulubmu?
  • Tick size, precision, min/max quantity və contract size bir-biri ilə məntiqi cəhətdən uyğundurmu?
  • Vendor simvol mapping-i test feed və production feed-də tapılırmı?
  • Quote, settlement, fee və marja valyutaları üçün conversion asılılığı müəyyən edilibmi?
  • Yeni leverage və marja parametrləri limit və liquidation məntiqi ilə sınaqdan keçirilibmi?
  • Effective vaxtı sessiya, batch job, rollover və ya hesabat cut-off ilə toqquşmurmu?
  • Bütün mandatory consumer-lər preview müqayisəsindən uğurla keçibmi?

İnstrument master üçün düzgün admin UX

Əməliyyat komandasına sadəcə uzun forma vermək kifayət deyil. UI əvvəlcə alətin xülasəsini, hazırkı aktiv versiyanı, növbəti planlı dəyişikliyi, downstream health statusunu və dəyişiklik tarixçəsini göstərməlidir. Sonra istifadəçini asset-class wizard, validation mesajları, mapping preview və approval queue ilə yönləndirməlidir.

İki müqayisə görünüşü kritikdir: əvvəlki və təklif olunan versiyanın field-level diff-i; ikinci isə instrument master ilə downstream consumer-lərin tətbiq etdiyi versiyaların reconciliation görünüşüdür. POLADO-nun ESFX layihəsi kimi maliyyə və analitika məhsullarından əldə edilən təcrübə göstərir ki, sıx əməliyyat ekranlarında məlumatın prioriteti və təhlükəsiz təsdiq axını texniki data modeli qədər önəmlidir.

Platforma sahibinin qəbul meyarları

Layihəni “admin-də simvol yaratmaq olur” meyarı ilə qəbul etməyin. Platforma yeni aləti draft kimi yaratmalı, source identifier-ləri bağlamalı, aktiv sinfinə uyğun contract specification-u yoxlamalı, iki nəfərlik approval-dan keçirməli, gələcək vaxt üçün planlamalı və bütün consumer-lərdə tətbiq statusunu göstərməlidir. Tarixi trade və hesabatlar isə sonrakı dəyişiklikdən sonra belə həmin anda qüvvədə olan instrument versiyasını yenidən qura bilməlidir.

Broker, CFD provayderi və ya multi-asset platforma qurursunuzsa, instrument master data modelinizi order, pricing və marja modullarından əvvəl dəqiqləşdirin. POLADO ilə konsultasiya üçün əlaqə saxlayın: mövcud konfiqurasiyaların auditini, target schema-nı, approval modelini, integration event-lərini və mərhələli delivery planını birlikdə hazırlaya bilərik.