कंपनी के बैलेंस, पेमेंट, कार्ड और approvals एक ही workspace में मैनेज करें।
Stablecoin ट्रांज़ैक्शन के लिए audit trails
ऐसा रिकॉर्ड जिससे auditor बिना एक भी follow-up ईमेल के काम कर सके, और इसे साल के अंत में नहीं बल्कि अपने-आप कैसे तैयार करें।
audit-ready stablecoin रिकॉर्ड आपसे पूछे बिना छह सवालों के जवाब देता है: पेमेंट किस लिए था, counterparty कौन था, कौन सी पॉलिसी लागू हुई, किसने अप्रूव किया, रिलीज़ से पहले स्क्रीनिंग का नतीजा क्या था, और किस hash से सेटल हुआ। blockchain सिर्फ़ आखिरी जवाब देता है। बाकी पाँच पेमेंट के समय ही कैप्चर करने होते हैं, क्योंकि बाद में उन्हें दोबारा नहीं बनाया जा सकता।
रिकॉर्ड की बनावट
| फील्ड | ऑडिटर इसे क्यों चाहते हैं |
|---|---|
| इनवॉइस / बिज़नेस रेफरेंस | हर outflow को किसी देनदारी से जोड़ता है |
| काउंटरपार्टी रिकॉर्ड स्नैपशॉट | साबित करता है कि उस समय डेस्टिनेशन सही वेंडर का ही था |
| एसेट, नेटवर्क, राशि, रिपोर्टिंग-करेंसी राशि | बाद में री-प्राइसिंग के बिना लेजर मिलान |
| लागू पॉलिसी वर्ज़न | दिखाता है कि कौन-सा कंट्रोल सेट लागू था |
| अनुरोधकर्ता की पहचान | तय करता है कि शुरुआत किसने की |
| Approvers की पहचान और quorum पूरा | ज़िम्मेदारियों का बँटवारा तय करता है |
| screening नतीजा और timestamp | निवारक कंट्रोल का सबूत, एक्ज़िक्यूशन से पहले की तारीख़ के साथ |
| ट्रांज़ैक्शन हैश और कन्फ़र्मेशन टाइम | स्वतंत्र रूप से सत्यापित settlement प्रूफ |
| नेटवर्क फ़ीस चुकाई गई | Reconciliation के समय बैलेंस के अंतर की वजह बताता है |
सभी चेन पर एकरूपता
Ethereum, Base, Polygon, Solana और Tron पर एक ही payment पांच अलग native रूपों में दर्ज होता है: अलग fee models, अलग confirmation नियम, अलग address formats। अगर आपके सबूतों में ये फ़र्क आ गए, तो period-end एक अनुवाद का काम बन जाता है। इसके बजाय capture के समय ही normalise करें: एक schema, एक rate source, एक fee field, और chain को format नहीं बल्कि attribute के रूप में दर्ज करें।
- राशि settled asset और आपकी reporting currency दोनों में रखें, rate source के नाम के साथ।
- नेटवर्क फ़ीस को अलग लाइन में दर्ज करें ताकि ledger एक-एक cent तक मेल खाए।
- हर चेन पर अप्रूवर्स के लिए एक ही आइडेंटिटी मॉडल का उपयोग करें।
- कन्फ़र्मेशन डेप्थ को मेटाडेटा मानें, रिकॉर्ड का ढाँचा बदलने की वजह नहीं।
अवधि-अंत reconciliation
- 01cut-off block पर हर address, asset और chain के balance का snapshot लें.
- 02दर्ज रेट सोर्स और समय के आधार पर रिपोर्टिंग करेंसी में कन्वर्ट करें।
- 03Ledger control account से मिलान करें और हर अंतर की सूची बनाएं।
- 04अंतर इस क्रम में सुलझाएँ: बुक न हुई नेटवर्क फ़ीस, रास्ते में चल रहे ट्रांसफ़र, रजिस्टर में न मौजूद एड्रेस।
- 05पुष्टि करें कि अवधि के हर पेमेंट का स्क्रीनिंग रिज़ल्ट उसके hash से पहले की तारीख का है।
- 06पॉलिसी change log निकालें और जांचें कि हर बदलाव का requester और approver अलग-अलग व्यक्ति हैं।
- 07Evidence pack एक्सपोर्ट करें और उसे प्लेटफ़ॉर्म के बाहर archive करें।
इम्यूटेबिलिटी के क्या फायदे हैं और क्या नहीं
append-only log रखना फ़ायदेमंद है: इससे कोई बाद में चुपचाप यह नहीं बदल सकता कि पेमेंट किसने अप्रूव किया। लेकिन immutability का मतलब integrity नहीं है। अगर पेमेंट के समय गलत डेटा दर्ज हुआ, तो immutable store उस गलत डेटा को हमेशा के लिए सुरक्षित कर देता है। असली वैल्यू रिलीज़ के समय सही फ़ील्ड्स अपने-आप कैप्चर करने से आती है, और उसके बाद ही उन्हें tamper-evident बनाने से।
Stablerail इसे कैसे बनाता है
सभी सपोर्टेड नेटवर्क पर हर पेमेंट के साथ काउंटरपार्टी स्नैपशॉट, पॉलिसी वर्ज़न, रिक्वेस्टर, अप्रूवर, स्क्रीनिंग रिज़ल्ट और हैश एक ही नॉर्मलाइज़्ड रिकॉर्ड में होते हैं। पॉलिसी और साइनर में बदलाव उनके अप्रूवल के साथ लॉग होते हैं। एक्सपोर्ट को ऐसे बनाया गया है कि उसे सीधे ऑडिटर को सौंपा जा सके, और एक्सपोर्ट के बाद वह आपकी अपनी फ़ाइल में रहता है, सिर्फ़ हमारे डैशबोर्ड में नहीं।
अक्सर पूछे जाने वाले सवाल
स्टेबलकॉइन ट्रांजैक्शन ऑडिट-रेडी कैसे बनता है?
ऐसा record जिससे कोई third party आपसे पूछे बिना भुगतान का पूरा ब्योरा समझ सके: business purpose और invoice reference, उस समय का counterparty record, लागू policy version, requester और approvers, execution से पहले की तारीख वाला screening result, और transaction hash जिसे वे खुद verify कर सकें।
क्या blockchain ही ऑडिट ट्रेल है?
नहीं। Chain सिर्फ़ यह साबित करती है कि दो एड्रेस के बीच वैल्यू गई। यह साबित नहीं करती कि किसने authorise किया, क्यों, किस policy के तहत, या destination सही vendor था। Chain रिकॉर्ड का एक फ़ील्ड है, पूरा रिकॉर्ड नहीं।
अलग-अलग चेन पर ऑडिट ट्रेल एक जैसा कैसे रखें?
हर पेमेंट को सेव करने से पहले एक ही schema में normalise करें, ताकि Tron और Base ट्रांसफ़र के फ़ील्ड एक जैसे हों। Reporting currency की राशि एक documented rate source से सेव करें। Period end पर reconciliation की कमियों की मुख्य वजह chain-specific exports होते हैं।
stablecoin ट्रांज़ैक्शन रिकॉर्ड कितने समय तक रखने चाहिए?
अपने क्षेत्राधिकार में दूसरे वित्तीय रिकॉर्ड जितने समय तक रखे जाते हैं, उतने ही समय तक रखें, आम तौर पर पाँच से सात साल. Evidence सिर्फ़ vendor dashboard में नहीं, अपने export में भी रखें, ताकि platform बदलने पर भी रिकॉर्ड बना रहे.
ऑन-चेन बैलेंस का लेजर से reconciliation कैसे करें?
अवधि के अंत में हर address, asset और chain के balance का snapshot लें, अपनी documented rate पर convert करें और ledger control account से मिलान करें. अंतर आमतौर पर unbooked network fees, in-flight transfers या register से छूटे address की वजह से होता है. इसी क्रम में जाँच करें.
ऑडिटर्स अक्सर किन चीज़ों पर ऐतराज़ जताते हैं?
साइनिंग के बजाय chat में दर्ज approvals, ट्रांज़ैक्शन के बाद की तारीख वाले screening नतीजे, भुगतानों में दिखने वाले पर counterparty रजिस्टर में न मौजूद पते, और ऐसे पॉलिसी बदलाव जिनका कोई रिकॉर्ड नहीं कि किसने मंज़ूरी दी।
आगे पढ़ें
कॉर्पोरेट स्टेबलकॉइन ट्रेज़री, कार्ड और पेआउट।
पैसा पाएं, approve करें, screen करें, भुगतान करें, कार्ड से खर्च करें और off-ramp करें, हर ट्रांज़ैक्शन पर ऑडिट प्रमाण के साथ।