इम्यूटेबल डबल-एंट्री लेजर API क्या है

किसी मार्केटप्लेस लेजर की पहचान इस बात से नहीं होती कि वह पैसों के लेन-देन को स्टोर करता है या नहीं - अधिकांश सिस्टम ऐसा करते हैं। इसकी पहचान तब होती है जब कोई पेमेंट प्रदाता एक ही वेबहुक को दो बार भेजता है, जब किसी सेलर को भुगतान मिलने के बाद रिफंड आता है, या जब कोई ऑडिटर यह पूछता है कि किसी सेलर का बैलेंस अपने मौजूदा अंक तक कैसे पहुँचा। वे पल यह उजागर करते हैं कि आपके पास एक इम्यूटेबल डबल-एंट्री लेजर है या एक आशावादी नाम वाला म्यूटएबल फील्ड।

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

रनिंग बैलेंस फील्ड नहीं, बल्कि संतुलित जर्नल एंट्रीज

सबसे स्पष्ट परीक्षण यह है कि API किसी सेलर के बैलेंस को कैसे प्रदर्शित करता है। यदि बैलेंस एक ऐसा नंबर है जिसे आपका एप्लिकेशन सीधे बढ़ाता (increment) है, तो यह डबल-एंट्री लेजर नहीं है। यदि बैलेंस पोस्ट की गई जर्नल लाइनों का एक व्युत्पन्न (derived) दृश्य है, तो यह हो सकता है।

हर ट्रांजैक्शन में समान डेबिट और क्रेडिट होने चाहिए। जब कोई खरीदार किसी ऐसे ऑर्डर के लिए €100 का भुगतान करता है जहाँ मार्केटप्लेस €15 कमीशन लेता है, तो लेजर क्लियरिंग खाते में €100 के डेबिट को सेलर देयता (payable) में €85 के क्रेडिट और कमीशन राजस्व में €15 के क्रेडिट के मुकाबले रिकॉर्ड करता है। दोनों पक्ष हमेशा एक ही आंकड़े पर योग करते हैं। यह संरचनात्मक नियम किसी रिपोर्ट तक पहुँचने से पहले ही बड़ी संख्या में बग्स को पकड़ लेता है।

एक जर्नल ट्रांजैक्शन में कम से कम ये बातें होनी चाहिए:

• एक यूनीक, इम्यूटेबल ट्रांजैक्शन ID
• डेबिट और क्रेडिट लाइनें, प्रत्येक में एक खाता, राशि और मुद्रा (currency) हो
• एक प्रभावी तिथि और एक पोस्टिंग टाइमस्टैम्प
• एक व्यावसायिक-घटना का प्रकार (बिक्री, रिफंड, payout, चार्जबैक)
• एक आइपोटेंसी की (idempotency key)
• ऑर्डर, पेमेंट या प्रदाता इवेंट का एक सोर्स रेफरेंस
• एक स्थिति (लंबित, पोस्ट किया गया, उलट दिया गया)
• वह सेवा या क्रेडेंशियल जिसने इसे बनाया है

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

क्षतिपूरक सुधारों (compensating corrections) के साथ केवल-अपेंड (append-only) पोस्टिंग

"इम्यूटेबल" का मतलब यह होना चाहिए कि पोस्ट किए गए जर्नल को उसी जगह पर एडिट नहीं किया जा सकता है। गलतियों को आगे सुधार कर ठीक किया जाता है, न कि मिटाया जाता है। एक गलत कमीशन एंट्री का एक रिवर्सल होता है जो मूल एंट्री को रद्द कर देता है, और फिर एक सुधरे हुए परिणाम को रिकॉर्ड करने वाली सुधरे हुई एंट्री होती है। दोनों मूल एंट्री से लिंक होते हैं, और ऑडिट इतिहास दिखाता है कि बदलाव किसने और कब शुरू किया था।

API को पोस्ट किए गए अकाउंटिंग रिकॉर्ड्स के खिलाफ सादे UPDATE और DELETE को अस्वीकार करना चाहिए। यह आपको गैर-वित्तीय मेटाडेटा संलग्न करने की अनुमति दे सकता है, जैसे कि सपोर्ट केस रेफरेंस, जब तक कि राशियाँ, खाते और टाइमस्टैम्प अछूते रहें।

उन तीन चीज़ों को अलग करना मददगार होता है जिन्हें लोग आपस में मिला देते हैं:

• ऑपरेशनल इम्यूटेबल: एप्लिकेशन उपयोगकर्ता पोस्ट की गई पंक्तियों को बदल या हटा नहीं सकते हैं।
• ऑडिट इम्यूटेबल: सिस्टम यह प्रदर्शित कर सकता है कि इतिहास बदला नहीं गया है।
• कानूनी प्रतिधारण (legal retention): लागू कानून द्वारा आवश्यक अवधि के लिए रिकॉर्ड रखे जाते हैं।

सख्त अनुमतियों, बैकअप और अनुशासित रिवर्सल वर्कफ़्लो वाला केवल-अपेंड (append-only) संबंधीय डेटाबेस (relational database) वास्तव में एक इम्यूटेबल लेजर प्रदान करता है। यहाँ ब्लॉकचेन कोई आवश्यकता नहीं है, और EU अकाउंटिंग डेटा के लिए यह आमतौर पर गोपनीयता और सुधार से जुड़ी ऐसी समस्याएं पैदा करता है जो इसके द्वारा जोड़े जाने वाले छेड़छाड़-सबूत लाभ से अधिक होती हैं।

एटॉमिकिटी और आइपोटेंसी

एक मार्केटप्लेस इवेंट को एटॉमिक रूप से पोस्ट किया जाना चाहिए। या तो सभी जर्नल लाइनें कमिट होती हैं या कोई भी नहीं। €100 की रसीद रिकॉर्ड करना लेकिन €15 के कमीशन को रिकॉर्ड करने में विफल रहना एक असंतुलित, भ्रामक परिणाम पैदा करता है जिसे बाद में किसी को सुलझाना पड़ता है। Nordlet इसे एप्लीकेशन लेयर के नीचे लागू करता है: एक डिफ़र्ड डेटाबेस ट्रिगर यह जाँचता है कि कमिट होने के समय हर पोस्टिंग संतुलित है, ताकि एक असंतुलित ट्रांजैक्शन को बिल्कुल भी कमिट न किया जा सके।

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

की को मूल घटना, घटना के प्रकार, प्रदाता की इवेंट ID, कानूनी इकाई (legal entity) और अनुरोध पेलोड के एक हैश से जोड़ा जाना चाहिए। यदि एक ही की अलग राशि या मुद्रा के साथ आती है, तो API को इसे चुपचाप स्वीकार करने के बजाय एक टकराव (collision) के रूप में मानना चाहिए और इसे अस्वीकार करना चाहिए। चुपचाप स्वीकार करना ही वह तरीका है जिससे ऑडिट ट्रेल्स खराब होते हैं। Nordlet का Idempotency-Key हेडर इस तरह काम करता है: समान की और पेलोड के साथ रीट्राय करने पर संग्रहीत प्रतिक्रिया (stored response) फिर से चलती है, और अलग पेलोड वाली समान की को idempotency_key_reuse के साथ अस्वीकार कर दिया जाता है। यह एक छोटी सी विशेषता है जिसका मिलान (reconciliation) पर बहुत बड़ा प्रभाव पड़ता है।

मल्टी-पार्टी स्प्लिट अकाउंटिंग

मार्केटप्लेस ऑर्डर कोई एक मूवमेंट नहीं है। एक ही बिक्री खरीदार के फंड, सेलर की कमाई, मार्केटप्लेस कमीशन, पेमेंट-प्रोसेसिंग फीस, कमीशन पर वैट (VAT), शिपिंग और रिजर्व को छू सकती है। लेजर को ऐसी खाता संरचनाओं की आवश्यकता होती है जो इन्हें एक नेट आंकड़े में मिलाने के बजाय अलग रखती हैं।

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

एक मार्केटप्लेस लेजर को एक से अधिक सेलर बैलेंस के बीच भी अंतर करना चाहिए:

बैलेंस स्टेट	यह क्या दर्शाता है
पेंडिंग (Pending)	किसी घटना से जुड़े फंड लेकिन अभी निकासी के लिए योग्य नहीं हैं
उपलब्ध (Available)	फंड जो रिलीज, रिजर्व, रिफंड और विवाद नियमों को पास करते हैं
होल्ड / आरक्षित (Held / reserved)	चार्जबैक, रिटर्न या धोखाधड़ी नियंत्रण के लिए रोकी गई राशियाँ
भुगतान किया गया (Paid out)	सेलर को हस्तांतरित राशियाँ
नकारात्मक / वसूली योग्य (Negative / recoverable)	रिफंड या फीस उपलब्ध फंड से अधिक होने पर सेलर द्वारा देय राशियाँ

पेंडिंग से उपलब्ध में पैसे ट्रांसफर करना अपने आप में एक संतुलित जर्नल ट्रांजैक्शन होना चाहिए, न कि एक रीलेबल किया गया फील्ड।

रिवर्सल, रिफंड और नेगेटिव बैलेंस

मार्केटप्लेस का पैसा दोनों दिशाओं में बहता है, अक्सर क्रम से बाहर (out of order)। कठिन मामले भुगतान के बाद के रिफंड और चार्जबैक हैं जो हफ्तों बाद आते हैं। एक गंभीर लेजर यह तय करता है कि जब सेलर का उपलब्ध बैलेंस रिफंड को कवर नहीं कर सकता है तो क्या होता है: एक नेगेटिव बैलेंस बनाएं, राशि को सेलर के प्रा प्राप्य (receivables) में ले जाएं, रिजर्व का उपयोग करें, या आगे के भुगतानों को प्रतिबंधित करें।

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

मुद्राएं (currencies) और सटीकता (precision)

सीमा पार (cross-border) मार्केटप्लेस को स्पष्ट रूप से पैसे संभालने की आवश्यकता होती है। राशियों को ISO 4217 मुद्रा कोड और एक सटीक प्रतिनिधित्व का उपयोग करना चाहिए, या तो पूर्णांक माइनर यूनिट या निश्चित-सटीकता (fixed-precision) वाले दशमलव स्ट्रिंग्स का, कभी भी फ्लोट्स का नहीं। कोई मूक राउंडिंग नहीं। जब कन्वर्जन होता है, तो लेजर को मूल राशि, FX दर, दर के स्रोत, टाइमस्टैम्प और परिणामी राशि को संरक्षित करना चाहिए, जिसमें राउंडिंग अंतर एक परिभाषित खाते में पोस्ट किए जाते हैं।

एक ही संतुलित ट्रांजैक्शन को स्पष्ट FX तंत्र के बिना मुद्राओं को नहीं मिलाना चाहिए। यदि ऐसा होता है, तो आपकी रिपोर्ट वास्तविकता से ऐसे तरीकों से असहमत होगी जो महीने के अंत में पता लगाना दर्दनाक होता है।

बाहरी प्रणालियों के मुकाबले मिलान (reconciliation)

एक आंतरिक रूप से संतुलित लेजर अपने दम पर आधिकारिक नहीं है। इसे बाहरी दुनिया से सहमत होना होगा: पेमेंट-प्रदाता के ट्रांजैक्शन, प्रदाता की फीस, सेटलमेंट रिपोर्ट, बैंक स्टेटमेंट, payout फाइलें और चार्जबैक रिपोर्ट।

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

EU सीमाएं जिनका API को सम्मान करना चाहिए, और वे जिन्हें वह नहीं कर सकता

यह वह जगह है जहाँ मार्केटिंग के दावे हकीकत से आगे निकल जाते हैं। एक लेजर EU की बाध्यताओं में मदद करता है, लेकिन यह अपने आप में उन्हें पूरा नहीं करता है।

वैट (VAT)। लेजर को कर-प्रासंगिक आयामों को संरक्षित करना चाहिए: क्षेत्राधिकार (jurisdiction), दर, कर श्रेणी, और यह कि दर कैसे निर्धारित की गई थी। इसे खरीदार को सेलर की बिक्री को मार्केटप्लेस के कमीशन से अलग करना चाहिए, और फीस पर वैट को केवल गुजरने वाली राशियों से अलग करना चाहिए। Nordlet प्रति-देश वैट गणना, VIES सत्यापन, और i.SAF रजिस्टर जनरेशन को संभालता है, साथ ही OSS और IOSS परिदृश्यों को भी संभालता है जो EU मार्केटप्लेस के सामने आते हैं। लेजर को एक सबूत और टैक्स इंजन के रूप में मानें, न कि टैक्स सलाह के रूप में।

DAC7। प्लेटफॉर्म रिपोर्टिंग नियमों के लिए सेलर की पहचान, क्षेत्राधिकार, ट्रांजैक्शन कुल, फीस, रिफंड और payout के बीच विश्वसनीय लिंक की आवश्यकता होती है। एक संतुलित लेजर ट्रांजैक्शन के सबूत तैयार करता है। यह यह निर्धारित नहीं करता है कि कोई सेलर रिपोर्ट करने योग्य है या नहीं, और यह KYC, ऑनबोर्डिंग या रिपोर्टिंग वर्कफ़्लो की जगह नहीं लेता है। ट्रांजैक्शन अकाउंटिंग और विनियामक रिपोर्टिंग को अलग-अलग मामलों के रूप में रखें।

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

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

लेजर API का मूल्यांकन करने के लिए एक चेकलिस्ट

फीचर लेबल सस्ते होते हैं। इसके बजाय सैंडबॉक्स में व्यवहार का परीक्षण करें। इन परिदृश्यों को चलाएं और सबूतों की जाँच करें:

• सेलर और मार्केटप्लेस के बीच विभाजित €100 के ऑर्डर को पोस्ट करें, और स्पष्ट खातों के साथ एक संतुलित जर्नल की पुष्टि करें।
• एक ही अनुरोध को दो बार भेजें, और एक ट्रांजैक्शन की पुष्टि करें, कोई डुप्लीकेट नहीं।
• किसी पोस्ट की गई एंट्री को एडिट करने का प्रयास करें, और पुष्टि करें कि इसे अस्वीकार कर दिया गया है या गैर-वित्तीय मेटाडेटा तक सीमित कर दिया गया है।
• गलत कमीशन को सुधारें, और एक लिंक्ड रिवर्सल प्लस सुधरे हुए एंट्री की पुष्टि करें।
• payout के बाद आंशिक रिफंड जारी करें, और जरूरत पड़ने पर सेलर प्राप्य (receivable) या नेगेटिव बैलेंस के साथ एक ट्रैसेबल रिफंड की पुष्टि करें।
• प्रदाता के वेबहुक को दोबारा चलाएं, और डुप्लीकेट पहचान की पुष्टि करें।
• बहु-मुद्रा (multi-currency) सेटलमेंट को प्रोसेस करें, और FX विवरण और कन्वर्जन अकाउंटिंग की पुष्टि करें।
• अवधि के अंत में सेलर के बैलेंस की क्वेरी करें, और एक प्रलेखित कट-ऑफ के साथ एक पुनरुत्पादित (reproducible) परिणाम की पुष्टि करें।
• प्रदाता सेटलमेंट आयात करें, और अपवाद स्थिति के साथ मिलान की पुष्टि करें जो इतिहास को अछूता छोड़ती है।
• गतिविधि के एक महीने को निर्यात (export) करें, और एक पूर्ण, पृष्ठ-विभाजित (paginated), दोहराए जाने योग्य अर्क (extract) की पुष्टि करें।

सबसे मजबूत सबूत दस्तावेज प्लस एक पुनरुत्पादित परीक्षण है। "रियल-टाइम," "ऑडिट-रेडी," और "इम्यूटेबल" जैसे शब्दों का डेटा मॉडल, त्रुटि शब्दार्थ (error semantics) और उनके पीछे के प्रतिधारण व्यवहार के बिना कोई मतलब नहीं है।

हम सबसे पहले क्या जांचेंगे

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

उसके बाद, API-पर् First विचार इस बात के लिए मायने रखते हैं कि आपकी टीम कितनी तेजी से शिप करती है: टाइप किए गए SDK, sale_invoice.paid जैसी घटनाओं के लिए वेबहुक, एक काम करने वाला सैंडबॉक्स, और बंद महीनों की सुरक्षा के लिए पीरियड लॉकिंग। Nordlet को इस मॉडल के आसपास बनाया गया था, जिसमें ऐप के माध्यम से API के माध्यम से एक ही फीचर सेट सामने आया था, यही वह चीज है जो एक प्लेटफॉर्म को थर्ड-पार्टी चेकआउट को जोड़ने के बजाय अपने स्वयं के उत्पाद के अंदर ऑडिट-रेडी बुक्स चलाने देती है। मार्केटप्लेस स्टैक में ऐसा लेजर कैसे फिट बैठता है, इसके व्यापक चित्र के लिए, मार्केटप्लेस अकाउंटिंग के लिए डबल-एंट्री लेजर API पर हमारी गाइड देखें.

FAQ

क्या डबल-एंट्री इस बात की गारंटी देती है कि मेरी अकाउंटिंग सही है?

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

क्या किसी पेमेंट प्रदाता का लेजर मार्केटप्लेस के लिए पर्याप्त है?

आमतौर पर नहीं। एक PSP अपने स्वयं के सिस्टम के भीतर फंड को ट्रैक करता है, जो मूवमेंट और payout के लिए उपयोगी है। आपके मार्केटप्लेस को अभी भी कमीशन राजस्व, सेलर देयता, फीस पर वैट, रिफंड, रिजर्व, विवादों और प्रबंधन रिपोर्टिंग के लिए अपने स्वयं के रिकॉर्ड की आवश्यकता है। दोनों प्रणालियों का मिलान किया जाना है, और प्रदाता के दृष्टिकोण को अपनी अकाउंटिंग के रूप में मानने से ऐसे अंतराल रह जाते हैं जो ऑडिट के समय सामने आते हैं।

क्या मुझे लेजर को इम्यूटेबल बनाने के लिए ब्लॉकचेन की आवश्यकता है?

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

क्या एक इम्यूटेबल लेजर GDPR के तहत डेटा को हमेशा के लिए रख सकता है?

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