Trading platform corporate actions processing development o zaman etibarlıdır ki, platforma dividend, stock split, merger, rights issue və könüllü seçimlər üçün bütün həyat dövrünü idarə edir: mənbədən gələn elan, versiyalaşdırılmış qayda, eligibility snapshot, entitlement hesablaması, vergi və yuvarlaqlaşdırma, təsdiqli posting, reconciliation və müştəri kommunikasiyası. Əsas prinsip budur: korporativ əməliyyat barədə məlumat vermək ilə müştərinin pulunu və ya qiymətli kağız mövqeyini dəyişmək eyni workflow deyil.

Bu fərq brokerlər, kastodianlar və investisiya tətbiqləri üçün vacibdir. İnformativ bildiriş natamam və ya sonradan dəyişdirilmiş ola bilər. Maliyyə nəticəsi yaradan emal isə record date, ex-date, payment date, hesab tipi, saxlanma zənciri, vergi statusu, fractional share qaydası və upstream kastodianın faktiki allocation məlumatı əsasında nəzarətli qərar tələb edir. POLADO bu cür inteqrasiya və əməliyyat məntiqini FinTech və trading sistemləri xidməti çərçivəsində xüsusi platforma funksiyası kimi layihələndirə bilər.

Korporativ əməliyyat sistemi nələri emal etməlidir?

Ən faydalı təsnifat hadisəni yalnız “dividend” və ya “merger” adlandırmaq deyil, onun əməliyyat xarakterini modelləşdirməkdir:

  • Mandatory distribution: nağd dividend, faiz ödənişi, stock dividend və ya məcburi redemption. Adətən müştəri seçimi tələb olunmur, lakin entitlement və vergi hesablaması tələb olunur.
  • Mandatory reorganisation: symbol/CUSIP dəyişməsi, split və reverse split, merger nəticəsində kağızın cash və ya yeni instrumentlə əvəzlənməsi.
  • Mandatory with choice: hüquq yaranır, lakin müştəri mövcud variantlardan birini seçə bilər; default option dəqiq modelləşdirilməlidir.
  • Voluntary event: tender offer, rights subscription, warrant exercise və digər election tələb edən hadisələr. Burada deadline, instruction status və qəbul olunmuş seçimin dəyişdirilməsi əsas risk zonalarıdır.

Hər event üçün platforma event type, instrument identity, issuer və agent reference-ləri, announcement statusu, seçim variantları, tarixlər, valyutalar, rate/factor, source sənədləri və narrative mətnini saxlamalıdır. ISO 20022 securities-events mesaj ailəsində notification, instruction, instruction status, movement confirmation və reversal kimi ayrı mesajların mövcudluğu da bu lifecycle ayrımını əks etdirir.

Arxitektura: elan obyektindən maliyyə posting-inə qədər

1. Məlumatı qəbul edin, amma dərhal icra etməyin

Feed, API, SWIFT/ISO mesajı, kastodian faylı və ya operatorun daxil etdiyi məlumat əvvəlcə raw source record kimi dəyişdirilmədən saxlanmalıdır. Daha sonra parser onu canonical event modelinə çevirir. Source message ID, payload hash, qəbul vaxtı və source versiyası audit üçün qorunur.

Normalizasiya layer-i event reference-ləri, ISIN/CUSIP və daxili instrument ID-ləri, tarixlərin time zone-u, rate-lər, seçim kodları və statusları uyğunlaşdırır. Bir event üzrə sonrakı announcement adətən “yeni event” deyil, əvvəlki versiyanın replacement, cancellation və ya update-i olur. Buna görə event identity ilə event version-u ayırın.

2. Effective-date idarəetməsi qurun

Tarix sahələri bir-birini əvəz etmir: announcement date, ex-date, record date, election deadline, market deadline, internal cut-off, payable date və settlement date ayrı saxlanmalıdır. Hər tarix üçün source, time zone və “confirmed / estimated / revised” statusu olmalıdır.

Daxili election deadline upstream deadline-dan əvvəl olmalıdır. Bu, instruction validation, compliance review, toplu submission və texniki retry üçün vaxt yaradır. UI müştəriyə həm bazar deadline-ını, həm də brokerin daxili deadline-ını açıq göstərməlidir; yalnız “son gün” etiketi kifayət etmir.

3. Eligibility və securities entitlement calculation

Entitlement engine cari mövqedən deyil, hadisənin qaydasına uyğun versiyalaşdırılmış position snapshot-dan hesablamalıdır. Snapshot aşağıdakı məlumatları daşımalıdır: hesab və beneficial-owner konteksti, instrument, settled və lazım olduqda unsettled quantity, record-date mövqeyi, loan/borrow və fail adjustment məlumatı, account tax profile, custody location və source lineage.

Sadə cash dividend üçün nəzəri formula belədir:

Gross entitlement = eligible quantity × dividend rate

Lakin istehsal sistemində nəticəyə currency precision, withholding tax, relief-at-source statusu, FX qaydası, minimum payable məbləğ, fractional entitlement, source allocation və sonradan gələn market claim düzəlişləri təsir edir. Buna görə “formula nəticəsi” ilə “posted result” ayrı obyektlər olmalıdır. İlk obyekt izah edilən hesablamadır; ikinci obyekt isə təsdiqlənmiş maliyyə hərəkətidir.

4. Split və reorganizasiya adjustment-ları

Stock split adjustment software yalnız quantity-ni nisbətə vurmaqla bitmir. 1-for-10 reverse split nümunəsində sistem köhnə və yeni instrument mapping-ini, effective timestamp-i, fractional share siyasətini, cash-in-lieu gəlirini, açıq order və risk limitlərinin davranışını, qiymət tarixçəsinin necə göstəriləcəyini və ledger posting-lərini ayrıca idarə etməlidir.

Trade tarixçəsini səssizcə overwrite etmək əvəzinə, adjustment event yaradın. Müştəri interfeysi yeni quantity-ni göstərsə də, arxa tərəfdə hansı mövqenin hansı ratio və qayda ilə dəyişdiyi bərpa edilə bilməlidir. Bu yanaşma sonradan düzəliş gələndə reversalı təhlükəsiz edir.

Election workflow: müştəri seçimini etibarlı instruction-a çevirin

Könüllü korporativ əməliyyatlar üçün portal ekranı təkbaşına workflow deyil. Hər election aşağıdakı state machine ilə idarə olunmalıdır:

  1. Event eligible hesablar üçün yayımlanır.
  2. Müştəri option, quantity və tələb olunan məlumatı daxil edir.
  3. Sistem eligibility, max quantity, deadline, account restriction və sənəd tələblərini yoxlayır.
  4. Instruction “received”, “validated”, “pending review”, “submitted”, “acknowledged”, “rejected”, “cancelled” və ya “completed” statuslarından keçir.
  5. Upstream cavabı, partial allocation və ya rejection ayrıca status/event kimi qeydə alınır.

İstifadəçinin “Submit” düyməsinə iki dəfə basması iki instruction yaratmamalıdır. Client request ID, event ID, account ID və election revision-u əsasında idempotency key istifadə edin. Deadline keçdikdən sonra UI-ni bağlamaqla kifayətlənməyin: API və batch import qatında da eyni qayda icra edilməlidir.

Idempotency, approval və düzəlişlər

Korporativ əməliyyatlarda təkrar delivery normal haldır: provider eyni mesajı yenidən göndərə, event update edə, allocation dəyişə və ya əvvəlki məlumatı ləğv edə bilər. Sistem bu halları “duplicate” və ya “error” kimi kor-koranə rədd etməməlidir.

  • Ingestion idempotency: eyni source payload bir dəfə qəbul edilir, lakin qəbul faktı izlənilir.
  • Calculation idempotency: eyni event version və snapshot üçün eyni calculation run təkrar yaradılmır.
  • Posting idempotency: ledger hərəkəti immutable business key ilə qorunur; retry ikinci kredit yaratmır.
  • Correction: səhv yazını edit etməyin. Reversal və yeni corrected posting yaradın, hər ikisini source event və approval qərarı ilə əlaqələndirin.

Material məbləğlər, manual rate override, tax override, cash-in-lieu adjustment və late election exception üçün maker-checker təsdiqi tətbiq edin. Bu nəzarətlər ayrıca log deyil, business workflow-nun öz hissəsi olmalıdır.

Ledger, reconciliation və audit-ready evidence

Financially consequential event təsdiqlənən kimi platforma cash, securities və lazım gəldikdə fee/tax üzrə balanslaşdırılmış ledger entry-lər yaratmalıdır. Accounting date, effective date, booking timestamp və value date ayrı sahələr ola bilər. Bu ayrım dövr sonu hesabatı, correction və backdated upstream allocation-lar üçün vacibdir.

Reconciliation ən azı üç səviyyədə aparılmalıdır: daxili entitlement calculation ilə upstream allocation; posting total-ları ilə custody/bank cash movement; event-level total-lar ilə account-level client allocation. Break queue fərqi yalnız məbləğ kimi yox, səbəb kodu, təsir olunan hesablar, source version, owner, SLA və resolution evidence ilə saxlamalıdır. Əməliyyat komandası bu iş səthini rahat istifadə edə bilmirsə, onu UI/UX və məhsul dizaynı işi kimi ayrıca layihələndirmək lazımdır.

Müştəri kommunikasiyası: bildiriş, təsdiq və izahı ayırın

Müştəriyə göndərilən məlumat üç fərqli məqsəd daşıya bilər:

  • Notice: hadisə elan edildi; məlumat ilkin və ya yenilənə biləndir.
  • Election invitation: seçim mümkündür; option-lar, risklər, deadline və default nəticə göstərilir.
  • Posting confirmation: cash və ya security hərəkəti hesabda qeydə alındı; bruto məbləğ, vergi, net məbləğ, ratio, quantity və reference təqdim edilir.

Bu mətnlər event schema-dan və template versiyasından yaranmalıdır, sərbəst copy-paste e-mail-dən yox. Hər göndəriş üçün recipient, kanal, dil, template version, render olunmuş məzmun, delivery status və source event version-u saxlayın. Müştəri sorğu verəndə support komandası “nə baş verdi?” sualını yalnız ekran görüntüsü ilə deyil, hesablamanın izahı və source evidence ilə cavablamalıdır.

Satınalma yoxlama siyahısı

  • Provider mesajını, raw sənədi və canonical event version-larını saxlaya bilirmi?
  • Record date və eligibility snapshot-ları sonradan tam bərpa oluna bilirmi?
  • Mandatory, mandatory-with-choice və voluntary event-lər fərqli state machine-lərlə dəstəklənirmi?
  • Tax, rounding, FX, fractional share və default option qaydaları versioned configuration-durmu?
  • Posting retry-ləri duplicate cash və ya duplicate securities yaratmadan işləyirmi?
  • Reversal, correction və rebooking əvvəlki nəticəni silmədən audit chain yaradırmı?
  • Upstream allocation, internal ledger və client allocation arasında break idarəetməsi varmı?
  • Operator override-ları approval və səbəb kodu olmadan edilə bilirmi?

POLADO ilə necə başlamaq olar

Yaxşı korporativ əməliyyat platforması bir dəfəlik “dividend modulundan” ibarət olmur. O, instrument master, account modeli, custody inteqrasiyası, ledger, notification və operations workflow-ları ilə əlaqəli nəzarətli bir domen qatıdır. POLADO əvvəlcə event növlərinizi, data mənbələrinizi, mövcud ledger sərhədlərinizi və exception həcminizi xəritələndirə, sonra mərhələli arxitektura və delivery planı hazırlaya bilər. FinTech və trading sistemləri xidməti ilə bu həllin əsasını, Texniki dəstək və konsaltinq ilə isə observability, release nəzarəti və davamlı əməliyyat modelini müzakirə edin.