Trading platform fee engine development yalnız əməliyyata faiz tətbiq etmək deyil. Etibarlı həll hər komissiya, swap, rebate və manual düzəliş üçün cavab verə bilməlidir: hansı qayda tətbiq edildi, qaydanın hansı versiyası qüvvədə idi, hansı məzənnə istifadə olundu, nəticə necə yuvarlaqlaşdırıldı və sonradan nə üçün yenidən hesablandı. Bu sübut zənciri yoxdursa, fee modulu mübahisəli spreadsheet-lərə və geri dönüşü çətin olan balans fərqlərinə çevrilir.

Broker, prop-trading məhsulu və ya multi-asset platforması üçün fee engine ayrıca, qayda əsaslı domen komponenti kimi hazırlanmalıdır. O, execution, position, hesab, kampaniya, IB strukturu, instrument specification və ledger ilə inteqrasiya edir, amma onların içində gizlənmir. POLADO-nun FinTech və trading sistemləri xidməti belə modulların platforma arxitekturasına, back-office iş axınlarına və inteqrasiyalara uyğun qurulmasına yönəlib.

Fee engine üçün əsas prinsip: qaydanı nəticədən ayırın

“EURUSD üçün 7 USD lot başına” kimi mətn qayda modeli deyil. Hesablama üçün strukturlaşdırılmış schedule lazımdır. Hər fee rule ən azı rule ID, versiya, status, qüvvəyə minmə intervalı, prioritet, eligibility şərtləri, formula, charge currency, rounding policy və approval metadata saxlamalıdır.

Hesablama nəticəsi isə immutable calculation record olmalıdır: input snapshot, seçilmiş rule version, formula parametrləri, aralıq dəyərlər, FX conversion source, nəticə, status və correlation ID. Tarifi dəyişəndə köhnə trade-lərin tarixi nəticəsi səssizcə dəyişməməlidir. Yeni schedule yalnız müəyyən edilmiş effective time-dan sonra yaranan hadisələrə tətbiq edilir; keçmiş nəticənin düzəlişi ayrıca adjustment və ya recalculation prosesi ilə qeydə alınır.

Tarif modelində nələri versiyalayın

  • Komissiya: lot, kontrakt, unit, notional, faiz, minimum/maksimum və ya sabit məbləğ.
  • Swap/overnight financing: long/short istiqaməti, instrument group, rollover cut-off, day multiplier, holiday calendar və day-count konvensiyası.
  • Rebate: trader-endirim, kampaniya krediti, liquidity və ya introducing broker payı.
  • Əlavə xərclər: exchange, regulatory, custody və ya platform fee kimi ayrı charge component-ləri.
  • Yuvarlaqlaşdırma: hesablama mərhələsində, charge currency-də və ya ledger posting-dən əvvəl tətbiq olunması.

Bu ayrılıq həm client statement-ləri, həm də downstream post-trade mesajları üçün faydalıdır: FIX spesifikasiyası commission və digər transaction fee-ləri ayrıca məlumat komponentləri kimi dəstəkləyir. Bu, daxili modelin də “bir total fee” əvəzinə komponentli olması üçün praktik əsasdır.

Eligibility və prioritet: “ən uyğun qayda” dəqiq müəyyən edilməlidir

Eyni trade-ə bir neçə schedule namizəd ola bilər: tenant üzrə default tarif, account group tarifi, VIP volume tier, instrument-specific istisna və promosyon. Sistem “ilk tapılan qayda” ilə işləməməlidir. Deterministik selection siyasəti yazılı və test edilə bilən olmalıdır.

Məsələn, seçim ardıcıllığı belə ola bilər: tenant və hüquqi şəxs scope-u; account və account group; instrument və instrument group; tərəf/side; execution venue; trade timestamp; volume tier; kampaniya; sonra isə explicit priority. Eyni prioritetdə iki qayda qalırsa, engine charge yaratmaq əvəzinə configuration exception qaytarmalıdır. Əks halda iki administratorun yaratdığı qaydaların sırası maliyyə nəticəsini gizli şəkildə dəyişə bilər.

Volume tier-ləri düzgün qurun

Tier hesablamasında periodun nə olduğu aydın olmalıdır: calendar month, rolling 30 gün, settlement month və ya broker-defined cycle. Həcmə hansı event-lər daxildir? Cancel edilmiş fill, correction, internal transfer və ya test account əməliyyatı necə davranır? Tier snapshot trade zamanı dondurulmalıdır; ayın sonunda yeni tier əldə olunması əvvəlki trade fee-lərini avtomatik yenidən yazmamalıdır, əgər müqavilə bunu açıq tələb etmirsə.

Komissiya, conversion və swap hesablamasını izah edilə bilən edin

Broker commission calculation software üçün formula təkcə nəticə deyil, audit olunan addımlar yaratmalıdır. Məsələn, 2.4 lot həcmində trade üçün 3.50 USD/lot komissiyası 8.40 USD-dir. Account currency EUR-dursa, conversion üçün 0.9200 rate, rate source, rate timestamp və rounding qaydası ayrıca saxlanmalıdır. Nəticə 7.728 EUR olarsa, 7.73 EUR-a yuvarlaqlaşdırmanın hansı decimal policy ilə edildiyi görünməlidir.

FX conversion-da “latest rate” istifadə etmək təhlükəlidir. Rule konkret mənbə, quote direction, bid/ask/mid siyasəti, valuation timestamp və fallback davranışı təyin etməlidir. Rate yoxdursa, engine gizli təxmini qiymət seçməməli; pending valuation və ya operational exception yaratmalıdır.

Trading swap calculation engine isə trade fill-dən çox açıq position snapshot-u ilə işləyir. Rollover job-u cut-off vaxtında eligible open quantity-ni, side-ı, instrument finanslaşdırma parametrini, multiplier-i və calendar-ni snapshot etməlidir. “Triple swap Wednesday” kimi bazar praktikası hard-code edilməməli, instrument və ya market calendar konfiqurasiyası olmalıdır. Position cut-off-dan sonra bağlanıbsa və ya correction alıbsa, engine seçilmiş policy-yə əsasən reversal, delta adjustment və ya controlled recalculation yaratmalıdır.

IB rebate və manual adjustment-ları ayrıca maliyyə hadisəsi kimi saxlayın

Introducing broker rebate system development üçün referral əlaqəsini sadəcə account profilində saxlamak kifayət deyil. Rebate eligibility trade zamanı snapshot edilməlidir: introducing broker, campaign, rate plan, payout currency, sharing basis, clawback şərti və settlement statusu. Bu yanaşma sonradan IB əlaqəsi dəyişdirildikdə keçmiş trade-lərin kimin gəliri olduğunu qoruyur.

Manual adjustment da “balance update” olmamalıdır. Operator adjustment type, amount, currency, reason code, bağlı trade/position/calculation ID, sübut faylı və approval statusu təqdim etməlidir. Maker-checker tələb olunan mühitdə yaradan istifadəçi öz əməliyyatını təsdiqləyə bilməməlidir. Düzəliş orijinal charge-ı silmək əvəzinə əks event və ya delta event yaratmalıdır.

Ledger event-ləri və reconciliation: etibarın əməliyyat qatı

Hər hesablanmış component üçün fee assessed, fee posted, fee reversed, rebate accrued, rebate paid və adjustment posted kimi domen event-ləri yaradın. Event-lər idempotency key, business date, event time, source trade ID, rule version və calculation ID daşımalıdır. Ledger posting bu event-lərdən yaranmalıdır; UI-də görünən total, statement export-u və GL inteqrasiyası eyni event zəncirinə söykənməlidir.

Trading fee reconciliation minimum üç səviyyədə işləməlidir:

  1. Execution-to-fee: eligible fill və rollover snapshot-larının hamısı hesablanıb?
  2. Fee-to-ledger: final calculation-ların hamısı bir dəfə və düzgün account/currency ilə post olunub?
  3. Internal-to-external: venue, liquidity provider, clearing broker və ya bank məlumatındakı charge-lar daxili nəticə ilə uyğun gəlir?

Fərqlər total məbləğə görə deyil, component, currency, trade ID, value date və səbəb koduna görə queue-ya düşməlidir. Trade capture və post-trade reporting standartları da correction və cancellation hadisələrinin ayrılıqda idarə olunmasını nəzərdə tutur; fee platformasında eyni prinsip downstream reconciliation-u daha idarə edilən edir.

Release-dən əvvəl yoxlanmalı ssenarilər

  • Partial fill-lər, cancel/replace və trade correction-lar.
  • Tarif dəyişikliyinin effective time sərhədində yaranan trade-lər.
  • Minimum fee, cap, negative rebate və çoxkomponentli charge-lar.
  • Account currency-dən fərqli charge və payout currency-ləri.
  • Rate mənbəyi əlçatmaz olduqda fallback və exception davranışı.
  • Rollover zamanı market holiday, weekend multiplier və position close/open sərhədi.
  • Retry zamanı duplicate fee posting-in qarşısının alınması.
  • Yeni rule versiyasının yalnız nəzərdə tutulan population-a təsir etməsi.

POLADO fee engine-i yalnız kalkulyator kimi deyil, order state, immutable ledger, reporting və back-office approval axınları ilə birləşən məhsul komponenti kimi dizayn edə bilər. FT10 layihəsi və ESFX layihəsi FinTech və analitika yönümlü məhsul təcrübəmizi göstərir. Yeni broker commission calculation software, swap modulu və ya reconciliation qatını planlaşdırırsınızsa, FinTech konsultasiyası üçün müraciət edin: mövcud event axınlarını, tarif modelini, istisnaları və təhlükəsiz mərhələli tətbiq planını birlikdə müəyyənləşdirək.