KYB workflow
KYB workflow वर्तमान customer, related-party, capability, task, submission, और document resources को business और उसके ownership की नीति समीक्षा के साथ जोड़ता है।वर्तमान workflow sequence
1. Business customer बनाएँ
Business customer कोPOST /v3/customers के साथ बनाएँ। वर्तमान customer को GET /v3/customers/{customerId} के साथ पढ़ें।
2. Related parties बनाए रखें
वर्तमान parties की समीक्षा के लिएGET /v3/customers/{customerId}/related-parties, एक बनाने के लिए POST /v3/customers/{customerId}/related-parties, और आपूर्ति किए गए facts को update करने के लिए PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} का उपयोग करें।
वर्तमान tasks द्वारा अनुरोधित direct owners, parent entities, UBOs, control persons, directors, officers, और signers को बनाए रखें। उनकी roles अलग हैं।
3. Eligible capability खोजें और अनुरोध करें
GET /v3/customers/{customerId}/capabilities/supported पढ़ें। POST /v3/customers/{customerId}/capabilities/{capabilityId} का उपयोग करके केवल तब available या beta capability का अनुरोध करें जब customer eligible हो।
4. वर्तमान tasks पढ़ें
वर्तमान work कोGET /v3/customers/{customerId}/tasks के साथ सूचीबद्ध करें। प्रत्येक actionable task को GET /v3/customers/{customerId}/tasks/{taskId} के माध्यम से प्राप्त करें, फिर इसकी वर्तमान revision, requirements, और sessions से अगली action निकालें।
5. वर्तमान task द्वारा अनुरोधित documents upload करें
एक अनुरोधित file कोPOST /v3/customers/{customerId}/documents के साथ upload करें। वर्तमान task निर्धारित करता है कि क्या एक document आवश्यक है और इसके स्वीकृत type, count, या format को narrow कर सकता है।
6. पूर्ण task answers submit करें
वर्तमान task revision के लिए एक पूर्ण answer setPOST /v3/customers/{customerId}/tasks/{taskId}/submissions के साथ submit करें। वर्तमान requirement ids का उपयोग करें और uploaded document ids को केवल वहीं संदर्भित करें जहाँ task पूछता है।
7. वर्तमान resources की निगरानी करें
प्रत्येक action या event के बाद, customer कोGET /v3/customers/{customerId}, capability को GET /v3/customers/{customerId}/capabilities/{capabilityId}, उसके applications को GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications, और किसी भी वर्तमान tasks को पुन: प्राप्त करें।
पूर्ण mechanics के लिए, business onboarding, Capabilities और tasks, और Integration Documents guide देखें।
Enhanced due diligence (EDD) triggers
निम्न के लिए EDD आवश्यक हो सकता है:- High-risk jurisdictions
- High-risk verticals, जिसमें gaming, trading, और crypto exchanges शामिल हैं
- जटिल ownership structures
- लागू thresholds से अधिक अपेक्षित मासिक volume
- Sanctioned देशों से जुड़े Operations
नीति समीक्षा outcomes
Outcome: KYB approval, caps के साथ conditional approval, या rejection। ये नीति समीक्षा outcomes हैं, वर्तमान API status values नहीं। एक conditional नीति निर्णय “conditional approval” नामक status बनाए बिना वर्तमान resources के माध्यम से प्रतिबिंबित हो सकता है।Verification timeline
ये अवधि विशिष्ट नीति अनुमान हैं, गारंटीकृत API व्यवहार नहीं।
सामान्य rejection कारण
नीति terms और API states
नीति निर्णयों को वर्तमान resource 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