ख़ुद बनाएँ या ख़रीदें: कोर बैंकिंग सिस्टम की असली लागत

देर-सबेर हर फ़िनटेक संस्थापक एक ही फ़ैसले की क़ीमत आँकता है: कोर बैंकिंग सिस्टम इन-हाउस बनाया जाए, या एक का लाइसेंस लेकर उसे कॉन्फ़िगर किया जाए। भोली तुलना — एक तरफ़ लाइसेंस फ़ीस, दूसरी तरफ़ कुछ डेवलपर वेतन — लगभग हमेशा ग़लत होती है, क्योंकि दोनों कॉलमों में एक जैसी चीज़ें होती ही नहीं।

ईमानदार तुलना है प्रोडक्ट के पूरे जीवनकाल की कुल स्वामित्व लागत: निर्माण, स्थायी रखरखाव, सुरक्षा और कंप्लायंस का चलता रहने वाला काम, और वह राजस्व जो निर्माण के दौरान आप नहीं कमाते। हम कोर बैंकिंग सॉफ़्टवेयर बनाते हैं, तो ज़ाहिर है हमारा एक पक्ष है — लेकिन नीचे दिया गया हिसाब वही है जो ख़रीदार होते तो हम ख़ुद देखना चाहते।

"कोर बैंकिंग सिस्टम" का असल मतलब क्या है

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

• ट्रांज़ैक्शनल कोर: एक डबल-एंट्री लेजर जो समवर्ती लोड में भी संतुलित रहता है, जहाँ हर बैलेंस लेजर से निकाला जाता है और हर प्रोवाइडर के साथ रोज़ मिलान होता है।
• ग्राहक प्रोडक्ट: ख़ुद बैंकिंग ऐप, KYC और KYB टियर वाली ऑनबोर्डिंग, मल्टी-करेंसी अकाउंट, ट्रांसफ़र, कार्ड — और, बढ़ते हुए, ऐसे क्रिप्टो वॉलेट जिनके पीछे असली की-कस्टडी हो।
• दूसरा प्रोडक्ट जिसे कोई दायरे में नहीं गिनता: कंप्लायंस क़तारों, ट्रांज़ैक्शन मॉनिटरिंग, फ़ी कॉन्फ़िगरेशन, रिपोर्टिंग और बारीक स्टाफ़ रोल्स के लिए एक ऑपरेशंस बैक ऑफ़िस।
• अदृश्य परत: एक अपेंड-ओनली ऑडिट ट्रेल, लॉगिन से आगे के टू-फ़ैक्टर फ़्लो, रेट लिमिटिंग, डिवाइस फ़िंगरप्रिंटिंग, और ऐसी की-मैनेजमेंट व्यवस्था जो सीक्रेट्स को कोड और डेटाबेस से बाहर रखती है।

बनाने का रास्ता: बजट में असल में क्या-क्या है

एक यथार्थवादी इन-हाउस निर्माण के लिए चाहिए वित्तीय सिस्टम के अनुभव वाले सीनियर बैकएंड इंजीनियर, फ़्रंटएंड इंजीनियर, DevOps और सुरक्षा, QA, और ऐसी प्रोडक्ट कोऑर्डिनेशन जो कंप्लायंस समझती हो। प्रोडक्शन गुणवत्ता तक पहुँचने वाली टीमें शायद ही कभी छह से दस सीनियर लोगों से छोटी होती हैं — और सबसे दुर्लभ प्रोफ़ाइल, यानी वे इंजीनियर जो प्रोडक्शन में लेजर और कस्टडी चला चुके हैं, ठीक वही है जिसे नियुक्त करना और रोके रखना सबसे कठिन है।

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

और ख़र्च लॉन्च पर ख़त्म नहीं होता। प्रोवाइडर APIs बदलते हैं, ब्लॉकचेन नेटवर्क अपग्रेड होते हैं, नियमन बदलता है, डिपेंडेंसी पुरानी पड़ती हैं। इन-हाउस कोर कोई ख़त्म हो जाने वाला प्रोजेक्ट नहीं है; यह एक स्थायी टीम है जिसे आप तब तक फ़ंड करने का वादा कर रहे हैं जब तक प्रोडक्ट मौजूद है।

वे लागतें जो कभी स्प्रेडशीट में नहीं आतीं

• अवसर लागत: लेजर बनाने में लगा हर महीना वह महीना है जब प्रोडक्ट बाज़ार में नहीं है। जिन प्रतिस्पर्धियों ने अपना कोर लाइसेंस पर लिया, वे ग्राहक जोड़ रहे हैं और प्राइसिंग पर काम कर रहे हैं, जबकि आप अभी प्रोवाइडर इंटीग्रेट कर रहे हैं।
• हायरिंग जोखिम: योजना मानकर चलती है कि जो टीम निर्माण शुरू करती है वही उसे पूरा करेगी। लेजर समझने वाले दो इंजीनियरों में से एक को बीच प्रोजेक्ट में खो देना ऐसा शेड्यूल झटका है जो महीनों में मापा जाता है।
• शुद्धता की पूँछ: 99% सही लेजर लगभग तैयार नहीं है — वह सपोर्ट टिकटों, मिलान की गड़बड़ियों और नियामकीय घटनाओं की फ़ैक्ट्री है। आख़िरी 1% की लागत पहले 99% से ज़्यादा होती है।
• सुरक्षा एक सतत ऑपरेशन के रूप में: पेनेट्रेशन टेस्ट, की-रोटेशन, इंसिडेंट रिस्पॉन्स, मॉनिटरिंग और अलर्टिंग — ऐसे आवर्ती ख़र्च जो कुछ ग़लत हो या न हो, बने रहते हैं।
• कंप्लायंस का रखरखाव: KYC दस्तावेज़ों की समाप्ति, बदलते क्रिप्टो-एसेट नियम, नई रिपोर्टिंग बाध्यताएँ। यह काम हर साल दोहराया जाता है और टाला नहीं जा सकता।
• बैक ऑफ़िस: इन-हाउस निर्माण स्टाफ़ टूलिंग को अक्सर बाद की सोच मानते हैं, और ऑपरेशंस टीम को विरासत में मिलती है एक SQL कंसोल। जो भी रेगुलेटर या ऑडिटर उसे देखेगा, वह आपसे उसे ठीक से दोबारा बनवाएगा।
• लोकलाइज़ेशन: असली RTL समर्थन के साथ कई भाषाओं में शिप करना तब सस्ता है जब पहले दिन से डिज़ाइन में शामिल हो, और प्रोडक्ट बन जाने के बाद जोड़ना महँगा।

ख़रीदने का रास्ता: आप किसका भुगतान करते हैं और क्या आपका रहता है

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

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

कब इन-हाउस बनाना ही सही फ़ैसला है

बनाएँ-या-ख़रीदें कोई तयशुदा जवाब वाला अलंकारिक सवाल नहीं है। बनाना तब सही है जब इनमें से कम से कम एक बात सच हो:

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

पाँच सवालों का फ़्रेमवर्क

• अंतर: क्या कोई ग्राहक कभी आपको इसलिए चुनेगा कि आपका लेजर घर का बना है? अगर आपकी बढ़त प्रोडक्ट, वितरण या प्राइसिंग में है, तो कोर प्लंबिंग है — अनिवार्य, पर आपके दोबारा ईजाद करने की चीज़ नहीं।
• समय-सीमा: क्या कारोबार बिना राजस्व के एक-दो साल झेल सकता है जब तक कोर बनता है, ऐसे बाज़ार में जो इंतज़ार नहीं करता?
• टीम: क्या आपके पास ऐसे इंजीनियर हैं — या आप उन्हें यथार्थ रूप से नियुक्त कर और रोक सकते हैं — जिन्होंने प्रोडक्शन में पैसा घुमाने वाले सिस्टम चलाए हों?
• तीन साल की लागत: निर्माण लागत और स्थायी रखरखाव टीम की तुलना तीन साल में लाइसेंस और सक्रिय मॉड्यूलों से करें — कभी भी लॉन्च लागत की तुलना लॉन्च लागत से नहीं।
• निकास: हर रास्ते पर बाहर निकलना कैसा दिखता है? इन-हाउस में जोखिम यह है कि अहम लोग ज्ञान लेकर चले जाएँ। वेंडर के साथ, समर्पित इंस्टेंस, अपनी डेटाबेस और अपनी कुंजियाँ माँगें — तब निकास एक माइग्रेशन है।

इस फ़ैसले में Coreza कहाँ खड़ा है

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

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