Trading platforması üçün müştəri hesabatlarının hazırlanması o deməkdir ki, portalda, PDF çıxarışında, dəstək ekranında və back-office-də görünən rəqəmlər eyni, bağlanmış hesabat məlumat dəstindən yaranır. Etibarlı sistem “ekranda indi nə görünür?” sualına yox, “müştəriyə hansı tarix, qayda versiyası və mənbə qeydləri əsasında hansı çıxarış təqdim edildi?” sualına cavab verir.

Bu fərq vacibdir. Canlı qiymət, cari FX məzənnəsi və ya sonradan düzəldilən icra məlumatı UI-da məbləği dəyişə bilər. Lakin dövr üçün yaradılmış çıxarışda mövqelər, pul vəsaitləri, komissiyalar və P&L hesabatın kəsim vaxtı, qiymətləndirmə qaydası və versiyası ilə birlikdə saxlanmalıdır. ABŞ-da əməliyyat təsdiqləri üçün tələb olunan məlumatlara tarix, vaxt, qiymət, miqdar, brokerin rolu və müəyyən kompensasiya açıqlamaları daxildir; SEC həmçinin təsdiqlərdəki məlumatların müştəri çıxarışları və jurnal qeydləri ilə uzlaşmasının vacibliyini vurğulayır. ([sec.gov](https://www.sec.gov/about/divisions-offices/division-trading-markets/division-trading-markets-compliance-guides/guide-broker-dealer-registration?utm_source=openai))

Hesabat mühərrikini UI hesablamasından ayırın

Sadə məhsulda frontend açıq mövqeni, son qiyməti və alış qiymətini götürərək P&L hesablaya bilər. Bu, yalnız informativ dashboard üçün məqbul ola bilər; endirilən çıxarış, müştəri sorğusu və ya maliyyə əməliyyatının sübutu üçün isə risklidir. Eyni hesab müxtəlif səhifələrdə fərqli filtr, yuvarlaqlaşdırma, qiymət vaxtı və FX çevirmə qaydası ilə fərqli nəticə verə bilər.

Daha sağlam arxitekturada reportinq xidməti ayrıca məlumat məhsulu yaradır:

  • Əməliyyat mənbələri: order və execution hadisələri, pul kitabçası, komissiya qaydaları, korporativ əməliyyatlar, instrument referens məlumatları və qiymət məlumatı.
  • Uzlaşdırma qatı: broker, kastodian, ödəniş provayderi və ya daxili ledger məlumatları ilə fərqləri aşkar edir; həll olunmamış istisnaları göstərir.
  • Hesabat anlıq görüntüsü: hesab, dövr, timezone, kəsim vaxtı, hesablama qaydası, qiymət mənbəsi və məlumat versiyası ilə birlikdə dondurulmuş nəticədir.
  • Təqdimat qatı: portal cədvəli, CSV, PDF və əməliyyat dəstəyi ekranı eyni snapshot API və ya eyni materiallaşdırılmış nəticədən oxuyur.

Bu prinsip FinTech və trading sistemləri işinin əsas hissəsidir: ledger, icra axınları və reportinq ayrı komponentlər ola bilər, amma hamısı eyni biznes hadisələrinə istinad etməlidir.

Kəsim vaxtı və hesabat dövrü əvvəlcədən açıq müəyyən edilməlidir

“Sentyabr hesabatı” təkbaşına spesifikasiya deyil. Sistem hər hesabat üçün ən azı dövrün başlanğıc və son anını, timezone-u, ticarət təqvimini, iş gününə keçid qaydasını və qiymətləndirmə vaxtını bilməlidir. Məsələn, 30 sentyabr 23:59:59 UTC ilə Nyu-York vaxtı üzrə bağlanış eyni nəticə verməyə bilər. 24/7 kripto məhsulu, T+1 hesablaşmalı qiymətli kağız və həftəsonu bağlı olan FX bazarı üçün eyni “gün sonu” anlayışı tətbiq olunmamalıdır.

Hər snapshot üçün saxlanmalı minimum metadatа

  • hesab və hüquqi şəxs/tenant identifikatoru;
  • hesabat dövrü, timezone və cut-off timestamp;
  • mövqe qiymətləndirməsi üçün istifadə olunan qiymət və qiymət vaxtı;
  • valyuta çevirmə məzənnəsi, məzənnə mənbəyi və çevirmə vaxtı;
  • P&L metodologiyası, məsələn FIFO, orta maya dəyəri və ya müqavilə üzrə qayda;
  • komissiya, borrow, funding, custody və digər haqq qaydalarının versiyası;
  • generator versiyası, yaradılma vaxtı, status və əvəzlənən hesabatın identifikatoru.

Belə metadata dəstək əməkdaşının “niyə bu rəqəm dəyişdi?” sualına araşdırıla bilən cavab verməsini təmin edir. Bu, texniki dəstək və konsaltinq proseslərində də faydalıdır: incident və ya məlumat korreksiyası zamanı müştəriyə göndərilmiş konkret versiyanı bərpa etmək mümkündür.

Mövqelər və P&L: yekun rəqəmdən əvvəl metodologiyanı göstərin

Trading P&L reporting system yalnız ümumi mənfəət və zərər rəqəmi verməməlidir. Müştəri və əməliyyat komandası onun komponentlərini ayıra bilməlidir:

  • Reallaşmış P&L: bağlanan lotlar və ya müqavilələr üzrə yaranan nəticə; istifadə olunan matching metodundan asılıdır.
  • Reallaşmamış P&L: açıq mövqenin hesabat kəsimindəki qiymətlə dəyəri və müəyyən edilmiş maya dəyəri arasındakı fərqdir.
  • Gəlir və xərclər: dividend, kupon, funding, borrow, komissiya, vergi və digər tətbiq edilən hərəkətlər P&L-dən ayrıca da görünməlidir.
  • Valyuta təsiri: hesabın baza valyutası ilə instrumentin və ya settlement valyutasının fərqi ayrıca izah olunmalıdır.

Məsələn, EUR ilə alınan ABŞ səhmi USD ilə bahalaşa, lakin EUR/USD dəyişdiyinə görə hesab sahibinin EUR nəticəsi fərqli görünə bilər. Hesabat yalnız “+500” yazmaq əvəzinə instrument gəlirini, FX çevirmə təsirini, komissiyanı və istifadə olunan məzənnəni ayırmalıdır. Bu, rəqəmi daha “gözəl” göstərmək üçün deyil, sonradan təkrar hesablamaq üçün lazımdır.

Pul hərəkətləri və komissiyalar ayrıca izlənən hadisələrdir

Nağd pul bölməsi sadəcə balans sütunu olmamalıdır. O, açılış balansı, depozit, çıxarış, alqı-satqı üzrə settlement, komissiya, vergi, faiz/funding, dividend və korporativ əməliyyat üzrə pul hərəkətlərini göstərməlidir. Hər sətirdə effektiv tarix, dəyər tarixi, valyuta, istiqamət, mənbə hadisə ID-si və status saxlanmalıdır.

Bu xüsusilə pending və settled məbləğlərin qarışdırılmaması üçün vacibdir. Məsələn, icra trade date-də baş verə bilər, cash isə daha sonra settlement tarixində dəyişə bilər. Portalda “available to trade”, “settled cash” və “statement closing cash” eyni anlayış deyilsə, adlar və hesablama qaydaları açıq olmalıdır. ESMA-nın MiFID II çərçivəsində xərclər və ödənişlər üzrə daha tez-tez ex-post məlumat təqdim edən firmalara verdiyi yanaşma da metodologiyanın ardıcıl olmasını və mümkün olduqda reallaşmış, məlum xərclərdən istifadə edilməsini vurğulayır. ([esma.europa.eu](https://www.esma.europa.eu/publications-data/questions-answers/1816?utm_source=openai))

Korporativ əməliyyatlar və korreksiyalar tarixi silməməlidir

Split, reverse split, dividend, merger, spin-off, simvol dəyişikliyi və ya kontrakt adjustment mövqenin miqdarını, maya dəyərini və tarixi P&L-ni dəyişə bilər. Belə hadisələr “mövcud mövqeni overwrite et” məntiqi ilə işlənməməlidir. Hesabatda müştərinin köhnə instrumentdən yeni instrumentə necə keçdiyini və hansı adjustment nisbətinin tətbiq edildiyini izləmək mümkün olmalıdır.

Eyni prinsip gecikmiş execution, ləğv, broker korreksiyası və ya səhv komissiya qaydası üçün keçərlidir. Yayımlanmış PDF və ya çıxarışda səhv varsa, orijinal sənəd səssiz dəyişdirilməməlidir. Düzgün proses belədir:

  1. dəyişiklik səbəbini və təsirlənən hadisələri qeyd edin;
  2. yeni hesablama versiyasını yaradın;
  3. əvvəlki snapshot-u qoruyun və onu əvəzlənmiş kimi işarələyin;
  4. müştəriyə korreksiya sənədini, versiyanı və aydın fərq izahını təqdim edin;
  5. dəstək və back-office ekranlarında eyni versiyanı göstərin.

Bu nəzarətlər UI/UX və məhsul dizaynı məsələsidir də: “corrected” statusu, versiya identifikatoru və izah edilən fərq həm dəstək yükünü, həm də müştərinin çaşqınlığını azaldır.

Yüklənən çıxarışlar audit olunmalıdır

PDF və CSV “export” düyməsinin texniki nəticəsi deyil, müştəriyə verilən artefaktdır. Sənəddə hesabat ID-si, yaradılma vaxtı, dövr, hesab identifikatorunun maskalanmış forması, baza valyutası, metodoloji qeydlər və korreksiya statusu olmalıdır. Sistem həmçinin kimin, hansı roldan, hansı tarixdə hansı sənədi endirdiyini audit jurnalında saxlamalıdır. İcazələr tenant və hesab səviyyəsində tətbiq edilməli, imzalı yükləmə keçidləri məhdud müddətli olmalı və həssas məlumatlar log-lara yazılmamalıdır.

İnkişafa başlamazdan əvvəl yoxlama siyahısı

  • Hər rəqəm üçün authoritative source of truth müəyyən edilibmi?
  • Order, fill, cash, fee və corporate-action hadisələri idempotent və izlənə biləndirmi?
  • Cut-off, timezone, qiymət və FX qaydaları məhsul spesifikasiyasında yazılıbmı?
  • Reallaşmış/reallaşmamış P&L və settlement statusları dəqiq ayrılıbmı?
  • Portal, PDF, CSV, support və back-office eyni snapshot-dan oxuyurmu?
  • Korreksiya əvvəlki sənədi silmədən yeni versiya yaradırmı?
  • İnstrument, valyuta, lot, mənfi balans və məlumat gecikməsi üçün test ssenariləri varmı?

POLADO trading və investisiya məhsulları üçün reportinq qatını order axınları, ledger, broker API-ləri və əməliyyat prosesləri ilə birlikdə layihələndirir. Mövcud platformanızda çıxarışların hansı qeydlərdən yarandığını, hansı fərqlərin risk yaratdığını və mərhələli tətbiq planını müzakirə etmək üçün FinTech komandamızla konsultasiya planlaşdırın.