FIX API və MT4 inteqrasiyası connector layihəsi kimi deyil, nəzarət olunan tərcümə və sübut qatı kimi qurulmalıdır. MetaTrader ticket-i, FIX ClOrdID-si, qarşı tərəfin OrderID-si və execution identifikatoru eyni şey deyil. Onları bir-birinin yerinə keçirmək qismən fill, cancel/replace zənciri, reconnect və ya günsonu düzəlişi zamanı yanlış order statusu, təkrarlanan fill və ya səhv balans riski yaradır.

POLADO-nun tövsiyə etdiyi model budur: hər iki tərəfdən gələn native hadisələri dəyişmədən saxlayın; onları canonical order və execution modelinə çevirin; bütün istehlakçıları idempotent edin; klientə göstərilən statusu, balansı və əməliyyat qərarını xarici icra həqiqəti ilə reconciliation tamamlanmadan yekun fakt kimi qəbul etməyin.

Bu məqalə ümumi FIX API inteqrasiyası, order-state management və reconciliation mövzularını təkrarlamır. Fokus məhz MT4/MT5-in platformaya məxsus ticket, account/group və simvol davranışını FIX və xarici brokerage API-lərinin execution modeli ilə təhlükəsiz birləşdirməkdir.

Bridge-in işi order göndərmək deyil, iki fərqli həqiqəti idarə etməkdir

MetaTrader mühitində order, deal və position fərqli obyektlər ola bilər. MT5 sənədləri order və deal üçün ticket-lərin mövcud olduğunu, onların position ilə əlaqələndirildiyini göstərir. FIX execution report isə order zənciri, client order ID, venue order ID və execution ID kimi ayrıca identifikatorlar daşıyır. FIX-də cancel/replace əməliyyatları ClOrdID və OrigClOrdID zənciri ilə ifadə olunur; execution report-dakı ExecID isə ayrıca execution hadisəsini müəyyən edir. Buna görə bridge “bir ticket = bir trade” fərziyyəsi ilə işləyə bilməz.

MetaTrader 5 trading model və FIX Execution Report field reference bu fərqin əsas texniki səbəbini göstərir. MT4 tərəfdə isə brokerin əlçatan interfeysi və server konfiqurasiyası ayrıca yoxlanmalıdır: MetaTrader 4-ün rəsmi broker API səhifəsi Manager API-ni platforma inteqrasiyası və əlavə funksionallıq üçün nəzərdə tutur.

POLADO bridge modeli: native hadisə, canonical model, projection

Bridge-də üç məlumat qatını ayırın:

  1. Native evidence: FIX mesajı, broker webhook-u, REST cavabı və ya MT4/MT5 server hadisəsi olduğu kimi, vaxt möhürü, mənbə, payload hash və qəbul vaxtı ilə saxlanılır.
  2. Canonical execution model: source-dan asılı olmayan OrderIntent, OrderRevision, Execution, CancelRequest, PositionEffect və ReconciliationBreak obyektləri yaradılır.
  3. Operational projections: trader ekranı, back-office queue, exposure, client history, hesabat və ledger üçün oxuna bilən statuslar canonical hadisələrdən qurulur.

Bu ayrım sonradan mapping qaydasını dəyişmək, gecikmiş execution-u yenidən emal etmək və ya vendor-un yanlış callback-ini araşdırmaq imkanı verir. Heç bir UI statusu və ya balans sətri silinmiş source payload-a əsaslanmamalıdır.

1. Identifikatorları mapping cədvəli ilə yox, identiklik qrafı ilə idarə edin

Bir order üçün aşağıdakı identifikatorların hamısı tələb oluna bilər:

  • Canonical intent ID: bridge-in yaratdığı dəyişməz daxili identifikator.
  • Client request ID: MT terminalı, admin əməliyyatı və ya daxili OMS tərəfindən yaranan sorğu identifikatoru.
  • MT order/deal/position ticket-ləri: platforma obyektinə aid native identifikatorlar.
  • FIX ClOrdID və OrigClOrdID: client order və düzəliş zənciri.
  • FIX OrderID, broker order ID və venue order ID: qarşı tərəfin və icra məkanının identifikatorları.
  • Execution/deal ID: hər fill, trade cancel və ya correction üçün idempotency açarı.

Sadəcə mt_ticket → fix_order_id cədvəli yetərli deyil. Bir intent bir neçə revision, bir revision bir neçə route, bir route bir neçə fill və fill correction yarada bilər. Model bu əlaqələri ayrıca yazmalıdır. Xüsusilə replace qəbul edilənə qədər əvvəlki order hələ fill ala bilər; ona görə modify sorğusu köhnə orderi avtomatik bağlanmış saymamalıdır.

Praktik qayda

İdentifikatorun mənasını və unikallıq sərhədini data contract-da yazın: məsələn, ExecID hansı qarşı tərəf və hansı trading day daxilində unikaldır; MT ticket hansı server və hesab üçün unikaldır; ClOrdID təkrar istifadə oluna bilərmi. “String gəldi, saxladıq” yanaşması production reconciliation üçün kifayət deyil.

2. Simvol və contract-size mapping-ni versioned instrument master-a bağlayın

EURUSD, EURUSD.a və ya EUR/USD eyni iqtisadi aləti ifadə edə bilər, lakin avtomatik olaraq eyni tradeable contract demək deyil. Suffix, prefix, digit, minimum lot, lot step, contract size, currency, margin modeli, swap qaydası və trading session fərqlənə bilər.

Bridge hər execution üçün sadəcə source symbol deyil, həmin anda qüvvədə olan instrument mapping versiyasını saxlamalıdır:

  • canonical instrument ID və source-specific symbol;
  • asset class, base/quote və settlement currency;
  • contract size, quantity unit, lot multiplier, minimum və step;
  • price precision, tick size və rounding qaydası;
  • hedging/netting davranışı və position aggregation qaydası;
  • mapping-in qüvvəyə minmə və bitmə vaxtı.

Lotu canonical quantity kimi saxlamaq risklidir. Canonical modeldə quantity iqtisadi vahiddə saxlanmalı, source adapter isə lot conversion etməlidir. Əks halda 1.00 lotun fərqli contract size daşıdığı iki hesab arasında exposure, commission və P&L səhv hesablana bilər. Bu mövzu trading platform instrument master və pricing engine normalization işinin birbaşa davamıdır.

3. Fill və statusu ayrı hadisələr kimi emal edin

Order statusu icranın özü deyil. Bir order accepted, working, partially filled, cancelled və ya filled ola bilər; eyni zamanda bir neçə fill, trade cancel və ya correction yarana bilər. Canonical modeldə:

  • Execution: execution ID, price, quantity, liquidity/routing məlumatı, execution time və source evidence daşıyır.
  • Order state: bütün etibarlı execution və lifecycle hadisələrinin nəticəsidir.
  • Position effect: account-un netting və ya hedging qaydası altında position-a təsiri ayrıca hesablanır.

FIX specification-də execution report üçün OrderID, ExecID, ExecType, OrdStatus, ClOrdID və bəzi hallarda OrigClOrdID fərqli məqsədlər daşıyır. Bu sahələri bir “status” sütununa sıxışdırmaq bridge-in audit imkanını zəiflədir.

Idempotency qaydası

Hər incoming execution üçün deterministik deduplication açarı yaradın: counterparty + account + execution_id + execution_version/event_type. Qarşı tərəf stabil execution ID vermirsə, source message ID, trade ID, timestamp, price, quantity və order reference-dən ehtiyat fingerprint hazırlayın, amma bunu daha zəif sübut kimi işarələyin. Dublikat mesaj “səssizcə ignore” edilməməli, native evidence saxlanmalı və dedupe qərarı izah oluna bilməlidir.

4. Cancel, modify və reconnect yarışlarını explicit state machine ilə qoruyun

Ən riskli ssenari budur: MT4/MT5 istifadəçisi modify və ya cancel verir, bridge sorğunu göndərir, şəbəkə əlaqəsi qopur, sonra həm fill, həm də cancel cavabı gəlir. Bu halda yalnız son alınan mesajla statusu əvəzləmək olmaz.

State machine ən azı bu faktları ayırmalıdır: request created, request transmitted, acknowledgement uncertain, pending cancel/replace, accepted replacement, rejected replacement, fill received, cancellation confirmed, external state unknown və reconciled final state. “Unknown” production sistemi üçün uğursuzluq deyil; sübutsuz olaraq “cancelled” və ya “filled” deməkdən daha təhlükəsiz əməliyyat statusudur.

FIX session sequence recovery transport səviyyəsində lazımdır, lakin business recovery-ni əvəz etmir. Mesaj store, sequence number və resend/gap-fill qaydaları bərpa oluna bilməlidir; QuickFIX/J sənədləşdirilmiş session parametrləri message persistence, resend davranışı və logon zamanı refresh kimi seçimləri göstərir. Bununla yanaşı reconnect-dən sonra open orders, recent executions və positions üzrə source-of-truth snapshot alınmalı, local projection həmin snapshot və hadisə axını ilə reconciliation edilməlidir.

5. Account və group mapping-ni authorization sərhədi kimi görün

MT account login, MetaTrader group, CRM client, legal entity, FIX account tag və liquidity profile bir-birindən ayrı anlayışlardır. Onları yalnız display name ilə qoşmaq yanlış route, yanlış leverage qrupu və ya başqa tenant-a aid məlumatın görünməsi riski yaradır.

Bridge-də ayrıca versioned entitlement mapping olmalıdır:

  • hansı daxili account hansı MT login və FIX/broker account-a bağlıdır;
  • hansı instruments, order types, max volume və routing profile icazəlidir;
  • group dəyişikliyi hansı tarixdən qüvvədədir;
  • kim mapping yaratdı, təsdiqlədi və geri aldı.

Privileged mapping dəyişiklikləri maker-checker təsdiqi, audit log və rollback qaydası tələb edir. Bu yanaşma account management control model ilə uyğun olmalıdır.

6. Günsonu reconciliation bridge-in əlavə funksiyası deyil

İntra-day event processing sürətli qərar üçün lazımdır; günsonu reconciliation isə həqiqəti bağlamaq üçündür. Hər trading day üçün aşağıdakıları qarşılaşdırın:

  • source order və canonical order count;
  • source fill/deal və canonical execution count, quantity, price və fee;
  • open order və pending request-lər;
  • position quantity və average price;
  • cash, commission, swap və digər maliyyə təsirləri;
  • mapping versiyası və account/group dəyişiklikləri.

Break-lər avtomatik balans düzəlişi yaratmamalıdır. Onlar severity, owner, source evidence, mümkün səbəb və təsdiqlənmiş remediation ilə queue-ya düşməlidir. Xarici execution həqiqəti ilə uyğunluq yoxdursa, klient statement-i və ya ledger posting-i “final” kimi təqdim etmək düzgün deyil.

İcra ardıcıllığı: bridge-i təhlükəsiz necə qurmaq olar

  1. Discovery və contract inventory: hər MT server, broker API və FIX counterpart üçün order types, identifiers, rate limits, recovery imkanları, snapshot endpoint-ləri və trading-day cut-off-ları sənədləşdirin.
  2. Canonical schema: order, revision, execution, position effect, instrument, account mapping və reconciliation break üçün versiyalı contract yaradın.
  3. Instrument və entitlement onboarding: simvol/contract mapping və account/group icazələrini test approval olmadan live-a açmayın.
  4. Adapter və durable inbox/outbox: source message qəbulunu business processing-dən ayırın; retry-ları təhlükəsiz və izlənən edin.
  5. Lifecycle simulator: partial fill, reject, cancel/replace race, duplicate callback, out-of-order event, disconnect və restart ssenarilərini avtomatlaşdırın.
  6. Shadow mode: əvvəl bridge nəticələrini mövcud əməliyyat sistemi ilə müqayisə edin; trade routing və ya client-facing projection-i yalnız break səviyyəsi idarəolunan olduqda açın.
  7. Runbooks və day-2 controls: sequence gap, unknown external state, mapping change, reconciliation break və counterparty outage üçün operator addımlarını əvvəlcədən təsdiqləyin.

Buraxılışdan əvvəl yoxlama siyahısı

  • Hər client request, MT ticket, broker/FIX order ID və execution ID arasında izah edilə bilən əlaqə varmı?
  • Simvol mapping-i contract size, quantity conversion və effective date ilə versioned-dirmi?
  • Dublikat və out-of-order execution projection-u dəyişmədən təhlükəsiz qəbul edilirmi?
  • Cancel/replace sorğusu qəbul olunana qədər köhnə order-in fill ala biləcəyi modeldə nəzərə alınıbmı?
  • Reconnect recovery həm session replay, həm source snapshot, həm də reconciliation edir?
  • Unknown external state operator queue-da görünürmü, yoxsa sistem onu əsassız terminal statusa çevirir?
  • Account/group mapping dəyişiklikləri audit, approval və rollback ilə idarə olunurmu?
  • Günsonu fərqləri owner, evidence və təsdiqlənmiş düzəliş olmadan balanslara təsir etmir?

Nə zaman xüsusi MetaTrader–FIX bridge sifariş etmək məntiqlidir

Bir və ya iki manual export ilə idarə olunan proses üçün böyük bridge həmişə düzgün cavab deyil. Lakin bir neçə MT server, LP və ya broker API, fərqli account qrupları, partial-fill exposure, client-facing statuslar, daxili risk və reconciliation tələbi varsa, sadə script əməliyyat riski yaradır. Bu halda bridge-in dəyəri “order göndərmək” deyil: source-native sübutu, idarə olunan tərcüməni, recoverable processing-i və yoxlanılmış execution həqiqətini eyni əməliyyat qatında birləşdirməkdir.

POLADO FinTech və trading sistemlərində belə inteqrasiyanı order lifecycle, instrument governance, back-office controls və reconciliation birlikdə nəzərə alınmaqla layihələndirir. Məqsəd MT4/MT5-i əvəz etmək deyil; platforma və xarici execution infrastrukturu arasında etibarlı, müşahidə olunan və audit edilə bilən sərhəd yaratmaqdır.