Trading platformaları üçün market data entitlement idarəetməsi istifadəçi, təşkilat, alət, birja, məlumat növü və istifadə formasını bir icazə qərarında birləşdirən sistemdir. Məqsəd yalnız “istifadəçi bu endpoint-ə daxil ola bilərmi?” sualını cavablamaq deyil. Sistem həm də istifadəçinin müəyyən bir instrument üzrə real-time və ya delayed quote görə biləcəyini, məlumatı eksport edə biləcəyini, alert yarada biləcəyini və ya həmin məlumat əsasında avtomatik əməliyyat işə sala biləcəyini yoxlamalıdır.

Bu, market-data məhsullarında tez-tez gözdən qaçan mühəndislik qatıdır. Eyni quote bir istifadəçi üçün real-time, digəri üçün 15 dəqiqə gecikmiş, üçüncüsü üçün isə ümumiyyətlə görünməz ola bilər. Üstəlik, lisenziya şərtləri display, non-display, daxili istifadə, xarici redistribusiya və professional istifadəçi kateqoriyaları arasında fərq qoya bilər. Birja, vendor və müqavilə şərtləri həmişə konkret məhsul üçün yoxlanmalıdır; entitlement sistemi hüquqi mətnin əvəzi deyil, həmin şərtlərin etibarlı texniki icrasıdır.

Entitlement modelini rol siyahısından daha dəqiq qurun

Sadə RBAC modeli — məsələn, admin, trader, viewer — UI idarəetməsi üçün faydalıdır, amma lisenziyalı market data üçün kifayət etmir. İcazə qərarı aşağıdakı konteksti nəzərə almalıdır:

  • Subject: istifadəçi, service account və ya təşkilatın konkret üzvü;
  • Tenant və account: eyni şəxsin fərqli şirkətlərdə fərqli abunələri ola bilər;
  • Data product: quote, trade, top-of-book, depth, reference data, historical bar və ya derived analytics;
  • Venue və instrument universe: birja, MIC, asset class, konkret simvol və ya instrument qrupu;
  • Freshness: real-time, delayed və ya end-of-day;
  • Action: display, API read, export, webhook, alert evaluation, model input və order-validation istifadəsi;
  • Conditions: professional status, müqavilə qəbulu, coğrafiya, cihaz və ya sessiya limiti, bitmə tarixi.

Bu struktur üçün praktik qayda: “role” istifadəçinin platformada nə edə biləcəyini, “entitlement” isə hansı lisenziyalı data product-u hansı məqsədlə istifadə edə biləcəyini ifadə etsin. Beləliklə, support komandası “Premium Trader” rolunu dəyişmədən müəyyən bir təşkilat üçün birjanın depth feed abunəsini dayandıra bilər.

Əsas data obyektlərini əvvəlcədən ayırın

Etibarlı sistemdə instrument kataloqu və kommersiya lisenziyası modeli eyni anlayış deyil. Instrument üçün ISIN, vendor symbol, exchange code, currency, asset class və trading status saxlanıla bilər. Lakin entitlement yoxlaması üçün ayrıca data product catalog lazımdır: məsələn, “Venue X equities top-of-book realtime” və “Venue X equities delayed display”. Hər məhsul bir və ya bir neçə instrument universe ilə əlaqələndirilir.

Bu ayrılıq vendor simvolu dəyişəndə və ya yeni birja əlavə olunanda icazələri yenidən əl ilə yazmağın qarşısını alır. Sxemə ən azı bu obyektlər daxildir:

  • Entitlement grant: subject, məhsul, action, effective_from, effective_to və status;
  • Agreement acceptance: qəbul edilmiş müqavilə versiyası, tarix, istifadəçi və ya təşkilat sübutu;
  • Usage policy: export limiti, concurrent session limiti, display/non-display qaydası;
  • Decision record: icazə sorğusunun nəticəsi, tətbiq edilən policy versiyası və səbəb kodu.

Avropa kontekstində ESMA guidance delayed data anlayışını məlumatın dərcindən 15 dəqiqə sonra təqdim edilən data kimi təsvir edir. Bu, hər feed üçün universal texniki fərziyyə deyil: məhsul və müqavilə üzrə delay qaydasını konfiqurasiya edin, UI-da isə istifadəçiyə açıq şəkildə göstərin.

Bir policy decision point, çoxlu enforcement point

İcazəni yalnız frontend-də gizlədilən düyməyə bağlamaq təhlükəlidir. Web chart, mobil tətbiq, REST/GraphQL API, streaming gateway, CSV export job və alert worker eyni qərarı ardıcıl tətbiq etməlidir.

Yaxşı arxitekturada mərkəzi Policy Decision Point (PDP) “bu subject bu resurs üçün bu action-u indi yerinə yetirə bilərmi?” qərarını verir. API gateway, websocket gateway, backend service, export worker və notification worker isə Policy Enforcement Point (PEP) kimi davranır. Kritik qərarları policy engine vasitəsilə ya birbaşa, ya da qısaömürlü imzalı entitlement token-i ilə yoxlayın.

Token yalnız “premium=true” kimi geniş claim daşımamalıdır. O, tenant, məhsul kodları, action-lar, policy version və qısa expiration saxlamalıdır. Stream qoşulduqda icazəni yoxlayın, sonra da entitlement dəyişiklikləri üçün event subscriber saxlayın. İstifadəçi ləğv edilərsə, aktiv websocket kanalı bağlanmalı, queued export dayandırılmalı və alert workflow növbəti qiymətləndirmədə hüququ yenidən yoxlamalıdır.

Cache və real-time stream sərhədlərini qoruyun

Ən çox rast gəlinən səhv server cache-də real-time nəticəni saxlamaq, sonra həmin nəticəni delayed istifadəçiyə qaytarmaqdır. Cache key yalnız symbol və interval olmamalıdır. Ən azı data-product/freshness tier, venue scope, tenant və lazım olduqda istifadə məqsədi ayrılmalıdır. Daha təhlükəsiz yanaşma xam feed cache-ni yalnız etibarlı backend zonasında saxlamaq, istifadəçiyə verilən response-u isə entitlement filtrindən sonra ayrıca cache-ləməkdir.

Websocket üçün bir ümumi “AAPL” topic əvəzinə icazə ilə yaradılan channel istifadə edin. Məsələn, subscription service istifadəçini lazımi data tier-ə uyğun daxili topic-ə qoşur; client isə birbaşa vendor feed və ya geniş yayım topic-i görmür. Mobil push notification üçün də qayda eynidir: alert yaradılarkən yoxlama kifayət deyil, alert işə düşəndə data məhsulu və delivery hüququ yenidən qiymətləndirilməlidir.

Export, non-display və “act” hüquqlarını ayrıca modelləşdirin

Ekranda quote göstərmək CSV ixracına avtomatik icazə demək deyil. Export üçün format, maksimum sətir sayı, zaman aralığı, məqsəd və expiry kimi ayrıca nəzarətlər tətbiq edin. Export işini server-side yaradın, auditləşdirin, qısaömürlü download URL verin və ləğv olunduqda hələ endirilməmiş faylı bloklayın.

Non-display istifadəsi də ayrıca action olmalıdır. Məsələn, sistemin quote-u risk limiti, siqnal, smart routing, model input və ya avtomatik qərar üçün oxuması insan ekranındakı display-dən fərqli müqavilə və hesabat öhdəliyi yarada bilər. Eyni səbəbdən “act” hüququnu quote display-dən ayırın: istifadəçi qiyməti görə bilər, amma həmin feed əsasında alert və ya order workflow işə sala bilməyə bilər.

Audit log sadəcə təhlükəsizlik jurnalı deyil

Audit qeydləri support, billing, daxili araşdırma və lisenziya hesabatları üçün yenidən qurula bilən sübut yaratmalıdır. Hər qərar üçün subject, tenant, data product, instrument/venue scope, action, nəticə, reason code, policy version, request correlation ID və timestamp qeyd edin. Məlumatın özünü və ya həssas token-ləri log-a yazmayın.

Əməliyyat baxımından bu suallara cavab verə bilməlisiniz: “Bu istifadəçi martın 4-də hansı data tier-i görürdü?”, “Niyə export rədd edildi?”, “Ləğv event-i neçə saniyəyə bütün kanallara yayıldı?” və “Hansı service account non-display məlumat oxudu?” Bu yanaşma FinTech və trading sistemləri üçün nəzərdə tutulmuş arxitekturanın vacib hissəsidir; analitika yönümlü ESFX kimi məhsullarda data mənbəyi, istifadə konteksti və istifadəçi təcrübəsi birlikdə nəzərdən keçirilməlidir.

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

  • Hər data product üçün display, export, alert, API və non-display action-ları ayrıca tanımlanıb.
  • Delayed və real-time response-lar UI-da fərqlənir və cache key-ləri qarışmır.
  • Web, mobile, API, websocket və background worker eyni policy qərarından istifadə edir.
  • Abunə, müqavilə qəbulu və professional status dəyişəndə revocation event-i yaranır.
  • Aktiv stream-lər, export job-lar və alert-lər ləğvdən sonra yenidən yoxlanır.
  • Audit trail qərarın həmin andakı policy versiyasını və səbəbini bərpa edir.
  • Vendor və birja müqavilələrindəki konkret reporting, redistribution və usage şərtləri hüquq və əməliyyat komandası ilə xəritələnib.

Market-data entitlement layer-i platformanın sonradan əlavə edilən feature-i kimi deyil, data distribution boundary-si kimi planlaşdırın. POLADO yeni market-data məhsulu, mövcud trading tətbiqində entitlement audit-i və ya multi-tenant permission system development üçün arxitektura hazırlaya bilər. Tələblərinizi və lisenziya ssenarilərinizi müzakirə etmək üçün əlaqə saxlayın.