Trading platform ledger hazırlanması brokerin və ya maliyyə platformasının hesab balansları üçün etibarlı həqiqət mənbəyinin qurulmasıdır. Bu, sadəcə balance sütununu yeniləmək deyil: depozit, çıxarış, trade, komissiya, swap, rebate, daxili transfer, düzəliş və reversal ayrıca, dəyişdirilməz yazılışlarla qeydə alınmalıdır. Cari balans, istifadəçi interfeysi və hesabatlar isə həmin yazılışlardan alınan proyeksiyalardır.

Bu yanaşma xüsusilə vacibdir, çünki trading məhsulunda eyni məbləğ müxtəlif anlarda fərqli iqtisadi vəziyyətdə ola bilər: hesabda mövcud, order üçün bloklanmış, settlement gözləyən və ya artıq çıxarış üçün rezerv edilmiş. İstifadəçi “balansım niyə dəyişdi?” soruşanda sistem yalnız yeni rəqəmi deyil, hərəkətlərin ardıcıllığını, mənbəyini, təsdiqini və əlaqəli əməliyyatlarını da göstərə bilməlidir.

Ledger nəyi source of truth etməlidir?

Order management, payment gateway, liquidity bridge və fee engine mühüm domen sistemləridir, lakin onlar maliyyə həqiqətinin özləri olmamalıdır. Onlar faktı bildirən və ya əmri yaradan sistemlərdir; ledger isə təsdiqlənmiş iqtisadi təsiri ikiqat yazılışa çevirən nəzarət qatıdır.

  • Depozit: müştəri vəsaiti artır, eyni məbləğ müvafiq clearing və ya payment-provider hesabında əks yazılış alır.
  • Çıxarış: əvvəlcə vəsait available balansdan locked balansına keçirilir; ödəniş təsdiqlənəndə öhdəlik və clearing hərəkətləri post edilir, rədd edilərsə rezerv açılır.
  • Trade və settlement: cash, instrument inventory, qarşı tərəf və ya clearing hesabları modelə uyğun yazılış alır. Sadələşdirilmiş “trade executed” hadisəsi birbaşa müştəri balansını dəyişməməlidir.
  • Komissiya, swap və rebate: müştəri hesabı ilə gəlir, xərc, payable və ya rebate-liability hesabları arasında ayrıca posting olmalıdır.
  • Manual düzəliş: operator köhnə yazılışı redaktə etmir; əsaslandırılmış, təsdiqli kompensasiya və ya reversal yazılışı yaradır.

Bu sərhəd FinTech və trading sistemləri işində əsas dizayn qərarıdır: balansı başqa servislərin lokal cədvəllərindən “toplamaq” qısa müddətdə rahat görünə bilər, lakin araşdırma, bərpa və reconciliation xərclərini artırır.

İkiqat yazılış: sıfır-cəmli maliyyə təsiri

Double-entry wallet ledger o deməkdir ki, hər posting ən azı debit və credit ayağına malikdir və eyni currency/asset üzrə ümumi təsir sıfır olmalıdır. Bu qayda sistemin “pul yaratmasını” və ya “pul itirməsini” texniki səhvlərdən ayırmağa kömək edir.

Məsələn, 1 000 USD depozit provider callback-i təsdiqləndikdən sonra belə modellənə bilər:

  • Müştərinin USD cash-liability hesabına +1 000 USD kredit;
  • Payment provider clearing asset hesabına +1 000 USD debit.

Hesabların debit və credit işarələri məhsulun seçdiyi accounting konvensiyasından asılıdır. Vacib hissə işarənin özü deyil, hər posting set-in balanslı, asset-aware və izah edilə bilən olmasıdır. Trading platformalarında currency ilə yanaşı instrument, lot, token və ya collateral vahidi də ledger asset-i ola bilər. Buna görə account key adətən təkcə customer_id deyil; entity, account purpose, asset, wallet type və bəzən legal entity kimi ölçüləri əhatə edir.

Available və locked balansları ayrıca hesablarla model edin

Available balance istifadəçinin yeni order, transfer və ya çıxarış üçün sərbəst istifadə edə bildiyi vəsaitdir. Locked balance isə açıq order, margin rezervi, pending withdrawal və ya ara emal üçün ayrılmış məbləğdir. Locked sahəsini yalnız bir status bayrağı kimi saxlamaq risklidir; lock/unlock da ledger hərəkəti olmalıdır.

Məsələn, 300 USD-lik order rezervi müştərinin available USD hesabından 300 USD çıxarıb locked-for-order USD hesabına 300 USD köçürür. Order ləğv edilərsə əks transfer post edilir. Fill, fee və margin nəticələri ayrıca posting set-ləridir. Beləliklə, əməliyyat komandası “nə qədər vəsait bağlıdır və hansı səbəbdən?” sualını order identifikatoru üzrə cavablandıra bilir.

Event-sourced trading ledger: hadisə ilə posting-i qarışdırmayın

Event sourcing tətbiq vəziyyətindəki dəyişikliklərin hadisələr ardıcıllığı kimi saxlanmasıdır; sistemin əvvəlki vəziyyətini həmin ardıcıllıqdan yenidən qurmaq mümkündür. Ledger üçün bu xüsusiyyət qiymətlidir, amma hər inteqrasiya mesajını dəyişdirilməz maliyyə həqiqəti kimi qəbul etmək düzgün deyil.

Praktik modeldə ən azı üç qat ayırın:

  1. Business event: məsələn, DepositProviderConfirmed, OrderReserveRequested, TradeSettled və ya SwapAccrued. Hadisə xarici və ya daxili mənbədən gələ bilər.
  2. Posting decision: qayda mühərriki hadisənin hansı accounting effect yaratdığını, hansı book-date, value-date, asset və hesabları istifadə etdiyini müəyyən edir.
  3. Journal entries və lines: dəyişdirilməz, balanslı maliyyə yazılışları. Current balance read model-i bu lines-lardan yaranır.

Bu ayrım sonradan business hadisəsi haqqında yeni məlumat gəldikdə vacib olur. Məsələn, payment provider əvvəl uğurlu görünən depoziti sonradan reverse edə bilər. İlkin posting-i silmək əvəzinə onu əlaqələndirən reversal journal yaradın. Audit görünüşündə həm orijinal təsir, həm reversal səbəbi, həm də provider reference qalır.

İmmutability “heç nə düzəltmirik” demək deyil

Maliyyə məhsullarında səhvlər qaçılmazdır: yanlış fee konfiqurasiyası, gecikmiş provider callback-i, duplicate mesaj və ya operator səhvi. Doğru cavab keçmiş sətri UPDATE etmək deyil. Hər düzəlişin ayrıca biznes səbəbi, müəllifi, təsdiq mərhələsi, əlaqəli orijinal journal ID-si və bəzən dörd-göz prinsipinə uyğun approval-u olmalıdır.

  • Reversal: orijinal posting-in bütün ayaqlarını əks işarə ilə ləğv edir.
  • Correction: düzgün iqtisadi nəticəyə çatmaq üçün fərq posting-i yaradır; orijinal yazılış görünən qalır.
  • Adjustment: goodwill credit, rounding və ya müqavilə üzrə kompensasiya kimi müstəqil, əsaslandırılmış hərəkətdir.

Admin ekranında “balansı dəyiş” düyməsi yox, “düzəliş təklifi yarat” axını olmalıdır. Orada səbəb kodu, məbləğ, asset, əlaqəli müştəri/ticarət/payment reference, əlavələr, maker və approver qeydə alınır. Bu, texniki dəstək və konsaltinq mərhələsində də istintaq və təhlükəsiz əməliyyat prosedurlarını sadələşdirir.

İdempotency və ardıcıllıq: retry maliyyə təsiri yaratmamalıdır

Şəbəkə vaxtı bitəndə client eyni withdrawal request-i təkrar göndərə bilər. Message broker isə consumer-i eyni callback ilə yenidən çağıra bilər. Buna görə hər maliyyə əmri üçün stabil idempotency key, payload fingerprint və nəticə saxlanmalıdır. Eyni key və eyni payload cavabı qaytarmalı, eyni key ilə fərqli payload isə konflikt yaratmalıdır.

Posting zamanı ən kritik invariant-ları bir tranzaksiyada qoruyun: journal başlığı, bütün debit/credit lines, idempotency qeydiyyatı və istifadə olunmuş source-event reference birlikdə commit edilməlidir. Asinxron oxu modelləri, bildirişlər və analitika sonradan outbox vasitəsilə yayıla bilər; lakin “balans yazıldı, event sonra itdi” və ya “event yayıldı, posting alınmadı” vəziyyətləri dizaynda nəzərə alınmalıdır.

Concurrency üçün minimum qaydalar

  • Hesab, asset və wallet üzrə serializasiya və ya optimistik versiyalaşdırma strategiyasını açıq seçin.
  • Negative available balance qadağası, credit limit və margin qaydalarını posting-dən əvvəl deterministik yoxlayın.
  • Hər event üçün source system, external reference, occurred-at, received-at və effective date saxlayın.
  • UTC zamanlarından istifadə edin; trading day və cut-off qaydalarını ayrıca biznes konfiqurasiyası edin.
  • Schema versiyasını event və journal metadata-da saxlayın ki, replay zamanı köhnə məlumatın mənası itirilməsin.

Reconciliation sübutu və operativ araşdırma

Ledger təkbaşına provider bank çıxarışı, custody məlumatı və ya execution venue qeydləri ilə avtomatik eyni olmayacaq. Lakin düzgün ledger reconciliation prosesini izah edilə bilən edir. Hər daxili posting xarici sübuta bağlana bilməlidir: provider transaction ID, bank statement line, trade ID, allocation ID, venue execution və ya settlement reference.

Gündəlik və intraday nəzarətlərə bunlar daxildir:

  • Hər journal üzrə debit cəmi = credit cəmi;
  • Hər asset üzrə client liability, clearing/custody asset və suspense hesablarının gözlənilən münasibəti;
  • Pending, unmatched və aged breaks siyahısı;
  • Source event-dən journal-a, journal-dan balance projection-a qədər traceability;
  • Reversal və adjustment-ların səbəb kodu və approval sübutu.

Bu arxitektura mövcud ESFX FinTech / Analytics kimi data-intensiv məhsullar və broker əməliyyatları üçün daha etibarlı audit, client reporting və exception idarəetməsi təməli yaradır.

Ledger layihəsi üçün praktik qəbul meyarları

Vendor və ya daxili komanda seçərkən “double entry dəstəkləyirsiniz?” sualı kifayət deyil. Aşağıdakı nəticələri demonstrasiya etməsini istəyin:

  1. Bir depozit, withdrawal rejection, partial fill, fee və reversal üzrə tam journal izini göstərin.
  2. Həmin hesabın available, locked və total görünüşünü müəyyən vaxt nöqtəsinə yenidən qurun.
  3. Eyni provider callback və eyni API request iki dəfə gələndə nəticənin yalnız bir dəfə post edilməsini sübut edin.
  4. Backdated correction üçün orijinal, reversal/correction və approval chain-i göstərin.
  5. Bir reconciliation break-in source reference-dən operator qərarına qədər həyat dövrünü göstərin.
  6. Journal schema dəyişdikdən sonra tarixi məlumatı necə oxuyacaqlarını və proyeksiyaları necə yenidən quracaqlarını izah edin.

POLADO ilə trading ledger arxitekturasını planlaşdırın

Ledger-in düzgün qurulması yalnız cədvəl dizaynı deyil; trading əməliyyatları, payment lifecycle, margin, fee qaydaları, back-office səlahiyyətləri, müşahidəolunma və reconciliation arasında sərhədlərin qurulmasıdır. POLADO komandası FinTech və trading sistemləri çərçivəsində ledger domain modeli, inteqrasiya müqavilələri, posting qaydaları, back-office workflow-ları və mərhələli modernizasiya planını hazırlamağa kömək edir.

Yeni broker platforması qurursunuzsa və ya balansı bir neçə kövrək cədvəldən hesablayan mövcud sistemi yeniləyirsinizsə, konsultasiya üçün əlaqə saxlayın. Məqsəd sadəcə cari balansı göstərmək deyil, hər məbləğin haradan gəldiyini, niyə dəyişdiyini və necə bərpa ediləcəyini sübut edən maliyyə həqiqət mənbəyi yaratmaqdır.