Trading platform üçün IB və tərəfdaş komissiya sistemi hazırlanması referral linki və promo-kod əlavə etməkdən daha geniş işdir. Broker və ya trading məhsulu üçün etibarlı sistem müştərinin kim tərəfindən gətirildiyini, hansı müqavilə ilə cəlb olunduğunu, hansı ticarət və ya maliyyə hadisəsinin komissiya yaratdığını, komissiyanın nə zaman təsdiqləndiyini və nəticədə payout-a necə çevrildiyini ayrıca idarə etməlidir.

Əsas prinsip budur: marketinq atribusiyası, maliyyə hesablaması və pulun ödənilməsi eyni cədvəl və ya eyni status sahəsi olmamalıdır. Referral məlumatı sonradan dəyişə, trade düzəliş oluna, rebate qaydası yenilənə və ya əməliyyat mübahisələndirilə bilər. Buna görə sistem ilkin faktları silmədən saxlamalı, sonrakı dəyişiklikləri isə ayrıca, izlənə bilən düzəliş hadisələri kimi qeydə almalıdır.

POLADO bu cür əməliyyat infrastrukturlarını FinTech və trading sistemləri xidməti çərçivəsində məhsulun mövcud trading, CRM, KYC, wallet və back-office komponentləri ilə inteqrasiya olunacaq şəkildə layihələndirə bilər. FinTech və analitika məhsullarında işlədiyimiz yanaşmaya ESFX layihəsində baxa bilərsiniz.

IB sistemi hansı biznes problemini həll etməlidir?

Introducing Broker, affiliate, agent və ya regional partner anlayışları kommersiya müqaviləsinə və yurisdiksiyaya görə fərqli ola bilər. ABŞ futures bazarında “introducing broker” ayrıca tənzimlənən vasitəçi kateqoriyasıdır; məhsulun fəaliyyət modeli həmin statusa və ya digər maliyyə öhdəliklərinə düşə bilər. Buna görə texniki komissiya sistemi hüquqi təsnifatı əvəz etmir: qaydalar compliance və hüquq komandası tərəfindən təsdiqlənməlidir.

Texniki baxımdan sistem aşağıdakı suallara birmənalı cavab verməlidir:

  • Müştəri hansı tərəfdaşa və hansı atribusiya qaydasına əsasən bağlıdır?
  • Bu əlaqə hesab, istifadəçi, hüquqi şəxs, trading account və ya kampaniya səviyyəsindədir?
  • Komissiya depozitə, spread gəlirinə, lot həcminə, net fee-yə, swap-a və ya hibrid formulaya görə hesablanır?
  • Hansı hadisələr qazancı provisional edir, hansı hadisələr onu təsdiqləyir?
  • Refund, chargeback, trade bust, correction və ya bonus sui-istifadəsi baş verərsə nə dəyişir?
  • Partnerə hansı məbləğ ödənilib, hansı məbləğ hələ hold dövründədir və hansı məbləğ mübahisəlidir?

Bu suallara yalnız dashboard ekranı ilə cavab vermək olmaz. Cavablar məlumat modeli, qayda versiyaları, event jurnalı və reconciliation prosesində kodlaşdırılmalıdır.

Atribusiyanı kupon kodundan ayırın

Kupon kodu yalnız mümkün atribusiya siqnalıdır. Yetkin bir introducing broker platform development arxitekturası ən azı referral link, qeydiyyat zamanı partner kodu, dəvət olunmuş istifadəçi, satış komandasının manual təyinatı, API ilə gətirilmiş lead və kampaniya kimi mənbələri qəbul etməlidir.

Atribusiya qaydasında yazılmalı sahələr

  • Subject: client, legal entity və ya trading account identifikatoru;
  • Partner: IB, master IB, affiliate və ya agent;
  • Source: link, promo code, CRM import, back-office assignment;
  • Effective interval: başlanğıc və bitmə vaxtı;
  • Rule and evidence: tətbiq olunan atribusiya siyasəti, kampaniya və sübut identifikatoru;
  • Status: pending, active, locked, superseded və ya disputed.

Məsələn, müştəri əvvəlcə A partnerinin referral linki ilə qeydiyyatdan keçib, lakin KYC tamamlanmazdan əvvəl satış əməkdaşı onu B partnerinə bağlayıbsa, sistem “kim sonuncu redaktə etdi?” sualı ilə işləməməlidir. O, hansı atribusiya siyasətinin üstün olduğunu, qərarın nə vaxt qüvvəyə mindiyini və əvvəlki bağın niyə dəyişdirildiyini saxlamalıdır. Bir account-un iki partner üçün eyni gəlir hadisəsindən komissiya yaratması yalnız açıq split qaydası varsa mümkün olmalıdır.

Konfiqurasiya olunan planlar, lakin versiyalaşdırılmış qaydalar

Trading partner commission software marketinq komandasına sərbəst formula redaktəsi imkanı verə bilər, amma artıq yaranmış qazancı gizlicə yenidən yazmamalıdır. Bunun üçün commission plan və plan version anlayışlarını ayırın.

Planın içində partner səviyyəsi, instrument qrupu, account tipi, region, client segmenti, minimum aktivlik, payout valyutası, hold müddəti və formula parametrləri olur. Yeni kommersiya şərti tətbiq ediləndə mövcud versiya bağlanır, yeni versiya gələcək effective date ilə yaradılır. Hər earning event hesablanarkən istifadə edilmiş plan versiyasını daşıyır.

Dəstəklənə bilən komissiya modelləri

  • Lot və ya notional həcmi üzrə sabit məbləğ;
  • Brokerin müəyyən etdiyi eligible revenue üzrə faiz;
  • Instrument, account tier və ya regiona görə fərqli rate;
  • Master IB və sub-IB arasında açıq bölüşdürülən çoxsəviyyəli model;
  • Minimum threshold, cap və ya aylıq tier ilə şərtlənən model;
  • Trading fəaliyyəti və ilk kvalifikasiya olunmuş maliyyə hadisəsini birləşdirən hibrid plan.

“Revenue” termini plan daxilində dəqiq təyin edilməlidir. Məsələn, gross commission, net trading fee, spread mark-up, swap gəliri və ya rebates çıxıldıqdan sonrakı məbləğ eyni anlayış deyil. Formula həm input sahələrini, həm yuvarlaqlaşdırma qaydasını, həm də mənfi düzəlişin davranışını açıq göstərməlidir.

Dəyişdirilməz earning event modeli qurun

Ən etibarlı modeldə trade execution, trading fee posted, deposit settled, rebate posted, correction və reversal kimi mənbə hadisələri komissiya mühərrikinə daxil olur. Mühərrik atribusiyanı və həmin tarixdə qüvvədə olan plan versiyasını tapır, sonra earning event yaradır.

Earning event minimum olaraq source event ID, client və account ID-ləri, partner ID, plan version, formula inputları, hesablanmış məbləğ, valyuta, status və yaranma vaxtını saxlamalıdır. Source event təkrar çatdırılarsa idempotency açarı ikinci qazanc yaratmağın qarşısını almalıdır.

Trade sonradan ləğv olunarsa və ya broker fee korreksiyası gələrsə, əvvəlki earning sətrini silməyin. Ona bağlı reversal və ya adjustment event yaradın. Bu yanaşma partner ekranında “nəyə görə balans dəyişdi?” sualına cavab verir və maliyyə komandası üçün payout reconciliation prosesini mümkün edir.

Təsdiq, hold və payout workflow-u

Komissiyanın hesablanması onun dərhal ödənilməsi demək deyil. Praktik status axını belə ola bilər: calculated → pending review/hold → approved → payable → paid. Lazım olduqda disputed, rejected, reversed və expired vəziyyətləri də ayrıca saxlanılır.

Approval qaydaları riskli kombinasiyaları növbəyə göndərə bilər: yeni partnerin ilk payout-ı, böyük məbləğ, qeyri-adi trading həcmi, eyni ödəniş vasitəsi ilə çox account, chargeback-dən sonra yaranan gəlir və ya manual atribusiya dəyişikliyi. Admin yalnız “approve” düyməsinə basmamalı; qərarın səbəbini, icraçını və timestamp-i audit log-a yazmalıdır.

Payout batch yaradılarkən sistem approved earning-ləri seçir, hold-ları və dispute-ları xaric edir, partner üzrə net payable məbləğini hesablayır və payout reference yaradır. Bank, wallet və ya payment provider nəticələri geri gəldikdə batch statusu reconciliation ilə yenilənir. “Paid” statusu sadəcə export faylının yaradılması deyil, faktiki ödənişin uyğunlaşdırılması olmalıdır.

Partner portalında hansı hesabatlar olmalıdır?

IB portal development for brokers şəffaf, amma məxfiliyə uyğun görünüş tələb edir. Partner bütün daxili margin və ya digər partner məlumatlarını görməməlidir. Onun portalında öz müqaviləsinə uyğun aqreqasiya, source məlumatı və izah edilə bilən statuslar olmalıdır.

  • Referral funnel: klik, lead, qeydiyyat, KYC statusu və aktiv trading account;
  • Aktiv müştəri və eligible trading volume;
  • Pending, approved, payable və paid qazanc;
  • Tarix, account qrupu, instrument və plan üzrə breakdown;
  • Adjustment və reversal səbəbləri;
  • Payout tarixçəsi, reference və sənəd yükləmələri;
  • Vergi, invoicing və ya compliance sənədləri üçün tələb olunan məlumatlar.

Hesabatlarda hər rəqəmin drill-down yolu olmalıdır: summary → earning event → source event → tətbiq edilən plan versiyası. Bununla partner support komandası və maliyyə əməliyyatları eyni faktlar üzərindən danışır.

İnteqrasiya və nəzarət checklist-i

  1. Trading platformadan execution, fee, correction və account status event-lərini müəyyən edin.
  2. CRM, KYC və back-office-dən client identity və eligibility statuslarını normallaşdırın.
  3. Partner, client və trading account ID-ləri arasında sabit mapping yaradın.
  4. Commission planlarını versiyalaşdırın; tarixçəni overwrite etməyin.
  5. Source event-lər, earning-lər, approval-lar və payout-lar üçün audit trail saxlayın.
  6. Duplicate event, gecikmiş callback, partial failure və replay ssenarilərini test edin.
  7. Gündəlik source-system totals ilə earning və payout total-larını reconciliation edin.
  8. Role-based access, export icazələri və həssas payout məlumatları üçün nəzarət tətbiq edin.

Komissiya sistemi ayrıca “marketing əlavəsi” deyil; trading məhsulunun maliyyə əməliyyatlarına toxunan bir moduludur. Onu ledger, fee engine, KYC statusları və payout prosesindən təcrid etmədən qurmaq daha az dispute, daha sürətli əməliyyat araşdırması və partner üçün daha inandırıcı şəffaflıq yaradır.

POLADO ilə IB komissiya sisteminin scope-u

POLADO mövcud broker və trading məhsullarında atribusiya modeli, commission planları, event inteqrasiyaları, partner portalı, back-office queue-ları və payout reconciliation üzrə texniki scope hazırlaya bilər. Əvvəlcə data mənbələrini, istisnaları və məsul komandaları xəritələndirmək, sonra isə ölçülə bilən mərhələlərlə implementasiya etmək vacibdir. Əlaqəli trading əməliyyatlarında audit, inteqrasiya və idarə olunan release ehtiyacları üçün texniki dəstək və konsaltinq xidmətindən də yararlana bilərsiniz.

Trading məhsulunuz üçün partner modelini, mövcud API-ləri və payout prosesini müzakirə etmək istəyirsinizsə, POLADO ilə əlaqə saxlayın. Məqsəd sadəcə referral ekranı yox, qaydaları izah edilə bilən və maliyyə komandası tərəfindən uzlaşdırıla bilən komissiya infrastrukturu yaratmaqdır.