Trading platformda müştəri hesabatlarının hazırlanması o deməkdir ki, müştərinin gördüyü hər bir balans, mövqe, əməliyyat və mənfəət/zərər göstəricisi uzlaşdırılmış mənbə hadisələrinə bağlanır, hesabat dövrü və kəsmə vaxtı aydın olur, sonradan isə eyni sənədi yenidən yaratmaq mümkündür. Məqsəd sadəcə qrafik və ya PDF yaratmaq deyil. Məqsəd müştəri, support komandası və relationship manager üçün “bu rəqəm haradan gəlib?” sualına sürətli və sübut edilə bilən cavab verən reporting qatını qurmaqdır.

Bu iş regulatora göndərilən faylların hazırlanmasından və ya daxili back-office ekranlarından fərqlənir. Müştəri yönümlü hesabatlar oxunaqlı, izah oluna bilən və yüklənə bilən olmalıdır; eyni zamanda onların hesablamaları ledger, order/fill, qiymətləndirmə, ödəniş və fee hadisələri ilə eyni həqiqət mənbəyinə söykənməlidir.

Müştəri çıxarışında nələr olmalıdır?

Yaxşı trading account statement development işi hesabatı ayrı-ayrı, yoxlanıla bilən bloklara bölür. Bu bloklar məhsul və yurisdiksiyaya görə dəyişə bilər, lakin adətən aşağıdakı məlumatlar tələb olunur:

  • hesab identifikatoru, əsas valyuta, seçilmiş dil, dövrün başlanğıc və bitişi;
  • açılış balansı, bağlanış balansı və mövcud pul vəsaiti;
  • depozit, çıxarış, geri qaytarma, daxili transfer və manual adjustment-lar;
  • açıq mövqelər: instrument, alış/satış istiqaməti, həcm, orta açılış qiyməti, qiymətləndirmə qiyməti, nominal dəyər və margin məlumatı;
  • bağlanmış əməliyyatlar: açılış/bağlanış vaxtı, qiymətlər, həcm, reallaşmış P&L, komissiya və digər xərclər;
  • reallaşmamış P&L, onun istifadə etdiyi qiymət və qiymətləndirmə vaxtı;
  • komissiya, spread mark-up, overnight swap/financing, rebate və vergi kimi ayrıca təsnif edilmiş xərclər;
  • hesabatın yaradılma vaxtı, məlumat kəsmə vaxtı, versiya nömrəsi və sənəd identifikatoru.

Əsas prinsip budur: yekun rəqəm tək başına kifayət deyil. Məsələn, “equity 12,450 USD” sətrinin hansı cash balansından, hansı açıq mövqelərin mark-to-market dəyərindən və hansı fee accrual-lardan yarandığını hesabat və support alətləri izah edə bilməlidir.

Reallaşmış və reallaşmamış P&L-ni qarışdırmayın

Müştəri mübahisələrinin geniş yayılmış səbəbi P&L terminlərinin qeyri-dəqiq təqdim edilməsidir. Reallaşmış P&L bağlanmış mövqedən yaranan nəticədir və məhsul qaydalarından asılı olaraq komissiya, swap və digər xərclərdən əvvəl və ya sonra göstərilə bilər. Reallaşmamış P&L isə hesabatın konkret qiymətləndirmə anında açıq mövqenin dəyər dəyişməsidir; bazar hərəkət etdikcə dəyişir.

Hər görünüşdə bu qaydalar açıq yazılmalıdır: istifadə olunan mark price bid, ask, mid və ya son trade-dir? Qiymət hansı timestamp-ə aiddir? FX çevirməsi hansı məzənnə ilə aparılıb? P&L gross, net, yoxsa tax/fee sonrası göstəricidir? “Bu gün” nəticəsi gecə rollover-dan sonra necə hesablanır? Bu konvensiyalar UI mətnində, PDF-də və CSV sütun başlıqlarında eyni olmalıdır.

Hesabatların etibarlılığı: əvvəl uzlaşdırma, sonra təqdimat

Reporting layer öz balans həqiqətini yaratmamalıdır. O, təsdiqlənmiş və izah edilə bilən hesablamalar üçün oxu modelidir. Sağlam arxitekturada hesabatlar aşağıdakı ardıcıllıqla formalaşır:

  1. Order, fill, trade, fee, swap, depozit və çıxarış kimi xam hadisələr qəbul edilir.
  2. Bu hadisələr dəyişdirilməz identifikatorlar və effective time ilə canonical formata normallaşdırılır.
  3. Ledger posting-ləri cash və payable/receivable hərəkətlərini yaradır.
  4. Position engine net mövqe, cost basis və realized nəticəni hesablayır.
  5. Pricing/valuation qatından müəyyən edilmiş qiymətlərlə unrealized P&L yaranır.
  6. Reconciliation prosesi trading, payment provider, liquidity və ledger mənbələrindəki fərqləri müəyyən edir.
  7. Yalnız təsdiqlənmiş data əsasında statement snapshot və export hazırlanır.

Bu səbəbdən reporting layihəsi adətən ledger arxitekturası və trading platform uzlaşdırması ilə birlikdə planlanmalıdır. Qırıq və ya gecikmiş upstream məlumatı gözəl dizaynlı PDF ilə düzəlmir.

Dövr, vaxt zonası və kəsmə vaxtını məhsul qaydasına çevirin

“1–31 mart” hesabatı kifayət qədər dəqiq spesifikasiya deyil. Sistem hesabatın business time zone-unu, dövrün daxil etmə sərhədini və late-arriving event siyasətini bilməlidir. Məsələn, UTC-dən sonra gələn, amma trade date-i əvvəlki günə aid olan fill nə vaxt görünəcək? Weekend rollover hansı günə yazılacaq? Müştərinin cihaz saatı ilə brokerin hesabat saatı fərqli olduqda hansı timestamp əsasdır?

Praktik yanaşma: statement üçün sabit cut-off qaydası təyin edin, bütün export-larda həmin time zone-u göstərin və hər sənəddə “məlumat bu vaxtadək daxil edilmişdir” qeydi saxlayın. ABŞ-da broker account statement-ləri üzrə tətbiq olunan qaydalar firmaya və fəaliyyət modelinə görə dəyişir; bəzi hallarda periodik statement tələbləri mövcuddur. Aİ-də isə MiFID II çərçivəsində müştəri alətləri və vəsaitləri üzrə dövri məlumatın dövr bitdikdən sonra gecikdirilmədən təqdim olunması vurğulanır. Platformanın hüquqi məcburiyyətlərini hüquq və compliance komandası ayrıca müəyyən etməlidir.

PDF və CSV: eyni rəqəm, fərqli istifadə məqsədi

PDF insan oxunuşu, arxiv və müştəri ilə yazışma üçün uyğundur. CSV isə müştərinin öz analitikasına, mühasibatına və ya vergi məsləhətçisinə məlumat ötürməsi üçün faydalıdır. Lakin CSV “UI-dən export” olmamalıdır; sabit sxem, versiyalanmış sütunlar, ISO tarix formatı, açıq valyuta kodları və düzgün decimal qaydaları olmalıdır.

PDF sənədində period summary, cash movements, trade history, open positions və fee breakdown bölmələri aydın ayrılmalıdır. CSV-də isə entity ID, trade ID, execution time, settlement/effective time, source currency, converted currency, pricing basis və adjustment reference kimi maşınla işlənə bilən sahələr əlavə dəyər yaradır. Müxtəlif dillərdə tərcümə olunmuş etiketlər təqdim edilə bilər, amma kodlar, tarixlər və maliyyə məntiqi lokallaşdırma səbəbindən dəyişməməlidir.

Düzəlişlər köhnə sənədi səssizcə əvəz etməməlidir

Gecikmiş swap, ləğv olunmuş trade, payment provider correction və ya corporate action kimi hallar keçmiş dövrə təsir edə bilər. Bu halda tarixçəni yenidən yazmaq müştəri etibarını və support prosesini zəiflədir. Daha doğru model original statement-i saxlayır, düzəliş səbəbini və təsir etdiyi sətirləri qeyd edir, sonra isə yeni revision yaradır.

Hər export üçün aşağıdakılar saxlanmalıdır: report ID, account ID, sorğu filtrləri, cut-off, generator versiyası, mənbə snapshot identifikatoru, yaradılma vaxtı, fayl hash-i və onu endirən istifadəçi. Müştəri əvvəlki PDF-ni göndərdikdə, komanda eyni revision-u bərpa etməli və yeni versiyanın ondan nə ilə fərqləndiyini deyə bilməlidir.

Broker client portal reporting üçün giriş və icazələr

Hesabatlar maliyyə və şəxsi məlumat daşıdığı üçün “account owner” yoxlaması yetərli olmaya bilər. Fərdi müştəri, corporate account administrator, trader, read-only auditor və relationship manager üçün ayrıca səlahiyyətlər lazım ola bilər. İcazə modeli həm ekranda görünüşü, həm CSV/PDF export-u, həm də tarix aralığı və account scope-u əhatə etməlidir.

Relationship manager üçün multi-account görünüş faydalıdır, lakin o, yalnız ona təyin edilmiş hesabları görməli və müştəri adından sənədi dəyişdirə bilməməlidir. Fee məntiqi və adjustment-lar üçün isə audit edilə bilən fee engine, cash movements üçün də depozit və çıxarış axınları ilə uyğun inteqrasiya vacibdir.

İcra checklist-i

  • Hər statement rəqəmini source event və ledger posting-ə bağlayın.
  • Account currency, valuation price və FX conversion qaydasını görünən edin.
  • Realized və unrealized P&L-ni ayrı saxlayın; gross/net təqdimatını izah edin.
  • Closed trades, open positions, cash movements və fees üçün sabit sxem qurun.
  • Time zone, reporting period və cut-off qaydasını sənədləşdirin.
  • PDF, CSV və portal ekranında eyni məntiqi istifadə edin.
  • Corrections üçün revision və fərq izahı yaradın; keçmiş export-u səssiz dəyişməyin.
  • Download və generation əməliyyatlarını audit log-a yazın.

POLADO ilə client reporting qatını qurun

POLADO trading məhsulları üçün etibarlı client portal, reporting API, export pipeline və mobil görünüşlər hazırlayır. Biz əvvəlcə data lineage, reconciliation break-ləri, P&L konvensiyaları və permission matrix-i müəyyənləşdirir, sonra müştərinin gündəlik istifadə edə biləcəyi sadə, lakin audit edilə bilən reporting təcrübəsini qururuq. FinTech və trading sistemləri xidmətimiz çərçivəsində statement-ləri ledger, əməliyyat, fee və cash komponentləri ilə bir məhsul arxitekturasında birləşdirə bilərik. Mövcud platformanızda hesabat rəqəmləri izah olunmursa və ya yeni client portal planlayırsınızsa, texniki konsultasiya üçün komandamızla əlaqə saxlayın.