Trading platform account management development brokerin və ya trading məhsulunun KYC nəticəsini real, təhlükəsiz və idarə olunan ticarət imkanına çevirməsidir. Bu qat sadəcə “hesab yarat” API-si deyil. O, müştəri profilini, hüquqi və risk məhdudiyyətlərini, trading server hesabını, maliyyə ledgeri və back-office iş proseslərini bir-birinə bağlayan həyat dövrü idarəetmə sistemidir.

Düzgün qurulmuş sistemdə hesabın hansı statusda olduğu, hansı trading qrupuna aid edildiyi, hansı alətlərdə ticarət edə bildiyi, leverage-in niyə dəyişdiyi və bu dəyişikliyi kimin təsdiqlədiyi istənilən anda aydın olmalıdır. Bu, xüsusilə çoxsaylı hesab, bir neçə server, müxtəlif yurisdiksiya və ya fərqli məhsul xətləri olan platformalarda vacibdir.

Hesab idarəetməsi KYC-dən və order idarəetməsindən nə ilə fərqlənir?

KYC onboarding şəxsin və ya şirkətin identifikasiyası, sənəd yoxlaması və uyğunluq qərarı ilə məşğul olur. Account management isə təsdiqlənmiş müştəri üçün trading hesabının faktiki imkanlarını yaradır və idarə edir. Order management order-in qəbulundan fill, cancel və reconciliation mərhələlərinədək olan icra həyat dövrünü izləyir. Margin mühərriki isə açıq mövqelərin təminat tələblərini hesablayır.

Hesab idarəetməsi bu komponentlərin arasında siyasət və reyestr rolunu oynayır: “Bu müştəriyə hansı hesablar verilə bilər?”, “Bu hesabda hansı simvollar aktivdir?”, “Leverage dəyişikliyi növbəti əməliyyatdan nə vaxt qüvvəyə minir?” və “Suspended hesabda hansı əməliyyatlar qadağandır?” kimi suallara cavab verir.

POLADO belə məhsulları FinTech və trading sistemləri xidməti çərçivəsində trading server, CRM, risk xidməti və back-office ilə inteqrasiya olunan idarəetmə qatları kimi layihələndirir. FinTech yönümlü məhsul nümunələri üçün FT10 və ESFX layihələrinə baxa bilərsiniz.

Hesab həyat dövrünü açıq state machine kimi qurun

Statusları sərbəst mətn və ya bir neçə boolean sahə ilə idarə etmək təhlükəlidir. Məsələn, is_active, is_verified və is_blocked kombinasiyası ziddiyyətli vəziyyətlər yarada bilər. Bunun əvəzinə icazə verilən keçidləri olan formal state machine istifadə edin.

Nümunə hesab statusları

  • requested — hesab tələbi qəbul olunub, provisioning başlamayıb;
  • pending_review — KYC, uyğunluq və ya əməliyyat yoxlaması gözlənilir;
  • provisioning — trading serverdə hesab açılır və konfiqurasiya edilir;
  • ready — texniki olaraq yaradılıb, lakin hələ ticarətə açılmayıb;
  • active — giriş və ticarət qaydaları imkan verdiyi həddə aktivdir;
  • trading_restricted — giriş, hesabat və ya vəsait əməliyyatları mümkündür, amma yeni order qadağandır;
  • suspended — risk, uyğunluq və ya əməliyyat araşdırması üçün müvəqqəti məhdudlaşdırılıb;
  • closing — yeni fəaliyyət dayandırılıb, açıq mövqelərin bağlanması və balans yoxlanması gözlənilir;
  • closed — hesab bağlanıb və yeni konfiqurasiya dəyişiklikləri qəbul etmir.

Hər keçid üçün ayrıca qaydalar olmalıdır. Məsələn, active → suspended risk əməkdaşının qərarı ilə dərhal tətbiq oluna bilər; suspended → active isə səbəb kodu, rəy və bəzən ikinci təsdiq tələb edə bilər. closed → active keçidi adətən qadağan olunmalıdır: yeni hesab açmaq və köhnə hesabı tarixi reyestr kimi saxlamaq daha etibarlıdır.

Trading qrupları konfiqurasiya paketidir, etiket deyil

Trading group bir çox sistemdə sadəcə “Retail EUR” və ya “Professional USD” adı ilə görünür. Əslində o, hesabın əməliyyat siyasətini müəyyən edən versiyalanmış konfiqurasiya paketidir. Qrupa valyuta, leverage intervalı, aktiv alətlər, order həcmi limitləri, komissiya və swap planları, trading sessiyaları, stop-out siyasəti, market-data entitlement-ları və execution routing parametrləri daxil ola bilər.

Vacib qayda: hesab qrupun cari qiymətlərini dinamik oxumamalıdır. Hesab üçün tətbiq olunan qrup versiyası saxlanmalıdır. Əks halda administrator qrupda kiçik dəyişiklik edəndə minlərlə hesabın şərti xəbərdarlıq və təsdiq olmadan dəyişə bilər.

Konfiqurasiya modelinin minimum hissələri

  • group_template — biznes tərəfindən tanınan qrup identifikatoru;
  • group_version — dəyişməz qayda dəsti və qüvvəyə minmə tarixi;
  • account_assignment — hesabın hansı versiyaya, hansı tarixdən bağlandığı;
  • instrument_policy — simvol, asset class, sessiya və ya məhsul üzrə icazələr;
  • exception_policy — konkret hesab üçün əsaslandırılmış istisna;
  • approval_record — dəyişikliyi kimin istədiyi, kimin təsdiqlədiyi və əsaslandırması.

Leverage, baza valyutası və alət hüquqları necə dəyişdirilməlidir?

Leverage dəyişikliyi təkcə profil sahəsinin yenilənməsi deyil. Açıq order və mövqeləri olan hesabda bu dəyişiklik margin tələbini, mövcud risk səviyyəsini və brokerin exposure limitini təsirləndirə bilər. Buna görə sistem dəyişiklikdən əvvəl hesabın açıq mövqelərini, pending order-lərini, equity və istifadə olunan margin-i yoxlamalı; risk mühərrikindən qiymətləndirmə almalı; sonra isə ya planlı tətbiq vaxtı təyin etməli, ya da təhlükəsiz şəkildə rədd etməlidir.

Baza valyutasının dəyişdirilməsi daha da həssasdır. Balans, ledger posting-ləri, statement-lər, fee hesablamaları və trading server məhdudiyyətləri nəzərə alınmadan “USD-dən EUR-a dəyiş” əməliyyatı aparmaq olmaz. Bir çox platformada bu, faktiki olaraq yeni hesab açılması və köhnə hesabın nəzarətli bağlanması deməkdir.

Alət hüquqları da server tərəfində tətbiq edilməlidir. UI-də gizlədilən simvol təhlükəsizlik nəzarəti deyil. API və trading gateway order qəbulunda hesabın aktiv statusunu, group versiyasını, instrument entitlement-ını və risk məhdudiyyətini yenidən yoxlamalıdır.

İnteqrasiya sərhədlərini əvvəlcədən müəyyən edin

Etibarlı arxitekturda hər sistemin sahib olduğu məlumat dəqiq göstərilir:

  • Identity/KYC: şəxsiyyət, sənəd yoxlaması, uyğunluq qərarı və risk atributları;
  • CRM: lead, münasibət meneceri, satış mənşəyi və kommunikasiya konteksti;
  • Account management: hesab reyestri, status keçidləri, qrup təyinatı, hüquqlar və audit;
  • Trading server: server hesabı, login/credential, execution parametrləri, mövqe və order faktları;
  • Risk sistemi: exposure, limit yoxlaması, məhdudlaşdırma qərarı və kill-switch siqnalları;
  • Ledger: dəyişməz pul hərəkətləri, balans mənbəyi və maliyyə reconciliation-u.

Account management ledger-in yerinə balans saxlamamalı, trading serverin yerinə mövqe mənbəyi olmamalıdır. Lakin hər hesabın daxili ID-si, trading-server ID-si, CRM əlaqəsi və ledger wallet/hesab əlaqəsi vahid identifikasiya xəritəsində görünməlidir.

Duplicate provisioning və təhlükəli dəyişikliklərdən qorunma

Praktik problemlər çox vaxt şəbəkə timeout-u və ya operatorun təkrar klikindən başlayır. Provisioning sorğusunda sabit idempotency key istifadə edin. Server cavabı itibsə, sistem yeni hesab yaratmaq əvəzinə eyni açarı, xarici sorğu identifikatorunu və trading serverdəki mövcud əlaqəni yoxlamalıdır.

İmtiyazlı əməliyyatları command kimi saxlayın: “leverage 1:100-dən 1:500-ə dəyiş”, “qrupu dəyiş”, “ticarəti suspend et”. Command-a köhnə və yeni dəyərlər, səbəb kodu, tələb edən istifadəçi, təsdiqləyən istifadəçi, correlation ID, təsirə məruz qalan hesablar, server cavabı və vaxt damğaları daxil olmalıdır. Yüksək riskli dəyişikliklərdə maker-checker, yenidən autentifikasiya və tətbiqdən əvvəl risk preview tətbiq edin.

Audit izi və release checklist

Audit log sadəcə “admin updated account” sətri olmamalıdır. O, kim, nəyi, hansı səlahiyyətlə, hansı köhnə/yeni dəyərlərlə, hansı request və approval kontekstində dəyişdirdi suallarını cavablandırmalıdır. Loglar dəyişməz saxlanmalı, axtarışa yararlı olmalı və əməliyyat hadisələri ilə əlaqələndirilməlidir.

  • Status keçid matrisi və qadağan keçid testləri hazırdırmı?
  • Provisioning retry-ları duplicate server hesabı yaratmırmı?
  • Group versiyası hesab tarixçəsində qorunurmu?
  • Leverage və instrument dəyişiklikləri server, risk və UI arasında eyni görünürmü?
  • Suspension yeni order-ləri bütün giriş nöqtələrində bloklayırmı?
  • Hər imtiyazlı dəyişiklikdə actor, reason, approval və before/after snapshot varmı?
  • Trading server və ledger ilə gündəlik reconciliation istisnaları növbəyə düşürmü?

Hesab həyat dövrünü yenidən qurarkən məqsəd sadəcə daha sürətli provisioning deyil; nəzarət edilə bilən, bərpa oluna bilən və izah edilə bilən əməliyyat modelidir. POLADO komandası mövcud trading server və back-office məhdudiyyətlərini xəritələndirib, state modelini, inteqrasiya müqavilələrini, admin workflow-larını və təhlükəsiz miqrasiya planını hazırlamaq üçün konsultasiya verə bilər.