ब्लॉग · 21 मई 2026

डिडिट वेबहुक के साथ डोरा-तैयार ऑडिट ट्रेल बनाना (HI)

डोरा वित्तीय फर्मों से अपने आईसीटी सिस्टम में क्या हुआ, कब हुआ और किसको हुआ, इसका प्रमाण देने की उम्मीद करता है। यहां बताया गया है कि डिडिट के सत्यापन वेबहुक से छेड़छाड़-प्रूफ ऑडिट ट्रेल कैसे बनाया जाए - एक कार्यशील JSON उदाहरण.

द्वारा Didit21 मई 2026अपडेट किया गया 21 मई 2026

डिजिटल ऑपरेशनल रेजिलिएंस एक्ट (DORA) वित्तीय संस्थाओं से एक कपटपूर्ण कठिन सवाल पूछता है: क्या आप यह साबित कर सकते हैं कि क्या हुआ? जब कोई पर्यवेक्षक किसी घटना की जांच करता है, जब कोई ऑडिटर आपके नियंत्रणों का नमूना लेता है, या जब कोई ग्राहक ऑनबोर्डिंग निर्णय पर विवाद करता है, तो आपको अपने सूचना और संचार प्रौद्योगिकी (ICT) सिस्टम में हर घटना का एक रिकॉर्ड – पूर्ण, समय-मुद्रांकित और छेड़छाड़-प्रूफ – चाहिए होता है। पहचान सत्यापन उन प्रणालियों में से एक है, और यह ठीक वही घटनाएँ उत्पन्न करता है जिन्हें आपको कैप्चर करने की आवश्यकता होती है।

यह पोस्ट व्यावहारिक है: डिडिट के सत्यापन और लेनदेन वेबहुक को डोरा-तैयार ऑडिट ट्रेल में कैसे बदला जाए, क्या संग्रहीत किया जाए, और इसे जांच में कैसे खड़ा किया जाए। इसमें एक कार्यशील वेबहुक उदाहरण शामिल है जिसके आधार पर आप आज ही निर्माण कर सकते हैं।

मुख्य बातें

डोरा प्रमाण की अपेक्षा करता है — घटना प्रतिक्रिया, लचीलापन परीक्षण और पर्यवेक्षी समीक्षा के लिए आईसीटी घटनाओं का एक विश्वसनीय रिकॉर्ड।
डिडिट हर सार्थक स्थिति परिवर्तन पर वेबहुक घटनाएँ उत्सर्जित करता है: status.updated, data.updated, transaction.status.updated, और business.status.updated।
प्रत्येक घटना एक अलग, टाइमस्टैम्प्ड तथ्य है जिसे आप एक अपरिवर्तनीय लॉग में जोड़ते हैं — एक ऑडिट ट्रेल का बिल्डिंग ब्लॉक।
प्रत्येक वेबहुक के हस्ताक्षर को सत्यापित करें, कच्चे पेलोड को संग्रहीत करें, और कभी भी लॉग किए गए रिकॉर्ड को न बदलें — केवल जोड़ना ही नियम है।
डिडिट के अपने नियंत्रण ट्रेल का समर्थन करते हैं: SOC 2 Type 1 (ATOM), ISO/IEC 27001:2022 (प्रमाणपत्र संख्या ES144068), और iBeta Level 1 PAD — आपके आईसीटी थर्ड-पार्टी रजिस्टर के लिए विक्रेता-स्तरीय आश्वासन।
परिणाम डोरा द्वारा वांछित क्या-हुआ रिकॉर्ड और एक्सेस कंट्रोल को रेखांकित करने वाले यह-कौन-है प्रमाणन दोनों को संतुष्ट करता है।

मानक क्या अपेक्षा करता है

डोरा पांच स्तंभों पर आधारित है: आईसीटी जोखिम प्रबंधन, घटना रिपोर्टिंग, डिजिटल ऑपरेशनल-रेजिलिएंस परीक्षण, सूचना-साझाकरण, और आईसीटी थर्ड-पार्टी जोखिम प्रबंधन। एक ऑडिट ट्रेल उनके बीच संयोजी ऊतक है। विशेष रूप से, वित्तीय संस्थाओं को इसकी आवश्यकता है:

आईसीटी-संबंधित घटनाओं का पता लगाना, लॉग करना और रिपोर्ट करना — जो यह मानता है कि क्या हुआ, उसे फिर से बनाने के लिए पर्याप्त दानेदार रिकॉर्ड है।
लचीलेपन का परीक्षण करें, जिसमें सिस्टम के माध्यम से लेनदेन और घटनाओं का पता लगाने की क्षमता शामिल है।
तीसरे पक्ष के जोखिम का प्रबंधन करें, जिसमें पहचान-सत्यापन विक्रेता जैसे प्रदाता से प्राप्त रिकॉर्ड शामिल हैं।
रिकॉर्ड बनाए रखें ऐसे रूप में जिसे पर्यवेक्षक अनुरोध कर सकें और उस पर भरोसा कर सकें।

एक उपयोगी ऑडिट ट्रेल की निहित आवश्यकताएं इससे उत्पन्न होती हैं: घटनाएँ पूर्ण (कोई मूक अंतराल नहीं), सटीक (जो हुआ उसके प्रति वफादार), समय-क्रमबद्ध (विश्वसनीय टाइमस्टैम्प के साथ), उत्तरदायी (एक विषय और एक अभिनेता से बंधी हुई), और छेड़छाड़-प्रूफ (आप दिखा सकते हैं कि रिकॉर्ड को बाद में नहीं बदला गया) होनी चाहिए।

यह क्यों मायने रखता है

जब कोई घटना होती है — एक संदिग्ध खाता-अधिग्रहण, एक विवादित सत्यापन, एक फ़्लैग किया गया लेनदेन — तो एक निहित घटना और एक नियामक समस्या के बीच का अंतर अक्सर आपके रिकॉर्ड की गुणवत्ता होती है। एक पूर्ण ट्रेल आपको अनुक्रम को फिर से बनाने, यह साबित करने देता है कि आपके नियंत्रण इच्छानुसार काम करते हैं, और एक पर्यवेक्षक को यह प्रदर्शित करते हैं कि आपने इसे ठीक से संभाला है। एक अधूरा ट्रेल आपको अनुमान लगाने पर छोड़ देता है, और पर्यवेक्षक को आश्वस्त नहीं करता है।

पहचान की घटनाएँ यहाँ उच्च-मूल्य वाली होती हैं क्योंकि वे सिस्टम की सीमा पर बैठती हैं: जिस क्षण किसी व्यक्ति को सत्यापित किया जाता है, फिर से सत्यापित किया जाता है, या उसकी स्थिति बदल जाती है, ठीक वही क्षण होता है जिसे आप सबसे अधिक रिकॉर्ड करना चाहते हैं। उन घटनाओं को घटित होने पर कैप्चर करना — बजाय इसके कि उन्हें बाद में एप्लिकेशन लॉग से फिर से बनाया जाए — यही है जो "हमें लगता है कि यह हुआ" को "यहां वही हुआ" में बदल देता है।

डिडिट कैसे मदद करता है

डिडिट एक सत्यापन, लेनदेन या व्यावसायिक सत्र में हर स्थिति संक्रमण के लिए एक वेबहुक उत्सर्जित करता है। आप पोल नहीं करते हैं; आपको कुछ बदलते ही एक हस्ताक्षरित घटना प्राप्त होती है।

घटना	कब ट्रिगर होती है	ऑडिट मूल्य
`status.updated`	सत्यापन सत्र की स्थिति बदल जाती है (जैसे `Approved`, `Declined`, `In Review` में)	निर्णय और उसके समय को रिकॉर्ड करता है
`data.updated`	सत्र पर सत्यापित डेटा बदल जाता है	क्या कैप्चर/बदला गया था उसे रिकॉर्ड करता है
`transaction.status.updated`	एक निगरानी किए गए लेनदेन की स्थिति बदल जाती है	निगरानी निर्णयों और विश्लेषक समाधानों को रिकॉर्ड करता है
`business.status.updated`	एक KYB व्यावसायिक इकाई की स्थिति बदल जाती है (`ACTIVE`/`FLAGGED`/`BLOCKED`)	व्यावसायिक-ऑनबोर्डिंग परिणामों को रिकॉर्ड करता है

प्रत्येक घटना एक स्व-निहित तथ्य है। आपका काम इसे सत्यापित करना, इसे कच्चा संग्रहीत करना और इसे कभी नहीं बदलना है। एक साथ वे घटनाएँ डिडिट द्वारा आपकी ओर से किए गए हर काम का एक केवल-जोड़ खाता बनाती हैं — ऑडिट ट्रेल डोरा आपके आईसीटी एस्टेट के पहचान-सत्यापन हिस्से के लिए चाहता है।

और क्योंकि डिडिट स्वयं प्रमाणित है — SOC 2 Type 1 (ATOM, 2026-04-09 तक), ISO/IEC 27001:2022 (ब्यूरो वेरिटास, प्रमाणपत्र संख्या ES144068, 2027-06-03 तक वैध), और iBeta Level 1 PAD — उन घटनाओं के पीछे का प्रदाता आपके डोरा आईसीटी थर्ड-पार्टी रजिस्टर के लिए अपना प्रमाण रखता है।

गहराई से देखें: एक वेबहुक को ऑडिट रिकॉर्ड में बदलना

यहां एक status.updated वेबहुक है जो एक सत्यापन सत्र के लिए है जो अभी Approved पर हल हुआ है:

{
  "event": "status.updated",
  "session_id": "sess_7b21e0c4",
  "vendor_data": "user_4521",
  "status": "Approved",
  "previous_status": "In Review",
  "workflow_id": "wf_kyc_eu_substantial",
  "checks": {
    "id_verification": "passed",
    "passive_liveness": "passed",
    "face_match": "passed"
  },
  "created_at": "2026-05-21T10:32:04Z",
  "signature": "t=1747824724,v1=9f86d081884c7d659a..."
}

उसे डोरा-तैयार ऑडिट रिकॉर्ड में बदलने के लिए, प्राप्ति पर चार काम करें:

हस्ताक्षर सत्यापित करें। अपने एंडपॉइंट के हस्ताक्षरित गुप्त का उपयोग करके कच्चे अनुरोध निकाय पर HMAC को फिर से गणना करें और पेलोड पर भरोसा करने से पहले इसकी signature हेडर से तुलना करें। जो भी विफल हो उसे अस्वीकार करें — एक असत्यापित घटना का कोई साक्ष्य मूल्य नहीं होता है।
कच्चे पेलोड को शब्दशः संग्रहीत करें। आपके स्वयं के अंतर्ग्रहण टाइमस्टैम्प के साथ, आपको प्राप्त हुए सटीक बाइट्स को बनाए रखें। भंडारण से पहले सामान्य या पुनर्गठन न करें; कच्ची घटना ही साक्ष्य है।
जोड़ें, कभी अपडेट न करें। केवल-जोड़ स्टोर (या ऐप भूमिका के लिए कोई UPDATE/DELETE अनुदान वाली तालिका) में लिखें। यदि कोई बाद की घटना पहले वाले को हटा देती है, तो पुराने session_id का संदर्भ देते हुए एक नई पंक्ति लिखें — कभी अधिलेखित न करें।
इसे छेड़छाड़-प्रूफ बनाएं। प्रत्येक रिकॉर्ड को हैश करें और हैश को अगले में श्रृंखला करें (प्रत्येक पंक्ति पिछली पंक्ति का हैश संग्रहीत करती है), या एक बार-लिखने वाले स्टोर में लिखें। अब आप यह साबित कर सकते हैं कि लॉग को बाद में नहीं बदला गया था।

परिणाम एक कालानुक्रमिक, उत्तरदायी, छेड़छाड़-प्रूफ खाता-बही है: किसी भी session_id के लिए आप हर स्थिति परिवर्तन को फिर से चला सकते हैं, देख सकते हैं कि कौन से चेक पास हुए, और ठीक उसी समय दिखा सकते हैं जब निर्णय लिया गया था — और यह साबित कर सकते हैं कि रिकॉर्ड को तब से छुआ नहीं गया है। यह वही मानक है जिसे एक पर्यवेक्षक या ऑडिटर ढूंढ रहा है, और यह वही पैटर्न है जिसे आप निगरानी निर्णयों के लिए transaction.status.updated और KYB परिणामों के लिए business.status.updated पर लागू करेंगे।

उपयोग के मामले

बैंक और ईएमआई एक डोरा-संरेखित आईसीटी घटना लॉग बना रहे हैं जिसमें पहचान निर्णय शामिल हैं।
क्रिप्टो वीएएसपी जिन्हें पर्यवेक्षकों को ऑनबोर्डिंग और लेनदेन-निगरानी निर्णयों का प्रमाण देना होगा।
अनुपालन टीमें लचीलापन परीक्षण की तैयारी कर रही हैं जो घटनाओं को एंड-टू-एंड ट्रैक करती हैं।
इंजीनियरिंग टीमें हस्ताक्षरित, केवल-जोड़ घटना अंतर्ग्रहण के साथ भंगुर मतदान की जगह ले रही हैं।

अक्सर पूछे जाने वाले प्रश्न

ऑडिट ट्रेल के लिए मुझे किन वेबहुक घटनाओं को कैप्चर करना चाहिए?

सत्यापन के लिए कम से कम status.updated और data.updated; लेनदेन निगरानी के लिए transaction.status.updated और KYB के लिए business.status.updated जोड़ें। प्रत्येक घटना को कैप्चर करें — पूर्णता ही मुख्य बात है।

क्या मुझे वेबहुक हस्ताक्षर सत्यापित करने की आवश्यकता है?

हाँ। एक असत्यापित वेबहुक को स्पूफ किया जा सकता है और इसका कोई साक्ष्य भार नहीं होता है। कच्चे निकाय पर हस्ताक्षर को फिर से गणना करें और लॉगिंग से पहले बेमेल को अस्वीकार करें।

केवल-जोड़ क्यों? क्या मैं स्थिति बदलने पर केवल एक रिकॉर्ड को अपडेट नहीं कर सकता?

डोरा छेड़छाड़-प्रूफ को महत्व देता है। यदि आप रिकॉर्ड को अधिलेखित करते हैं, तो आप यह साबित नहीं कर सकते कि इतिहास को नहीं बदला गया था। प्रत्येक परिवर्तन के लिए एक नई घटना जोड़ना पूर्ण, प्रमाणनीय अनुक्रम को संरक्षित करता है।

क्या डिडिट की घटनाओं को कैप्चर करना डोरा की सभी आवश्यकताओं को पूरा करता है?

नहीं — डोरा व्यापक है। डिडिट की घटनाएँ आपके आईसीटी एस्टेट के पहचान-सत्यापन और निगरानी वाले हिस्से को कवर करती हैं। आप उन्हें एक पूर्ण ट्रेल के लिए अपने बाकी सिस्टम से लॉग के साथ जोड़ेंगे।

क्या डोरा थर्ड-पार्टी रजिस्टर के लिए डिडिट के अपने प्रमाण हैं?

हाँ — SOC 2 Type 1 (ATOM), ISO/IEC 27001:2022 (प्रमाणपत्र संख्या ES144068, 2027-06-03 तक वैध), और iBeta Level 1 PAD, सभी आपके विक्रेता उचित परिश्रम का समर्थन करने के लिए उपलब्ध हैं।

शुरू करने के लिए तैयार हैं?

ट्रस्ट हब पर डिडिट के प्रमाणपत्र देखें, दस्तावेज़ों में वेबहुक एकीकरण विवरण पढ़ें, और मूल्य निर्धारण पृष्ठ पर पारदर्शी मूल्य निर्धारण की समीक्षा करें। जब आप तैयार हों, मुफ्त में शुरू करें — हर महीने 500 मुफ्त केवाईसी चेक, $0.33 से शुरू होने वाले मुख्य सत्यापन प्रवाह के साथ।