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

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

वास्तव में क्या पुष्ट है

हम ख़ुद को उन्हीं बातों तक सीमित रखते हैं जो कंपनी ने घोषित कीं और जो विशेषज्ञ प्रकाशनों ने रिपोर्ट कीं, क्योंकि जाँच जारी है और बहुत कुछ अभी सामने नहीं आया है:

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

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

अनुरोध सफल क्यों हुआ: प्रमाणीकरण प्राधिकरण नहीं है

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

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

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

आपके व्यवसाय को वही अनुरोध सरल रूप में मिलता है

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

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

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

सऊदी कानून आपसे क्या माँगता है

व्यक्तिगत डेटा संरक्षण कानून (PDPL) इस सवाल को खुला नहीं छोड़ता। यह आपके व्यवसाय पर दोहरा दायित्व डालता है: केवल वहीं खुलासा करें जहाँ अनुमति हो, और ग़लती होने पर रिपोर्ट करें।

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

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

Origami का दृष्टिकोण

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

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

इस हफ़्ते अपनाने के लिए एक पन्ने की प्रक्रिया

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

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

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

स्रोत