Trading platformlarında bazar məlumatı səlahiyyətlərinin hazırlanması o deməkdir ki, platforma hər qiyməti göndərməzdən əvvəl həmin istifadəçinin, hesabın və kanalın bu məlumatı almaq, görmək, ixrac etmək və ya avtomatlaşdırılmış şəkildə istifadə etmək hüququnu yoxlayır. Bu, pricing engine-in vəzifəsi deyil: pricing engine qiyməti qəbul edir, normallaşdırır və paylama üçün hazırlayır; entitlement qatı isə konkret istifadəçiyə hansı məlumatın hansı şərtlərlə çata biləcəyini müəyyən edir.
Broker, market-data vendor və ya trading məhsulu üçün bu fərq kritikdir. Eyni şəxs veb kabinetində delayed qiymət görə, mobil tətbiqdə real-time kotirovka ala, API vasitəsilə isə ümumiyyətlə data əldə etməyə bilər. Digər istifadəçi eyni simvol üçün display hüququna malik olsa da, export, non-display alqoritmik istifadə və ya üçüncü tərəfə yenidən yayım hüququna malik olmaya bilər. Bu qaydalar kanal-kanaI ayrıca kodlanarsa, nəticə uyğunsuz görünüş, yanlış billing və audit zamanı sübut boşluğu olur.
Entitlement sistemi hansı problemi həll edir?
Market-data entitlement system üç suala ardıcıl və izahlı cavab verməlidir: kim sorğu edir, nəyi istəyir və hansı məqsəd və kanalda istifadə etmək istəyir? Qərar yalnız “premium paket aktivdir” flag-i olmamalıdır. O, data məhsulunu, birjanı və ya vendor feed-ini, instrument və ya instrument qrupunu, istifadəçi kateqoriyasını, hesab statusunu, təşkilatı, regionu, cihaz və sessiyanı, istifadə növünü və qüvvədəolma müddətini nəzərə almalıdır.
Məsələn, “EUR/USD üçün real-time bid/ask” sorğusu üçün qayda aşağıdakı nəticələrdən birini qaytara bilər:
- real-time display icazəlidir;
- yalnız 15 dəqiqə delayed display icazəlidir;
- son qiymət və ya end-of-day məlumatı göstərilə bilər;
- məlumat gizlədilməli, əvəzində subscription ekranı açılmalıdır;
- display icazəlidir, amma API export və bot istifadəsi qadağandır.
Bir çox birja siyasəti entitlement/disentitlement prosesinin, hər məhsul üzrə nəzarətin, istifadəçi siyahılarının və hesabatların nümayiş etdirilməsini tələb edir. Məsələn, Nasdaq-ın compliance materialı istifadəçi və terminal səlahiyyətlərinin, real-time və delayed çatdırılma vaxtının, eyni vaxtda girişin və deaktivləşdirmə prosesinin yoxlanmasını ayrıca qeyd edir. NYSE də delayed data və entitlement control tələblərini ayrıca siyasət kateqoriyaları kimi dərc edir.
Etibarlı arxitekturanın əsas komponentləri
1. Entitlement source of truth
Hüquqların mənbəyi adətən bir neçə sistemdən gəlir: CRM və ya billing abunəliyi, KYC/professional statusu, trading account group, təşkilat müqaviləsi, birja forması və əməliyyat komandası tərəfindən verilən istisna. Bunları birbaşa hər tətbiqin öz bazasına yazmaq əvəzinə, kanonik entitlement modeli yaradılmalıdır.
Praktik modeldə entitlement grant aşağıdakı sahələri saxlayır: subject type və ID, account və ya organization scope, feed/product ID, instrument scope, permission type, channel scope, usage type, effective-from/to, source reference, status, approver və versiya. “Niyə bu istifadəçi bu datanı gördü?” sualına həmin qeyd və onun mənbə sənədi cavab verməlidir.
2. Şəxs, hesab və sessiya vəziyyətləri
İstifadəçi aktiv olsa belə hesab bağlanmış, KYC review-da, borclu, məhdudlaşdırılmış və ya yalnız read-only vəziyyətində ola bilər. Ona görə entitlement qərarı identity service, account-management qatından gələn statuslar və sessiya kontekstini birlikdə qiymətləndirməlidir. Hesabın vəziyyəti dəyişəndə revocation dərhal işləməlidir; növbəti gecə batch job-u gözləmək real-time feed üçün qəbul edilən nəzarət deyil.
Bu dizayn trading hesablarının idarə edilməsi, onboarding və abunəlik prosesləri ilə inteqrasiya tələb edir. POLADO bu cür nəzarət qatlarını FinTech və trading sistemləri xidməti çərçivəsində kanonik hesab və əməliyyat məlumatları ilə birləşdirə bilər.
3. Instrument və məhsul səviyyəsində qaydalar
“Real-time equities” kimi geniş hüquq bəzi məhsullar üçün kifayət edə bilər, lakin sistem instrument-level istisnaları da dəstəkləməlidir. Qayda exchange, asset class, feed, symbol list, market segment və ya konkret instrument üçün tətbiq oluna bilər. Instrument master entitlement servisinin sahibi deyil, amma onun sabit instrument ID-si, statusu, birja və asset-class atributları qayda qiymətləndirməsi üçün vacibdir.
Qaydaları kodda dağınıq if/else blokları kimi saxlamaq əvəzinə, versiyalanan policy modelindən istifadə edin. Prioritet, deny-overrides prinsipi, effective date və rule testləri açıq olmalıdır. Beləliklə, yeni feed və ya müştəri paketi üçün release etmədən konfiqurasiya ilə dəyişiklik etmək mümkün olur; yenə də iki nəfərlik təsdiq və audit izi qalır.
Real-time, delayed, display və non-display hüquqlarını ayırın
Delayed data “real-time məlumatın bir az gecikmiş kopyası” kimi texniki workaround deyil; ayrı məhsul və ayrı qərar nəticəsi kimi modellənməlidir. Qərar cavabında data mode, delay interval, source label, usage constraints və expiry açıq qaytarılmalıdır. UI həmin metadata əsasında “Delayed” etiketini göstərməli, API isə gecikməni gizlətməməlidir.
Display və non-display istifadəsini də eyniləşdirməyin. Terminalda insanın qiymətə baxması ilə botun qiyməti alqoritm, siqnal, risk hesablaması və ya cache yaratmaq üçün qəbul etməsi fərqli hüquq ola bilər. Eyni qayda export, screenshot/download, webhook və downstream redistribution üçün də keçərlidir. ABŞ bazar infrastrukturu üzrə SEC materiallarında proprietary market-data məhsulları üçün display və non-display kimi fərqli istifadə formalarının mövcudluğu, eləcə də istifadəçi kateqoriyalarına görə fərqli fee modelləri qeyd edilir.
Qərarın tətbiqi: yalnız UI yox, bütün çıxış nöqtələri
Entitlement yoxlanışı yalnız frontend-də gizlədilən widget olmamalıdır. İstifadəçi web portal, iOS/Android tətbiqi, desktop terminal və API-dən eyni data məhsuluna çıxış istəyə bilər. Hər bir çatdırılma nöqtəsi mərkəzi qərar xidmətindən eyni policy qərarını almalıdır.
- Web və mobil: subscribe etməzdən əvvəl entitlement check, dəyişiklikdə stream-dən unsubscribe və düzgün status/upsell ekranı.
- Trading terminal: login və account switch zamanı entitlement snapshot; server tərəfdə revocation push.
- REST/WebSocket API: token scopes kifayət deyil; endpoint, instrument, usage və rate-limit entitlement-lə yoxlanmalıdır.
- Export və reportlar: tarixçə, CSV və PDF görünən qiymət ekranı ilə eyni hüquqlara avtomatik malik sayılmamalıdır.
Həssas əməliyyat ekranlarında bu qaydaların istifadəçiyə aydın, lakin iş axınını pozmayan formada çatdırılması üçün UI/UX və məhsul dizaynı ayrıca dəyər yaradır.
Cache sərhədləri və dərhal ləğvetmə
Yüksək tezlikli quote sorğusunda hər tick üçün uzaq entitlement bazasına müraciət etmək gecikmə və risk yaradır. Sağlam yanaşma qərarı qısaömürlü cache-ləmək, lakin cache key-ə subject, account, channel, product, instrument scope və policy version daxil etməkdir. “Bu istifadəçi real-time-dır” kimi geniş cache key data sızmasına səbəb ola bilər.
Revocation üçün iki mexanizm birlikdə lazımdır: qısa TTL və event-driven invalidation. Billing ləğvi, account freeze, KYC status dəyişikliyi, user disable və ya operatorun manual disentitlement əməliyyatı event yaradır. Consumer-lər həmin event-i emal edib aktiv stream-ləri dayandırır, cache-i təmizləyir və audit hadisəsi yazır. Revocation zamanı sadəcə növbəti sorğunu rədd etmək kifayət deyil; artıq açılmış WebSocket subscription-ları da bağlanmalı və ya delayed feed-ə keçirilməlidir.
Audit, əməliyyat dəstəyi və ölçüləbilən nəzarət
Hər allow və deny üçün tam tick payload-ını saxlamayın; bu həm baha, həm də lazımsız ola bilər. Əvəzində decision audit event yaradın: request ID, subject/account, policy version, data product, instrument scope, channel, usage, nəticə, reason code, effective entitlement ID, timestamp və correlation ID. İdarəetmə komandası üçün ayrıca “kimdə hansı hüquq var?”, “bu hüquq nə vaxt və hansı mənbədən verilib?”, “son 30 gündə hansı entitlement dəyişib?” sualları cavablandırılmalıdır.
Operational dashboard aşağıdakı siqnalları göstərməlidir: deny spike, delayed-to-real-time conversion, orphaned subscriptions, revocation propagation delay, cache hit/miss, policy evaluation latency və feed üzrə aktiv recipient sayı. Audit və observability planı başlanğıcdan qurulmazsa, support komandası müştəri şikayətini yalnız log axtarışı ilə həll etməyə çalışacaq. Bu səbəbdən Texniki dəstək və konsaltinq ilə SLO-lar, alert-lər, runbook-lar və release nəzarəti birlikdə planlanmalıdır.
Layihəyə başlamazdan əvvəl qərar checklist-i
- Hər feed üçün müqavilə, istifadə kateqoriyası və reporting tələblərini toplayın.
- Real-time, delayed, display, non-display, export və redistribution üçün ayrıca permission lüğəti yaradın.
- İstifadəçi, organization, trading account, device/session və instrument scope-larını modelə daxil edin.
- Billing, KYC, account state və admin override-ların kanonik entitlement mənbəsini müəyyən edin.
- Revocation SLA-sını və aktiv stream-lərin necə dayandırılacağını yazılı təsdiqləyin.
- Web, mobile, terminal, API və export üçün eyni decision service istifadəsini tələb edin.
- Provider auditinə uyğun change history, recipient report və decision evidence hazırlayın.
Nəticə: düzgün qurulmuş entitlement sistemi qiymət yayımını idarə etmir; qiymətin kimə, hansı data məhsulu kimi, nə vaxtadək və hansı istifadə məqsədi ilə çatacağını idarə edir. POLADO broker və data məhsulları üçün bu qatın policy modeli, API-ləri, kanal inteqrasiyası, audit izi və operational support dizaynını ESFX kimi maliyyə-analitika təcrübəsindən istifadə edərək planlaşdıra bilər. Mövcud feed-ləriniz, subscription paketləriniz və kanal xəritənizlə konsultasiya üçün müraciət edin.