Skip to main content

Verification status और workflow

नीति-facing KYC यात्रा जानकारी collection से review के माध्यम से approval या rejection निर्णय तक जाती है। वर्तमान API resources अलग capability, application, task, और submission lifecycles उजागर करते हैं।
नीति समीक्षा labels और timing अनुमान API behavior को परिभाषित नहीं करते। नीचे दिए गए labels से एक state machine implement न करें।

नीति-facing समीक्षा concepts

ये नीति-facing समीक्षा concepts onboarding यात्रा का वर्णन करते हैं। वे वर्तमान API enums, webhook values, या गारंटीकृत transitions नहीं हैं। इन labels का उपयोग केवल तब करें जब नीति यात्रा पर चर्चा हो। जब तक कोई वर्तमान generated schema स्पष्ट रूप से अपने संदर्भ में उसी value की माँग न करे, इन्हें वर्तमान status values के रूप में न भेजें।

Standard KYC review flow

  1. Individual customer बनाएँ।
  2. एक eligible capability खोजें और अनुरोध करें।
  3. वर्तमान task detail पढ़ें।
  4. Customer को एक first-party hosted verification session पर भेजें या task द्वारा अनुरोधित पूर्ण task answers submit करें।
  5. Review चलने दें जबकि वर्तमान resources अपनी स्वयं की review states रिपोर्ट करते हैं।
  6. यह निर्धारित करने के लिए वर्तमान resources को पुन: प्राप्त करें कि क्या अधिक action आवश्यक है या capability ready, restricted, rejected, या canceled है।
नीति यात्रा इसे not started, pending verification, under review, और फिर approved या rejected के रूप में वर्णित कर सकती है। वे terms API transition sequence को परिभाषित नहीं करते।

Enhanced KYC review flow

  1. वर्तमान में अनुरोधित standard identity और liveness work पूरा करें।
  2. जब enhanced review अतिरिक्त जानकारी का अनुरोध करता है तो नवीनतम task पढ़ें।
  3. वर्तमान hosted session या task submission के माध्यम से अनुरोधित proof of address, proof of funds, या अन्य evidence प्रदान करें।
  4. Documents केवल तब upload करें जब वर्तमान task पूछता है।
  5. Manual review के दौरान वर्तमान resources की निगरानी जारी रखें।
  6. वर्तमान capability, application, task, और submission states के आधार पर रुकें या जारी रखें।
Compliance team customer के registered email address के माध्यम से enhanced review का coordination भी कर सकती है।

सामान्य rejection कारण

Verification timeline

ये अवधि विशिष्ट नीति अनुमान हैं, गारंटीकृत API behavior नहीं।

वर्तमान API state vocabularies

वर्तमान resources अलग closed vocabularies का उपयोग करते हैं:
  • Capability status: pending, ready, restricted, rejected, canceled
  • Application status: requested, in_review, action_required, ready, rejected, disabled, canceled
  • Task status: action_required, in_review, satisfied, rejected, canceled
  • Submission outcome: in_review, accepted, changes_requested, rejected
इन vocabularies को एक verification status में collapse न करें।

Events और वर्तमान state

वर्तमान में दस्तावेज़ीकृत Webhooks को change notifications के रूप में उपयोग करें, फिर वर्तमान customer, capability, application, और task resources को पुन: प्राप्त करें। Events प्रामाणिक resource reads का स्थान नहीं लेते, और कोई नीति-facing label किसी विशेष event का संकेत नहीं देता। वर्तमान action loop के लिए Capabilities और tasks देखें।

Support

KYC नीति प्रश्नों के लिए, compliance@swipelux.com से संपर्क करें। API issues के लिए, support@swipelux.com से संपर्क करें।