FinTech ledger arxitekturası məhsuldakı hər pul və ya aktiv hərəkətini dəyişməz journal entry-lərlə qeyd edən, double-entry qaydasını tətbiq edən və balansları bu qeydlərdən yaradan sistemdir. Trading, wallet və payment məhsullarında sifariş, transfer və ya payment cədvəlləri əməliyyat axınını izah edir; onlar maliyyə həqiqətinin yeganə mənbəyi olmamalıdır.

Məsələn, “payment succeeded” statusu təkbaşına istifadəçinin nə qədər vəsait xərclədiyini, platformanın nə qədər komissiya qazandığını, provayder üzrə nə qədər settlement gözlədiyini və sonradan chargeback olarsa nə edilməli olduğunu cavablandırmır. Ledger həmin təsiri balanslaşdırılmış, tarixçəsi qorunan yazılarla göstərir.

POLADO trading və maliyyə məhsullarında order lifecycle, inteqrasiya və back-office proseslərini ledger prinsipləri ilə birlikdə layihələndirir. FinTech və trading sistemləri xidmətinə baxaraq məhsulunuz üçün uyğun arxitektura müzakirəsinə başlaya bilərsiniz.

Niyə mutable order və payment qeydləri balans üçün kifayət etmir?

Order və ya payment obyektinin status sahəsi tez-tez dəyişir: created → pending → succeeded → reversed. Bu, istifadəçi interfeysi və workflow üçün faydalıdır, lakin tarixçəni yenidən yazır. “Amount” və “status” sahələrinin son vəziyyətinə baxmaqla əvvəl hansı rezervin qoyulduğunu, hansı komissiyanın ayrıca tutulduğunu və ya düzəlişin hansı səbəbdən aparıldığını tam bərpa etmək çətinləşir.

Ledger yanaşmasında biznes hadisəsi bir journal transaction yaradır. Həmin transaction ən azı iki entry-dən ibarətdir və debit/credit cəmi sıfır olmalıdır. Nəticədə hər dəyər hərəkətinin qarşı tərəfi olur: istifadəçi cash hesabı, platforma fee income hesabı, provayder clearing hesabı, merchant payable hesabı və ya tranzit hesabı.

Bu, sadəcə mühasibat terminologiyası deyil. Bu, mühəndislik invariantıdır: sistem “pul haradan gəldi və hara getdi?” sualına hər zaman entry-lərlə cavab verməlidir. Məsələn, double-entry ledger transaction modelində bir transaction-dakı debit və credit məbləğlərinin bərabərliyi, bütün entry-lərin birlikdə atomik uğuru və ya uğursuzluğu əsas prinsipdir.

Ledger-in əsas modeli: hesablar, journal transaction-lar və entry-lər

1. Hesabların məqsədini əvvəlcədən müəyyənləşdirin

Ledger account yalnız “istifadəçi balansı” demək deyil. Məhsulunuzun pulun və ya aktivin hansı mərhələdə olduğunu görməsi üçün fərqli hesablar tələb oluna bilər:

  • istifadəçinin available cash və ya available asset hesabı;
  • rezervdə olan vəsait üçün held account;
  • platformanın fee revenue və fee receivable hesabları;
  • payment provayderi, bank, broker və ya custodian üzrə clearing hesabı;
  • merchant, seller və ya affiliate üçün payable hesabı;
  • operational correction və suspense hesabları.

Hesablar tenant, istifadəçi, valyuta, aktiv, provayder və ya hüquqi/operational sərhəd üzrə bölünə bilər. Lakin hesab adlarını və normal debit/credit istiqamətlərini təsadüfi seçmək olmaz: həmin seçimlər reportinq, balance projection və reconciliation məntiqinə birbaşa təsir edir.

2. Journal transaction biznes hadisəsini təmsil etsin

Bir payment capture, trading fill, daxili wallet transferi və ya komissiya tutulması bir journal transaction ola bilər. Transaction-a özünəməxsus identifikator, hadisə tipi, effective time, yaradılma vaxtı, source system, correlation ID və istinad identifikatorları əlavə edin. Entry-lərdə isə account ID, amount, currency və debit/credit istiqaməti saxlanmalıdır.

Order ID və payment provider reference kimi məlumatları entry-dən ayrıca, dəyişdirilə bilən metadata kimi də saxlamaq olar. Amma maliyyə təsiri — məbləğ, hesablar və istiqamət — posted olduqdan sonra dəyişdirilməməlidir.

Dəyişməzlik “səhvi silmək olmaz” demək deyil

Praktik immutable ledger səhv entry-ni update və ya delete etməklə düzəltmir. Əvəzində yeni, balanslaşdırılmış reversal və ya correction transaction-u yazır. Beləliklə, həm ilkin qərar, həm də sonrakı düzəliş görünür.

Məsələn, 2 AZN fee əvəzinə səhvən 20 AZN post edilibsə, ilkin transaction-u edit etməyin. Əvvəlki təsiri ləğv edən reversal, sonra düzgün 2 AZN-ni yazan yeni transaction yaradın. UI yalnız net nəticəni göstərə bilər, amma əməliyyat komandası və audit araşdırması tam səbəb zəncirini görə bilir.

Bu prinsip trading fill-lərinə də aiddir. Brokerdən gələn düzəliş, əvvəlki fill-i səssizcə mutate etmək əvəzinə, ayrıca adjustment hadisəsi kimi ledger-ə keçməlidir. ESFX layihəsi kimi maliyyə analitikası məhsullarında məhz mənbə hadisələri, identifikatorlar və hesablamalar arasındakı izlenebilirlik vacibdir.

Holds, releases və available balansı necə modelləşdirilməlidir?

Wallet və trading məhsullarında istifadəçiyə göstərilən available balance çox vaxt ledger total-dan fərqlənir. İstifadəçi alış sifarişi verdikdə vəsait hələ xarici sistemdə xərclənməyib, amma həmin vəsait yeni əməliyyat üçün əlçatan olmamalıdır.

Sağlam model available və held mövqelərini açıq ayırır. Hold yaradılarkən vəsait available hesabdan held hesabına keçirilə bilər. Sifariş ləğv olunarsa release transaction-u held məbləği yenidən available-a qaytarır. Qismən fill olduqda yalnız istifadə olunan hissə settlement və fee entry-lərinə keçir, qalanı isə release edilir.

Bu dizayn “available = total − active_holds” kimi kövrək, sonradan hesablanan formuldan daha aydındır. Hər hold, release və qismən istifadə ledger-də ayrıca hadisədir; support komandası istifadəçinin niyə trade aça bilmədiyini izah edə bilir.

Idempotent posting və concurrency: eyni hadisəni iki dəfə yazmayın

Şəbəkə timeout-u, webhook retry-si və queue-nun ən azı bir dəfə çatdırılma davranışı eyni əməliyyatın təkrar gəlməsini normal edir. Ledger posting endpoint-i hər request üçün idempotency key qəbul etməli, həmin açarı payload fingerprint və nəticə ilə saxlamalıdır. Eyni key və eyni payload yenidən gəldikdə sistem ikinci transaction yaratmaq əvəzinə əvvəlki nəticəni qaytarmalıdır; eyni key ilə fərqli payload isə xəta verməlidir.

İdempotency təkbaşına kifayət deyil. Eyni hesabın available vəsaitini paralel request-lər xərcləməyə çalışa bilər. Posting transaction-u atomik olmalı, balans yoxlanışı və entry insert-ləri eyni database transaction daxilində aparılmalı, conflict olduqda isə nəzarətli retry mexanizmi işləməlidir. Serializable izolyasiya bəzi sistemlərdə ardıcıl icraya uyğun olmayan nəticələri aşkar edib transaction-u rollback edə bilər; tətbiq belə xətaları yenidən icra etməyə hazır olmalıdır.

Balans proyeksiyaları ledger-in əvəzi deyil

İstifadəçi ekranı üçün hər sorğuda milyonlarla entry toplamaq lazım deyil. Ayrı balance projection və ya materialized read model saxlamaq məntiqlidir. Amma bu projection source of truth deyil, ledger-dən yenidən qurula bilən performans qatıdır.

Praktik yanaşma:

  1. Posted journal transaction və entry-ləri append-only əsas qat kimi saxlayın.
  2. Hər committed posting-dən sonra account-balance projection-u eyni transaction-da və ya etibarlı outbox/event mexanizmi ilə yeniləyin.
  3. Projection version-u və son işlənmiş ledger sequence nömrəsini saxlayın.
  4. Periodik olaraq seçilmiş account-ları entry-lərdən yenidən hesablayın və projection fərqlərini exception queue-ya göndərin.

Cache, dashboard və axtarış indeksinin gecikməsi istifadəçi təcrübəsi məsələsidir. Ledger ilə projection arasındakı izahsız fərq isə operational incident-dir.

Reconciliation və exception queue: xarici həqiqətlə müqayisə

İnternal ledger sizin məhsul həqiqətinizdir; bank, processor, broker və custodian isə xarici mənbələrdir. Trading platform balance reconciliation və payment reconciliation yalnız gün sonu reportu deyil. Sistem sizin gözlədiyiniz settlement, fill, fee və transferləri xarici statement, webhook və ya batch faylı ilə uyğunlaşdırmalıdır.

Uyğunlaşdırma nəticələrini “matched”, “missing external”, “missing internal”, “amount mismatch”, “duplicate”, “late event” və “needs review” kimi vəziyyətlərə bölün. Heç vaxt naməlum fərqi avtomatik olaraq istifadəçi balansına yazmayın. Əvvəl exception queue-da istinadlar, məbləğlər, zamanlar, provayder response-ları və məsul şəxs üçün araşdırma konteksti yaradın.

Bu yanaşma FT10 kimi FinTech yönümlü məhsullar üçün də genişlənə bilən əməliyyat bazası yaradır: engineering komandası posting təhlükəsizliyini, operations komandası isə izahlı istisnaları idarə edir.

Buraxılışdan əvvəl FinTech ledger arxitekturası yoxlama siyahısı

  • Hər posted transaction üçün debit və credit cəmləri bərabərdirmi?
  • Posted maliyyə entry-ləri dəyişdirilməzdir, correction-lar isə ayrıca transaction-durmu?
  • Hər external event üçün sabit source reference və idempotency strategiyası varmı?
  • Hold, partial consumption, release, fee və reversal halları ayrıca sınaqdan keçirilibmi?
  • Available, held, pending və settled anlayışları UI, API və ledger-də eyni mənadadırmı?
  • Balance projection ledger-dən yenidən qurula və fərqlər aşkar edilə bilirmi?
  • Reconciliation mismatch-ləri araşdırıla bilən exception queue-a düşürmü?
  • Support və back-office istifadəçisi bir balansın tərkibini entry-lər səviyyəsində izah edə bilirmi?

Nəticə: statuslar workflow üçündür, ledger isə maliyyə həqiqəti üçün

Order, payment və transfer statusları məhsul workflow-unun vacib hissəsidir. Lakin onlar maliyyə vəziyyətinin dəyişməz sübutu deyil. Düzgün qurulmuş FinTech ledger arxitekturası dəyər hərəkətlərini balanslaşdırır, təkrar posting-in qarşısını alır, düzəlişləri gizlətmir, balans proyeksiyalarını yoxlanıla bilən edir və xarici sistemlərlə reconciliation üçün əsas yaradır.

Wallet, payment və ya trading məhsulunuzda ledger qatını yeni qurursunuzsa və ya mövcud mutable balans məntiqini əvəz etməlisinizsə, POLADO-nun FinTech və trading sistemləri xidməti çərçivəsində data model, posting flow, reconciliation və back-office tələblərini birlikdə qiymətləndirə bilərik.