कंपनी के बैलेंस, पेमेंट, कार्ड और approvals एक ही workspace में मैनेज करें।
stablecoin पेमेंट्स के लिए इंटरनल कंट्रोल्स
वह control framework जो auditors पहले से मांग रहे हैं, blockchain की नहीं बल्कि disbursement cycle की भाषा में।
स्टेबलकॉइन पेमेंट पर कंट्रोल के उद्देश्य वही हैं जो वायर पर कंट्रोल के होते हैं: ऑथराइज़ेशन, सटीकता और एसेट की सुरक्षा। लेकिन ये कंट्रोल बाद में पकड़ने वाले नहीं, पहले से रोकने वाले होने चाहिए, क्योंकि सेटलमेंट वापस नहीं हो सकता। व्यवहार में इसका मतलब है व्हाइटलिस्टेड डेस्टिनेशन, ज़िम्मेदारियों का बंटवारा, राशि के हिसाब से अप्रूवल कोरम, रिलीज़ से पहले स्क्रीनिंग, और ऐसा एविडेंस रिकॉर्ड जो पॉलिसी, अप्रूवर और ट्रांज़ैक्शन hash को एक साथ जोड़ता है।
Control matrix
| जोखिम | कंट्रोल | तैयार सबूत |
|---|---|---|
| हमलावर के दिए address पर भुगतान | काउंटरपार्टी रिकॉर्ड पर डेस्टिनेशन whitelist; बदलाव फिर से अप्रूव होते हैं | रिक्वेस्टर, अप्रूवर और टाइमस्टैम्प के साथ चेंज लॉग |
| अनधिकृत भुगतान | जिम्मेदारियों का बँटवारा: preparer release नहीं कर सकता | पेमेंट पर रिक्वेस्टर और अप्रूवर की अलग-अलग पहचान |
| एक compromised डिवाइस | MPC quorum signing: m-of-n approvals | सिग्नेचर सेट ट्रांज़ैक्शन के साथ सेव |
| sanctions उल्लंघन | intent पर screening, hit पर release रोकें | hash से पहले timestamp वाला screening नतीजा |
| डेलीगेटेड अथॉरिटी से बढ़कर वैल्यू | राशि, asset और counterparty के हिसाब से tiered limits | भुगतान पर लागू पॉलिसी वर्ज़न |
| कंट्रोल का चुपचाप कमज़ोर होना | सिर्फ़ Admin पॉलिसी बदल सकते हैं, पूरे quorum के साथ | पॉलिसी बदलावों की अपरिवर्तनीय हिस्ट्री |
| वेंडर लॉक-इन / निरंतरता | डॉक्यूमेंटेड key export के साथ self-custody | टेस्ट की हुई recovery प्रक्रिया |
छोटी टीम में जिम्मेदारियों का बँटवारा
सबसे आम आपत्ति यह है कि चार लोगों की finance टीम duties को अलग नहीं कर सकती। कर सकती है, बंटवारा इस आधार पर होता है: action, विभाग के आधार पर नहीं। एक व्यक्ति payment runs तैयार करता है और counterparty register संभालता है। दो अन्य लोगों के पास signing keys हैं और वे approve करते हैं। एक administrator policy का ज़िम्मेदार है, पर payments तैयार नहीं करता। किसी के पास तैयारी का अधिकार और signing keys का बहुमत, दोनों एक साथ नहीं होते। पूरी ज़रूरत बस इतनी ही है।
- Preparer: पेमेंट रन बनाता है, रिलीज़ नहीं कर सकता।
- Approvers: दो या ज़्यादा signers, payee नहीं बना सकते।
- Administrator: पॉलिसी और रोल संभालता है, बदलाव के लिए quorum ज़रूरी।
- Observer: ऑडिटर और CFO के लिए read-only एक्सेस।
एविडेंस पैक तैयार हो रहा है
- 01मौजूदा policy दस्तावेज़: limits, approvers, quorum, whitelisted destinations।
- 02उस अवधि का policy change log, जिसमें दिखता है कि हर बदलाव किसने मांगा और किसने approve किया।
- 03भुगतानों का sample, जिसमें requester, approver, policy version, screening result और hash शामिल हैं।
- 04blocked payment प्रयासों की सूची, इस बात का सबूत कि preventive control काम करता है।
- 05counterparty register, जिसमें हर destination जोड़े और verify किए जाने की तारीख दर्ज है।
- 06मुख्य custody दस्तावेज़, जिनमें recovery प्रक्रिया और उसका पिछला टेस्ट कब हुआ, शामिल है।
- 07अवधि के अंत में on-chain बैलेंस का ledger से reconciliation।
आम कमियां
| हम क्या देखते हैं | यह क्यों फेल होता है | ठीक करें |
|---|---|---|
| एक shared hardware wallet | न segregation, न recovery, न attribution | हर व्यक्ति की अलग key के साथ quorum signing |
| हर हफ्ते screening | रोकथाम नहीं; पेमेंट पहले ही settle हो चुका | intent पर screening, hit पर रोक |
| हर पेमेंट पर एड्रेस पेस्ट करना | एड्रेस बदलना नुकसान की सबसे बड़ी वजह है | Counterparty रिकॉर्ड पर Whitelist |
| Chat थ्रेड में approvals | ट्रांज़ैक्शन से जुड़ा नहीं, आसानी से जाली बन सकता है | साइनिंग के समय approval क्रिप्टोग्राफ़िक रूप से दर्ज |
| कोई भी ऑपरेटर पॉलिसी बदल सकता है | दुरुपयोग से पहले एक्सेस हटाया जा सकता है | सिर्फ़ Admin द्वारा, quorum से मंज़ूर पॉलिसी बदलाव |
Stablerail इसे कैसे लागू करता है
रोल, लिमिट और अप्रूवल कोरम संगठन स्तर पर एक बार सेट होते हैं और हर वॉल्ट पर अपने आप लागू होते हैं। पॉलिसी सिर्फ़ एडमिन बदल सकते हैं, और बदलाव के लिए भुगतान जितना ही साइनिंग कोरम चाहिए। स्क्रीनिंग रिलीज़ से पहले चलती है, और हर भुगतान अपने पॉलिसी वर्ज़न, अप्रूवर, स्क्रीनिंग नतीजे और हैश के साथ एक्सपोर्ट होता है। ऊपर वाला एविडेंस पैक, जोड़ना नहीं पड़ता, अपने आप बनता है।
अक्सर पूछे जाने वाले सवाल
स्टेबलकॉइन पेमेंट्स पर ऑडिटर्स किन इंटरनल कंट्रोल्स की उम्मीद करते हैं?
preparer और approver के बीच जिम्मेदारियों का बँटवारा, राशि के हिसाब से approval quorum, अनुमत destinations की whitelist, execution से पहले sanctions screening का एविडेंस, recovery path के साथ documented key custody, और हर policy या signer बदलाव का immutable log।
क्या SOX क्रिप्टो पेमेंट्स पर लागू होता है?
अगर आप US public filer हैं, तो stablecoin पेमेंट पर कंट्रोल उसी ICFR scope में आते हैं जिसमें कोई भी दूसरा disbursement प्रोसेस आता है। कंट्रोल objectives नहीं बदलते (authorisation, completeness, accuracy, एसेट्स की सुरक्षा), सिर्फ एविडेंस का फॉर्मेट बदलता है।
एक छोटी फाइनेंस टीम के लिए कम से कम कौन से कंट्रोल्स जरूरी हैं?
चार बातें: destinations whitelist हों और हर बदलाव दोबारा approve हो, कोई एक व्यक्ति पेमेंट बनाने और release करने दोनों का काम न करे, release से पहले screening हो, और keys के लिए quorum ज़रूरी हो. दो लोगों की टीम ये चारों चला सकती है; इससे कम में बड़ी रकम भेजनी ही नहीं चाहिए.
ऑन-चेन चलने वाले कंट्रोल का सबूत कैसे दें?
Policy version, requester, approvers की पहचान, screening नतीजा और transaction hash को एक रिकॉर्ड में, इसी क्रम में timestamp के साथ रखें। Auditor hash को स्वतंत्र रूप से verify कर सकता है, जो bank statement से ज़्यादा मज़बूत evidence है।
कंट्रोल preventive हों या detective?
निवारक, क्योंकि on-chain भुगतान वापस नहीं लिए जा सकते। रिकंसिलिएशन और जाँच के लिए detective कंट्रोल अब भी ज़रूरी हैं, लेकिन सिर्फ़ बाद की समीक्षा पर टिका फ़्रेमवर्क अपरिवर्तनीय पेमेंट रेल के लिए कमी (deficiency) माना जाएगा।
पेमेंट पॉलिसी बदलने की अनुमति किसे होनी चाहिए?
सिर्फ़ administrators, और बदलाव के लिए पेमेंट जितना ही signing quorum ज़रूरी होना चाहिए। Policy संगठन के स्तर पर होती है, इसलिए एक बदलाव सभी vaults पर एक साथ लागू होता है। इसे रूटीन सेटिंग मानना सबसे आम कमी है जो हम देखते हैं।
आगे पढ़ें
कॉर्पोरेट स्टेबलकॉइन ट्रेज़री, कार्ड और पेआउट।
पैसा पाएं, approve करें, screen करें, भुगतान करें, कार्ड से खर्च करें और off-ramp करें, हर ट्रांज़ैक्शन पर ऑडिट प्रमाण के साथ।