वॉलेट लॉन्च करने का सबसे तेज़ तरीका है एक पंक्ति में एक संख्या: एक balance कॉलम जिसे पैसा आने पर बढ़ाया जाए और जाने पर घटाया जाए। डेमो में यह चलता है। पायलट में यह चलता है। फिर, पहले दस हज़ार असली लेनदेन के आसपास कहीं, कोई रिपोर्ट चलाता है, आँकड़े मेल नहीं खाते, और कोई नहीं बता पाता कि पैसा कहाँ गया। जब असली मूल्य दाँव पर हो, तो यह सिर्फ़ बग नहीं रहता: यह भरोसे का अंत है, और भरोसा ही वह एकमात्र चीज़ है जो कोई वित्तीय उत्पाद सचमुच बेचता है।
इसे रोकने वाला अनुशासन छह सौ साल पुराना है। डबल-एंट्री बहीखाता सॉफ़्टवेयर पर चिपकाई गई कोई लेखा-सजावट नहीं है; यह वह डेटा मॉडल है जो किसी मुद्रा प्रणाली को सिद्ध करने योग्य बनाता है। इसीलिए हर क्लियरिंग स्तर का लेजर इसी पर बनता है, और इसीलिए आपके वॉलेट का लेजर भी इसी पर बनना चाहिए।
वह अपरिवर्तनीय नियम जिस पर बाकी सब टिका है
डबल-एंट्री लेजर में पैसा न बनाया जाता है, न नष्ट किया जाता है: वह सिर्फ़ चलता है। हर लेनदेन प्रविष्टियों का एक समूह पोस्ट करता है जिनके डेबिट और क्रेडिट का योग ठीक शून्य होता है। एक जमा एजेंट के फ़्लोट खाते को डेबिट करती है और ग्राहक के वॉलेट को उतनी ही राशि से क्रेडिट करती है। एक भेजना भेजने वाले को डेबिट करता है, पाने वाले को क्रेडिट करता है, और शुल्क के लिए एक आय खाते को क्रेडिट करता है। पूरी प्रणाली में, हर क्षण:
सभी डेबिट का योग हमेशा सभी क्रेडिट के योग के बराबर होता है। खाते शून्य पर संतुलित रहते हैं। हमेशा।
यह एक गुण बहुत बड़ा काम करता है। इसका अर्थ है कि ऐसा कोई कोड पथ नहीं है जो मूल्य बना या मिटा सके: कोई बैलेंस सिर्फ़ किसी दूसरे बैलेंस के बदलाव के प्रतिबिंब के रूप में ही बदल सकता है। इसका अर्थ है कि मुख्य वित्त अधिकारी खातों पर हस्ताक्षर कर सकता है और नियामक उन पर भरोसा कर सकता है, क्योंकि प्रणाली अपनी बनावट से सही है, उम्मीद से नहीं। और इसका अर्थ है कि मिलान एक फ़ोरेंसिक जाँच न रहकर एक ऐसा गुण बन जाता है जिसे आप दावे के साथ कह सकते हैं और परख सकते हैं।
इसकी तुलना एकल-बैलेंस तरीके से कीजिए। वहाँ बैलेंस एक ऐसा तथ्य है जिसका कोई स्रोत नहीं। अगर वह गलत है, तो आप नहीं बता सकते कि कोई क्रेडिट दो बार लग गया, कोई डेबिट खो गया, या किसी रेस कंडीशन ने दो लेखन को आपस में उलझा दिया। आपके पास एक संख्या है, पर कोई कहानी नहीं। डबल-एंट्री लेजर, सबसे बढ़कर, एक ऐसी प्रणाली है जो कहानी सँभालकर रखती है।
खाते, प्रविष्टियाँ, और पैसे को गति के रूप में मॉडल क्यों करें
सोच में बदलाव यह है कि बैलेंस को ऐसी चीज़ मानना बंद करें जिसे आप संग्रहित करते हैं, और उसे ऐसी चीज़ मानना शुरू करें जिसे आप निकालते हैं। बैलेंस किसी खाते पर पोस्ट की गई प्रविष्टियों का योग है। वॉलेट खाते हैं। एजेंटों के फ़्लोट खाते हैं। शुल्क आय, सस्पेंस, सेटलमेंट, बिना दावे वाली राशि: सब खाते हैं। मूल्य की हर गति एक लेनदेन है जिसमें दो या अधिक प्रविष्टियाँ होती हैं जिनका योग शून्य होता है।
इसका एक गहरा परिणाम है: लेजर सिर्फ़ जोड़ने वाला होता है। आप कभी किसी बैलेंस को उसकी जगह पर नहीं बदलते; आप नई प्रविष्टियाँ पोस्ट करते हैं। इतिहास कभी दोबारा नहीं लिखा जाता। यही प्रणाली को ऑडिट योग्य बनाता है: जो भी पैसा कभी चला, उसने एक स्थायी, क्रमबद्ध निशान छोड़ा, और किसी भी बीते क्षण का कोई भी बैलेंस उस क्षण तक की प्रविष्टियों को दोबारा चलाकर फिर से बनाया जा सकता है।
वे हिस्से जिन्हें लोग भूल जाते हैं, और बाद में जिनकी कीमत चुकाते हैं
अपरिवर्तनीय नियम ज़रूरी है, पर काफ़ी नहीं। तीन गुण कागज़ पर सही लेजर को ऐसा लेजर बनाते हैं जो असली नेटवर्क और असली विरोधियों के सामने टिक सके।
आइडेम्पोटेंसी
नेटवर्क टूटते हैं। क्लाइंट अनुरोध भेजता है, जवाब रास्ते में खो जाता है, और क्लाइंट, ठीक ही, दोबारा कोशिश करता है। सुरक्षा के बिना, दूसरा अनुरोध दूसरा लेनदेन पोस्ट कर देता है और ग्राहक से दो बार पैसा कट जाता है। इसका हल है आइडेम्पोटेंसी कुंजी: हर तार्किक ऑपरेशन एक अनोखा टोकन लेकर आता है, लेजर दर्ज करता है कि कौन से टोकन पहले ही लागू हो चुके हैं, और जाने-पहचाने टोकन वाला दोहराया गया अनुरोध दोबारा पोस्ट करने के बजाय मूल परिणाम लौटा देता है।
यह सरल लगता है पर बारीक है। जाँच और लेखन परमाणु (एटॉमिक) होने चाहिए: अगर दो दोहराव एक साथ पहुँचें, तो ठीक एक को जीतना चाहिए और दूसरे को परिणाम देखना चाहिए, ऐसी कोई खिड़की नहीं होनी चाहिए जिसमें दोनों आगे बढ़ जाएँ। यहाँ गलती की तो आपने लोड के नीचे दोहरा खर्च बना दिया, ठीक वही विफलता जो परीक्षण में नहीं दिखती और लॉन्च के दिन दिखती है।
रिवर्सल, डिलीट नहीं
चीज़ें बिगड़ती हैं: कोई विवाद, कोई गलती, धोखाधड़ी का दावा। सहज प्रवृत्ति होती है कि गड़बड़ लेनदेन को मिटा दिया जाए। कभी डिलीट न करें। मिटाया गया लेनदेन ऑडिट ट्रेल में एक छेद है, और नियामक छेद को लीपापोती के रूप में पढ़ता है। इसके बजाय एक रिवर्सल पोस्ट कीजिए: एक नया लेनदेन जिसकी प्रविष्टियाँ मूल लेनदेन का प्रतिबिंब हों, और मूल लेनदेन जस का तस रहे। बैलेंस पर शुद्ध असर शून्य होता है; इतिहास गलती और उसका सुधार दोनों दिखाता है, साथ में कारण और ऑपरेटर। एक ऐसा रिवर्सल इंजन जो किसी भी सेवा (P2P, बिल भुगतान, सामान की खरीद, एजेंट पर नकद, फ़्लोट, बचत) को पलट सके, ऑडिट योग्य प्रणाली और बहस के बीच का अंतर है।
पूर्व-जाँच
बैलेंस, लिमिट और KYC स्थिति की पुष्टि लेनदेन पोस्ट होने से पहले होती है, उसी परमाणु ऑपरेशन के भीतर जो उसे पोस्ट करता है: कभी बाद में नहीं, और कभी ऐप में नहीं जहाँ इन्हें दरकिनार किया जा सकता है। जिस लिमिट को ग्राहक पार नहीं कर सकता, वह कोई निष्क्रिय बटन नहीं है; वह उस बिंदु पर लागू की गई बाध्यता है जहाँ पैसा चलने वाला है। ऐप एक सुविधा है; लेजर ही प्राधिकार है। जो भी नियम मायने रखता है, उसे वहीं रहना चाहिए जहाँ पैसा रहता है।
समवर्तिता: जहाँ सही डिज़ाइन दम तोड़ देते हैं
दो अनुरोध एक ही क्षण में एक ही वॉलेट पर पहुँचते हैं: एक भेजना और एक निकासी, दोनों अपने-आप में वैध, पर मिलकर बैलेंस से ज़्यादा। एक भोला कार्यान्वयन दोनों में बैलेंस पढ़ता है, दोनों में उसे पर्याप्त पाता है, और दोनों पोस्ट कर देता है, जिससे खाता ओवरड्रॉ हो जाता है। यह क्लासिक वित्तीय रेस कंडीशन है, और जब तक आप असली समवर्ती अनुरोधों के बीच न हों, यह दिखाई नहीं देती।
बचाव यह है कि खाते को क्रमबद्धता की इकाई बनाया जाए: किसी खाते पर पोस्ट करते समय लॉक लिया जाए या परमाणु सशर्त लेखन इस्तेमाल हो, ताकि दोनों अनुरोध क्रम में आएँ, दूसरा पहले का असर देखे, और ठीक एक सफल हो। कठिन हिस्सा यह है कि ऐसा पूरे लेजर को क्रमबद्ध किए बिना किया जाए: पूरे सिस्टम पर नहीं, हर खाते पर लॉक, ताकि प्रणाली सही रहते हुए तेज़ भी रहे। यही वह समस्या है जो लेजर बना चुके इंजीनियरों को उन इंजीनियरों से अलग करती है जो यह सीखने वाले हैं कि लेजर कठिन क्यों होते हैं।
मिलान एक गुण बन जाता है, आपात अभ्यास नहीं
एकल-बैलेंस प्रणाली में मिलान हर रात की जाँच है: सब कुछ निर्यात करो, पेमेंट रेल से तुलना करो, अंतर ढूँढो, और उम्मीद करो कि सुबह से पहले मिल जाए। डबल-एंट्री प्रणाली में मिलान ज़्यादातर एक स्वतः-सिद्ध सत्य है जिसका आप दावा कर सकते हैं: आंतरिक खाते अपनी बनावट से शून्य पर संतुलित रहते हैं, और बाकी काम बाहरी सेटलमेंट (बैंक, मोबाइल मनी ऑपरेटर और कार्ड प्रोसेसर ने वास्तव में जो राशि भेजी) को उन सस्पेंस और सेटलमेंट खातों से मिलाना है जिन्हें लेजर पहले से ट्रैक करता है। अंतर ऐसे विशिष्ट बेमेल प्रविष्टियों के रूप में सामने आते हैं जिनके साथ एक साफ़ सवाल जुड़ा होता है, न कि बिना कहानी वाली किसी गायब संख्या के रूप में।
एक व्यावहारिक उदाहरण: एक भेजना, पोस्ट किया गया
मान लीजिए एक ग्राहक अपने दोस्त को 1,000 भेजता है, 25 के शुल्क के साथ। डबल-एंट्री लेजर में वह एक भेजना तीन प्रविष्टियों वाला एक लेनदेन है। राशियाँ उदाहरण के लिए हैं।
| खाता | डेबिट | क्रेडिट |
|---|---|---|
| भेजने वाले का वॉलेट | 1,025 | |
| पाने वाले का वॉलेट | 1,000 | |
| शुल्क आय | 25 | |
| कुल | 1,025 | 1,025 |
डेबिट क्रेडिट के बराबर हैं, इसलिए लेनदेन शून्य पर संतुलित है। इसके बारे में आप जो भी सवाल पूछ सकते हैं, उसका जवाब प्रविष्टियों में है: भेजने वाले ने कितना चुकाया, पाने वाले को कितना मिला, ऑपरेटर ने कितना कमाया, और कब। अगर बाद में यह भेजना रिवर्स किया जाए, तो एक प्रतिबिंब लेनदेन वही तीन पंक्तियाँ उलटी दिशा में पोस्ट करता है, और दोनों इतिहास में बने रहते हैं।
एजेंट पर नकद, पोस्ट किया गया
एजेंट लेनदेन दिखाते हैं कि यह मॉडल क्यों बड़े पैमाने पर चलता है। जब कोई ग्राहक किसी एजेंट के पास 2,000 नकद जमा करता है, तो एजेंट का इलेक्ट्रॉनिक फ़्लोट ग्राहक के पास चला जाता है, और एजेंट को कमीशन मिलता है। 20 के उदाहरणार्थ कमीशन के साथ:
| खाता | डेबिट | क्रेडिट |
|---|---|---|
| एजेंट फ़्लोट | 2,000 | |
| ग्राहक वॉलेट | 2,000 | |
| कमीशन व्यय | 20 | |
| एजेंट को देय कमीशन | 20 | |
| कुल | 2,020 | 2,020 |
नकद खुद कभी लेजर को नहीं छूता, क्योंकि वह काउंटर पर भौतिक रूप से हाथ बदल चुका है। लेजर जो दर्ज करता है, वह है एजेंट से ग्राहक तक जाने वाला इलेक्ट्रॉनिक मूल्य, और सेवा के लिए एजेंट को भुगतान करने का दायित्व। जब कमीशन चुकाए जाते हैं, तो एक और संतुलित लेनदेन देय राशि को साफ़ कर देता है। कुछ भी अनुमान से नहीं होता, कुछ भी बाद में स्प्रेडशीट में नहीं गिना जाता।
खातों की सूची (चार्ट ऑफ़ अकाउंट्स) डिज़ाइन करना
आप जो खाते बनाते हैं, वही तय करते हैं कि लेजर किन सवालों का जवाब दे सकता है। एक वॉलेट प्लेटफ़ॉर्म को आमतौर पर चाहिए:
- ग्राहक, एजेंट, मर्चेंट और कॉर्पोरेट वॉलेट, हर एक का एक खाता;
- उत्पाद के हिसाब से बँटे शुल्क आय खाते, ताकि आप देख सकें कि हर सेवा कितना कमाती है;
- एजेंटों और साझेदारों के लिए कमीशन व्यय और देय कमीशन;
- हर बाहरी साझेदार के लिए सेटलमेंट खाते: हर बैंक, स्विच, बिलर और रेल;
- ऐसे पैसे के लिए सस्पेंस खाते जिसकी अंतिम मंज़िल अभी पक्की नहीं है, जैसे किसी साझेदार के जवाब का इंतज़ार कर रहा ट्रांसफ़र;
- एक सुरक्षा-निधि प्रतिबिंब जो ट्रस्ट खाते में होने वाली राशि को ट्रैक करे, ताकि बैंक स्टेटमेंट से रोज़ की तुलना एक ही जाँच हो।
एक उपयोगी कसौटी: अगर वित्त विभाग कोई सवाल पूछे और उसका जवाब स्प्रेडशीट माँगे, तो शायद आपका एक खाता कम है।
लेजर का ठीक से परीक्षण
ऐसी प्रणाली के लिए जिसे कभी गलत नहीं होना चाहिए, साधारण यूनिट टेस्ट काफ़ी नहीं हैं। मायने रखने वाले परीक्षण उदाहरणों के बजाय गुणों की जाँच करते हैं:
- हर लेनदेन शून्य पर संतुलित होता है, हज़ारों यादृच्छिक लेनदेन प्रकारों और राशियों पर।
- रीप्ले स्थिति के बराबर है: प्रविष्टियों से हर बैलेंस दोबारा बनाने पर ठीक वही बैलेंस मिलते हैं जो संग्रहित हैं।
- दोहराव कभी डुप्लिकेट नहीं बनाते: एक ही अनुरोध कई बार भेजना, एक साथ भी, सिर्फ़ एक बार पोस्ट होता है।
- रेस कभी ओवरड्रॉ नहीं करतीं: एक खाते पर प्रतिस्पर्धी डेबिट दागने से वह कभी अपनी लिमिट से नीचे नहीं जाता।
- रिवर्सल बहाल करते हैं: किसी भी लेनदेन को रिवर्स करने पर हर प्रभावित बैलेंस अपने पिछले मूल्य पर लौट आता है।
ये परीक्षण रिलीज़ पाइपलाइन का हिस्सा होने चाहिए, और इन्हें प्रोडक्शन डेटा पर रीड-ओनली रूप में भी चलाया जाना चाहिए, ताकि अपरिवर्तनीय नियम की जाँच सिर्फ़ टेस्ट डेटा पर नहीं, असली खातों पर लगातार होती रहे।
एकल-बैलेंस प्रणाली से माइग्रेशन
कई टीमें ये सिद्धांत लॉन्च के बाद खोजती हैं। सेवा रोके बिना माइग्रेशन संभव है:
- मौजूदा बैलेंस की संरचना फ़्रीज़ करें और एक कट-ऑफ़ समय पर उसका स्नैपशॉट लें।
- नए लेजर में ओपनिंग बैलेंस लेनदेन बनाएँ जो स्नैपशॉट के हर बैलेंस को इक्विटी या माइग्रेशन खाते के विरुद्ध पोस्ट करें।
- कुछ समय तक दोनों प्रणालियों को साथ-साथ चलाएँ, हर नया लेनदेन दोनों में पोस्ट करें और रोज़ बैलेंस की तुलना करें।
- हर अंतर की जाँच तब तक करें जब तक समानांतर संचालन लगातार कई दिनों तक साफ़ न रहे।
- रीड को नए लेजर पर ले जाएँ, फिर पुराना बैलेंस कॉलम हटा दें।
समानांतर संचालन आमतौर पर पुरानी प्रणाली की ऐतिहासिक गलतियाँ उजागर करता है। नए लेजर को किसी गलत संख्या से मिलाने के लिए मजबूर करने के बजाय, उन्हें ईमानदारी से सुलझाने के लिए समय रखें।
फ़ायदा
लेजर को इस तरह बनाइए और कई कठिन चीज़ें आसान हो जाती हैं। स्टेटमेंट प्रविष्टियों पर एक क्वेरी हैं। ऑडिट एक रीप्ले हैं। विवादों का कागज़ी निशान होता है। नए चैनल (USSD से भेजना, ऐप से भेजना, API से शुल्क) उसी गारंटीशुदा कोर तक पहुँचने के अलग-अलग दरवाज़े भर हैं, जिसका मतलब है कि वे एक-दूसरे से भटक नहीं सकते। नियम एक जगह रहते हैं, एक बार लागू होते हैं, सबके लिए।
इसे जल्दबाज़ी में बनाइए और आपको उल्टा विरासत में मिलेगा: एक संख्या जिसे आप समझा नहीं सकते, एक मिलान जिस पर आप भरोसा नहीं कर सकते, और एक लॉन्च का दिन जब आपको पता चलता है कि जो चीज़ बनाने में सबसे सस्ती थी, वही रखने में सबसे महँगी निकली।
एक से अधिक मुद्रा
रेमिटेंस या क्षेत्रीय भुगतान सँभालने वाले वॉलेट एक दूसरे आयाम से मिलते हैं: मुद्रा। नियम वही रहता है, पर हर मुद्रा पर अलग से लागू होता है। हर खाता एक ही मुद्रा रखता है, और हर लेनदेन को उस हर मुद्रा में शून्य पर संतुलित होना चाहिए जिसे वह छूता है। इसलिए मुद्रा रूपांतरण दो संतुलित हिस्से हैं जिन्हें एक विनिमय खाता जोड़ता है: ग्राहक की स्थानीय मुद्रा ऑपरेटर की स्थानीय मुद्रा स्थिति में जाती है, और डॉलर ऑपरेटर की डॉलर स्थिति से पाने वाले तक जाते हैं। विनिमय खाते किसी भी क्षण ऑपरेटर का मुद्रा जोखिम दिखाते हैं, जो ठीक वही है जिसकी ट्रेज़री को जोखिम सँभालने के लिए ज़रूरत है। एक खाते में कई मुद्राएँ मिलाना, या दोनों हिस्से दर्ज किए बिना तुरंत रूपांतरण करना, वह तरीका है जिससे बहु-मुद्रा लेजर चुपचाप पैसा गँवाते हैं।
स्टेटमेंट, महीने का समापन और ऑडिट
क्योंकि बैलेंस प्रविष्टियों से निकाले जाते हैं, स्टेटमेंट बस किसी अवधि में किसी खाते की प्रविष्टियाँ हैं, जिनके साथ एक ओपनिंग और क्लोज़िंग बैलेंस होता है जिसे बीच की प्रविष्टियों से मेल खाना चाहिए। महीने का समापन एक परियोजना नहीं, एक जाँच बन जाता है: ट्रायल बैलेंस शून्य पर संतुलित है, सुरक्षा-निधि बैंक से मेल खाती है, सस्पेंस की व्याख्या हो चुकी है, और शुल्क व कमीशन के योग उत्पाद रिपोर्टों से मेल खाते हैं। ऑडिटर कोई भी बैलेंस चुनकर उसे अलग-अलग लेनदेन तक ट्रेस कर सकते हैं, हर एक के साथ टाइमस्टैंप, चैनल, संदर्भ और, जहाँ कोई व्यक्ति शामिल था, ऑपरेटर। यही ट्रेस करने की क्षमता पहले ऑडिट को डरावना नहीं, सामान्य बनाती है।
सस्पेंस खाते, सही तरह से सँभाले हुए
सस्पेंस वह जगह है जहाँ पैसा तब इंतज़ार करता है जब उसकी अंतिम मंज़िल अभी पता नहीं होती: किसी दूसरे नेटवर्क को भेजा गया ट्रांसफ़र जो पुष्टि की प्रतीक्षा में है, ऐसी जमा जिसका संदर्भ किसी ग्राहक से मेल नहीं खाता, किसी साझेदार का भुगतान जो बिना विवरण के आया। यह उपयोगी है क्योंकि सवाल खुला रहने तक यह खातों को संतुलित रखता है। यह खतरनाक तब बनता है जब यह ऐसी जगह बन जाए जहाँ पैसा भुला दिया जाता है। अच्छा तरीका सरल है: सस्पेंस की हर मद अपना संदर्भ और वहाँ होने का कारण साथ रखती है, हर मद का एक ज़िम्मेदार और एक उम्र होती है, बैलेंस की रोज़ समीक्षा होती है, और कुछ दिनों से पुरानी हर चीज़ ऊपर भेजी जाती है। ऐसा सस्पेंस बैलेंस जो सिर्फ़ बढ़ता ही जाए, इस बात का संकेत है कि ऊपर कहीं कुछ टूटा हुआ है।
अक्सर पूछे जाने वाले सवाल
क्या डबल-एंट्री बैलेंस अपडेट करने से धीमी है?
एक अपडेट की जगह दो या तीन प्रविष्टियाँ पोस्ट करने से लागत बहुत कम बढ़ती है, और तेज़ पढ़ने के लिए बैलेंस प्रविष्टियों के साथ-साथ बनाए रखे जा सकते हैं। प्रदर्शन का असली काम पूरे सिस्टम के बजाय हर खाते पर लॉक लगाने में है, जो एक अच्छी तरह डिज़ाइन किया गया लेजर करता है।
अगर लेजर डबल-एंट्री है, तो क्या हमें अब भी लेखाकारों की ज़रूरत है?
हाँ। लेजर आंतरिक संगति की गारंटी देता है; उत्पादों का लेखा कैसे हो, बाहरी अंतरों की जाँच और नियामकों को रिपोर्टिंग, यह सब अब भी लोग तय करते हैं। बदलता यह है कि वे अपना समय गायब संख्याएँ ढूँढने के बजाय विवेकपूर्ण निर्णय में लगाते हैं।
क्या लेजर की किसी प्रविष्टि को कभी संपादित किया जा सकता है?
नहीं। सुधार नए लेनदेन होते हैं, आमतौर पर रिवर्सल, जिनके साथ कारण और ऑपरेटर दर्ज होते हैं। संपादन योग्य लेजर का ऑडिट नहीं हो सकता।
PesaBridge इस अपरिवर्तनीय नियम को कोर में लागू करता है। ऐप्स, USSD और डेवलपर API पैसे की आवाजाही को दोबारा लागू नहीं करते: वे उन नियमों को प्रस्तुत करते हैं जिनकी लेजर पहले से गारंटी देता है, इसलिए हर चैनल सही है क्योंकि केंद्र सही है।