P2P ट्रांसफ़र के बाद किसका किस पर बकाया: पैसे और देनदारियों का रास्ता

बकाया भुगतान किसका है, यह समझने के लिए एक सांकेतिक ट्रांज़ैक्शन लेते हैं: 12:04 पर ग्राहक ने 10 000 मुद्रा इकाइयाँ ट्रांसफ़र कीं। ट्रेडर को क्रेडिट दिखता है, ऑपरेटर ने मर्चेंट को «भुगतान हो गया» भेजा, दुकान ने सामान दे दिया। लेकिन 10 000 अब भी लाभार्थी के अकाउंट में हैं। अब पैसा किसके पास है, दुकान से सेटलमेंट कौन करेगा, और ट्रेडर के ग़ायब हो जाने से दुकान को असल में क्या बचाता है? एक हरा स्टेटस इनमें से किसी सवाल का जवाब नहीं देता।

P2P प्रोसेसिंग में पैसे की भौतिक आवाजाही और देनदारियों के पैदा होने को अलग रखना ख़ास तौर पर ज़रूरी है। मैसेज एक सेकंड में पूरी श्रृंखला पार कर सकता है, जबकि सेटलमेंट शाम को हो सकता है। इन दोनों पलों के बीच कोई न कोई असल में बाक़ियों को कर्ज़ दे रहा होता है। अगर यह भूमिका पहले से तय नहीं की गई, तो आम तौर पर पहले अटके सेटलमेंट के समय ही इसका पता चलता है।

पहले मॉडल तय करें

P2P के नाम पर अलग-अलग ढाँचे मिलते हैं। एक्सचेंज प्लेटफ़ॉर्म पर ख़रीदार और विक्रेता फ़िएट को डिजिटल एसेट से बदलते हैं, और प्लेटफ़ॉर्म अपने नियमों के अनुसार एसेट की होल्डिंग संभालता है। लाइसेंस प्राप्त पेमेंट प्रक्रिया में प्रतिभागी अनुमत भूमिकाओं में फ़ंड स्वीकार करते या भेजते हैं। तीसरे पक्ष के निजी अकाउंट पर ट्रांसफ़र का अनौपचारिक नेटवर्क अपने क़ानूनी और बैंकिंग जोखिमों वाला एक अलग ढाँचा है। API और कोलैटरल डिपॉज़िट होने से वह अनुमत पेमेंट सेवा नहीं बन जाता।

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

पेमेंट डिटेल्स दिखाने से पहले पहला रिज़र्वेशन बनता है

मर्चेंट 10 000 का ऑर्डर बनाता है। ऑपरेटर ऑर्डर आइडेंटिफ़ायर, मुद्रा, रक़म, वैधता अवधि और सहमत टैरिफ़ सहेजता है। फिर उपयुक्त निष्पादक चुनता है, अनुमत पेमेंट मेथड, अकाउंट की उपलब्धता, लिमिट और कोलैटरल जाँचता है। साथ ही इस ऑर्डर के लिए क्षमता रिज़र्व की जाती है। सफल रिज़र्वेशन के बाद ही ग्राहक को ठोस पेमेंट डिटेल्स और निर्देश दिए जाते हैं।

मान लीजिए मर्चेंट का कमीशन 400 है, जिसमें से 150 ट्रेडर को और 250 ऑपरेटर को मिलते हैं। सफल निष्पादन पर मर्चेंट को 9 600 मिलने चाहिए। अगर ट्रेडर का मेहनताना जमा किए गए पैसे से काटा जाता है, तो ऑपरेटर को उसका भावी ट्रांसफ़र 9 850 होगा। अनुबंध पूरी रक़म 10 000 या किसी और एक्सपोज़र पर रिज़र्व तय कर सकता है। हमारे उदाहरण के लिए 10 000 चुनते हैं: रिज़र्व एक ठोस रक़म का होता है, किसी मनमाने «एक स्लॉट» का नहीं।

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

बैंक क्रेडिट के बाद अलग-अलग कर्ज़ बनते हैं

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

अब ट्रेडर के पास 10 000 फ़िएट हैं और उसे ऑपरेटर को 9 850 भेजने हैं। ऑपरेटर को मर्चेंट को 9 600 देने हैं। 250 का अंतर उसके अपने ख़र्चों से पहले उसका मेहनताना है, और 150 निष्पादक का मेहनताना है। ऑपरेटर के रिकॉर्ड में ट्रेडर पर दावा और दुकान के प्रति देनदारी बन गई। इससे ऑपरेटर के बैंक अकाउंट में अभी पैसा नहीं आया।

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

इस तस्वीर में कोलैटरल कहाँ है

मान लीजिए ट्रेडर ने पहले से 30 000 मूल्य का कोलैटरल दिया है। ट्रांज़ैक्शन से पहले वह ग्राहकों के कलेक्शन से अलग दर्ज था। पेमेंट डिटेल्स देने के बाद 10 000 की उपलब्ध क्षमता रिज़र्व हुई। भुगतान की पुष्टि से यह रिज़र्व ज़रूरी तौर पर रिलीज़ नहीं होता: अगर ट्रेडर अब भी जमा किया गया फ़िएट रखे हुए है, तो ऑपरेटर के प्रति सेटलमेंट जोखिम बना रहता है।

चुने गए मॉडल में रिज़र्व 9 850 के पुष्ट ट्रांसफ़र और रिलीज़ की बाक़ी शर्तें पूरी होने तक बना रहता है। अगर सिस्टम «प्राप्त हुआ» दबाते ही पूरी क्षमता लौटा देता है, तो बकाया की अलग लिमिट के बिना एक ही कोलैटरल अभी न चुकाए गए कर्ज़ को अनंत तक बढ़ने देता है। यह एक अलग क्रेडिट मॉडल है, जिसे अलग लिमिट और जोखिम की सोची-समझी स्वीकृति चाहिए।

कोलैटरल को देनदारी के बदले सिर्फ़ तय आधार पर समायोजित किया जा सकता है। साथ ही कर्ज़ दो बार नहीं चुकना चाहिए: जमा हुए सेटलमेंट ट्रांसफ़र से और साथ में कोलैटरल की कटौती से। दोनों ऑपरेशन एक ही एक्सपोज़र से जुड़ते हैं। फ़्रीज़ किए गए डिजिटल एसेट को भी दुकान को पेआउट के लिए उपलब्ध फ़िएट अपने-आप नहीं माना जा सकता।

शाम का सेटलमेंट पैसे की श्रृंखला पूरी करता है

ट्रेडर सहमत सेटलमेंट रूट से 9 850 भेजता है। ऑपरेटर असली प्राप्ति का रजिस्टर से मिलान करता है, ट्रेडर पर दावा घटाता है और कोई दूसरा होल्ड न हो तो संबंधित कोलैटरल रिलीज़ करता है। फिर मर्चेंट को 9 600 का भुगतान करता है। पुष्ट पेआउट के बाद दुकान के प्रति देनदारी बंद हो जाती है; ऑपरेटर के पास ख़र्चों से पहले 250 बचते हैं, ट्रेडर के पास 150।

अगर ऑपरेटर ने दुकान को 12:10 पर पैसा दिया और ट्रेडर से सेटलमेंट 18:00 पर मिला, तो ये पाँच घंटे पचास मिनट उसकी अपनी उपलब्ध लिक्विडिटी या अनुमत फ़ंडिंग स्रोत से चले। इस पूरे समय देनदारियों का संतुलन मिल सकता था। लेकिन नक़दी घट रही थी। इसलिए «सब कुछ डिपॉज़िट से कवर है» वाला वाक्य समय पर भुगतान करने की क्षमता आँकने के लिए काफ़ी नहीं।

बैच सेटलमेंट में एक बैंक ट्रांसफ़र कई ऑर्डर, कमीशन और पहले से सहमत सुधार एक साथ बंद कर सकता है। बँटवारा रजिस्टर की संरचना के अनुसार होता है। यहाँ किसी एक ग्राहक ट्रांज़ैक्शन की ठीक रक़म वाला ट्रांसफ़र खोजने से झूठा अलार्म बजेगा, और पूरी रक़म पहले मिलते-जुलते ऑर्डर पर डाल देने से बाक़ियों के बैलेंस बिगड़ जाएँगे।

दूसरा मॉडल: कामकाजी बैलेंस से कटौती

प्रीपेड कामकाजी बैलेंस वाले ढाँचे भी होते हैं। इन्हें अलग से देखें: ट्रेडर का ऑपरेटर पर 1 000 USDT का दावा था, और उदाहरण के लिए सहमत रेट प्रति USDT 100 सेटलमेंट इकाइयाँ है। 10 000 फ़िएट स्वीकार करने के बाद कामकाजी बैलेंस से 98.5 USDT काटे जाते हैं, जो 9 850 के बराबर हैं। ऑपरेटर पर ट्रेडर का दावा घटकर 901.5 USDT रह जाता है, और मिला हुआ फ़िएट ट्रेडर के पास रहता है। सेटलमेंट की शर्तों के अनुसार मर्चेंट के लिए 9 600 मान्य होते हैं; असली पेआउट के लिए ऑपरेटर को अब भी उपयुक्त लिक्विडिटी चाहिए।

इस दूसरे मॉडल में उन्हीं 9 850 को फ़िएट में दोबारा भेजना नहीं होता: कामकाजी दावा घटाकर आर्थिक सेटलमेंट पहले ही हो चुका है। अलग से तय गारंटी रिज़र्व ख़र्च होना ज़रूरी नहीं। दोनों ढाँचों को मिला देने पर ट्रेडर को दो बार सेटलमेंट करना पड़ेगा। साथ ही आंतरिक बैलेंस कंपनी पर एक सामान्य दावा, यहाँ तक कि बिना सुरक्षा वाला दावा भी हो सकता है; सुंदर स्क्रीन एसेट की अलग कस्टडी या तुरंत निकासी का अधिकार साबित नहीं करती।

अगर पक्षों के बीच राउटर हो

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

अगर हमारे पहले उदाहरण में ऑपरेटर ऐसे बिचौलिये को अपने 250 में से 50 देता है, तो बाक़ी ख़र्चों से पहले उसके पास 200 बचते हैं। दुकान का कर्ज़ अब भी 9 600 है, और तकनीकी सेवा की देनदारी अलग से 50 है। हर भुगतान का मैसेज बिचौलिये से होकर जा सकता है, भले ही ग्राहक का पैसा उससे होकर बिल्कुल न गुज़रे। रूटिंग और डेटा के लिए उसकी ज़िम्मेदारी सभी फ़ंड की वापसी की गारंटी के बराबर नहीं है।

तीन जगहें, जहाँ श्रृंखला आम तौर पर टूटती है

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

हर ऑर्डर के लिए एक सुसंगत जवाब दोबारा बना पाना उपयोगी है: ग्राहक का पैसा किसे मिला; भुगतान किसने और किस आधार पर मान्य किया; अभी पैसा किस पर बकाया है; यह दावा किससे सुरक्षित है; किस असली ट्रांसफ़र से यह बंद होगा। अगर योजना का कोई भी हिस्सा «पार्टनर» शब्द से बदल दिया गया है, तो वित्तीय पारदर्शिता ठीक वहीं ख़त्म हो जाती है।