Swift फ़ोन नंबर से अंतरराष्ट्रीय ट्रांसफ़र की जाँच कर रहा है

लंबी बैंक डिटेल पैसे भेजने से पहले ही एक बड़ी रुकावट बन जाती है। 28 सितंबर 2026 को Swift ने pay-by-alias पहल पेश की: Swift pay-by-alias में भागीदार फ़ोन नंबर या ईमेल जैसे जाने-पहचाने आइडेंटिफ़ायर के ज़रिए अंतरराष्ट्रीय ट्रांसफ़र पर शोध कर रहे हैं। जुड़ने वाले स्थानीय तरीकों में Bizum, PayID और Pix का नाम लिया गया है। काम अभी proof of concept के चरण में है।

भुगतान का सबसे ज़्यादा दिखने वाला हिस्सा

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

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

आसान पता पूरे रूट को नहीं बताता

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

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

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

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

बैंकों और PSP के लिए इसका क्या मतलब है

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

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

आगे किस पर नज़र रखें

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

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