Trading Platform FIX API inteqrasiyası: sessiya bərpası, sequence nəzarəti və order mapping

Trading platform FIX API integration development layihəsinin təhlükəsiz olması üçün FIX bağlantısı ayrıca texniki müqavilə, dayanıqlı sessiya vəziyyəti, bərpa edilə bilən mesaj jurnalı və operativ prosedurlarla hazırlanmalıdır. Normal ssenaridə NewOrderSingle göndərmək kifayət deyil: TCP bağlantısı qırılanda, qarşı tərəf resend sorğusu verəndə, eyni execution report yenidən gələndə və ya cancel/replace cavabı gecikəndə platformanın nəticəsi hələ də düzgün və audit edilə bilən qalmalıdır.

POLADO-da FinTech və trading sistemləri çərçivəsində FIX qoşulmasını OMS, risk nəzarətləri, hesab strukturu, audit jurnalı və əməliyyat ekranları ilə birlikdə layihələndiririk. Məqsəd yalnız mesaj mübadiləsi deyil, broker, venue və ya likvidlik provayderi ilə istehsal mühitində idarə edilə bilən inteqrasiyadır.

Əvvəlcə FIX “dialektini” və məsuliyyət sərhədini razılaşdırın

FIX standartı mesajların ümumi çərçivəsini verir, lakin hər qarşı tərəfin implementation guide sənədi ayrıca müqavilədir. Eyni mesaj tipi fərqli required tag-lar, custom tag-lar, fərqli TimeInForce dəyərləri, instrument identifikatorları, reject reason-ları və bərpa qaydaları ilə istifadə oluna bilər. Buna görə işin ilk artefaktı “biz FIX dəstəkləyirik” cümləsi deyil, versiya və mesaj-sahəsi matrisi olmalıdır.

• BeginString və tətbiq versiyası, məsələn FIX.4.2, FIX.4.4 və ya FIXT sessiya profili;
• hər istiqamət üzrə mesajlar: order entry, execution reports, cancel/replace, mass status, trade capture və inzibati mesajlar;
• required, optional və proprietary tag-lar, data type-lar və default dəyərlər;
• instrument, tərəf, hesab, sub-account, trader və routing identifikatorlarının mənası;
• sessiya vaxtları, heartbeat intervalı, IP/TLS/authentication qaydaları və reset pəncərəsi;
• sertifikasiya ssenariləri, test endpoint-ləri, kontakt və incident eskalasiyası.

Bu sənəd həm inteqrasiya adapterinin, həm də biznes mapping qatının sərhədini müəyyən edir. Məsələn, bir venue üçün symbol, digər tərəf üçün SecurityID + SecurityIDSource məcburi ola bilər. Bu fərqi UI, OMS və ya risk mühərrikinə yaymaq əvəzinə, qarşı tərəfə aid adapterdə və kontrollu instrument mapping cədvəlində saxlamaq daha təhlükəsizdir.

FIX sessiyası TCP socket deyil

FIX sessiyası iki tərəf arasında ardıcıl sequence nömrələri ilə işləyən, bağlantının özündən uzunömürlü məntiqi vəziyyətdir. Bağlantı kəsilə bilər, lakin sessiyanın inbound və outbound nömrələri, göndərilmiş mesajların məzmunu və emal edilmiş hadisələrin izi saxlanmalıdır. Bu səbəbdən bir sessiyanın eyni anda iki aktiv sahibi olmamalıdır.

Dayanıqlı sessiya vəziyyəti

Hər counterparty/session üçün ən azı növbəti outbound sequence nömrəsi, gözlənilən inbound sequence nömrəsi, logon statusu, son heartbeat vaxtı və reset siyasəti dayanıqlı saxlanmalıdır. Outbound mesajın sequence nömrəsi ayrılması, mesajın jurnalına yazılması və şəbəkəyə verilməsi arasında proses dayanarsa, restart zamanı hansı nömrənin artıq istifadə olunduğunu dəqiq bilmək lazımdır. Əks halda duplicate order və ya bərpa olunmayan boşluq yarana bilər.

Yüksək əlçatanlıqda active/passive failover tətbiq edilirsə, liderlik mexanizmi və shared durable store vacibdir. İki node eyni CompID cütü ilə paralel göndəriş edərsə, sequence ardıcıllığı pozular. Bu, sadə load balancer problemi deyil; sessiya mülkiyyəti problemidir.

Heartbeat və bağlantı itkisi

Heartbeat yalnız “server yaşayır” siqnalı deyil. Gecikmə həddi, TestRequest qaydası, cavabsızlıq vaxtı, reconnect backoff-u və operator xəbərdarlığı əvvəlcədən müəyyən olunmalıdır. Sistem hər reconnect-u, logon/logout-u, sequence mismatch-i və TestRequest timeout-unu strukturlaşdırılmış jurnal hadisəsi kimi saxlamalıdır.

Sequence number recovery: reset rahat çıxış yolu deyil

Session sequence number-ları bir-bir artır və disconnect-dən sonra adətən davam etməlidir. Qarşı tərəf gözlədiyindən yüksək nömrəli mesaj alanda ResendRequest göndərə, aşağı nömrə və ya təkrar mesaj alanda isə PossDupFlag, OrigSendingTime və öz qaydalarına əsasən emal edə bilər. Buna görə outbound mesaj store-u və inbound raw-message jurnalı recovery dizaynının əsas hissəsidir.

Resend cavabında tətbiq mesajları orijinal business məzmununu qoruyaraq təkrar göndərilə bilər; artıq çatdırılması lazım olmayan inzibati boşluqlar isə uyğun GapFill davranışı tələb edə bilər. Praktik qayda budur: mühərrik kitabxanasının default davranışına kor-koranə etibar etməyin. Qarşı tərəfin guide sənədində resend, gap fill, SequenceReset və poss-dup davranışını konkret test edin.

ResetSeqNumFlag yalnız iki tərəfin əvvəlcədən razılaşdırdığı siyasət olduqda işlədilməlidir. “Bağlantı qırıldı, 1-dən başlayaq” yanaşması keçmiş order və execution hadisələrinin itirilməsi və ya təkrar tətbiq olunması riski yaradır. Reset vaxtı, initiator tərəf, açıq order-ların vəziyyəti və resetdən əvvəl boşluqların yoxlanması runbook-da açıq göstərilməlidir.

Inbound emalını idempotent edin

Sequence yoxlaması vacibdir, amma biznes idempotentliyinin əvəzi deyil. Eyni execution report resend nəticəsində gələ, failover zamanı yenidən görünə və ya venue tərəfindən fərqli transport yolundan təkrar çatdırıla bilər. OMS yalnız “bu MsgSeqNum-u görmüşəmmi?” sualına yox, “bu biznes hadisəsini artıq tətbiq etmişəmmi?” sualına da cavab verməlidir.

Canonical execution modeli adətən counterparty, session, ExecID, OrderID, ClOrdID zənciri, trade date və hadisə tipini saxlayır. Dəqiq unique key qarşı tərəfin semantikasından asılıdır; bəzi inteqrasiyalarda ExecID kifayətdir, digərlərində əlavə sahələr tələb olunur. Bu qərar mapping spesifikasiyasında yazılmalı, database constraint və replay testləri ilə qorunmalıdır.

Order və execution mapping-i canonical modelə çevirin

FIX tag-larını birbaşa daxili order cədvəlinə köçürmək sonradan çətinlik yaradır. Daha düzgün yanaşma xarici dialekti daxili canonical order, order revision və execution event modelinə çevirməkdir. Daxili model hər order-in müştəri identifikatorunu, broker/venue identifikatorunu, parent-child əlaqələrini, status keçidlərini, miqdarları, qiymətləri, komissiya sahələrini və xam mesaj istinadını saxlamalıdır.

• ClOrdID: sizin request identifikatorunuz və amend zəncirinin əsasıdır; cancel/replace üçün yeni və unikal dəyər yaradın.
• OrigClOrdID: dəyişdirilən və ya ləğv edilən əvvəlki request-i bağlayır.
• OrderID: qarşı tərəfin order identifikatorudur; replace zamanı dəyişə də, dəyişməyə də bilər.
• ExecID: execution hadisəsinin idempotent emalı üçün əsas namizəddir.
• LastQty/LastPx və CumQty/LeavesQty: fill hadisəsi ilə order-in toplanmış vəziyyətini ayırmağa kömək edir.
• ExecType və OrdStatus: hadisə növünü cari order vəziyyəti ilə qarışdırmamağa imkan verir.

Partial fill, pending cancel, pending replace, replace, cancel reject və unsolicited cancel kimi keçidlər state machine ilə modelləşdirilməlidir. Bu məqalə likvidlik körpüsünün route seçimi və failover mövzusu deyil; həmin səviyyə üçün FT10 kimi FinTech iş nümunələrini nəzərdən keçirə bilərsiniz. Buradakı fokus hər FIX sessiyasının etibarlı semantikasıdır.

Reject-ləri operator üçün izah edilə bilən edin

Session Reject, Business Message Reject, New Order Single üçün Execution Report reject və Order Cancel Reject eyni hadisə deyil. Hər biri fərqli sahibə və fərqli növbəti addıma malik ola bilər. Məsələn, sintaksis və ya sequence xətası sessiya və ya adapter problemi ola bilər; price band, account permission və ya instrument statusu biznes/risk qərarıdır; cancel reject isə order-in hələ aktiv, dolmuş və ya artıq başqa request tərəfindən dəyişdirilmiş olduğunu göstərə bilər.

Operator ekranında raw FIX message, parsed tag-lar, daxili order ID, counterparty reason code, correlation ID, zaman xətti və təklif olunan runbook addımı görünməlidir. Sadəcə “order failed” statusu support komandasına kifayət etmir.

Sertifikasiya və production readiness yoxlama siyahısı

1. Hər mesaj üçün field-level mapping, nümunə payload və mənfi testlər təsdiqlənib.
2. Disconnect, reconnect, inbound/outbound gap, resend və sequence reset ssenariləri test edilib.
3. Duplicate execution, partial fill, cancel/replace yarışları və delayed reject sınaqdan keçirilib.
4. Open-order və trade status sorğuları ilə bərpa/reconciliation proseduru müəyyən edilib.
5. Session dashboard, alert-lər, raw-message retention, redaction və audit access qaydaları tətbiq olunub.
6. Counterparty sertifikasiyası, production cutover planı, rollback və əlaqə matrisi hazırdır.

Əməliyyat dəstəyi buraxılışdan sonra başlayır: heartbeat gecikməsi, resend həcmi, sequence gap sayı, reconnect tezliyi, reject kodlarının paylanması və order-to-ack latency izlənməlidir. POLADO bu işi texniki dəstək və konsaltinq ilə davam etdirə, dəyişiklikləri kontrollu release, test sübutu və runbook yeniləməsi ilə idarə edə bilər.

Nə vaxt FIX inteqrasiya tərəfdaşı ilə işləmək lazımdır?

Əgər platformanız broker, venue və ya institusional likvidlik provayderinə qoşulursa, əsas sual “mesaj göndərə bilirikmi?” deyil. Doğru sual budur: “Sessiya səhər yenidən qurulanda, gün ərzində failover olanda və qarşı tərəf köhnə mesajları istəyəndə order həqiqəti, fill-lər və audit izi qorunacaqmı?” Bu sualın cavabı arxitektura, test və əməliyyat prosesində olmalıdır.

FIX connectivity roadmap, counterparty specification review və ya mövcud engine auditinə ehtiyacınız varsa, POLADO ilə əlaqə saxlayın. Biz sessiya sahibliyini, mapping qatını, recovery ssenarilərini və production support modelini platformanızın mövcud OMS, risk və əməliyyat prosesinə uyğun planlaşdıra bilərik.