क्या फ़िनटेक ऐप लॉन्च करने के लिए बैंकिंग लाइसेंस चाहिए?
"क्या फ़िनटेक ऐप लॉन्च करने के लिए बैंकिंग लाइसेंस चाहिए?" असल में तीन सवाल हैं जो एक ही कोट पहने खड़े हैं। क्या आप ग्राहकों का पैसा अपने पास रखते हैं? क्या आप उसे move करते हैं? और उस movement को किसकी नियामकीय अनुमति कवर करती है — आपकी, या किसी और की? इनके जवाब मिलते ही लाइसेंस वाला सवाल ज़्यादातर अपने आप हल हो जाता है। छोटा सार, जो ज़्यादातर टीमों को चौंकाता है: अधिकांश फ़िनटेक ऐप कभी बैंकिंग लाइसेंस नहीं रखते, क्योंकि अधिकांश फ़िनटेक ऐप वह एक काम कभी करते ही नहीं जिसके लिए बैंकिंग लाइसेंस होता है। आगे इस पूरे दायरे का नक्शा है, कानूनी सलाह नहीं — मकसद यह जानना है कि कोई आपको समय-सीमा या कीमत बताए, उससे पहले कौन-से सवाल पूछने हैं।
बैंकिंग लाइसेंस असल में किसलिए होता है
पूर्ण बैंकिंग लाइसेंस — EU की भाषा में credit institution authorisation — एक खास, कड़ी निगरानी वाली गतिविधि की अनुमति देता है: जनता से जमा (deposits) लेना और उसी पैसे को आगे कर्ज़ के रूप में देना। यह maturity mismatch, यानी ग्राहक जिन बैलेंसों को माँग पर निकाल सकते हैं उनसे लंबी अवधि के कर्ज़ों को फ़ंड करना, ही वजह है कि बैंकों पर भारी पूँजी-आवश्यकताएँ, deposit-guarantee की ज़िम्मेदारियाँ और एक supervisor होता है जो उनकी balance sheet को पंक्ति-दर-पंक्ति पढ़ता है। अगर आपका ऐप deposits नहीं लेता और उनके बदले कर्ज़ नहीं देता, तो आप लगभग निश्चित रूप से बैंकिंग लाइसेंस की बात ही नहीं कर रहे। आप किसी हल्की चीज़ को देख रहे हैं, दायरे में थोड़ा नीचे — और पूरी कहानी वही दायरा है।
अनुमतियों का स्पेक्ट्रम: सबसे भारी से सबसे हल्की तक
वित्तीय अनुमतियाँ कई स्तरों में आती हैं। सबसे ऊपर क्रेडिट संस्था यानी बैंक है, जो जमा राशि रख सकता है और कर्ज़ दे सकता है। उसके नीचे इलेक्ट्रॉनिक मनी संस्था (EMI) ई-मनी जारी कर सकती है: वह ग्राहकों की राशि अपने पास रखकर उसे कार्ड या वॉलेट में उपलब्ध करा सकती है, लेकिन उसके पास रखा फ़्लोट सुरक्षित (safeguarded) रखना होता है — अलग और अछूता, कभी उधार नहीं दिया जाता। उसके नीचे पेमेंट संस्था (PI) भुगतान execute कर सकती है — ट्रांसफ़र शुरू करना, राशि कलेक्ट करना, रेमिट करना, कार्ड ट्रांज़ैक्शन acquire करना — पर वह लंबे समय तक राशि रखने के लिए नहीं बनी है; पैसा उसके ज़रिए गुज़रता है, वहाँ टिकता नहीं। और सबसे नीचे एजेंट या डिस्ट्रीब्यूटर है, जिसके पास अपना कोई लाइसेंस नहीं होता; वह उस लाइसेंस-प्राप्त संस्था के प्राधिकरण के तहत काम करता है जिसने उसे पंजीकृत किया है।
पैटर्न यह है कि हर पायदान नीचे उतरने पर एक क्षमता घटती है और उसके साथ पूँजी और दायित्व का एक हिस्सा भी। जमा राशि रखना सबसे भारी अनुमति है; ऐसा करने में सक्षम किसी का एजेंट होना सबसे हल्की। ज़्यादातर कंज़्यूमर fintech ऐप — वॉलेट, कार्ड, ट्रांसफ़र, पेमेंट लिंक — EMI और पेमेंट संस्था की श्रेणी में आते हैं, या ऐसे पार्टनर के ऊपर बनते हैं जिसके पास इनमें से कोई अनुमति हो। बहुत कम को बैंक बनना पड़ता है, और यह बात शुरुआत में समझ लेने से बहुत सारी भटकी हुई मेहनत बच जाती है।
खुद को परखने का एक आसान तरीका: अगर आपके ग्राहक ऐप में बैलेंस रखेंगे — टॉप-अप किया जाने वाला वॉलेट, पहले से लोड किया जाने वाला कार्ड — तो आप ई-मनी के दायरे में हैं, क्योंकि राशि रखना ही वह अनुमति है जो EMI को परिभाषित करती है। अगर पैसा सिर्फ़ गुज़रता है — आप ट्रांसफ़र शुरू करते हैं, बिल कलेक्ट करते हैं, पेआउट सीधे आगे भेज देते हैं — तो पेमेंट संस्था की अनुमति स्वाभाविक विकल्प है, चाहे वह आपके पास हो या पार्टनर के पास। अगर आप फ़ंड को छूते ही नहीं और सिर्फ़ कहीं और रखे खातों की जानकारी दिखाते हैं, तो उसके लिए भी एक हल्का अपना पंजीकरण होता है। आप जितने भारी स्तर पर होंगे, उतनी ही अधिक पूँजी और निगरानी साथ आएगी; डिज़ाइन का लक्ष्य यह है कि आप उतने से भारी स्तर पर न बैठें जितना उत्पाद को वाकई चाहिए।
अनुमति किराये पर लेना: पार्टनर मॉडल
किसी अनुमति के ऊपर बनाने के लिए उसे खुद रखना ज़रूरी नहीं है। आम रास्ता है उसे किराये पर लेना। स्पॉन्सर-बैंक या Banking-as-a-Service व्यवस्था में लाइसेंस-प्राप्त बैंक या EMI खाते रखता है, IBAN और कार्ड जारी करता है और फ़्लोट को सुरक्षित रखता है; आप उसके API के ऊपर ऐप बनाते हैं और अनुभव लॉन्च करते हैं। एजेंट मॉडल में आप किसी पेमेंट संस्था के एजेंट के रूप में — या ई-मनी जारीकर्ता के डिस्ट्रीब्यूटर के रूप में — पंजीकृत होते हैं, और उनका लाइसेंस आपकी गतिविधि को कवर करता है; नियामक आपको उन्हीं के माध्यम से जानता है। अनुबंध अलग हैं, पर बुनियादी तथ्य एक ही है: स्टैक में कहीं न कहीं कोई अनुमति रखता है। सवाल बस इतना है कि वह आप हैं या आपका पार्टनर।
किसकी कितनी ज़िम्मेदारी
लाइसेंस किराये पर लेने से ज़िम्मेदारी किराये पर नहीं जाती। नियामक के प्रति जवाबदेह लाइसेंस-प्राप्त संस्था ही होती है — ग्राहकों के फ़ंड की सुरक्षा, एंटी-मनी-लॉन्ड्रिंग निगरानी और पूरे प्रोग्राम के आचरण के लिए। लेकिन ये दायित्व अनुबंध के ज़रिए नीचे की ओर बहते हैं। पार्टनर के लाइसेंस पर चलने के बावजूद KYC और ऑनबोर्डिंग आप ही चलाएँगे, AML के लिए ट्रांज़ैक्शन पर नज़र आप ही रखेंगे, और पार्टनर जिन सीमाओं और रिपोर्टिंग से बँधा है उनका पालन भी आप ही करेंगे। ज़िम्मेदारी आउटसोर्स नहीं होती, बँटती है: पार्टनर नियामक के प्रति उसका मालिक है और आपसे एक अनुबंध के ज़रिए उसका बड़ा हिस्सा वापस आपके पाले में डाल देता है। उस अनुबंध को उतने ही ध्यान से पढ़ें जितने ध्यान से आप वह लाइसेंस पढ़ते जो आपने न लेने का फ़ैसला किया।
लाइसेंस दूसरों का पैसा रखने या भेजने की अनुमति है। सॉफ़्टवेयर वह ज़रिया है जिससे उस पैसे को निर्देश दिए जाते हैं, उसका मिलान होता है और ग्राहक को वापस दिखाया जाता है। आप दोनों एक वेंडर से खरीद सकते हैं या दो से — पर खरीदते हमेशा दोनों हैं।
सॉफ़्टवेयर और लाइसेंस अलग-अलग खरीद हैं
यही वह समझ है जो पूरे प्रोजेक्ट को नए सिरे से सजा देती है। ग्राहक को पेमेंट ऐप एक चीज़ दिखता है, पर वह दो चीज़ों का मेल है: पैसा रखने या भेजने की विनियमित अनुमति, और वह सॉफ़्टवेयर जो लेन-देन को निर्देश देता है, लेजर रखता है, क्रेडिट का मिलान करता है और स्क्रीन पर बैलेंस दिखाता है। इन दोनों को अलग-अलग जुटाया जाता है। आप अपना लाइसेंस रखकर सॉफ़्टवेयर खरीद सकते हैं; लाइसेंस रखकर सॉफ़्टवेयर खुद बना सकते हैं; पार्टनर के ज़रिए अनुमति किराये पर लेकर ऊपर सॉफ़्टवेयर खरीद सकते हैं; या दोनों एक ही वेंडर से ले सकते हैं जिसने उन्हें बंडल किया हो। चारों सामान्य हैं। जो सामान्य नहीं है — और चुपचाप प्रोजेक्ट के महीने खा जाता है — वह है दोनों को आपस में उलझा देना: जब ज़रूरत BaaS पार्टनर और एक ऐप की थी तब “बैंकिंग लाइसेंस” ढूँढना, या यह मानकर ऐप ढूँढना कि अनुमति उसके साथ जुड़ी आएगी।
इन्हें अलग खरीद के रूप में देखना इसलिए स्पष्टता देता है कि आप दोनों की कीमत और समय-सारणी अलग-अलग तय कर सकते हैं। सॉफ़्टवेयर को उसकी खूबियों पर परखा जा सकता है — ऑनबोर्डिंग फ़्लो काम करता है या नहीं, लेजर सही है या नहीं, ऑपरेटर उसे वाकई चला सकते हैं या नहीं — जबकि अनुमति को अधिकार-क्षेत्र, safeguarding और शर्तों पर परखा जाता है। Protocore Pay (/products/pay) सॉफ़्टवेयर लेयर का अपने आप में एक उदाहरण है: एक whitelabel ऐप प्लेटफ़ॉर्म और ऑपरेटर कंसोल, जो आपके लाए किसी भी विनियमित रेल के ऊपर चलता है। यह लाइसेंस नहीं है, और कोई भी सॉफ़्टवेयर लाइसेंस नहीं होता — इसीलिए योजना में लाइसेंस एक अलग मद बना रहता है।
किसी भी प्लेटफ़ॉर्म वेंडर से पूछने लायक सवाल
“अपना fintech लॉन्च करें” वाला प्लेटफ़ॉर्म कोई भी पिच करे, यही छोटी-सी सूची ज़्यादातर अस्पष्टता छाँट देती है। क्या आपके उत्पाद में विनियमित अनुमति शामिल है, या मुझे अपनी लानी है? अगर शामिल है, तो लाइसेंस किसका है, किन देशों में, और क्या मैं उस संस्था का सीधा ग्राहक हूँ या उसके एजेंट का? ग्राहकों के फ़ंड की सुरक्षा कौन करता है, और वे कहाँ रखे जाते हैं? एंटी-मनी-लॉन्ड्रिंग के लिए नियामक के सामने किसका नाम है — आपका, पार्टनर का या मेरा? लाइसेंस मेरा न होने पर भी कौन-से दायित्व अनुबंध से मुझ पर आते हैं? और अगर साझेदारी खत्म हो जाए, तो मेरे ग्राहकों के पैसे और उनके डेटा का क्या होगा? इनके जवाब वेंडरों को जल्दी तीन खानों में बाँट देते हैं — जो सॉफ़्टवेयर बेचते हैं, जो किसी पार्टनर की अनुमति दोबारा बेचते हैं, और जिन्होंने सचमुच दोनों को बंडल किया है — और बताते हैं कि आप असल में किससे बात कर रहे हैं।
इस सबकी राहत देने वाली तस्वीर: ज़्यादातर ऐप सॉफ़्टवेयर और पार्टनर की अनुमति के साथ लॉन्च होते हैं, और अपने लाइसेंस की ओर तभी बढ़ते हैं जब वॉल्यूम, मार्जिन या रणनीति पूँजी और compliance टीम को सार्थक बना दे। यह जानना कि आपको असल में कौन-सी पायदान चाहिए — और कि सॉफ़्टवेयर और अनुमति अलग मदों में खरीदे जाते हैं — आधी लड़ाई है। बाकी है ऊपर के सवाल पूछना और जवाबों को ध्यान से पढ़ना। इनमें से कुछ भी कानूनी सलाह नहीं है, और सीमाएँ व श्रेणियों के नाम अधिकार-क्षेत्र के अनुसार बदलते हैं; इसे वह नक्शा मानें जो आप नियामक या सलाहकार से बातचीत में साथ ले जाते हैं, उनका विकल्प नहीं।
कोई सिस्टम बनवाना है?
हमें समस्या बताइए। हम आर्किटेक्चर और योजना के साथ लौटेंगे।