Trading platform qiymət mühərrikinin hazırlanması icra oluna bilən bid/ask qiymətlərinin etibarlı şəkildə yaradılması deməkdir. Bu, provayderdən gələn qiyməti sadəcə ekranda göstərmək deyil: sistem instrumenti tanımalı, provider formatını normallaşdırmalı, uyğun bid və ask səviyyələrini seçməli, markap və spread qaydalarını tətbiq etməli, qiymətin yaşını yoxlamalı və yalnız aktiv ticarət sessiyasında yayımlamalıdır.

Broker yeni instrumentlər, likvidlik provayderləri və ya müştəri qrupları əlavə etdikcə qiymət məntiqi kritik istehsalat komponentinə çevrilir. Yanlış symbol mapping, gecikmiş feed, mənfi və ya tərs spread, yaxud bütün qruplara təsadüfən eyni markapın tətbiqi müştəri insidentinə və əməliyyat riskinə səbəb ola bilər. Etibarlı qiymət nə nəticəyə, nə də gəlirliliyə zəmanət verir; o, platformanın qiymət nəzarətlərini və əməliyyat dayanıqlığını gücləndirir.

Qiymət mühərrikinin əsas məsuliyyəti

Yaxşı forex pricing engine development arxitekturası xam bazar məlumatı ilə platformanın yayımladığı kotirovkanı ayrı anlayışlar kimi saxlayır. Upstream feed dəyişməz xam hadisə kimi arxivlənir. Ondan sonra normalizasiya, seçmə, markap və qoruyucu yoxlamalar tətbiq olunur. Beləliklə, komanda sonradan “müştəri nə görüb?” və “bu qiymət hansı provider hadisəsindən yaranıb?” suallarını cavablandıra bilir.

  • Ingestion: FIX, WebSocket, REST polling və ya vendor protokolundan hadisələri qəbul edir.
  • Canonical model: provider simvolunu daxili instrument ID, bid, ask, ölçü, mənbə vaxtı, qəbul vaxtı, sequence və keyfiyyət statusu ilə standartlaşdırır.
  • Pricing: aktiv mənbələri seçir, top-of-book və ya qayda əsaslı composite bid/ask yaradır.
  • Distribution: yalnız səlahiyyətli tenant, hesab qrupu və kanala uyğun kotirovkanı göndərir.
  • Control plane: qaydaların versiyalarını, təsdiqlərini, auditini, override və kill-switch imkanını saxlayır.

Bu komponentlər POLADO-nun FinTech və trading sistemləri xidmətində platformanın order, risk, hesabat və back-office hissələri ilə birlikdə layihələndirilə bilər.

Feed-ləri normallaşdırmaq: symbol adından artıq məsələ

Bir provayder EURUSD, digəri EUR/USD, üçüncüsü isə vendor prefiksi və ya fərqli precision ilə instrument göndərə bilər. Eyni görünən kod həmişə eyni müqavilə demək deyil. Xüsusilə metal, indeks, CFD, kripto və expirylı məhsullarda valyuta, contract size, quote currency, lot step, tick size, ticarət sessiyası və rollover qaydaları ayrıca təsdiqlənməlidir.

Canonical instrument reyestri yaradın

Hər daxili instrument üçün ayrıca versiyalanan reyestr saxlayın: daxili ID, asset class, display symbol, provider symbol-ları, precision, tick size, contract məlumatı, trading calendar, həcm vahidi və qiymət mənbəsi siyasəti. Mapping-i kodda dağınıq if/else qaydaları ilə deyil, review edilən konfiqurasiya kimi idarə edin.

Hər inbound hadisədə ən azı provider ID, provider instrument ID, source timestamp, receive timestamp, sequence və raw payload identifikatoru qorunmalıdır. FIX market-data incremental yenilənmələri yeni, dəyişdirilmiş və silinmiş book entry-ləri ifadə edə bilər; buna görə consumer yalnız son qiyməti qəbul edən sadə parser yox, entry state-i düzgün saxlayan stateful komponent olmalıdır.

Bid/ask qurulması və qiymət keyfiyyəti

Qiymət mühərriki bid və ask-i eyni mənbədən almağa məcbur deyil, lakin seçmə qaydası açıq olmalıdır. Məsələn, hər iki tərəf üçün ən yaxşı etibarlı qiyməti seçmək olar; daha konservativ model isə eyni providerin cüt tərəfini üstün tuta bilər. Hansı üsul seçilirsə seçilsin, aşağıdakı invariant-lar yoxlanmalıdır:

  • bid və ask müsbət olmalı, bid ask-dən böyük olmamalıdır;
  • spread instrument üçün müəyyən edilən məntiqli intervalda qalmalıdır;
  • qiymət əvvəlki etibarlı qiymətə nisbətən anormal sıçrayış etməməlidir;
  • provider sequence və ya event vaxtı geri getdikdə hadisə kor-koranə tətbiq olunmamalıdır;
  • həcm məlumatı varsa, minimum qəbul edilən likvidlik limiti yoxlanmalıdır.

Broker markap mühərriki: konfiqurasiya edilən və audit olunan qaydalar

Broker markup engine xam composite qiymətdən müştəriyə yayımlanan qiyməti yaradır. Sadə nümunədə alış tərəfi üçün ask üzərinə, satış tərəfi üçün bid-dən müəyyən pip və ya faiz dəyəri əlavə edilir. Amma production qaydası adətən instrument, asset class, hesab qrupu, region, ağ-label tenant, ticarət sessiyası və bəzən həcm kateqoriyasına görə dəyişir.

Markap hesablaması decimal əsaslı olmalı, floating-point yuvarlaqlaşdırma səhvlərindən qaçmalıdır. Qayda mühərriki həmçinin tətbiq ardıcıllığını deterministik saxlamalıdır: məsələn, əvvəl source qiyməti seçmək, sonra protective floor/ceiling, sonra markap, sonda instrument precision-a yuvarlaqlaşdırmaq. Komanda bu ardıcıllığı sənədləşdirməli və test etməlidir; fərqli sırada eyni qaydalar fərqli client price yarada bilər.

Təhlükəsiz rule governance

  • Qaydanın sahibini, təsdiqləyən şəxsi, effective-from vaxtını və versiyasını saxlayın.
  • Yeni markapı əvvəlcə shadow mode-da hesablayın və köhnə nəticə ilə fərqi ölçün.
  • Geri dönüş üçün əvvəlki qayda versiyasını bir əməliyyatla aktivləşdirin.
  • Manual override-ları səbəb, operator və expiry vaxtı ilə audit edin.
  • Qrupun səviyyəsində limit qoyun ki, səhv konfiqurasiya qeyri-real spread yaratmasın.

Köhnəlmiş kotirovkadan qorunma və fallback feed

Stale quote protection trading platform üçün yalnız provider timestamp kifayət deyil. Provider saatı, şəbəkə gecikməsi və queue backlog fərqli mənzərə yarada bilər. Buna görə hər qiymət üçün source timestamp, platformaya qəbul vaxtı və son uğurlu publish vaxtını izləmək lazımdır. Stale qaydası instrument və sessiyaya görə dəyişə bilər: aktiv FX cütü üçün qəbul edilən yaş ilə həftəsonu bağlanan CFD üçün qəbul edilən yaş eyni olmamalıdır.

Yaş həddi keçildikdə sistemin davranışı əvvəlcədən seçilməlidir: quote-u invalid etmək, son qiyməti “indicative” kimi etiketləmək, yalnız display kanalında göstərmək və ya yeni order qəbulunu dayandırmaq. İcra edilə bilən köhnə quote-u səssiz şəkildə göstərmək düzgün fallback deyil.

Fallback təhlükəsizlik kəməri olmalıdır

Alternativ providerə keçid aşağıdakı halları izah edə bilməlidir: əsas feed nə vaxt pozuldu, hansı sağlamlıq siqnalı keçidi başlatdı, hansı qiymət mənbəsi aktiv oldu və nə vaxt primary feed-ə qayıdıldı. Fallback seçimi yalnız “son mesaj gəldi” qaydası ilə edilməməlidir. Spread, outlier faizi, ardıcıllıq boşluğu, gecikmə və providerin instrument coverage-i birlikdə qiymətləndirilməlidir.

Əsas və fallback feed-lər fərqli symbol convention və precision istifadə edirsə, eyni canonical instrument testləri hər iki mapping üçün aparılmalıdır. Likvidliyin icraya yönləndirilməsi ayrıca mövzudur; price feed failover-u order routing failover-u ilə qarışdırılmamalıdır.

Sessiyalar, yayım və müşahidəolunma

Qiymət mühərriki market calendar-dan xəbərdar olmalıdır. Açılış, bağlanış, günlük rollover, bayram, erkən bağlanış və maintenance pəncərələri publish siyasətinə təsir edir. Sessiya xaricində son quote-u “live” kimi saxlamaq əvəzinə, instrument statusu açıq verilməlidir. Session qaydalarının ayrıca dizaynı üçün market session management yanaşması ilə pricing qaydaları uzlaşdırılmalıdır.

Quote distributor adətən hər consumer üçün ayrıca qiymət hesablamamalıdır. Daxildə raw, normalized, composite və client-group price qatlarını saxlayıb uyğun audience-a stream göndərmək daha idarəolunandır. Snapshot və incremental update semantics, reconnect zamanı resync, rate limiting və backpressure də dizaynın hissəsidir.

Operativ paneldə instrument və provider üzrə quote age, update rate, rejected event count, spread, source-to-publish latency, fallback state, subscriber lag və markap nəticələri görünməlidir. Bu göstəricilər alarmla birlikdə işləməli, lakin qiymət hadisələrinin özündən audit log-larını əvəz etməməlidir.

İcra nəticələri ilə uzlaşdırma

Qiymət sistemi order zamanı verilən quote ID və rule version-u order lifecycle-a ötürməlidir. Sonradan bir fill araşdırılarkən komanda inbound qiyməti, normalized state-i, tətbiq olunan markapı, clientə yayımlanan quote-u, order qəbul vaxtını və execution nəticəsini bağlaya bilməlidir. Bu, qiymət mühərrikini ESFX FinTech/analytics layihəsi kimi analitika və əməliyyat monitorinqi qatları ilə daha faydalı inteqrasiya etməyə imkan verir.

Layihəyə başlamazdan əvvəl qərar siyahısı

  1. Hansı instrumentlər, providerlər, client qrupları və yayım kanalları ilk mərhələyə daxildir?
  2. Hər instrument üçün canonical mapping, precision, session və stale threshold kim tərəfindən təsdiqlənəcək?
  3. Composite qiymət siyasəti nədir: best bid/ask, primary-first, yoxsa sağlamlıq balına əsaslanan seçim?
  4. Markap hansı ardıcıllıqla tətbiq olunur və kim rule dəyişikliyini təsdiqləyir?
  5. Stale, crossed market, outlier və feed outage zamanı display və trade acceptance davranışı nədir?
  6. Quote ID, qayda versiyası və provider hadisəsi execution araşdırmasına necə bağlanacaq?

POLADO pricing pipeline, admin nəzarətləri, observability, test ssenariləri və trading platform inteqrasiyasını birlikdə müəyyənləşdirə bilər. Mövcud feed-ləriniz, instrument siyahınız və client-group qaydalarınız əsasında FinTech həlli üçün konsultasiya ilə prioritet arxitekturanı və mərhələli implementasiya planını müzakirə edin.