P2P में इंटरनल फ्रॉड: जब कर्मचारी और भुगतान लेजर से मेल न खाएँ

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

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

पहला मामला: कन्फ़र्मेशन विश्वसनीय दिखता है, पैसा पूरा नहीं

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

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

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

दूसरा मामला: मंज़ूर कुछ हुआ, भेजा कुछ और गया

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

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

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

तीसरा मामला: दो लोग भी आपस में मिल सकते हैं

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

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

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

ट्रायंगुलेशन ग्राहक की जानी-पहचानी तस्वीर तोड़ देता है

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

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

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

कर्मचारियों का शिकार किए बिना जाँच

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

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

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