तुमचे एजंट तुमची सुरक्षा समस्या नसावेत — आणि तुमची इन्फ्रास्ट्रक्चरही नसावी

गेल्या काही वर्षांत, आम्ही भारतभर डझनभर सहकारी बँका आणि बँकिंग सॉफ्टवेअर कंपन्यांशी बोललो आहोत. त्यापैकी जवळपास प्रत्येकाने संकलन पायाभूत सुविधांपर्यंत एकाच मार्गाने पोहोचले: कोणीतरी Android app बनवले, ते core banking system शी जोडले, आणि agents मैदानात संकलन करू लागले. ते काम केले. सदस्यांना पावत्या मिळाल्या. ठेवी आल्या.

सुरक्षा नंतर आली. ती नेहमीच नंतर येते.

हे टीका नाही. जवळपास प्रत्येक उत्पादन कसे बनवले जाते हेच आहे — आधी वैशिष्ट्ये, कारण वैशिष्ट्ये दृश्यमान मूल्य निर्माण करतात. सुरक्षा अपयशी होईपर्यंत अदृश्य असते, त्यामुळे ती वाट पाहते.

बहुतेक उद्योगांमध्ये, ही कालमर्यादा स्वीकार्य आहे. बँकिंग संकलन पायाभूत सुविधांमध्ये, "नंतर" म्हणजे सदस्य डेटा उल्लंघन, RBI ऑडिट निरीक्षण, किंवा सहा महिन्यांचे संकलन नोंदी घेऊन गेलेला फील्ड agent चा फोन — थांबवण्याचा कोणताही मार्ग नसताना.

आम्ही आमच्या सुरुवातीच्या दिवसांत ezPigmy त्याच प्रकारे बनवले. हे कसे होते हे आम्हाला नेमके समजते.

---

"पूर्ण संकलन पायाभूत सुविधा" म्हणजे नक्की काय

जेव्हा बँक किंवा बँकिंग सॉफ्टवेअर कंपनी संकलन पायाभूत सुविधा बनवण्याचा निर्णय घेते, तेव्हा पृष्ठभाग व्यवस्थापनीय वाटतो: एक Android app, एक backend API, एक database.

प्रत्यक्ष व्याप्ती पूर्णपणे वेगळी बाब आहे.

उत्पादन-तयार, अनुपालन-योग्य संकलन पायाभूत सुविधांसाठी काय आवश्यक आहे — प्रत्येक आयटम एक स्वतंत्र अभियांत्रिकी आणि नियामक समस्या:

UPI switch — NPCI सदस्यत्व किंवा उप-सदस्यत्व, देयक निपटारा प्रवाह, स्वयंचलित सुलह, विवाद निराकरण, व्यवहार मर्यादा, आणि 24/7 uptime बंधने.

NCMC card switch — National Common Mobility Card प्रमाणन, अनियमित कनेक्टिव्हिटी असलेल्या ग्रामीण भागांसाठी offline prepaid card व्यवहार समर्थन, आणि card जीवनचक्र व्यवस्थापन. UPI पेक्षा पूर्णपणे वेगळा प्रमाणन मार्ग.

RuPay switch — देशांतर्गत card नेटवर्क एकीकरण, PCI-DSS अनुपालन व्याप्ती, व्यवहार routing, आणि सहसा सहा ते बारा महिने घेणारी प्रमाणन प्रक्रिया.

Managed Android device — Mobile Device Management stack, application lockdown धोरणे, agents ना अनधिकृत apps इन्स्टॉल करण्यापासून रोखणारी OS-स्तरीय अंमलबजावणी, आणि device offline झाल्यानंतर पुन्हा कनेक्ट झाल्यावर काम करणारी remote wipe क्षमता.

Device-level security — चोरलेला पासवर्ड वेगळ्या device वरून वापरता येणार नाही यासाठी cryptographic session binding, session keys साठी सुरक्षित संचयन, आणि विशिष्ट व्यवस्थापित terminal शी जोडलेले biometric प्रमाणीकरण.

Encrypted transactions — ट्रान्झिटमधील डेटासाठी TLS 1.3, विश्रांतीतील डेटासाठी AES-256, आणि encryption keys उघड न करता फिरवणारी आणि संरक्षित करणारी key व्यवस्थापन प्रणाली.

SMS alert infrastructure — TRAI सह DLT नोंदणी, message template मंजुरी, sender ID नोंदणी, delivery tracking, आणि प्राथमिक मार्ग अपयशी झाल्यावर fallback routing.

WhatsApp Business API — Business Solution Provider भागीदारी, Meta कडून message template मंजुरी, delivery receipt हाताळणी, आणि opt-out व्यवस्थापन.

Full audit trail — प्रत्येक session आणि व्यवहारासाठी tamper-proof, device-timestamped logs — नियामक आणि ऑडिटर वाचू आणि सत्यापित करू शकतात अशा स्वरूपात निर्यात करता येतात.

हे scratch पासून बनवणाऱ्या सक्षम संघासाठी वास्तववादी अंदाज: सहा ते आठ अभियंते, अठरा ते चोवीस महिने, त्यापैकी काहीही उत्पादन-कठोर आणि प्रमाणित करण्यापूर्वी.

---

सुरक्षा ही शेवटची गोष्ट आहे जी कोणी विचार करतो (जोपर्यंत ती नाही)

सुरक्षा जवळपास नेहमीच कोणत्याही उत्पादनात जोडली जाणारी शेवटची थर असते. संघ निष्काळजी आहेत म्हणून नाही — कारण ती अपयशी होईपर्यंत अदृश्य असते, आणि अपयशी वैशिष्ट्य नेहमीच अदृश्य धोक्यापेक्षा अधिक तातडीचे असते.

बँकिंग संकलन सॉफ्टवेअरमध्ये, तीन गोष्टी विलंबित सुरक्षेला विशेषतः महाग बनवतात:

सदस्य आर्थिक डेटा. उल्लंघन एखाद्या अमूर्त वापरकर्ता खात्यावर परिणाम करत नाही. हे सदस्याच्या pigmy बचत शिल्लकावर, त्यांच्या कर्ज परतफेडीच्या इतिहासावर, त्यांच्या ठेव नोंदीवर परिणाम करते. खरे लोक, खरे पैसे, खरी हानी.

फील्ड agents कार्यालयापासून दूर काम करतात. संकलन app साठी आक्रमण पृष्ठभाग तुमचा server room नाही — तो तुमचे agents भेट देणाऱ्या प्रत्येक गावातील प्रत्येक device आहे. कार्यालयीन नेटवर्कमध्ये firewalls आणि IT देखरेख आहे. ग्राहकाच्या दरवाजावर वैयक्तिक फोनमध्ये agent ने गेल्या आठवड्यात इन्स्टॉल केलेले कोणतेही apps आहेत.

नियामक अधिक काळजीपूर्वक पाहत आहेत. शहरी सहकारी बँकांसाठी IT शासनावरील RBI च्या Master Circular ने बँकांनी सदस्य डेटा ऍक्सेस करणाऱ्या प्रत्येक device वर नियंत्रण प्रदर्शित करावे अशी अपेक्षा ठेवते. "Agent त्यांचा वैयक्तिक फोन वापरतात" हे ऑडिटर कोणते device नियंत्रणे अंमलात आहेत असे विचारतात तेव्हा समाधानकारक उत्तर नाही.

आम्ही विशिष्ट, दस्तऐवजीकृत आक्रमण वेक्टर्सबद्दल तपशीलवार लिहिले आहे — malware व्यवहार फायली वाचत आहे, clipboard hijack हल्ले OTP चोरत आहेत, बनावट app overlays क्रेडेन्शियल्स पकडत आहेत, remote wipe शिवाय हरवलेले फोन. तुम्ही ते वाचले नसल्यास: तुमच्या agent चा वैयक्तिक फोन तुमच्या बँकेसाठी सुरक्षा धोका का आहे.

विद्यमान आर्किटेक्चरवर retrofit केलेली सुरक्षा नेहमीच सुरुवातीपासून डिझाइन केलेल्या सुरक्षेपेक्षा अधिक खर्च करते आणि कमी संरक्षण देते. वेदनादायक ऑडिट निरीक्षण टाळणारे संघ ते आहेत ज्यांनी सक्तीच्या घटनेची वाट पाहिली नाही.

---

AI च्या युगात, कोणीही स्कॅम app बनवू शकतो

काही वर्षांपूर्वी, विश्वासार्ह बनावट बँकिंग app बनवण्यासाठी कुशल developer आवश्यक होता — आठवड्यांचे काम, विशिष्ट ज्ञान, खरे प्रयत्न. तो अडथळा आता गेला आहे.

आज, AI coding tools काही तासांत plain-text वर्णनातून काम करणारे Android APK तयार करू शकतात. तांत्रिक नसलेली व्यक्ती त्यांना काय हवे आहे ते वर्णन करू शकते — "pigmy संकलन app सारखे दिसणारे app, login क्रेडेन्शियल्स पकडते आणि server ला पाठवते" — आणि कार्यात्मक code मिळवते. कोणत्याही programming पार्श्वभूमीची आवश्यकता नाही.

यामुळे agents च्या वैयक्तिक फोनवर संकलन सॉफ्टवेअर चालवणाऱ्या प्रत्येक बँकेचे धोका प्रोफाइल बदलते. विश्वासार्ह दुर्भावनापूर्ण app बनवणे कठीण आहे यावर विश्वास ठेवणे आता पुरेसे नाही. ते नाही.

संकलन सॉफ्टवेअर व्यवस्थापित नसलेल्या वैयक्तिक फोनवर चालत असताना शक्य होणारे विशिष्ट स्कॅम प्रकार येथे आहेत:

1. बनावट संकलन app overlay — खऱ्या संकलन app च्या वर एक समान स्क्रीन प्रस्तुत करणारे app. Agent त्यांचे login क्रेडेन्शियल्स प्रविष्ट करतात तेव्हा, बनावट app खऱ्या app ला नियंत्रण देण्यापूर्वी ते पकडते आणि पुढे पाठवते. Agent ला काहीही असामान्य दिसत नाही.

2. AI-cloned UPI देयक स्क्रीन — खरे देयक हल्लेखोराच्या VPA कडे पाठवत असताना सदस्याला यशस्वी देयक पुष्टी दाखवणारी बनावट UPI व्यवहार UI. पावती खरी वाटते. पैसे इतरत्र जातात.

3. Silent data harvesting APK — "read storage" परवानगी मागते, अनेक agents न वाचता देतात. संकलन app च्या स्थानिक व्यवहार इतिहास, सदस्य नावे, फोन नंबर आणि खाते तपशील शांतपणे वाचते. सर्वकाही remote server वर upload करते. कोणतेही दृश्यमान वर्तन नाही.

4. Clipboard OTP interceptor — clipboard सतत निरीक्षण करते. SMS द्वारे OTP आल्यावर आणि agent ते कॉपी करतात तेव्हा, interceptor सेकंदांत ते पकडते आणि हल्लेखोराला पाठवते — agent ते वापरण्यापूर्वीच.

5. WhatsApp impersonation bot — Agent च्या WhatsApp session (त्याच वैयक्तिक फोनवर) चा उपयोग agent कडून आलेल्यासारखे वाटणारे संदेश सदस्यांना पाठवण्यासाठी करतो, नवीन खाते क्रमांकावर देयके मागतो.

6. बनावट passbook display — खऱ्या system मध्ये कमी ठेव रक्कम नोंदवत असताना सदस्यांना वाढीव बचत शिल्लक दाखवते. विसंगती आठवड्यांनंतर ऑडिटमध्ये दिसून येते, स्पष्ट पुरावा साखळीशिवाय.

7. Session token चोरी — संकलन app च्या स्थानिक स्टोरेजमधून live authenticated session token काढतो आणि remote device वरून replay करतो. DPoP-असंरक्षित session सह, यामुळे agent च्या माहितीशिवाय पूर्ण खाते प्रवेश मिळतो.

यापैकी कोणताही हल्ला सैद्धांतिक नाही. सर्व एकाच मूळ अवस्थेचा फायदा घेतात: अनेक स्रोतांकडून अनेक apps चालवणारा वैयक्तिक फोन, काय इन्स्टॉल केले आहे यावर कोणतेही संस्थात्मक नियंत्रण नाही.

लॉक-डाउन व्यवस्थापित संकलन terminal वर, यापैकी कोणतेही आक्रमण पृष्ठभाग अस्तित्वात नाही. device वर फक्त एकच application आहे. ते बदलले, overlay केले किंवा पूरक केले जाऊ शकत नाही. File system इतर कोणत्याही process द्वारे वाचता येत नाही. Hijack करण्यासाठी clipboard नाही कारण WhatsApp नाही, browser नाही, कोणत्याही प्रकारचे दुसरे app नाही.

प्रत्येक बँकेसाठी प्रश्न हे हल्ले केले जातील का हा नाही. प्रश्न तुमचे agents वापरत असलेले device त्या हल्ल्यांना उतरण्यासाठी पृष्ठभाग देते का हा आहे.

---

ezPigmy Stack चे API तुम्हाला बदल्यात काय देते

ezPigmy Stack ही अशी पायाभूत सुविधा थर आहे जिच्याशी सहकारी बँका आणि बँकिंग सॉफ्टवेअर पुरवठादार एकत्रित होऊ शकतात — प्रत्येक भाग स्वतःच बनवण्याऐवजी आणि प्रमाणित करण्याऐवजी. आधीच उत्पादनात चालत असलेले हे आहे:

UPI Switch — NPCI-प्रमाणित UPI संकलन. Agents QR code किंवा push-pay द्वारे दरवाजावर संकलन करतात. निपटारा, सुलह आणि विवाद हाताळणी पायाभूत सुविधा स्तरावर व्यवस्थापित केली जाते. तुमचे application एक API call करते; switch बाकी सर्व हाताळतो.

NCMC Card Switch — ezPigmy Stack च्या प्रमाणित switch द्वारे National Common Mobility Card व्यवहार प्रक्रिया केले जातात. अनियमित कनेक्टिव्हिटीसह काम करणाऱ्या ग्रामीण agents साठी offline prepaid card संकलनास समर्थन देते. तुमच्या बाजूने वेगळ्या NCMC प्रमाणनाची आवश्यकता नाही.

RuPay Switch — प्रमाणित REST API द्वारे देशांतर्गत RuPay card स्वीकृती. PCI-DSS अनुपालन व्याप्ती platform सोबत आहे. तुमचे एकीकरण एकच authenticated API call आहे.

Managed Android Device — संकलन application साठी लॉक केलेले उद्देश-निर्मित संकलन terminal. Play Store नाही, वैयक्तिक app इन्स्टॉलेशन नाही, WhatsApp नाही. MDM platform स्तरावर प्रशासित केले जाते. बँकांकडे व्यवस्थापन console वरून remote wipe, session रद्द करणे आणि device ऑडिट उपलब्ध आहे.

Encrypted Transactions — प्रत्येक व्यवहार TLS 1.3 वर प्रवास करतो. विश्रांतीतील डेटा AES-256. Session tokens DPoP वापरून जारी करणाऱ्या device शी cryptographically bound असतात — चोरलेला पासवर्ड वेगळ्या device वर session उघडण्यासाठी पुरेसा नाही. हे कसे कार्य करते →

SMS Alerts — Template व्यवस्थापन आणि delivery tracking सह DLT-नोंदणीकृत पायाभूत सुविधा. सदस्यांना संकलनाच्या ठिकाणी पुष्टी मिळते. वेगळ्या telecom विक्रेता संबंधाची आवश्यकता नाही.

WhatsApp Notifications — WhatsApp Business API कनेक्टेड notification pipeline. संकलन पुष्टी, देयक पावत्या आणि passbook अपडेट WhatsApp वर सदस्यांना वितरित केले जातात. Template मंजुरी आणि BSP भागीदारी ezPigmy Stack द्वारे व्यवस्थापित.

Full Audit Trail — प्रत्येक login, प्रत्येक व्यवहार, प्रत्येक session घटना device ओळखकर्ता, agent ओळख आणि server-सत्यापित timestamp सह लॉग केले जातात. नियामक-तयार. मागणीनुसार निर्यात.

---

बनवा विरुद्ध एकत्रित करा: प्रामाणिक तुलना

दोन्ही मार्ग खरे पर्याय आहेत. प्रश्न पुढील दोन वर्षांत तुमच्या संघाचा वेळ काय मूल्य आहे — आणि नियामकापूर्वी किंवा नंतर तुमच्या सुरक्षा आर्किटेक्चरमधील कोणत्याही उणीवा शोधायच्या आहेत का.

---

बँकिंग सॉफ्टवेअर पुरवठादारांना: API मार्ग तुमच्या ग्राहकांसाठी आणि तुमच्यासाठी चांगला आहे

तुम्ही सहकारी बँकांसाठी संकलन सॉफ्टवेअर बनवत असाल, तर हा विभाग तुमच्यासाठी आहे.

तुमचे application एखाद्या agent च्या वैयक्तिक फोनवर चालत असताना, त्या deployment ची सुरक्षा स्थिती फोन कारखाना सोडलेल्या दिवशी ठरवली गेली — तुमच्या संघाने नाही, बँकेने नाही. Agent ने तेव्हापासून इन्स्टॉल केलेल्या प्रत्येक गोष्टीने, त्यांनी दिलेल्या प्रत्येक परवानगीने, आणि device हरवल्यास कोणाला ते पोहोचता येईल का याने आकार दिला गेला.

ही व्यवस्थापित नसलेल्या hardware वर deploy करण्याची संरचनात्मक मर्यादा आहे. हे तुमच्या उत्पादनाचे प्रतिबिंब नाही.

चिंता धोका कुठे उतरतो याबद्दल आहे. जेव्हा एखाद्या बँकेला agent device नियंत्रणांबद्दल ऑडिट निरीक्षण मिळते, तेव्हा संभाषण ते वापरत असलेल्या सॉफ्टवेअरकडे आणि त्या सॉफ्टवेअरने काय प्रदान केले याकडे वळते. Device व्यवस्थापन, session नियंत्रणे आणि audit trail प्रदर्शित करू न शकणाऱ्या बँकेला नियामकाशी कठीण संभाषण करावे लागते — त्यांचे उर्वरित systems कितीही चांगले असले तरी.

ezPigmy Stack सोबत API एकीकरण हे बदलते. तुमचे उत्पादन तुमचेच राहते — तुमचा interface, तुमचा workflow, बँकेशी तुमचे नाते. Device, देयक switches, encryption थर आणि अनुपालन आर्किटेक्चर platform द्वारे प्रदान केले जाते. तुमचे बँक ग्राहक तुमच्या उत्पादनाद्वारे पहिल्या दिवसापासून व्यवस्थापित, प्रमाणित, ऑडिट करण्यायोग्य पायाभूत सुविधा मिळवतात.

हे तुम्ही बनवलेल्या गोष्टी बदलण्याबद्दल नाही. हे तुमच्या ग्राहकांना एक मजबूत पाया देण्याबद्दल आहे — आणि तुमच्यापैकी कोणाकडेही असण्याची गरज नाही असा धोका वर्ग काढून टाकण्याबद्दल आहे.

तुमच्या विद्यमान उत्पादनासोबत एकीकरण कसे काम करू शकते याबद्दल तुम्हाला स्वारस्य असल्यास, आम्ही त्या संभाषणासाठी उघडे आहोत.

---

तुमच्या बँकेसाठी पूर्ण stack चालताना पाहायचे आहे का? मोफत demo बुक करा →

बँकांसाठी संकलन सॉफ्टवेअर बनवत आहात आणि API एकीकरण एक्सप्लोर करायचे आहे का? बोलूया →