Trading platform market session management development broker və trading məhsulu üçün sadəcə “bazar açıqdır, yoxsa bağlıdır?” yoxlaması deyil. Düzgün həll hər alət üzrə sessiyaları, ticarət tarixini, likvidlik provayderi məhdudiyyətlərini, birja bayramlarını, yay-qış vaxtı keçidlərini, texniki fasilələri və rollover hadisələrini idarə olunan qaydalar sistemi kimi modelləşdirir. Bu yanaşma platformanın yanlış vaxtda order qəbul etməsinin, səhv swap hesablamasının və müştəriyə zidd məlumat göstərməsinin qarşısını alır.
POLADO-nun FinTech və trading sistemləri xidməti çərçivəsində sessiya və rollover mexanizmi order qəbulu, qiymət yayımı, risk yoxlamaları, hesab hesabatları və back-office əməliyyatları ilə eyni qaydalar mənbəyindən işləyəcək şəkildə layihələndirilə bilər.
Niyə trading saatları sabit timestamp kimi saxlanmamalıdır?
“Bazar bazar ertəsindən cüməyə 24/5 açıqdır” kimi sadə qayda forex məhsulu üçün belə kifayət etmir. Bir instrumentin kotirovka saatı, order qəbul saatı, yeni mövqe açma saatı, bağlama-only rejimi, klirinq pəncərəsi və ticarət günü sərhədi fərqli ola bilər. CFD, spot FX, futures, səhmlər, kripto və sintetik alətlər eyni təqvimlə idarə edilməməlidir.
Məsələn, NYSE əsas sessiyasını Şərq vaxtı ilə 09:30–16:00 göstərir, lakin erkən və gec sessiyaların qaydaları, eləcə də qısaldılmış bayram günləri ayrıca mövcuddur. CME isə məhsul və platforma üzrə fərqli bayram saatları dərc edir və cədvəllərin dəyişə biləcəyini açıq qeyd edir. Bu, məhsul komandası üçün vacib nəticə yaradır: təqvim məlumatı kod daxilində dəyişməz sabit kimi deyil, qüvvəyə minmə tarixi olan konfiqurasiya kimi saxlanmalıdır.
Etibarlı sessiya modelinin əsas hissələri
1. Instrument, ticarət məkanı və qayda profili
Hər instrument rekordunda öz sessiya profilinə istinad olmalıdır. Profil yalnız “timezone + açılış + bağlanış” sahələrindən ibarət olmamalıdır. Ən azı aşağıdakılar ayrılmalıdır:
- instrument və ya instrument qrupu;
- birja, broker daxili məhsulu və ya likvidlik provayderi mənbəyi;
- IANA timezone identifikatoru, məsələn America/New_York və ya Europe/London;
- həftəlik standart sessiyalar və sessiya fazaları;
- order qəbul, yeni mövqe, yalnız-bağlama və qiymət-yayımı icazələri;
- ticarət tarixi və biznes tarixi qaydası;
- overnight maliyyələşdirmə, swap və ya futures roll qaydası.
UTC-də hesablanmış başlanğıc və son anlar icra üçün faydalıdır, lakin qaydanın əsas təsviri lokal timezone və lokal biznes semantikası ilə saxlanmalıdır. Əks halda yay-qış vaxtı keçidlərində eyni UTC saatını hər həftə tətbiq etmək yanlış sessiyaya səbəb ola bilər.
2. Prioritetli istisnalar
Normal həftəlik qrafik yalnız baza qatıdır. Onun üzərində versiyalanmış istisnalar işləməlidir: tam bağlanış, erkən bağlanış, gec açılış, xüsusi aukson rejimi, yalnız mövcud mövqelərin bağlanması, planlı maintenance və ya provayderin kotirovka fasiləsi. Bir tarixdə birdən çox qayda qarşılaşarsa, sistemin prioriteti aydın olmalıdır: məsələn, instrument-spesifik təsdiqlənmiş override ümumi regional bayram şablonundan üstün olmalıdır.
Bayram inteqrasiyası “ölkə bayramları API-si”nə kor-koranə qoşulmaq demək deyil. Hüquqi bayram ilə konkret venue-nun ticarət statusu eyni anlayış deyil. Birja və likvidlik provayderinin rəsmi bildirişi mənbə kimi saxlanmalı, əməliyyat komandası isə dəyişiklikləri təsdiqləyərək yayıma buraxmalıdır.
Yay-qış vaxtı keçidləri və timezone səhvləri
Forex trading hours management-də ən görünməz risklərdən biri müxtəlif regionların DST-yə eyni tarixdə keçməməsidir. ABŞ və Avropanın keçid həftələrində London–New York seanslarının nisbi üst-üstə düşməsi müvəqqəti dəyişə bilər. Server vaxtını dəyişdirmək və ya bütün alətləri sabit UTC pəncərəsinə bağlamaq bu problemi həll etmir.
Yaxşı dizayn təkrarlanan və mövcud olmayan lokal vaxtları da test edir. Payız keçidində bəzi lokal saatlar iki dəfə baş verir; yaz keçidində isə müəyyən vaxt intervalı ümumiyyətlə mövcud olmur. Qaydalar timezone kitabxanası ilə deterministik şəkildə UTC intervalına çevrilməli, hər çevrilmənin tətbiq edilən qayda versiyası auditə yazılmalıdır.
Rollover və swap cut-off sistemini necə qurmaq olar?
Trading platform rollover system development sessiyanın sadəcə sonuna cron işə salmaqdan daha geniş məsələdir. Rollover hadisəsi hansı mövqelərin uyğun olduğunu, hansı biznes tarixinin tətbiq edildiyini, hansı swap cədvəlinin istifadə olunduğunu, xüsusi multiplikatorun olub-olmadığını və nəticənin necə düzəliş ediləcəyini müəyyən etməlidir.
Swap cut off calculation system üçün tövsiyə olunan ardıcıllıq belədir:
- Rollover run-u üçün instrument, hesab qrupu və trade-date kontekstini müəyyən edin.
- Cut-off anında açıq mövqelərin dəyişməz snapshot-ını yaradın.
- Hər mövqeyə tətbiq olunan maliyyələşdirmə qaydasını, valyuta konversiyasını və multiplikatoru versiya ilə birlikdə seçin.
- Hesablamanı idempotent açarla ledger və ya fee engine-ə göndərin; eyni run yenidən icra olunarsa ikinci yazılış yaranmamalıdır.
- İstisnaları növbəyə çıxarın: itkin qiymət, bağlanmamış konversiya məzənnəsi, mənfi balans məhdudiyyəti və ya provayder fərqi.
- Müştəri hesabatı və back-office üçün məbləğlə yanaşı səbəb, cut-off, rate source və rule version-u saxlayın.
Çərşənbə gecəsi kimi “üçqat swap” yanaşması məhsulun universal həqiqəti deyil. Bu, instrument, broker siyasəti, settlement konvensiyası və bayramlarla bağlıdır. Ona görə multiplikator qaydası ayrıca konfiqurasiya edilməli, əl ilə override isə ikinci təsdiq və əsaslandırma tələb etməlidir. Komissiya və maliyyələşdirmə yazılışlarının auditli quruluşu üçün ESFX FinTech / Analytics layihəsi kimi analitik və əməliyyat yönümlü təcrübələr də faydalı referens yarada bilər.
Controlled schedule change: təhlükəsiz dəyişiklik prosesi
Əməliyyat komandası “sabah 30 dəqiqə tez bağlanır” dəyişikliklərini birbaşa production bazasına yazmamalıdır. Cədvəl dəyişikliyi idarə olunan buraxılış kimi işləməlidir:
- mənbə linki, müəllif, hazırlayan və təsdiqləyən;
- təsir dairəsi: venue, instrument qrupu, hesab qrupu və region;
- qüvvəyə minmə və bitmə anı;
- əvvəlki və yeni qayda versiyası;
- preview: təsirlənən sessiyalar, rollover-lar, order məhdudiyyətləri və bildirişlər;
- iki nəfərli təsdiq, planlı yayım və təhlükəsiz rollback;
- dəyişməz audit jurnalı.
Preview xüsusilə vacibdir: administrator dəyişiklikdən əvvəl “növbəti 14 gündə XAUUSD, US500 CFD və müvafiq futures kontraktlarında nə dəyişəcək?” sualının cavabını görməlidir. Sistem həmçinin ziddiyyətləri bloklamalıdır; məsələn, maintenance pəncərəsi ilə açıq ticarət sessiyasının eyni anda aktivləşməsi.
Müştəri kommunikasiya və məhsul interfeysi
Schedule dəyişiklikləri yalnız əməliyyat ekranında qalmamalıdır. Trading terminalı bazarın statusunu, növbəti açılış vaxtını və mümkün məhdudiyyəti istifadəçinin timezone-unda başa düşülən formada göstərməlidir. Müştəri bildirişində instrumentlər, təsir intervalı, timezone, order davranışı və rollover təsiri konkret yazılmalıdır. “Bayram səbəbilə qrafik dəyişir” kimi ümumi mesaj kifayət deyil.
İnterfeysdə countdown göstərilirsə, o, backend-in eyni session-decision API-sindən gəlməlidir. Frontend-in ayrıca hesablaması ilə back-office qərarı fərqlənərsə, istifadəçi açıq gördüyü vaxtda rədd edilən order göndərə bilər. Bu əməliyyat ekranlarını daha aydın və təhlükəsiz etmək üçün UI/UX və məhsul dizaynı mərhələsində statuslar, warning-lər və override axınları ayrıca işlənməlidir.
Buraxılışdan əvvəl yoxlama siyahısı
- Hər instrument üçün növbəti 12–18 ayın sessiya proqnozu yaradılır.
- DST başlanğıcı və sonu, tam bağlanış, erkən bağlanış və gec açılış test edilir.
- Order qəbul, cancel/modify, close-only, qiymət yayımı və risk yoxlaması ayrı-ayrı sınaqdan keçirilir.
- Rollover run-ları təkrar işə salınır və idempotentlik təsdiqlənir.
- Tarixi düzəlişin köhnə hesabatı səssiz dəyişmədiyi, ayrıca adjustment yaratdığı yoxlanır.
- Provider təqvimi gecikəndə və ya ziddiyyətli olduqda manual approval yolu test edilir.
- Bildiriş, status səhifəsi və terminal UI eyni rule version-dan məlumat alır.
Nəticə
Etibarlı sessiya mühərriki trading məhsulunun təqvim modulu deyil; order davranışını, maliyyələşdirməni, risk nəzarətini və müştəri etibarını birləşdirən əsas biznes qaydaları qatıdır. Statik cədvəllər qısa müddətdə işləyə bilər, lakin bayram, provayder dəyişiklikləri və DST ilə ilk istisnada risk yaradır. POLADO ilə sessiya profilləri, holiday override-ları, rollover job-ları, audit trail və operator UX-ni vahid arxitekturada planlamaq üçün FinTech konsultasiyası sifariş edin.