Financial market data platform development prosesində ən təhlükəli səhvlərdən biri “API-dən məlumat gəlir, deməli qrafik doğrudur” fərziyyəsidir. API uğurla cavab qaytara bilər, amma məhsul yenə də istifadəçiyə yanlış şamlar, müqayisələr, indikatorlar və siqnallar göstərə bilər. Səbəb adətən bağlantı deyil: eyni görünən simvolun fərqli aləti ifadə etməsi, vaxt sərhədlərinin uyğun olmaması, natamam real-time axın və ya şübhəli məlumatın sakitcə hesablama qatına keçməsidir.
Forex və kripto analitika məhsulu məlumatı sadəcə ekranda göstərməməlidir. O, hər müşahidənin hansı alətə, hansı mənbəyə, hansı bazar növünə, hansı vaxt aralığına və hansı keyfiyyət statusuna aid olduğunu qorumalıdır. Bu yanaşma indikator hesablamalarını, backtest nəticələrini və istifadəçi etibarını birbaşa yaxşılaşdırır.
İşləyən API niyə etibarlı bazar məlumatı demək deyil?
“BTCUSD”, “BTC-USD” və “BTCUSDT” eyni iqtisadi ideyaya yaxın görünsə də, eyni qiymət seriyası deyildir. Birincisi bir mənbədə spot cüt ola bilər, digəri başqa birjada spot bazar, üçüncüsü isə USDT kotirovkalı ayrıca instrumentdir. Forex-də də “EURUSD”, “EUR/USD”, “EURUSD.r” və ya brokerin daxili CFD simvolu fərqli likvidlik, ticarət saatı, spread, swap və ya kontrakt şərtləri daşıya bilər.
Bu fərqlər aşağıdakı hallarda istifadəçiyə yanlış nəticə göstərə bilər:
- Spot BTC/USD qiymətini perpetual futures indikatoru ilə müqayisə etmək;
- EUR/USD broker CFD seriyasını banklararası və ya başqa provayderin referens seriyası kimi təqdim etmək;
- Bir mənbədəki son bağlanışı digər mənbənin hələ açıq olan şamı ilə müqayisə etmək;
- USDT kotirovkasını USD kimi etiketləmək və ya dönüşüm fərqini gizlətmək;
- Delist edilmiş, ticarəti dayandırılmış və ya adı dəyişdirilmiş instrument üzrə tarixi seriyanı yeni aktivlə birləşdirmək.
Bu səbəbdən məhsulun əsas vahidi ekrandakı “ticker” olmamalıdır. Əsas vahid kanonik instrument olmalıdır: aktiv sinfi, baza aktiv, kotirovka aktiv, bazar tipi, kontrakt tipi, mənbə, exchange/broker identifikatoru, qiymət vahidi, həcm vahidi və status metadatası ilə birlikdə.
Simvol xəritələnməsini ayrıca məhsul komponenti kimi qurun
Etibarlı crypto market data normalization üçün provider simvolunu birbaşa UI və ya indikator mühərrikinə ötürmək düzgün deyil. Arada versiyalaşdırılan instrument master və mapping qatı olmalıdır. Məsələn, daxili identifikatorunuz CRYPTO:SPOT:BTC:USDT:BINANCE ola bilər; provayder üçün isə ayrıca “BTCUSDT” sorğusu saxlanar. Bu model istifadəçi interfeysini provayder sintaksisindən ayırır.
Instrument master üçün minimum sahələr
- Dəyişməyən daxili instrument ID-si;
- Aktiv sinfi: forex, spot crypto, perpetual, futures, CFD və s.;
- Baza və kotirovka aktivləri, həmçinin cütün istiqaməti;
- Mənbə və provider/exchange-dəki dəqiq symbol və ya product ID;
- Qiymət, həcm və müqavilə ölçüsü semantikası;
- Tick size, lot/contract multiplier, minimum ticarət miqdarı;
- Aktivlik, listinq, delistinq və ticarət statusu;
- Mapping versiyası və dəyişiklik auditi.
Kripto birjalarının öz product ID qaydaları və ticarət statusları olur. Məsələn, Coinbase bazar-məlumatı interfeysində product ID-lərdən istifadə edir və instrument statusu, tick size və digər atribut dəyişikliklərinin ayrıca hadisə kimi ötürülə biləcəyini sənədləşdirir. Bu, statik simvol siyahısını aylarla dəyişmədən saxlamağın riskli olduğunu göstərir. ([docs.cdp.coinbase.com](https://docs.cdp.coinbase.com/exchange/fix-api/market-data?utm_source=openai))
Futures və perpetual müqayisələrində əlavə ehtiyat lazımdır. Eyni əsas aktiv üçün spot, perpetual və müddətli futures qiymətləri eyni deyil. Müddətli kontraktın expiry tarixi, multiplier-i, settlement valyutası və roll-over qaydası kanonik modeldə görünməlidir. Əks halda “BTC qiyməti” adlı qrafik əslində tarixçəsi fasiləli olan bir kontrakt seriyasını göstərə bilər.
Şamlar vaxt seriyasıdır: UTC, sərhəd və bağlanma statusu
OHLC şamı dörd rəqəm deyil; o, dəqiq interval üzrə aqreqasiyadır. Bir saatlıq şamın 10:00-da, yoxsa 10:30-da açılması RSI, moving average, breakout və gündəlik performans hesablamalarını dəyişir. Buna görə bütün daxili event və bar vaxtlarını UTC Unix timestamp kimi saxlayın, istifadəçi seçdiyi IANA saat qurşağını isə yalnız təqdimat qatında tətbiq edin.
Sabit “UTC+4” və ya “EST” kimi qısaltmalarla biznes məntiqi qurmaqdan çəkinin. Saat qurşağı qaydaları və yay vaxtı dəyişiklikləri hüquqi qərarlardan asılıdır; IANA Time Zone Database bu qaydaları periodik yeniləyir. ([iana.org](https://www.iana.org/time-zones?utm_source=openai))
Provayderin şam semantikasını ayrıca yoxlamaq vacibdir. Binance kline axınlarında standart şam sərhədləri UTC əsasında verilir, lakin başqa saat qurşağı ofseti üzrə qurulmuş kline variantı da mövcuddur; payload-dakı zaman damğaları yenə UTC kimi şərh edilir. Açıq şamın ayrıca “closed” statusu da verilir. ([github.com](https://github.com/binance/binance-spot-api-docs/blob/master/web-socket-streams.md?utm_source=openai))
Şam emalı üçün qaydalar
- Hər bar üçün intervalın başlanğıcı, sonu, interval adı, mənbə vaxtı və qəbul vaxtını saxlayın.
- “Açıq” şamı son şam kimi göstərin, lakin onu bağlanmış tarixçə ilə eyni statusda hesablamayın.
- İndikatorun yalnız bağlanmış şamlardan hesablanıb-hesablanmadığını açıq müəyyən edin.
- Gündəlik, həftəlik və aylıq şamların session/boundary qaydasını qrafik yaxınlığında göstərin.
- İstifadəçi saat qurşağını dəyişəndə şamları yenidən qurmaq, yoxsa yalnız oxu dəyişmək qərarını interval semantikasına uyğun verin.
Məsələn, “gündəlik dəyişmə” kartı “00:00 UTC-dən bəri”, “New York sessiyasından bəri” və ya provayderin ticarət günündən bəri hesablanırsa, bu məlumat etiketdə görünməlidir. Əks halda iki düzgün hesablanmış, amma fərqli başlanğıc nöqtəli faiz eyni ekran elementində zidd görünəcək.
Gecikmiş, natamam və ya sıradan çıxmış axını gizlətməyin
Real-time sözünü yalnız məhsulun həqiqətən bildiyi vəziyyət üçün istifadə edin. Gecikmə “provider timestamp” ilə “platformanın son uğurlu emal vaxtı” arasındakı fərq kimi ölçülməlidir. Ekranda “Live”, “Delayed”, “Stale”, “Recovering” və “Unavailable” statusları mənbə və ölçülən gecikmə ilə birlikdə görünə bilər.
WebSocket TCP üzərində işləsə belə, bazar məlumatı hadisələri itə və ya sıradan kənar gələ bilər. Coinbase sənədləri sequence number boşluğunun buraxılmış mesaj göstərə biləcəyini, istehlakçının gap və out-of-order hadisələrini idarə etməli olduğunu qeyd edir. Heartbeat mesajları da buraxılmış hadisələrin aşkarlanması üçün istifadə oluna bilər. ([docs.cdp.coinbase.com](https://docs.cdp.coinbase.com/exchange/websocket-feed/overview?utm_source=openai))
Praktik bərpa axını belədir: boşluq aşkar et, həmin instrument üçün hesablamaları müvəqqəti etibarsız say, snapshot və ya REST tarixçəsi ilə yenidən sinxronlaş, ardıcıl deltaları tətbiq et, sonra statusu yenidən “Live” et. Sadəcə son qiyməti yeniləmək order book, həcm və mikrostruktur analitikası üçün kifayət etmir.
“Delayed” anlayışı da kommersiya etiketi deyil, dəqiq müqavilə və ekran davranışıdır. Məsələn, ESMA sənədlərində real-time məlumatın yayımdan sonra 15 dəqiqədən az gecikmə ilə, delayed məlumatın isə 15 dəqiqə sonra təqdim edilməsi kimi təriflər istifadə olunur. Məhsulunuzun lisenziya və mənbə şərtləri fərqli ola bilər, amma istifadəçiyə hansı feed-in gecikdiyini aydın demək vacibdir. ([esma.europa.eu](https://www.esma.europa.eu/sites/default/files/library/esma70-156-2477_cp_guidelines_on_market_data.pdf?utm_source=openai))
Market data quality checks: hesablamadan əvvəl nə yoxlanmalıdır?
Keyfiyyət yoxlaması yalnız ETL monitorinqi deyil; o, analitika qaydasıdır. Hər bar və ya tick üçün status, səbəb və bərpa izi saxlanmalıdır. Bu, sonradan “niyə siqnal dəyişdi?” sualına cavab verməyə imkan verir.
- Tamlıq: gözlənilən interval mövcuddurmu, ardıcıl barlar arasında izahsız boşluq varmı?
- Ardıcıllıq: sequence, trade ID və ya source timestamp geriyə getmirmi?
- OHLC məntiqi: low ≤ open/close ≤ high qaydası pozulmurmu?
- Qiymət məqbulluğu: əvvəlki etibarlı qiymətə nisbətən kəskin hərəkət alət və bazar rejimi ilə uyğun gəlirmi?
- Həcm semantikası: base volume, quote volume, contract volume və tick count bir-birinə qarışdırılmırmı?
- Staleness: son source event gözlənilən tezlikdən köhnədirmi?
- Cross-source fərq: referens mənbədən kənarlaşma xəbərdarlıq həddini keçirmi?
- Instrument statusu: ticarət dayandırılıb, auction rejimindədir, delist edilib və ya kontrakt dəyişibmi?
Yoxlamadan keçməyən məlumatı səssizcə “0” ilə doldurmaq və ya əvvəlki close qiymətini yeni bar kimi təkrarlamaq təhlükəlidir. Qapalı bazarda və ya təbii likvidlik boşluğunda boşluq doğru məlumatdır. Sistem onu missing, expected closed market və ya provider incident kimi fərqləndirməlidir.
İstifadəçi üçün şəffaf data-status dizaynı
Etibarlılıq yalnız backend funksiyası deyil. Trading dashboard development zamanı qrafikin yanında mənbə, market type, quote currency, interval sərhədi, son yenilənmə vaxtı və data statusu görünməlidir. Şübhəli barlar tooltip və ya vizual markerlə işarələnə, indikator kartında isə “natamam tarixçəyə görə müvəqqəti” qeydi göstərilə bilər.
İstifadəçi “qiymət nədir?” sualı ilə yanaşı “bu qiymət haradan, nə vaxt və hansı keyfiyyətlə gəlib?” sualına da bir neçə klikdən az məsafədə cavab tapmalıdır.
Bu yanaşma analitika portalı, siqnal aləti və daxili risk paneli üçün eynidir. POLADO komandası FinTech və trading sistemləri çərçivəsində data ingestion, normallaşdırma, analitika interfeysləri və nəzarət mexanizmləri qurur. ESFX layihəsi kimi FinTech/analytics məhsullarının təcrübəsi düzgün data modelinin UI və məhsul qərarlarından ayrı düşünülməməli olduğunu göstərir.
Buraxılışdan əvvəl mühəndislik yoxlama siyahısı
- Hər görünən ticker üçün kanonik instrument ID və provider mapping təsdiqlənibmi?
- Spot, CFD, perpetual və futures seriyaları ayrı market type kimi saxlanılıbmı?
- Bütün raw hadisələr UTC-də, source timestamp və ingestion timestamp ilə yazılıbmı?
- Hər interval üzrə şam başlanğıcı, sonu və “closed” qaydası sənədləşdirilibmi?
- WebSocket gap, reconnect, snapshot və replay ssenariləri test edilibmi?
- Missing bar və bazarın bağlı olması eyni vəziyyət kimi qəbul edilmir ki?
- İndikatorlar şübhəli və ya natamam məlumatda dayandırılır, yoxsa etiketlənirmi?
- İstifadəçi feed mənbəyini, gecikməni və son yenilənmə vaxtını görə bilirmi?
- Mapping və korreksiya dəyişiklikləri audit edilə bilirmi?
Yeni platforma qurursunuzsa və ya mövcud qrafikləriniz provider dəyişəndə fərqli nəticə verirsə, bu yoxlamalar texniki auditin başlanğıcı olmalıdır. Məhsulunuzun data modelini, feed bərpa prosesini və istifadəçi görünürlüğünü dəyərləndirmək üçün POLADO ilə konsultasiya planlaşdıra bilərsiniz.