Trading platform KYC onboarding development zamanı əsas məqsəd “doğrulandı” cavabını almaq deyil; hər müştərinin hansı imkanlardan istifadə edə biləcəyini etibarlı, izah edilə bilən və idarə oluna bilən şəkildə müəyyən etməkdir. Məhsulun daxili hesab vəziyyətini KYC provayderinin texniki nəticəsi ilə eyniləşdirmək əksər problemlərin başlanğıcıdır. Provayder bir sessiya üçün processing, requires input və ya verified qaytara bilər. Platforma isə paralel olaraq profil tamlığı, müştəri tipi, risk və əməliyyat qaydaları, review qərarı və hesabın aktivlik səviyyəsini idarə etməlidir.

Yaxşı dizayn edilmiş flow legitim istifadəçini sistem səhvi, gecikmiş webhook və ya operator növbəsi səbəbilə lazımsız bloklamır. Eyni zamanda, aktivləşmə tələbləri tamamlanmamış hesabın depozit, çıxarış, order göndərişi və ya leverage dəyişməsi kimi əməliyyatlara keçməsinə imkan vermir. POLADO bu tip məhsul axınlarını FinTech və trading sistemləri xidməti çərçivəsində back-office, API inteqrasiyaları və əməliyyat nəzarətləri ilə birlikdə layihələndirir.

Bir status sahəsi kifayət deyil: üç ayrı vəziyyət qatı yaradın

Bir çox ilkin versiyada kyc_status = approved | pending | rejected sahəsi olur. Bu, istifadəçi sayı və istisnalar artdıqda kifayət etmir. Daha dayanıqlı model üç müstəqil qat saxlayır.

1. Provayder sessiyası və sübutların emalı

Bu qat yalnız inteqrasiya faktlarını saxlayır: provayder adı, xarici sessiya ID-si, attempt nömrəsi, alınma vaxtı, provayder statusu, səbəb kodu, webhook ID-si və sənədin texniki nəticəsi. Məsələn, istifadəçi passport yükləyib, sessiya processing vəziyyətində ola bilər; bu hələ daxili “gözləyir” qərarı deyil. Bir istifadəçinin bir neçə cəhdi ola biləcəyindən attempt-ləri ayrıca obyekt kimi saxlamaq lazımdır.

2. Daxili uyğunluq və review qərarı

Bu qat daxili iş axınını ifadə edir: not_started, awaiting_customer, queued_for_review, in_review, approved, declined, expired və superseded. Burada qərarı kimin verdiyi, hansı qayda və ya səbəb əsasında verildiyi, əlavə məlumatın nə vaxt istəndiyi və növbəti addım qeyd edilir. Provayderin “verified” nəticəsi bəzi məhsullarda avtomatik təsdiq üçün giriş siqnalı, digərlərində isə yalnız manual review üçün yetərli məlumat ola bilər.

3. Hesab imkanları və aktivləşmə vəziyyəti

Hesabın məhsul icazələri ayrıca model olmalıdır. Məsələn: can_view_market_data, can_create_demo_account, can_fund, can_withdraw, can_trade, can_use_margin. Bu yanaşma “KYC keçildi = bütün funksiyalar açıldı” kimi riskli sadələşdirməni aradan qaldırır. İcazələr aktiv review qərarından, hesab tipindən, uyğunluq anketindən və platformanın məhsul siyasətindən hesablana bilər.

Provayder statusu xarici faktı, review statusu daxili qərarı, capability modeli isə məhsulun icazəsini göstərir. Bu üç anlayış bir sütunda birləşdirilməməlidir.

Praktik onboarding vəziyyət maşını

İstifadəçi üçün sadə ekran lazımdır, amma backend daha dəqiq transition-ları dəstəkləməlidir. Faydalı minimum lifecycle aşağıdakı kimidir:

  1. Draft: istifadəçi hesab yaradır, lakin əsas profil məlumatları tamamlanmayıb.
  2. Identity required: məhsul aktivləşmə üçün doğrulama istəyir; istifadəçiyə konkret addım göstərilir.
  3. Submitted / processing: sənəd və ya məlumat göndərilib, xarici nəticə gözlənilir.
  4. Action required: foto keyfiyyəti, etibarsız sənəd, uyğunsuz ad və ya çatışmayan məlumat səbəbilə istifadəçi addımı tələb olunur.
  5. Review queued: qayda əsasında və ya provayder nəticəsinə görə iş compliance növbəsinə düşür.
  6. Under review: operator işi üzərinə götürüb; istifadəçiyə yalnız gözləməli olduğu bildirilir.
  7. Approved: daxili aktivləşmə qaydaları hesablanır və uyğun imkanlar açılır.
  8. Declined: həmin attempt bağlanır; mümkün olduqda təhlükəsiz, aydın və aksiya yönümlü səbəb kateqoriyası göstərilir.
  9. Expired: istifadəçi flow-u vaxtında tamamlamayıb və ya sessiya artıq istifadə oluna bilməz; yeni attempt yaradıla bilər.

Failed və declined eyni şey deyil. “Failed” çox vaxt texniki və ya istifadəçi düzəldə biləcəyi nəticəni bildirir: OCR oxumadı, sənəd kadrdan kənardadır, selfie çəkilişi uğursuz oldu. “Declined” isə daxili iş axınında bağlanmış qərardır. Bu fərq support müraciətlərini, yenidən cəhd UX-ini və operator işini xeyli yaxşılaşdırır.

Aktivləşməni webhook-a birbaşa bağlamayın

KYC provayderindən gələn webhook mühüm siqnaldır, lakin hesabı birbaşa aktivləşdirən tək əməliyyat olmamalıdır. Webhook təkrarlana, sıradan kənar çata və ya keçici olaraq alınmaya bilər. Endpoint imzanı yoxlamalı, xam payload-u məhdud girişli saxlamalı, event ID-ni deduplikasiya etməli və emalı idempotent etməlidir. Sonra event ayrıca işçi tərəfindən emal olunaraq daxili attempt yenilənir, review qaydaları icra edilir və capability recalculation işi növbəyə qoyulur.

Məsələn, “verified” event-i iki dəfə gəlsə, ikinci emal yeni aktivləşmə e-maili, ikinci audit yazısı və ya təkrar wallet yaratmamalıdır. Eyni qayda operatorun “approve” düyməsi üçün də keçərlidir: transaction daxilində qərar, audit hadisəsi və capability yenilənməsi ya birlikdə tamamlanmalı, ya da bərpa edilə bilən outbox mexanizmi ilə ötürülməlidir.

Manual review növbəsi operatorun işləyə biləcəyi məhsul olmalıdır

FinTech verification queue sadəcə filtrli cədvəl deyil. Operatorun qərar üçün lazım olan konteksti eyni yerdə görməsi lazımdır: müştəri ID-si, hesab tipi, yaş, ölkə və ya segment kimi icazəli əməliyyat məlumatları, aktiv attempt, provayder nəticəsi, səbəb kodu, əvvəlki attempt-lər, açıq sorğular, SLA yaşı və audit tarixçəsi. Məlumatı mümkün qədər maskalayın; sənəd görüntüsü və həssas PII üçün rol əsaslı, əsaslandırılmış giriş tətbiq edin.

Növbə dizaynı üçün faydalı funksiyalar

  • Prioritet, yaşlanma, məhsul və səbəb kateqoriyası üzrə filtrləmə və sıralama.
  • Atomic “claim” əməliyyatı: iki operatorun eyni işi paralel qərarlaşdırmaması üçün.
  • Approve, decline, request information, reassign və escalate kimi məhdud transition-lar.
  • Standart səbəb kodları və istifadəçiyə göstərilən ayrıca, təhlükəsiz mesaj şablonları.
  • Qərar zamanı istifadə olunan qayda versiyası, operator ID-si, vaxt möhürü və əvvəl/sonra snapshot-ları.
  • İşçinin daxili qeydi ilə müştəriyə görünən mesajın ayrılması.

Əgər komandada əlavə yoxlama və ya dörd-göz prinsipi tələb olunan hallar varsa, “reviewer qərarı” ilə “account activation approval” addımını ayrı icazələrə bölün. Bu, bütün müştərilər üçün ağır proses yaratmadan seçilmiş istisnalar üçün istifadə oluna bilər. Operasional ekranların sadəliyi və səhv ehtimalının azaldılması üçün UI/UX və məhsul dizaynı işi compliance komandasının real qərar prosesindən başlamalıdır.

İstifadəçini bloklamadan təhlükəsiz məhdudiyyətlər tətbiq edin

Onboarding-in məqsədi hər şeyi dərhal bağlamaq deyil; mərhələyə uyğun ən az məhdudiyyətlə təhlükəsiz irəliləyiş yaratmaqdır. Məsələn, draft hesab bazar məlumatlarını və demo mühiti görə bilər, amma real order göndərə bilməz. “Processing” hesabında istifadəçi profilini tamamlaya və yardım mərkəzinə keçə bilər, lakin pul hərəkəti və canlı ticarət açılmır. “Action required” ekranı sadəcə “uğursuz oldu” deməməli, istifadəçinin indi nə edəcəyini izah etməlidir: yeni sənəd təqdim et, məlumatı düzəlt və ya support-a müraciət et.

Bu qaydaları frontend-də gizlədilmiş düymələr kimi deyil, backend policy enforcement kimi tətbiq edin. Order API, funding API, withdrawal API və mobil tətbiq endpoint-ləri hər sorğuda server tərəfdən capability-ni yoxlamalıdır. Ticarət əməliyyatlarının digər risk nəzarətləri ilə birlikdə işləməsi barədə daha geniş yanaşma üçün FT10 kimi FinTech layihə istiqamətlərinə baxmaq faydalıdır.

Audit tarixi, məlumat saxlanması və müşahidəolunma

Audit log “status dəyişdi” səviyyəsində qalmamalıdır. Hər hadisə üçün entity tipi və ID-si, actor tipi (istifadəçi, operator, sistem, webhook), actor ID-si, correlation ID, əvvəlki və yeni vəziyyət, səbəb kodu, policy/rule versiyası, zaman və əlaqəli xarici event ID-si saxlanmalıdır. Dəyişməz event jurnalından cari vəziyyəti ayrıca projection kimi hesablamaq, həm araşdırma, həm də backfill üçün faydalıdır.

Sənəd şəkillərini, tam identifikasiya məlumatlarını və provider payload-larını ümumi tətbiq loglarına yazmayın. Access log-larını da audit edin. Məxfilik, retention və redaction davranışı seçilmiş provayder, yurisdiksiya və şirkət siyasətinə uyğun konkretləşdirilməlidir; bu məqalə hüquqi və ya tənzimləyici məsləhət deyil.

Release-dən əvvəl test siyahısı

  • Eyni webhook iki dəfə, gecikmiş və fərqli ardıcıllıqla gəldikdə nəticə dəyişmirmi?
  • Provayder müvəqqəti əlçatmaz olduqda istifadəçi səhvən declined görünmürmü?
  • Yeni attempt köhnə attempt-in nəticəsini və ya təsdiqini təsadüfən əvəz etmir ki?
  • Review queue-da iki operator eyni işi eyni vaxtda təsdiqləyə bilirmi?
  • “Approved” qərarından əvvəl order, funding və withdrawal endpoint-ləri server tərəfdən bağlanırmı?
  • Əməliyyat qərarı və capability dəyişməsi audit tarixçəsində izah edilə bilirmi?
  • Support əməkdaşı PII görmədən istifadəçiyə növbəti addımı deyə bilirmi?
  • İstifadəçi uyğunsuzluq və ya sənəd keyfiyyəti problemi zamanı yenidən cəhd yolunu aydın görürmü?

Broker və ya trading məhsulunuz üçün KYC workflow development planlaşdırırsınızsa, ilk addım ekranlar deyil: vəziyyət maşını, capability matrix, exception queue, inteqrasiya contract-ları və failure ssenariləridir. POLADO komandası mövcud onboarding axınını audit edə, provayder inteqrasiyasını və back-office-i layihələndirə, sonra isə təhlükəsiz release planı qura bilər. Layihənizi müzakirə etmək üçün əlaqə saxlayın.