Trading platforması üçün post-trade allocation development blok order icra olunduqdan sonra başlayan nəzarətli prosesin hazırlanmasıdır: hansı hesabın əməliyyatda iştirak etdiyini müəyyənləşdirmək, icra olunmuş həcmi qaydalara uyğun bölmək, hər iştirakçı üçün orta qiyməti hesablamaq, uyğunsuzluqları yoxlamaq, təsdiqləri ötürmək və sonrakı düzəlişləri izlə bilən formada saxlamaq. Bu, sadəcə əməliyyatların Excel faylına köçürülməsi deyil; institusional əməliyyatlar üçün ayrıca qayda, sübut və inteqrasiya qatıdır.

Bu qat OMS-in order göndərilməsi və icra idarəetməsi funksiyasını əvəz etmir. Həmçinin reconcilation sistemi ilə eyni deyil: reconciliation sonradan iki və ya daha çox mənbədəki qeydləri müqayisə edərək fərqləri aşkar edir. Post-trade allocation isə icradan sonra hansı hesabın hansı miqdarı, qiyməti, komissiyası və settlement təlimatını alacağını yaradır və təsdiqə göndərir. Geniş back-office isə mühasibat, hesablaşma, sənədlər və inzibati prosesləri də əhatə edə bilər.

Post-trade allocation qatının əsas iş axını

Etibarlı block trade allocation system development həlli brokerdən, icra məkanından və ya daxili OMS-dən gələn hər fill-i dəyişdirilməz icra hadisəsi kimi qəbul etməlidir. Ardınca sistem həmin fill-ləri düzgün blok, instrument, tərəf, broker və ticarət günü kontekstində qruplaşdırır.

  1. İcra məlumatının qəbulu: fill ID, icra vaxtı, miqdar, qiymət, valyuta, komissiya, broker və order identifikatorları qəbul edilir.
  2. İştirakçıların sabitlənməsi: blok üçün əvvəlcədən təyin olunmuş və ya təsdiqlənmiş hesab siyahısı, hədəf miqdarları və məhdudiyyətləri tarixçəli snapshot kimi qorunur.
  3. Uyğunluğun yoxlanması: hesab statusu, mandat, instrument məhdudiyyəti, valyuta, lot ölçüsü, settlement təlimatı, broker məhdudiyyəti və mövcud qaydalar yoxlanır.
  4. Bölgünün hesablanması: tam və ya qismən icra olunmuş həcm deterministik qaydaya əsasən bölüşdürülür.
  5. Nəzarət və təsdiq: qayda pozuntusu olmayan bölgülər avtomatik irəliləyir; istisnalar isə operatorun qərar növbəsinə düşür.
  6. Aşağı sistemlərə ötürülmə: təsdiqlər, allocation təlimatları, settlement məlumatları və statuslar API, fayl və ya FIX mesajları ilə göndərilir.

Orta qiymət hesablaması və qismən icralar

Bir blok order bir neçə fill ilə fərqli qiymətlərdən icra oluna bilər. Orta qiymət adətən miqdar üzrə çəkili hesablanır: bütün fill-lərin qiymət×miqdar cəmi, ümumi icra miqdarına bölünür. Məsələn, 400 vahid 10.00-dan və 600 vahid 10.20-dən icra olunubsa, 1,000 vahid üçün orta qiymət 10.12-dir. Hesablar üzrə bölgü həmin təsdiqlənmiş orta qiymət əsasında yaradılır; komissiya, vergi və digər xərclər isə siyasətə uyğun ayrıca bölüşdürülməlidir.

Qismən icrada sistem yalnız faktiki icra edilmiş həcmi bölməlidir. Pro-rata qayda geniş istifadə olunsa da, hər məhsul və mandat üçün universal seçim deyil. Minimum lot, hesab limiti, cash availability, yönləndirilmiş broker qaydası və ya müqavilə üzrə məhdudiyyət kimi şərtlər nəticəyə təsir edə bilər. Buna görə mühərrik sadəcə faiz hesablamamalı, nəyə görə məhz bu nəticənin yarandığını da göstərməlidir.

Qalıq və yuvarlaqlaşdırma qaydaları

100 vahidlik blokun 33/33/34 kimi bölünməsi asandır, lakin nəticə lot ölçüsünə uyğun gəlməyə bilər. Platforma əvvəlcə uyğun xam bölgünü, sonra lot və yuvarlaqlaşdırma qaydasını, sonda isə qalıq miqdarın kimə verildiyini qeyd etməlidir. Qalıq üçün əvvəlcədən təsdiqlənmiş prioritet qaydası, rotasiya və ya operator təsdiqi tələb oluna bilər. Gizli əl düzəlişi audit və ədalətlilik riskini artırır.

Allocation validation: göndərməzdən əvvəl dayandırılmalı səhvlər

Post-trade processing software yalnız allocation yaratmamalı, onun göndərilməsinə mane olan halları da ayırmalıdır. Minimum yoxlama dəsti aşağıdakıları əhatə edir:

  • hesablar üzrə allocation cəminin blokun icra edilmiş həcminə bərabər olması;
  • buy/sell tərəfinin, instrumentin, ticarət tarixinin və valyutanın uyğunluğu;
  • hesabın aktiv və əməliyyat üçün səlahiyyətli olması;
  • mənfi və ya hədəfdən artıq miqdarların qarşısının alınması;
  • lot, qiymət dəqiqliyi və valyuta yuvarlaqlaşdırmasının tətbiqi;
  • tələb olunan settlement təlimatlarının mövcudluğu;
  • təkrar göndəriş və ya eyni fill-in iki dəfə işlənməsi riskinin idempotency açarları ilə bloklanması.

Yoxlama nəticəsi sadəcə “failed” statusu olmamalıdır. Operator ekranda hansı qaydanın, hansı məlumatla və hansı hadisə nəticəsində pozulduğunu görməlidir. Bu, əməliyyat komandasının e-poçt və spreadsheet araşdırmasına sərf etdiyi vaxtı azaldır.

Düzəlişlər: qeydi dəyişmək yox, yeni hadisə yaratmaq

Ən kritik dizayn qərarlarından biri düzəlişlərin idarə edilməsidir. Təsdiqlənmiş allocation sətrinin miqdarını və ya hesabını səssiz şəkildə yeniləmək olmaz. Düzgün yanaşma ilkin allocation-un versiyasını qorumaq, düzəliş səbəbini, sorğu sahibini, təsdiq edən şəxsi, vaxtı və yeni nəticəni ayrıca correction event kimi yazmaqdır.

Məsələn, hesab settlement təlimatının etibarsız olduğu müəyyən edilərsə, sistem ilkin bölgünü saxlayır, düzəliş sorğusu açır, yenilənmiş bölgünü versiyalaşdırır və lazım gələrsə downstream tərəfə cancel/replace və ya amendment göndərir. Beləliklə, “nə dəyişdi?” və “kim dəyişdi?” suallarına texniki loglardan deyil, əməliyyat tarixçəsindən cavab almaq mümkündür.

Texniki arxitektura: allocation-u ayrıca idarə olunan domen edin

Etibarlı institusional trading operations platform üçün allocation modulu execution, hesab master məlumatları və settlement inteqrasiyaları arasında ayrıca domen kimi modellənməlidir. Əsas obyektlərə block, execution fill, allocation instruction, allocation line, eligibility snapshot, validation result, approval, outbound message, acknowledgement və correction daxildir.

Hər obyekt üçün sabit daxili identifikatorlar, xarici sistem identifikatorları, versiya nömrəsi, yaradılma vaxtı və dəyişdirilməz event history lazımdır. Outbound inteqrasiyalar retry edilə bilən, idempotent və acknowledgement statuslarını saxlayan queue əsaslı mexanizmlə qurulmalıdır. FIX istifadə edilirsə, platforma qarşı tərəfin qəbul etdiyi mesaj versiyasını, rədd səbəbini və resend davranışını da əməliyyat kontekstində göstərməlidir.

Alınacaq həll üçün qiymətləndirmə checklist-i

  • Qaydalar kod dəyişmədən konfiqurasiya oluna bilirmi, yoxsa yalnız sərt yazılmış məntiqdir?
  • Qismən fill, çoxsaylı qiymət, lot və qalıq miqdar ssenariləri necə işləyir?
  • Hesab uyğunluğu həmin anın snapshot-u ilə sübut edilirmi?
  • Operator hansı düzəlişi edə bilər, hansı halda maker-checker təsdiqi tələb olunur?
  • İlkin nəticə, düzəliş və downstream acknowledgement eyni audit zəncirində görünürmü?
  • OMS, broker, custodian və reconciliation alətləri ilə sərhədlər açıq müəyyən edilibmi?
  • Komissiya, vergi, fee və net amount hesablamalarının sahibi hansı komponentdir?

POLADO ilə post-trade allocation development

POLADO mürəkkəb əməliyyatlar üçün FinTech və trading sistemləri hazırlayır: execution məlumatının normallaşdırılması, qayda mühərriki, auditli əməliyyat ekranları, API/FIX inteqrasiyaları və nəzarətli exception workflow-ları. Mövcud məhsulun operator təcrübəsi və sıx ekranları ayrıca diqqət tələb edirsə, UI/UX və məhsul dizaynı xidməti ilə allocation masalarını, təsdiq növbələrini və düzəliş axınlarını təhlükəsiz işlənən interfeysə çevirə bilərik. FinTech və analitika təcrübəmizə ESFX layihəsində də baxa bilərsiniz.

Blok əməliyyatlarınız spreadsheet, əl ilə export və ya izlənməyən düzəlişlərlə idarə olunursa, tələbləri execution, allocation, təsdiq və reconciliation sərhədləri ilə birlikdə təhlil etmək üçün POLADO ilə konsultasiya planlaşdırın.