Trading platform liquidity bridge integration development brokerin və ya FinTech məhsulunun orderlərini bir və ya bir neçə liquidity provider-ə (LP) nəzarətli şəkildə yönləndirən execution qatının hazırlanmasıdır. Sadə API bağlantısından fərqli olaraq bridge hər order üçün hansı LP-yə müraciət ediləcəyini, cavab gecikəndə nə ediləcəyini, qismən fill-lərin necə saxlanacağını və provider sessiyası kəsiləndə açıq orderlərin necə yoxlanacağını müəyyən etməlidir.

Bu qat zəifdirsə, yaxşı müştəri interfeysi və risk mühərriki belə qeyri-müəyyən execution nəticələri, təkrarlanan orderlər, yanlış qiymət və ya gec aşkarlanan exposure ilə üzləşə bilər. Məqsəd təkcə “order göndərildi” cavabı almaq deyil; platformanın öz daxili həqiqət mənbəyini qoruması, provider hadisələrini izah edilə bilən vəziyyətlərə çevirməsi və istənilən anda orderin real statusunu bərpa edə bilməsidir.

Liquidity bridge nəyi həll edir?

Bridge trading core, risk sistemi, market-data qatları və LP-lər arasında adapter və routing orkestrasiyası rolunu oynayır. LP bağlantısı FIX, REST, WebSocket və ya proprietary protokol ilə qurula bilər. Protokol dəyişsə də, platformanın daxili contract-ı sabit qalmalıdır: canonical instrument, order, execution, reject və session-status modelləri.

  • Platforma simvolunu LP instrumentinə və contract ölçüsünə map edir.
  • Quote-ları qəbul edir, freshness və tradability qaydalarını tətbiq edir.
  • Pre-trade risk yoxlamasından keçən orderi uyğun LP-yə route edir.
  • Provider acknowledgement, reject, partial fill, full fill, cancel və correction hadisələrini vahid formata salır.
  • Exposure, limit, sessiya keyfiyyəti və routing qaydalarına əsasən seçim edir.
  • Disconnect, timeout və provider outage zamanı təhlükəsiz degrade və failover davranışını idarə edir.

FIX-də Execution Report orderin broker və ya execution tərəfi tərəfindən başa düşülən cari vəziyyətini və həmin vəziyyəti yaradan hadisəni çatdırmaq üçün nəzərdə tutulur. Praktikada isə hər LP öz required field-lərini, reject kodlarını, session davranışını və bəzən əlavə custom tag-ları fərqli tətbiq edir. Buna görə LP mesajını birbaşa client-facing status kimi istifadə etmək düzgün model deyil.

Symbol mapping: instrument adı deyil, execution müqaviləsidir

“XAUUSD” və ya “BTCUSD” adı təkbaşına inteqrasiya üçün kifayət etmir. Eyni görünən instrument provider-lər arasında fərqli contract size, decimal precision, minimum quantity, quantity step, quote currency, trading session, swap və ya margin parametrlərinə malik ola bilər. Bridge-də versionlanan instrument registry saxlanmalıdır.

Hər mapping üçün saxlanmalı əsas məlumatlar

  • Platform instrument ID və LP instrument ID;
  • asset class, base/quote currency və settlement qaydası;
  • price scale, quantity scale, minimum/maximal order həcmi və step;
  • contract multiplier və lot conversion;
  • allowed order types, time-in-force və side mapping;
  • LP-yə məxsus session calendar və trading halt qaydaları;
  • mapping-in aktivlik intervalı və dəyişiklik audit izi.

Bu registry routing-dən əvvəl yoxlanmalıdır. Əks halda platforma 0.01 lot qəbul edib LP-nin 1-unit minimumu səbəbilə reject göndərməsi, yaxud quantity conversion nəticəsində nəzərdə tutulandan böyük exposure yaratması mümkündür. Market-data və analytics məhsullarında da eyni prinsip vacibdir; POLADO-nun ESFX layihəsi market məlumatı, indikatorlar və analitikanın eyni məhsulda aydın data model tələb etdiyini göstərən uyğun nümunədir.

Quote handling: son qiymət həmişə trade edilə bilən qiymət deyil

Bridge quote-ları yalnız cache-ə yazmamalıdır. Hər quote üçün source, receive timestamp, provider timestamp varsa onun dəyəri, bid/ask, sequence və freshness vəziyyəti saxlanmalıdır. Routing qərarı zamanı sistem müəyyən etməlidir: qiymət kifayət qədər yenidir, spread məqbuldur, instrument həmin LP-də tradeable-dir və sessiya sağlamdırmı?

Stale quote siyasəti konkret olmalıdır. Məsələn, quote freshness həddi aşılırsa platforma orderi kor-koranə başqa LP-yə yönləndirməməlidir: yeni LP-də qiymət, minimum həcm və execution qaydası fərqli ola bilər. Market order üçün yeni quote əsasında revalidation, limit order üçün isə ilkin limitin yenidən yoxlanması tələb oluna bilər. Bu qərar məhsul qaydasına və hüquqi/commercial modelə uyğun sənədləşdirilməlidir.

Execution routing sistemi necə işləməlidir?

Etibarlı trading execution routing system “ən yaxşı qiymətə route et” kimi qeyri-müəyyən qayda ilə bitmir. Rule engine hər LP üçün mövcudluğu, instrument eligibility, quote freshness, spread, observed latency, reject rate, mövcud exposure, LP limitləri, order type və client/account group qaydalarını qiymətləndirir. Nəticə qərar və səbəblərilə birlikdə saxlanmalıdır.

Praktik routing ardıcıllığı

  1. Order üçün immutable client request ID yaradın və sintaksis, hesab statusu, instrument və risk uyğunluğunu yoxlayın.
  2. Canonical order yaradın; accepted-for-routing statusu ilə request qəbulunu provider acceptance-dan ayırın.
  3. Eligible LP siyahısını symbol, sessiya, limit və sağlamlıq filtrindən keçirin.
  4. Routing policy ilə əsas LP-ni və icazəli fallback-ləri seçin; qərarın input-larını audit edin.
  5. LP adapter vasitəsilə outbound request göndərin və platform order ID, LP client ID, session ID əlaqəsini saxlayın.
  6. Provider hadisələrini canonical execution event-lərə çevirin; order state transition-ları atomik tətbiq edin.
  7. Fill-ləri exposure, mövqe, fee və ledger proseslərinə etibarlı şəkildə ötürün.

Bir neçə LP ilə işləyən platformada “ən yaxşı” route yalnız top-of-book qiyməti deyil. Daha dar spread tez-tez daha kiçik mövcud həcmlə, daha zəif fill ehtimalı ilə və ya daha yüksək rejection riski ilə müşayiət oluna bilər. Sistem öz routing məqsədini açıq müəyyən etməlidir: qiymət prioriteti, fill certainty, latency, exposure balancing, provider concentration və ya bunların idarə olunan kombinasiyası.

Fill, reject və cancel normalization

LP bridge development üçün əsas prinsip budur: provider statusları platformanın daxili state machine-ni əvəz etmir. Canonical modeldə ən azı pending submission, working/new, partially filled, filled, cancel pending, canceled, rejected, expired və indeterminate/recovery-required kimi vəziyyətlər və keçid qaydaları olmalıdır.

Hər execution event üçün provider execution ID, platform order ID, LP order ID, execution time, receive time, last quantity, last price, cumulative quantity, leaves quantity, liquidity/source məlumatı və raw payload reference saxlanmalıdır. Qismən fill-lər ayrıca event kimi tətbiq edilməli, cumulative nəticə isə deterministic hesablanmalıdır. Eyni execution ID yenidən gəlsə, exposure və mövqe ikinci dəfə dəyişməməlidir.

Reject-ləri sadəcə “failed” kimi göstərmək əməliyyat komandasını kor edir. Canonical reject kateqoriyalarına invalid instrument, quantity/step, market closed, price protection, insufficient liquidity, risk reject, session unavailable, rate limit və unknown/provider-specific daxildir. Raw code və mətn isə mütləq qorunmalıdır. Order lifecycle-in daha dərin tətbiqi üçün order state management yanaşması bridge-in state keçidləri ilə eyni contract üzərində işləməlidir.

Idempotency və qeyri-müəyyən nəticələr

Timeout orderin reject edildiyini sübut etmir. LP orderi qəbul etmiş, lakin acknowledgement itmiş ola bilər. Buna görə transport retry ilə business retry fərqləndirilməlidir. Eyni economic orderin ikinci dəfə bazara getməsinin qarşısını almaq üçün daxili idempotency key, mümkün olduqda LP client order ID və request journal istifadə edin.

Timeout zamanı düzgün yol adətən “yenidən göndər” deyil: orderi indeterminate kimi işarələyin, sessiyanın bərpasını gözləyin, LP status inquiry, execution replay və ya drop-copy/reconciliation kanalı ilə nəticəni yoxlayın. Yalnız əvvəlki cəhdin heç vaxt qəbul olunmadığı etibarlı sübut ediləndə yeni submission yaradılmalıdır. Bu dizayn prinsipi FinTech testing və failure scenario planında ayrıca sınaqdan keçirilməlidir.

Failover: yeni LP-yə keçmək həmişə təhlükəsiz deyil

Failover canlı sessiya kəsiləndə route-un avtomatik dəyişməsi deyil. Əsas LP disconnect olduqda bridge üç sualı cavablamalıdır: hansı orderlər hələ working ola bilər, hansı request-lərin nəticəsi qeyri-müəyyəndir və hansı instrumentlər üçün ikinci LP həqiqətən ekvivalent execution imkanı verir?

Sağlam failover nəzarətləri

  • Session heartbeat, logon/logout, message gap, quote staleness və reject spike monitorinqi;
  • LP və instrument səviyyəsində circuit breaker; problemli route-un avtomatik bloklanması;
  • Yeni orderlər üçün primary, secondary və manual-review siyasəti;
  • Açıq orderlər üçün cancel-on-disconnect, status recovery və manual intervention qaydası;
  • İkinci LP-yə göndərməzdən əvvəl symbol, price, quantity və risk revalidation;
  • Human operator üçün kill switch, route disable və auditli override imkanları.

Exposure-aware routing burada vacibdir. Platforma müəyyən LP-də net exposure, provider credit limiti və ya instrument limiti yüksəldikdə route payını azalda bilər. Lakin routing bridge risk mühərrikini əvəz etməməlidir: pre-trade limit, reserve/release və kill-switch qaydaları ayrıca authoritative risk qatında qalmalıdır. Bu sərhədi POLADO-nun FinTech və trading sistemləri xidməti çərçivəsində architecture discovery zamanı dəqiqləşdirmək faydalıdır.

Audit log və post-trade reconciliation

Bridge üçün audit log yalnız error log deyil. Hər order üzrə qəbul edilmiş request, risk qərarı, routing qərarı, outbound payload reference, provider response, state transition, retry, operator action və reconciliation nəticəsi ardıcıl zaman xətti kimi görünməlidir. Raw LP mesajları təhlükəsiz saxlanmalı, canonical event-lərlə əlaqələndirilməli və access control tətbiq edilməlidir.

Post-trade reconciliation real-time event axınının əvəzi deyil; onun nəzarət mexanizmidir. Müəyyən intervalda və end-of-day prosesində platform order/fill cəmi LP execution report, drop copy, statement və ya rəsmi report ilə müqayisə edilməlidir. Break-lər “missing execution”, “quantity mismatch”, “price mismatch”, “unknown external order”, “duplicate event” və “unresolved order status” kimi qruplaşdırılmalı, ownership və resolution workflow-a malik olmalıdır.

Satınalma və texniki discovery checklist-i

  • Hər LP üçün protokol, certification/UAT, session, throttling və support modelini bilirsinizmi?
  • Instrument mapping, quantity conversion və trading session məlumatının sahibi kimdir?
  • Hansı qərarlar routing engine-də, hansılar risk engine-də, hansılar back office-də authoritative-dir?
  • Timeout, disconnect, duplicate execution, out-of-order event və partial-fill ssenariləri üçün qəbul edilmiş davranış varmı?
  • Primary LP outage zamanı yeni və açıq orderlər üçün ayrıca siyasət mövcuddurmu?
  • Reconciliation break-lərini kim görür, kim düzəldir və hansı data sübut kimi saxlanır?

Yeni LP qoşulması, multi-LP architecture və ya köhnə manual bridge əməliyyatlarının əvəzlənməsi planlanırsa, ilk deliverable kod deyil: integration contract, canonical model, routing/failover matrix, recovery proseduru və test planıdır. POLADO ilə layihəni müzakirə edin; komanda execution connectivity-ni risk, audit, back-office və production support tələbləri ilə birlikdə scope edə bilər.