SWIFT

MT और MX संदेशों के माध्यम से SWIFT अंतरण एवं संचार

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

सामान्य SWIFT अंतरण MT (मैसेज टाइप) संदेशों के नाम से जाने जाने वाले मानकीकृत संदेश प्रकारों की एक श्रृंखला का उपयोग करते हैं। इन संदेशों के प्रारूप और फ़ील्ड पूर्व-निर्धारित होते हैं, जिससे वित्तीय संस्थान उनमें निहित जानकारी को सरलता से समझ और संसाधित कर सकते हैं।

MX (ISO 20022) संदेश वित्तीय संदेश प्रेषण का एक नया मानक हैं, जो XML (eXtensible Markup Language) पर आधारित है। ये अधिक समृद्ध और संरचित प्रारूप प्रदान करते हैं, जिससे उन्नत डेटा विनिमय और बेहतर स्ट्रेट-थ्रू प्रोसेसिंग संभव होती है। SWIFT नेटवर्क में MX संदेश क्रमशः MT संदेशों का स्थान ले रहे हैं, जिसका उद्देश्य बेहतर अंतर-संचालनीयता और डेटा प्रबंधन क्षमताएँ प्रदान करना है।

यद्यपि पारंपरिक SWIFT अंतरण दशकों से अंतरराष्ट्रीय भुगतानों की रीढ़ रहे हैं, फिर भी इनकी कुछ सीमाएँ हैं, जिनमें सीमित पारदर्शिता, धीमी प्रसंस्करण गति और असंरचित डेटा शामिल हैं।

Swift 103+ STP (स्ट्रेट थ्रू प्रोसेसिंग)

Swift 103+ STP स्ट्रेट थ्रू प्रोसेसिंग (STP) के लिए अनुकूलित पारंपरिक MT प्रारूप था; सह-अस्तित्व की समाप्ति के बाद इसकी भूमिका pacs.008 STP उपयोग दिशानिर्देश ने ले ली है। STP के माध्यम से आरंभ से लेकर अंतिम निपटान तक की संपूर्ण भुगतान प्रक्रिया बिना किसी मैन्युअल हस्तक्षेप के इलेक्ट्रॉनिक रूप से संपन्न की जा सकती है।

अतिरिक्त विशेषताएँ:

1. मानकीकृत प्रारूप: इसमें मानकीकृत प्रारूप का कड़ाई से पालन आवश्यक है, जिससे त्रुटियाँ और विलंब कम होते हैं।
2. स्वचालित प्रसंस्करण: लेन-देन स्वचालित रूप से संसाधित किए जाते हैं, जिससे तीव्र और अधिक कुशल प्रसंस्करण सुनिश्चित होता है।
3. मैन्युअल हस्तक्षेप में कमी: मैन्युअल प्रविष्टि और सत्यापन की आवश्यकता न्यूनतम हो जाती है, जिससे त्रुटियों और विलंब का जोखिम घटता है।
4. तेज़ निपटान: पारंपरिक पद्धतियों की तुलना में लेनदेन का निपटान अधिक शीघ्रता से होता है।

STP के लिए विचारणीय बिंदु:

1. सटीक डेटा प्रविष्टि: विलंब या अस्वीकृति से बचने के लिए डेटा सटीक रूप से दर्ज किया जाना चाहिए।
2. प्रारूप संबंधी अपेक्षाओं का अनुपालन: बैंकों को सुनिश्चित करना होगा कि 103+ STP की प्रारूप संबंधी अपेक्षाओं का कड़ाई से पालन किया जाए।
3. सॉफ़्टवेयर और प्रणालियाँ: STP को प्रभावी ढंग से संभालने के लिए बैंकों के पास उपयुक्त सॉफ़्टवेयर और प्रणालियाँ होना आवश्यक है

संदेश-प्रेषण और निपटान के बीच अंतर समझना आवश्यक है। SWIFT संस्थाओं के बीच संरचित वित्तीय संदेशों का प्रेषण करता है, किंतु वह स्वयं न तो निधियों का अंतरण करता है और न ही शेष राशियाँ धारण करता है। SWIFT पुष्टि, जिसमें pacs.008 संदेश भी शामिल है, तभी मान्य होती है जब वह सहभागी संस्थाओं की बैंकिंग प्रणालियों में संसाधित और समायोजित किसी वास्तविक लेनदेन से संबद्ध हो।

संस्थागत सत्यापन के बिना प्रस्तुत किसी भी स्वतंत्र SWIFT दस्तावेज़, स्क्रीनशॉट या संदेश को पूर्ण हो चुके निपटान का प्रमाण नहीं माना जाना चाहिए।

SWIFT gpi अंतरण।

SWIFT gpi (ग्लोबल पेमेंट्स इनोवेशन):

2017 में आरंभ की गई SWIFT gpi एक ऐसी पहल है जिसे पारंपरिक SWIFT अंतरणों की सीमाओं को दूर करने के लिए, सीमा-पार भुगतानों की गति, पारदर्शिता और अनुरेखणीयता बढ़ाकर, तैयार किया गया है। SWIFT gpi भुगतान सेवाओं को बेहतर बनाने के लिए मौजूदा MT और MX संदेश प्रारूपों का उपयोग करती है। SWIFT gpi की प्रमुख विशेषताएँ इस प्रकार हैं:

• तीव्र भुगतान: gpi प्रक्रियाओं को सरल बनाता है और बैंकों के बीच कड़े सेवा-स्तर समझौते (SLA) स्थापित करता है, जिसके परिणामस्वरूप लेन-देन का समय कम होता है, प्रायः कुछ मिनटों या सेकंडों के भीतर।
• भुगतान ट्रैकिंग: gpi ट्रैकर वास्तविक समय में लेन-देन की निगरानी संभव बनाता है, जिससे पारदर्शिता बढ़ती है और मैन्युअल जाँच की आवश्यकता घटती है।
• शुल्क पारदर्शिता: बैंक ग्राहकों को लेन-देन शुल्क की जानकारी पहले से उपलब्ध करा सकते हैं, जिससे बेहतर निर्णय लेने में सहायता मिलती है।
• अधिक समृद्ध डेटा: gpi अधिक विस्तृत और संरचित सूचना-विनिमय का समर्थन करता है, जिससे मिलान (रिकॉन्सिलिएशन) और विनियामक अनुपालन बेहतर होता है।

SWIFT gpi पारंपरिक SWIFT अंतरणों की सीमाओं का समाधान करता है और एंड-टू-एंड ट्रैकिंग, तीव्र प्रसंस्करण तथा अधिक समृद्ध डेटा के माध्यम से सीमा-पार भुगतानों को बेहतर बनाता है।

गैर-SWIFT gpi प्रतिभागियों के लिए प्रमुख मापदंड

जब कोई गैर-SWIFT gpi प्रतिभागी (उदाहरणतः कोई बैंक या वित्तीय संस्था जो gpi में प्रत्यक्ष रूप से नामांकित नहीं है) किसी gpi प्रतिभागी बैंक को भुगतान निर्देश भेजता है, तो gpi बैंक उसे आवश्यक SWIFT संदेश प्रारूपों (ग्राहक क्रेडिट अंतरण हेतु pacs.008, कवर अंतरण हेतु pacs.009 COV और वित्तीय संस्था क्रेडिट अंतरण हेतु pacs.009) में परिवर्तित कर सकता है। यह परिवर्तन gpi नेटवर्क के भीतर प्रसंस्करण और ट्रैकिंग को संभव बनाता है, बशर्ते निर्देश में अनिवार्य फ़ील्ड भरने और gpi नियमों के अनुपालन, जैसे एंड-टू-एंड ट्रेसेबिलिटी, के लिए पर्याप्त डेटा हो।

गैर-gpi प्रतिभागी सामान्यतः ये मापदंड घरेलू भुगतान योजनाओं, API या पारंपरिक प्रारूपों के माध्यम से उपलब्ध कराते हैं, और gpi बैंक gpi-विशिष्ट जोड़ संभालता है (जैसे, यदि UETR उपलब्ध न कराया गया हो तो उसे उत्पन्न करना, यद्यपि गैर-gpi संस्थाओं के लिए उसे आगे भेजना वैकल्पिक है)। सटीक आवश्यकताएँ क्षेत्राधिकार, मुद्रा और द्विपक्षीय समझौतों के अनुसार भिन्न हो सकती हैं, परंतु मूल मापदंड CBPR+ (क्रॉस-बॉर्डर पेमेंट्स एंड रिपोर्टिंग प्लस) दिशानिर्देशों और ISO 20022 मानकों से लिए गए हैं। 22 नवंबर 2025 को सह-अस्तित्व की अवधि समाप्त होने के बाद से, सीमा-पार भुगतान निर्देशों का आदान-प्रदान ISO 20022 प्रारूप में होता है; नीचे दिए गए पारंपरिक MT फ़ील्ड संदर्भ केवल सुविधा एवं संदर्भ हेतु हैं।
1. पक्ष पहचान (देनदार और लेनदार का विवरण)
ये प्रवर्तक और लाभार्थी की पहचान करते हैं, जिससे यात्रा नियम (ट्रैवल रूल) संबंधी आवश्यकताओं के लिए FATF अनुशंसा 16 का अनुपालन सुनिश्चित होता है।

• डेबिटर/ऑर्डर देने वाला ग्राहक: पूरा नाम, संरचित पता (सड़क, शहर, डाक कोड, देश) और खाते की पहचान (जैसे IBAN या खाता संख्या)। पूर्व के MT 103/MT 202 COV में यह फ़ील्ड 50a से संबद्ध है; pacs.008/pacs.009 के लिए <Dbtr> और <DbtrAcct> से।
• लेनदार/लाभार्थी ग्राहक: पूरा नाम, संरचित पता और खाता पहचान। यह पूर्ववर्ती MT 103/MT 202 COV के फ़ील्ड 59a से, तथा pacs.008/pacs.009 में <Cdtr> और <CdtrAcct> से संबद्ध है।
• अंतिम ऋणी/ऋणदाता (यदि लागू हो): यदि वे प्राथमिक पक्षों से भिन्न हों, तो बेहतर पारदर्शिता के लिए उनका विवरण शामिल करें (वैकल्पिक, किंतु gpi ट्रैकिंग के लिए अनुशंसित)। यह pacs.008/pacs.009 में <UltmtDbtr>/<UltmtCdtr> से मैप होता है।

आवश्यकता का कारण: सटीक रूटिंग और विनियामक जाँच को संभव बनाता है; अपूर्ण डेटा के कारण लेन-देन अस्वीकृत या विलंबित हो सकते हैं।

2. एजेंट एवं रूटिंग जानकारी
शृंखला में शामिल वित्तीय संस्थानों को निर्दिष्ट करता है।

• डेबिटर एजेंट: प्रेषक बैंक का BIC (बैंक आइडेंटिफ़ायर कोड) या अन्य पहचानकर्ता। यह पूर्ववर्ती MT 103 के फ़ील्ड 52a से संबद्ध है; pacs.008/pacs.009 में <DbtrAgt>।
• क्रेडिटर एजेंट: प्राप्तकर्ता बैंक का BIC। यह पूर्ववर्ती MT 103/MT 202 COV के फ़ील्ड 57a से संबद्ध है; pacs.008/pacs.009 में <CdtrAgt>।
• मध्यस्थ एजेंट (यदि ज्ञात हों): किसी भी कॉरेस्पोंडेंट के BIC (अधिकतम 3 स्तर तक)। पूर्ववर्ती MT में यह फ़ील्ड 56a से मेल खाता है; pacs.008/pacs.009 में <IntrmyAgt1-3>।
• निर्देशक/निर्देशित एजेंट: श्रृंखला में तत्काल प्रेषक/प्राप्तकर्ता के BIC। वैकल्पिक, किंतु सीरियल या कवर पद्धतियों में सहायक।
• पूर्ववर्ती निर्देशक एजेंट (यदि लागू हो): बहु-चरणीय श्रृंखलाओं के लिए, अधिकतम 3 पूर्ववर्ती एजेंट।

यह क्यों आवश्यक है: उचित मध्यस्थ मार्गण सुनिश्चित करता है; pacs.009 COV में सटीकता के लिए नामों के बजाय BICFI का उपयोग करें।

3. लेनदेन विवरण
निपटान के लिए मूल वित्तीय तत्व।

• राशि और मुद्रा: अंतर-बैंक निपटान राशि और ISO 4217 मुद्रा कोड (उदाहरण के लिए, USD, EUR)। पूर्व MT 103/MT 202 COV में फ़ील्ड 32A से संबद्ध; pacs.008/pacs.009 में <IntrBkSttlmAmt>।
• निर्दिष्ट राशि (यदि भिन्न हो): कटौतियों से पूर्व की मूल राशि।
• इंटरबैंक निपटान तिथि: निपटान की मूल्य तिथि। MT में फ़ील्ड 32A के एक भाग से संबद्ध है; pacs.008/pacs.009 में <IntrBkSttlmDt>।
• निपटान पद्धति: इंगित करें कि निपटान RTGS (CLRG), कवर (COVE) या एजेंट (INDA/INGA) के माध्यम से है। कोई प्रत्यक्ष MT समतुल्य नहीं, किंतु अंतर्निहित है।

आवश्यकता का कारण: मूल्य अंतरण को परिभाषित करता है; सभी प्रारूपों के लिए अनिवार्य।

4. संदर्भ एवं ट्रैकिंग पहचानकर्ता
पता लगाने की सुविधा (ट्रेसेबिलिटी) के लिए, विशेषकर gpi में।

• एंड-टू-एंड पहचान: संपूर्ण श्रृंखला को जोड़ने वाला संदर्भ (जैसे, इनवॉइस या लेन-देन आईडी)। pacs.008/pacs.009 में <EndToEndId>।
• निर्देश पहचान: प्रेषक का संदर्भ (MT में 16 वर्णों तक सीमित)। पूर्ववर्ती MT में फ़ील्ड 20 से संबद्ध; pacs.008/pacs.009 में <InstrId>।
• यूनिक एंड-टू-एंड ट्रांज़ैक्शन रेफ़रेंस (UETR): एंड-टू-एंड ट्रैकिंग के लिए एक UUID। यह pacs.008/pacs.009 में और पूर्ववर्ती MT103/MT202 के फ़ील्ड 121 में अनिवार्य है; यदि कोई प्रारंभिक चैनल इसे उपलब्ध नहीं कराता, तो शृंखला में पहला Swift बैंक इसे उत्पन्न करता है।
• लेन-देन पहचान: अतिरिक्त आंतरिक संदर्भ।

यह क्यों आवश्यक है: यह gpi ट्रैकिंग और लिंकिंग (जैसे pacs.008 से pacs.009 COV) को सक्षम बनाता है; UETR सार्वभौमिक पुष्टिकरणों के लिए मुख्य घटक है।

5. प्रयोजन एवं सेवा संबंधी जानकारी
भुगतान के प्रकार का वर्गीकरण करती है।

• प्रयोजन और श्रेणी प्रयोजन कोड: ISO कोड (उदाहरण के लिए, वेतन के लिए SALA) जो लेनदेन की प्रकृति दर्शाते हैं। कुछ गलियारों में अपेक्षित; pacs.008 में <Purp> और <CtgyPurp>।
• सेवा-स्तर कोड: gpi सेवा की पहचान करता है (जैसे gpi ग्राहक क्रेडिट अंतरण के लिए G001); गैर-gpi बैंकों को, सहमति के बिना, gpi-विशिष्ट कोड सम्मिलित नहीं करने चाहिए। MT में फ़ील्ड 23E से तथा pacs.008/pacs.009 में <SvcLvl> से संबद्ध।
• लोकल इंस्ट्रूमेंट कोड: विशिष्ट योजनाओं (जैसे, समूह के भीतर अंतरण) के लिए।

आवश्यकता का कारण: विनियामक अनुपालन और प्रसंस्करण में प्राथमिकता सुनिश्चित करता है; ISO माइग्रेशन के बाद यह उत्तरोत्तर अनिवार्य होता जा रहा है।

6. प्रेषण एवं अतिरिक्त निर्देश

• प्रेषण संबंधी जानकारी: असंरचित (अधिकतम 140 वर्ण) अथवा संरचित (जैसे, इनवॉइस विवरण)। पूर्ववर्ती MT 103 में फ़ील्ड 70 से संबद्ध; pacs.008/pacs.009 में <RmtInf>।
• एजेंटों के लिए निर्देश: उदाहरणतः प्राप्तकर्ता के लिए /REC/, खाते के लिए /ACC/, या दूरभाष निर्देश (PHOB)। पूर्ववर्ती MT में फ़ील्ड 72 से संबद्ध; pacs.008/pacs.009 में <InstrForNxtAgt>/<InstrForCdtrAgt>।
• निपटान समय संकेतक: अनुरोधित समय (जैसे, CLS समय के लिए CLSTm)।

आवश्यकता का कारण: संदर्भ और संचालन संबंधी निर्देश प्रदान करता है; pacs.009 COV में कवर पद्धतियों के लिए अनिवार्य।

7. विनियामक एवं अनुपालन संबंधी डेटा

• विनियामक रिपोर्टिंग: कोड या ब्योरे (जैसे कर पहचान संख्या, CRED/DEB जैसा रिपोर्टिंग संकेतक)। MT में फ़ील्ड 77B से तथा pacs.008/pacs.009 में <RgltryRptg> से संबद्ध।
• वापसी कारण कोड (वापसी के लिए, यदि लागू हो): जैसे, बंद खाते के लिए AC04, जो मूल संदेशों से जुड़े pacs.004 में दर्शाया जाता है।

यह क्यों आवश्यक है: AML/KYC और रिपोर्टिंग दायित्वों की पूर्ति करता है; विनियमित भुगतान कॉरिडोर में अनिवार्य है।

सर्वोत्तम पद्धतियों के लिए, जो प्रतिभागी gpi के सदस्य नहीं हैं, उन्हें MT से MX रूपांतरण के दौरान डेटा के कटने से बचने के लिए डेटा की संरचना उपयुक्त रूप से करनी चाहिए और विशिष्ट आवश्यकताओं के लिए gpi सदस्य बैंक से परामर्श करना चाहिए। यदि भुगतान में कवर पद्धतियाँ शामिल हैं, तो संदेशों में अंतर्निहित ग्राहक विवरण एक-दूसरे के अनुरूप होने चाहिए (जैसे, pacs.008 से pacs.009 COV)।

SWIFT gpi में भुगतान संदेश

SWIFT gpi (ग्लोबल पेमेंट्स इनोवेशन) ढाँचे में, मूल भुगतान संदेश (जैसे ग्राहक अंतरणों के लिए pacs.008 या कवर अंतरणों के लिए pacs.009 COV) भेजे जाने के बाद अपरिवर्तनीय माने जाते हैं। प्राप्तकर्ता बैंक इन संदेशों की सामग्री में प्रत्यक्ष रूप से कोई बदलाव या संशोधन नहीं कर सकते, क्योंकि SWIFT संदेश पूरी भुगतान शृंखला में अखंडता और लेखापरीक्षण-योग्यता बनाए रखने के लिए डिज़ाइन किए गए हैं। इसके बजाय, कोई भी परिवर्तन, सुधार या निरस्तीकरण पृथक अनुवर्ती संदेशों, gpi Tracker के माध्यम से स्थिति अद्यतनों, या gSRP (gpi Stop and Recall Payment) जैसी समर्पित सेवाओं के माध्यम से किया जाता है। इससे Unique End-to-End Transaction Reference (UETR) के उपयोग द्वारा संपूर्ण अनुरेखण्यता सुनिश्चित होती है।

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

प्राप्तकर्ता बैंकों द्वारा परिवर्तन का अनुरोध करने या उसे सुगम बनाने की शर्तें
जब मूल भुगतान को निर्देशानुसार संसाधित नहीं किया जा सकता, तब प्राप्तकर्ता बैंक परिवर्तन (जैसे विवरणों में सुधार) का अनुरोध कर सकते हैं या ऐसी कार्रवाई कर सकते हैं जिससे परिवर्तन की आवश्यकता सूचित हो। यह सामान्यतः पूछताछ संदेशों (जैसे MT 195/199) या प्रेषक द्वारा आरंभ किए गए अनुरोधों के उत्तरों के माध्यम से किया जाता है। प्रमुख शर्तें इस प्रकार हैं:

• भुगतान विवरण में त्रुटियाँ: यदि अशुद्धियाँ हों, जैसे लाभार्थी खाता गलत हो (उदाहरणार्थ, बंद खाता – कोड AC04), मुद्रा गलत हो (कोड CURR), एजेंट रूटिंग गलत हो (कोड AGNT), या तकनीकी समस्याएँ हों (कोड TECH), तो प्राप्तकर्ता बैंक भुगतान को रोक सकता है और प्रेषक से संशोधित जानकारी देने अथवा नया भुगतान भेजने का अनुरोध कर सकता है। इससे पूर्ण अस्वीकृति से बचा जाता है और समाधान का अवसर बना रहता है।
• भुगतान लागू करने में असमर्थता: कोड CUTA (Cancel Upon Unable to Apply) के अंतर्गत, यदि विसंगतियों (जैसे नाम/खाते में अंतर या अपर्याप्त विवरण) के कारण भुगतान जमा नहीं किया जा सकता, तो प्राप्तकर्ता बैंक सुधार हेतु प्रेषक से रद्दीकरण या संशोधन का विवरण माँग सकता है।
• संदिग्ध धोखाधड़ी या अनधिकृत लेनदेन: धोखाधड़ी (कोड FRAD) की स्थिति में, प्राप्तकर्ता बैंक प्रेषक के पूर्व अनुरोध के बिना स्वयं समस्याओं का पता लगा सकता है और धनराशि लौटाने की प्रक्रिया आरंभ कर सकता है। वह प्रेषक के रिकॉल अनुरोधों के उत्तर में धनराशि को रोककर रख सकता है और, यदि धनराशि पहले ही जमा हो चुकी हो, तो जोखिम कम करने के लिए धनराशि लौटाने से पहले क्षतिपूर्ति (कोड INDM) का अनुरोध कर सकता है।
• डुप्लिकेट या अनुचित भुगतान: DUPL (डुप्लिकेट भुगतान) या UPAY (अनुचित भुगतान) जैसे कोड प्राप्तकर्ता बैंक को यह अनुमति देते हैं कि लेनदेन त्रुटिपूर्ण या अनुचित होने की स्थिति में वह उसे चिह्नित कर रद्द करने का अनुरोध कर सके।
• विनियामक अथवा अनुपालन संबंधी मुद्दे: यदि भुगतान स्थानीय कानूनों, प्रतिबंधों या AML अपेक्षाओं (कोड LEGL) का उल्लंघन करता है, तो प्राप्तकर्ता बैंक उसे अस्वीकार कर सकता है या रोक सकता है और प्रेषक से अतिरिक्त दस्तावेज़ या संशोधन का अनुरोध कर सकता है।
• ग्राहक या लाभार्थी के निर्णय: यदि लाभार्थी भुगतान अस्वीकार कर देता है (कोड CUST या NOAS – लाभार्थी से कोई उत्तर नहीं), तो प्राप्तकर्ता बैंक उसे लौटा सकता है और प्रेषक को सूचित कर सकता है, तथा संभवतः परिवर्तनों की पुष्टि का अनुरोध कर सकता है।
• लंबित समाधान: लंबित मामलों (कोड PDCR) में, जैसे डेबिट प्राधिकार (RQDA) की प्रतीक्षा या अगले एजेंट के उत्तर (PTNA) की प्रतीक्षा, प्राप्तकर्ता बैंक भुगतान को रोक सकता है और आगे बढ़ने के लिए अतिरिक्त निर्देश या संशोधन का अनुरोध कर सकता है।

सभी मामलों में, स्ट्रेट-थ्रू प्रोसेसिंग को समर्थन देने के लिए अनुरोधों की संरचना स्वचालन के अनुकूल होनी चाहिए (जैसे UETR, मूल संदर्भ जैसे फ़ील्ड 20/32A/50/59, और संदेशों के फ़ील्ड 79 में विशिष्ट कोड सम्मिलित करना)। यदि धनराशि जमा की जाती है तो द्विपक्षीय रूप से क्षतिपूर्ति अनुबंध आवश्यक हो सकते हैं, और प्राप्तकर्ता बैंक पर अनुरोध स्वीकार करने की बाध्यता नहीं है, किंतु उसे अत्यावश्यक अनुरोधों (जैसे धोखाधड़ी से संबंधित) को प्राथमिकता देनी होगी।

शामिल प्रक्रियाएँ

• प्रेषक-प्रारंभित रिकॉल पर प्रतिक्रिया: प्रेषक (डेबिटर एजेंट) सामान्यतः MT 192/292 (या camt.056 जैसे ISO 20022 समकक्षों) के माध्यम से रिकॉल प्रारंभ करता है, जो gSRP सेवा द्वारा क्रमिक रूप से या सीधे प्राप्तकर्ता बैंक को भेजा जाता है। प्राप्तकर्ता बैंक को तत्काल पावती देनी होती है और CNCL (रद्द), RJCR (कारण सहित अस्वीकृत) या PDCR (लंबित) जैसे कोड का उपयोग करते हुए MT 196/296 (या संरचित होने पर MT 199/299) के माध्यम से उत्तर देना होता है। स्वीकृत होने पर, धनराशि pacs.004 (भुगतान वापसी) के माध्यम से लौटाई जाती है।
• प्राप्तकर्ता बैंकों की स्वतंत्र कार्रवाइयाँ: यदि आंतरिक रूप से धोखाधड़ी का पता चलता है, तो प्राप्तकर्ता बैंक संरचित विवरण के साथ pacs.004 का उपयोग करके निधियाँ लौटा सकता है, और वास्तविक समय की स्थिति अद्यतन के लिए ट्रैकर के माध्यम से सूचित कर सकता है।
• संशोधन/स्पष्टीकरण हेतु अनुरोध: प्राप्तकर्ता बैंक परिवर्तनों, जैसे अतिरिक्त विवरण, का अनुरोध करने के लिए पूछताछ संदेशों (जैसे MT 195/295) का उपयोग करते हैं। यह रोके गए भुगतानों में सामान्यतः देखा जाता है।
• ट्रैकर एकीकरण: सभी कार्रवाइयाँ gpi Tracker को वास्तविक समय में अद्यतन करती हैं, जो API अथवा GUI के माध्यम से उपलब्ध है, और इस प्रकार सभी पक्षों के लिए पारदर्शिता सुनिश्चित होती है। gpi सदस्यों के लिए gCCT (ग्राहक क्रेडिट अंतरण), gCOV (कवर) और gSRP की अनिवार्य नियम-पुस्तिकाओं का पालन करना आवश्यक है।
• सीमाएँ और सफलता के कारक: परिवर्तनों की गारंटी नहीं है; सफलता भुगतान के चरण (क्रेडिट से पूर्व अधिक आसान), लाभार्थी के सहयोग और क्षेत्राधिकार पर निर्भर करती है। यदि राशि जमा हो चुकी है, तो वापसी के लिए लाभार्थी की सहमति या क्षतिपूर्ति आवश्यक है। विनियम सदैव दिशानिर्देशों पर अभिभावी होते हैं।

ये प्रथाएँ मुख्य रूप से gpi सदस्यों पर लागू होती हैं, परंतु गैर-gpi बैंक गेटवे के माध्यम से भाग ले सकते हैं। नवीनतम विवरण के लिए कृपया SWIFT की आधिकारिक नियम-पुस्तिकाओं का संदर्भ लें, क्योंकि प्रक्रियाएँ (जैसे ISO 20022 माइग्रेशन के साथ) विकसित होती रहती हैं।

SWIFT gpi में संदेशन और निपटान का पृथक्करण

SWIFT gpi मुख्यतः संदेश प्रणाली (जैसे ग्राहक अंतरणों के लिए pacs.008, वित्तीय अंतरणों के लिए pacs.009 जैसे ISO 20022 प्रारूप, अथवा पारंपरिक MT103/MT202) के माध्यम से भुगतान निर्देशों और उनकी ट्रैकिंग का संचालन करता है, परंतु धन का वास्तविक संचलन निपटान स्तर पर पृथक रूप से होता है। निपटान सामान्यतः कॉरेस्पोंडेंट बैंकिंग संबंधों (नोस्ट्रो/वोस्ट्रो खाते), द्विपक्षीय नेटिंग, अथवा क्लियरिंग एवं सेटलमेंट मैकेनिज़्म (CSM) जैसे रियल-टाइम ग्रॉस सेटलमेंट (RTGS) प्रणालियों (जैसे यूरोप में T2, पूर्व में TARGET2, अमेरिका में Fedwire, या यूनाइटेड किंगडम में CHAPS) के माध्यम से होता है। gpi ट्रैकर संदेश की स्थिति की वास्तविक-काल दृश्यता प्रदान करता है, किंतु निधियों का अंतरण इन्हीं अंतर्निहित प्रणालियों पर निर्भर करता है।

सीमा-पार भुगतान निर्देशों के लिए सह-अस्तित्व की अवधि 22 नवंबर 2025 को समाप्त हो गई: MT 103 और MT 202 जैसे भुगतान निर्देशों का स्थान pacs.008 और pacs.009 जैसे ISO 20022 (MX) संदेशों ने ले लिया है, जबकि अन्य MT श्रेणियों को बाद की तिथियों पर समाप्त किया जा रहा है। नीचे स्पष्ट किया गया है कि खाता/क्लियरिंग/निपटान स्तर पर वापसी (रिटर्न) और होल्ड की समाप्ति किस प्रकार होती है।

खाता/क्लियरिंग/निपटान स्तर पर धन कैसे लौटाया जाता है
वापसी की प्रक्रिया सफल रिकॉल अनुरोध (gSRP – gpi Stop and Recall Payment सेवा के माध्यम से) अथवा स्वतंत्र पहचान (जैसे धोखाधड़ी, त्रुटियाँ) के बाद आरंभ की जाती है। gSRP में प्रेषक की ओर से camt.056 (भुगतान निरस्तीकरण अनुरोध) का प्रयोग होता है, जिसका उत्तर camt.029 (जाँच का समाधान) से दिया जाता है। स्वीकृति के बाद, धन की वापसी एक नए भुगतान निर्देश के माध्यम से की जाती है, जो प्रवाह को उलट देता है, प्राप्तकर्ता बैंक के खाते को डेबिट करता है और श्रृंखला के माध्यम से वापस क्रेडिट करता है। यह मूल संदेश में कोई परिवर्तन नहीं है, बल्कि एक पृथक लेनदेन है।

प्रमुख निपटान पद्धतियाँ और वापसी प्रक्रियाएँ
निपटान पद्धतियाँ निर्धारित करती हैं कि वापसी (रिटर्न) किस प्रकार होती है:

• CLRG (बाज़ार अवसंरचना के माध्यम से क्लियरिंग): RTGS या CSM के माध्यम से निपटान (जैसे किसी केंद्रीय बैंक के माध्यम से)। रिटर्न में pacs.004 का उपयोग किया जाता है, जिसके द्वारा बाज़ार अवसंरचना को प्राप्तकर्ता एजेंट के खाते को डेबिट करने और पूर्ववर्ती एजेंट के खाते को क्रेडिट करने का निर्देश दिया जाता है, प्रायः वास्तविक समय में या उसी दिन।
• INGA (निर्देशक एजेंट पहले निपटान करता है): प्रेषक संदेश भेजने से पहले धनराशि का निपटान करता है। pacs.004 के माध्यम से वापसी निपटान के बाद निर्देशित एजेंट के खाते को डेबिट करती है।
• INDA (निर्देशित एजेंट प्राप्ति पर निपटान करता है): प्राप्तकर्ता संदेश प्राप्त होने पर निपटान करता है। यदि निपटान नहीं हुआ है, तो pacs.002 के माध्यम से अस्वीकार करें (कोई निधि अंतरित नहीं होती); यदि निपटान हो चुका है, तो pacs.004 के माध्यम से वापस करें।
• COVE (कवर पद्धति): कवर अंतरण (pacs.009 COV) वाले उच्च-मूल्य भुगतानों के लिए प्रयुक्त। वापसी विपरीत शृंखला का अनुसरण करती है: लाभार्थी एजेंट से मध्यवर्ती संस्थाओं तक pacs.004 वापस भेजा जाता है और कॉरेस्पोंडेंट खातों को तदनुसार डेबिट/क्रेडिट किया जाता है।

निपटान स्तर पर चरण-दर-चरण वापसी प्रक्रिया

1. आरंभ एवं स्वीकृति: प्रेषक प्रतिसंहरण का अनुरोध करता है (जैसे UETR सहित camt.056 के माध्यम से)। प्राप्तकर्ता प्रत्युत्तर (camt.029) देता है और यदि निधि उपलब्ध है/लाभार्थी के खाते में अभी जमा नहीं हुई है, तो अनुरोध स्वीकार करता है (जमा होने से पूर्व यह अपेक्षाकृत सरल है)। यदि निधि जमा हो चुकी है, तो लाभार्थी की सहमति अथवा क्षतिपूर्ति की आवश्यकता हो सकती है।

2. निधि वापसी निर्देश: प्राप्तकर्ता pacs.004 (भुगतान वापसी) या वापसी कोड (जैसे RETN) सहित पारंपरिक MT 103/MT 202 जारी करता है। इस संदेश में शामिल होता है:

• मूल संदर्भ (UETR, एंड-टू-एंड ID, निर्देश ID)।
• भूमिकाओं का उलटाव: मूल लेनदार देनदार बन जाता है; मूल देनदार का एजेंट लेनदार बन जाता है।
• निपटान विवरण: मूल अंतर-बैंक निपटान राशि/तिथि, विनिमय दर (यदि विदेशी मुद्रा विनिमय शामिल हो), शुल्क (यदि काटे गए हों)।
• वापसी कारण कोड (जैसे, बंद खाते के लिए AC04, धोखाधड़ी के लिए FRAD)।
• क्रेडिट हेतु खाता निर्दिष्ट करने के लिए निपटान खाता फ़ील्ड (यदि मूल संदेश में हो)।

3. निपटान का निष्पादन:

• pacs.004 से प्राप्तकर्ता बैंक के नोस्ट्रो/वोस्ट्रो खाते (जो पूर्ववर्ती एजेंट या MI के पास धारित है) में डेबिट प्रारंभ होता है।
• निधियाँ उसी निपटान पद्धति (जैसे CLRG में RTGS अंतरण) का उपयोग करते हुए श्रृंखला के माध्यम से चरण-दर-चरण वापस जमा की जाती हैं।
• आंशिक वापसी की स्थिति में, अतिरिक्त जानकारी में आनुपातिक राशि के साथ "PART" उल्लिखित करें।
• ट्रैकर स्थिति (जैसे, “वापस किया गया”) को रियल-टाइम में अद्यतन करता है, जो API या GUI के माध्यम से दिखाई देती है।

4. अंतिम क्रेडिट: मूल प्रेषक के खाते में राशि जमा की जाती है, प्रायः शुल्कों की कटौती के साथ। CSM के माध्यम से होने पर निपटान अविभाज्य (एटॉमिक) होता है; द्विपक्षीय व्यवस्थाओं में इसमें दिन के अंत में नेटिंग सम्मिलित हो सकती है।

5. वापसी के बाद की सूचनाएँ: बही-खाते के अद्यतन की पुष्टि के लिए camt.053/054 (खाता विवरण/डेबिट-क्रेडिट सूचना) का उपयोग करें। “वापसी को वापस करने” के लिए आगे कोई pacs.004 नहीं: इसके स्थान पर पूछताछ का उपयोग करें।
जहाँ संभव हो, वापसी स्वचालित होती है, किंतु अनुपालन के कारण या निधि फ्रीज़ होने की स्थिति में मैन्युअल हस्तक्षेप हो सकता है। वसूली की गारंटी नहीं है; यह मुख्यतः इस पर निर्भर करती है कि रिकॉल कितनी शीघ्रता से भेजा गया और निधि पहले ही जमा हो चुकी है या नहीं। यदि निपटान नहीं हुआ है (जैसे निपटान-पूर्व अस्वीकृत), तो कोई निधि स्थानांतरित नहीं होती: इसके स्थान पर pacs.002 का उपयोग करें।

रोके गए भुगतान खाता/क्लियरिंग/निपटान स्तर पर कैसे जारी (हरी झंडी) किए जाते हैं

होल्ड तब होता है जब किसी भुगतान को तत्काल संसाधित नहीं किया जा सकता (उदाहरणार्थ, त्रुटियों, अनुपालन जाँच या स्पष्टीकरण की प्रतीक्षा के कारण), जिससे वह निपटान के बिना “लंबित” स्थिति में रहता है। समाधान होने तक कोई निधि डेबिट/क्रेडिट नहीं की जाती। gpi ट्रैकर “On Hold” या “Pending” जैसी स्थितियाँ दर्शाता है (उदाहरणार्थ, PDCR कोड), और समाधान के लिए पूछताछ संदेशों (MT 195/199 या camt.029) का उपयोग किया जाता है।

रोक (होल्ड) लगने की परिस्थितियाँ

• बेमेल (जैसे, खाता/नाम में विसंगति – CUTA कोड)।
• विनियामक जाँच (उदाहरणार्थ, प्रतिबंध – LEGL कोड)।
• लाभार्थी की प्रतिक्रिया (NOAS कोड) या डेबिट प्राधिकार (RQDA) की प्रतीक्षा है।
• लाभार्थी बैंक पर ऑफ़लाइन घंटे या बैच प्रोसेसिंग।

निपटान स्तर पर निर्मुक्ति प्रक्रिया
1. होल्ड अधिसूचना: प्राप्तकर्ता pacs.002 (स्थिति अद्यतन) या लंबित कोड सहित MT 199 भेजता है, और आंशिक निपटान की स्थिति में (जैसे कवर पद्धतियों में) निधियों को सस्पेंस/एस्क्रो खाते में रोके रखता है।
2. समाधान: प्रेषक संशोधन/स्पष्टीकरण प्रदान करता है (जैसे MT 195 प्रत्युत्तर या camt.029 के माध्यम से)। समाधान होने पर प्राप्तकर्ता मूल निर्देश का प्रसंस्करण कर अनुमति प्रदान करता है।
3. निपटान निष्पादन:

• मूल pacs.008/pacs.009 को होल्ड से मुक्त कर दिया जाता है।
• निधियों का निपटान निर्दिष्ट पद्धति से होता है: प्रेषक के खाते को डेबिट किया जाता है, प्राप्तकर्ता के खाते को क्रेडिट किया जाता है (उदाहरणार्थ, CLRG में RTGS के माध्यम से), और तत्पश्चात लाभार्थी के खाते में अंतिम क्रेडिट किया जाता है।
• लाभार्थी चरण (प्राप्तकर्ता बैंक से अंतिम ग्राहक तक) प्रायः वह स्थान होता है जहाँ विलंब होता है, विशेष रूप से उन बाज़ारों में जहाँ पूंजी नियंत्रण हैं या अवसंरचना सीमित है।
• ट्रैकर “क्रेडिट किया गया” या “पूर्ण” में अपडेट हो जाता है, और pacs.002 (भुगतान स्थिति रिपोर्ट) इसकी पुष्टि करता है।

4. यदि जारी न किया गया हो: यदि मामला अनसुलझा रहे (जैसे समय-सीमा समाप्त होने पर), तो ऊपर बताए अनुसार pacs.004 के माध्यम से लौटाएँ, या pacs.002 द्वारा अस्वीकृत करें (कोई निपटान नहीं)।

gpi नियमों के अनुसार जहाँ संभव हो उसी दिन खाते में राशि जमा करना अपेक्षित है; Swift ने 2018 में बताया कि लगभग 50% gpi भुगतान 30 मिनट के भीतर और लगभग 100% भुगतान 24 घंटे के भीतर जमा किए गए। पूंजी नियंत्रण या बैंक के बंद रहने के घंटे जैसे कारक रोक की अवधि बढ़ा सकते हैं, किंतु gpi इसे न्यूनतम करने के लिए स्वचालन पर बल देता है।

SwiftNet Instant

SwiftNet Instant। यह एक रियल-टाइम, कम विलंबता वाला संदेश-प्रेषण प्लेटफ़ॉर्म है जो 24/7 उपलब्ध रहता है और क्लियरिंग एवं सेटलमेंट मैकेनिज़्म (CSM) तथा उनके प्रतिभागियों के बीच तत्काल भुगतान प्रवाहों के सुरक्षित आदान-प्रदान का समर्थन करता है।

ग्राहक अपने मौजूदा Swift कनेक्टिविटी और सुरक्षा अवसंरचना, जिसमें VPN बॉक्स, लीज्ड लाइनें और हार्डवेयर सिक्योरिटी मॉड्यूल सम्मिलित हैं, के माध्यम से SwiftNet Instant से जुड़ सकते हैं। बैंक के IT परिवेश के साथ एकीकरण Alliance Gateway Instant (AGI) के माध्यम से किया जाता है।

तत्काल भुगतान शृंखला के सभी पक्ष AGI और SwiftNet Instant मैसेजिंग का उपयोग कर सकते हैं। इसके अनुप्रयोगों में ओवरले सेवा से भुगतान आरंभ करना, प्रायोजक सदस्य के साथ अप्रत्यक्ष सदस्य संवाद, अथवा किसी कॉर्पोरेट द्वारा भुगतान की पुष्टि प्राप्त करना शामिल हैं।

SWIFT Instant घरेलू त्वरित भुगतान प्रणालियों से जुड़कर ISO 20022 मानक के उपयोग से घरेलू और अंतरराष्ट्रीय दोनों स्तरों पर वास्तविक समय में लेन-देन के प्रसंस्करण को संभव बनाता है। ये प्रणालियाँ वित्तीय उद्योग में भुगतान प्रक्रियाओं के आधुनिकीकरण और सरलीकरण के निरंतर प्रयासों का प्रतिनिधित्व करती हैं।

SWIFT डायरेक्ट डेबिट

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

SWIFT प्रणाली के भीतर डायरेक्ट डेबिट लेन-देन आरंभ करने की प्रक्रिया में सामान्यतः निम्नलिखित चरण सम्मिलित होते हैं:

1. ऋणदाता और ऋणी के बीच करार: ऋणदाता और ऋणी के बीच पूर्व-विद्यमान करार होना आवश्यक है, जिसमें डायरेक्ट डेबिट लेन-देन के नियम एवं शर्तें शामिल हों। इस करार में एक अधिदेश या प्राधिकरण की व्यवस्था भी हो सकती है, जिससे ऋणदाता ऋणी के बैंक खाते से भुगतान एकत्र कर सके।
2. संदेश विनिमय: लेनदार का बैंक देनदार के बैंक को SWIFT संदेश भेजकर डायरेक्ट डेबिट आरंभ करता है — ISO 20022 में pacs.003 (ग्राहक डायरेक्ट डेबिट) या pacs.010 (वित्तीय संस्था डायरेक्ट डेबिट), जो पहले MT 104 या MT 204 थे। इस संदेश में लेनदेन का विवरण होता है, जैसे राशि, मुद्रा, देनदार के खाते की जानकारी और कोई अन्य आवश्यक जानकारी।
3. सत्यापन और प्राधिकरण: देनदार का बैंक लेनदेन के विवरण का सत्यापन करता है, देनदार के खाते में निधियों की उपलब्धता की जाँच करता है और लेनदेन के प्राधिकरण की पुष्टि करता है। यदि सब कुछ उचित पाया जाता है, तो देनदार का बैंक देनदार के खाते से निधियाँ डेबिट करने की कार्रवाई करता है।
4. निधि अंतरण: निधियों का निपटान देनदार के बैंक और लेनदार के बैंक के बीच कॉरेस्पोंडेंट खातों या क्लियरिंग एवं निपटान प्रणाली के माध्यम से किया जाता है।
5. पुष्टि: निधि प्राप्त होने पर, लेनदार का बैंक लेनदार को पुष्टि संदेश भेजता है, जिसमें डायरेक्ट डेबिट लेनदेन के सफलतापूर्वक पूर्ण होने की सूचना दी जाती है।

SWIFT प्रणाली के अंतर्गत डायरेक्ट डेबिट लेनदेन आरंभ करने की पूर्वापेक्षाएँ इस प्रकार हैं:

1. बैंक खाते: लेनदार और देनदार, दोनों के पास ऐसी वित्तीय संस्थाओं में बैंक खाते होने चाहिए जो SWIFT नेटवर्क का भाग हैं।
2. करार और प्राधिकरण: प्रत्यक्ष डेबिट लेनदेन सक्षम करने के लिए लेनदार और देनदार के बीच पूर्व-विद्यमान करार और प्राधिकरण (अधिदेश) होना आवश्यक है।
3. SWIFT संदेश प्रारूप: लेनदार और उसके बैंक को उपयुक्त संदेश प्रारूपों का उपयोग करना होगा: डायरेक्ट डेबिट आरंभ करने के लिए pain.008, बैंकों के बीच pacs.003 या pacs.010।
4. बैंक शुल्क: लेनदार और देनदार को SWIFT प्रणाली के भीतर डायरेक्ट डेबिट लेनदेन से जुड़े किसी भी शुल्क की जानकारी होनी चाहिए, क्योंकि ये शुल्क संबंधित बैंकों और देशों के अनुसार भिन्न हो सकते हैं।

इंटरबैंक SWIFT संदेश-प्रणाली में RMA

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

RMA क्या है?

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

RMA का महत्व

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

RMA कैसे कार्य करता है

RMA प्रक्रिया में कई प्रमुख चरण सम्मिलित हैं:

1. RMA संबंधों की स्थापना: दो बैंक SWIFT के माध्यम से सूचना का आदान-प्रदान आरंभ कर सकें, इससे पहले उन्हें परस्पर RMA स्थापित करने पर सहमत होना आवश्यक है। यह समझौता एक डिजिटल हस्तांदोलन के समान है, जो परस्पर विश्वास और संवाद की सहमति का सूचक है।
2. कुंजियों का आदान-प्रदान: प्रत्येक बैंक RMA एप्लिकेशन के माध्यम से RMA प्राधिकरण भेजता है, जिसे प्रतिपक्ष स्वीकार करता है। RMA ने पूर्ववर्ती द्विपक्षीय कुंजी विनिमय (BKE) का स्थान लिया है; संदेशों का प्रमाणीकरण स्वयं SWIFTNet PKI (पब्लिक की इन्फ्रास्ट्रक्चर) के माध्यम से होता है।
3. RMA सेटिंग्स का विन्यास: प्रत्येक बैंक RMA टूल का उपयोग अनुमतियाँ विन्यस्त करने और यह निर्दिष्ट करने के लिए करता है कि दूसरे बैंक से किन प्रकार के संदेश स्वीकार किए जाएँगे। इसे व्यापक श्रेणियों में रखा जा सकता है या विशिष्ट संदेश प्रकारों और उप-वर्गों को शामिल करते हुए सूक्ष्म रूप से निर्धारित किया जा सकता है।
4. सक्रियण और निगरानी: RMA सेटिंग्स कॉन्फ़िगर और सक्रिय हो जाने के बाद, बैंक प्राप्त होने वाले संदेशों की निगरानी कर सकते हैं कि वे स्थापित अनुमतियों के अनुरूप हैं या नहीं। व्यावसायिक आवश्यकताओं या सुरक्षा संबंधी चिंताओं की स्थिति में अनुमतियों को संशोधित या रद्द करने के लिए RMA उपकरण भी उपलब्ध कराता है।

व्यावहारिक अनुप्रयोग

उच्च निवल मूल्य वाले व्यक्तियों और कॉर्पोरेट संस्थाओं के लिए निवेश एवं संपत्ति प्रबंधन में विशेषज्ञता रखने वाले IFB के लिए RMA कई लाभ प्रदान करता है:

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

RMA और MT799. बैंक RMA संबंध का अनुरोध करने या उसके समन्वय के लिए MT799 का उपयोग कर सकते हैं, बशर्ते चैनल इसकी अनुमति देता हो। RMA प्राधिकरण स्वयं RMA प्रणाली में प्रदान किया जाता है; केवल MT799 से कोई अनुमति सक्रिय नहीं होती। जहाँ MT799 के लिए आवश्यक RMA प्राधिकरण उपलब्ध नहीं है, वहाँ MT799 सीधे भेजकर उसे दरकिनार नहीं किया जा सकता। तब यह व्यवस्था Swift के रिलेशनशिप मैनेजमेंट पोर्टल की RMA संचार सुविधा के माध्यम से, जो प्राधिकरणों के आदान-प्रदान से पहले प्रतिपक्षों के साथ समन्वय के लिए बनाई गई है, अथवा किसी अन्य अनुमत चैनल के माध्यम से तय की जाती है। इसलिए “MT799 द्वारा RMA” साथ चलने वाले बैंक पत्राचार का वर्णन कर सकता है; तकनीकी RMA प्राधिकरण एक अलग चरण है।

संक्षेप में

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

RMA सुरक्षित एवं चयनात्मक अंतर-बैंक संचार की रीढ़ हैं, जो यह सुनिश्चित करते हैं कि SWIFT नेटवर्क के माध्यम से आदान-प्रदान किया गया प्रत्येक संदेश सुरक्षा के उच्चतम मानकों का पालन करे और पूर्णतः प्रमाणित हो। IFB जैसे बैंकों के लिए, अपने परिचालन की सुरक्षा और अपने वैश्विक भागीदारों के साथ विश्वास निर्मित करने हेतु RMA को समझना और उनका प्रबंधन करना अत्यंत महत्वपूर्ण है।

Swift डिजिटल ब्लॉकचेन वित्तीय निर्देश

सितंबर 2025 में Swift ने घोषणा की कि 30 से अधिक वित्तीय संस्थाओं के साथ मिलकर उसने एक साझा डिजिटल बही के अभिकल्पन और विकास का कार्य आरंभ किया है। 9 जुलाई 2026 को Swift ने घोषित किया कि बही प्रारंभिक उपयोग के लिए तैयार है, और 17 बैंक टोकनीकृत जमा के वास्तविक (लाइव) लेनदेन का पायलट संचालन करने की तैयारी कर रहे हैं: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB और Wells Fargo। पहला अनुप्रयोग बैंकों के बीच वास्तविक समय में, 24/7 सीमा-पार निर्देशों को सक्षम बनाने पर केंद्रित होगा – जो अंतरराष्ट्रीय लेनदेन प्रसंस्करण के ताने-बाने में एक महत्वपूर्ण सुधार है।

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

Swift के मुख्य कार्यकारी, जेवियर पेरेज़-तासो, ने समझाया:
"साझा बही-खाते को Swift के मौजूदा संदेश-प्रेषण, API और ISO 20022 के साथ जोड़ने से एक और भी सशक्त संरचना बनती है – ऐसी संरचना जो आरंभ से ही लेन-देन प्रवाहों में जोखिम, नियंत्रण और अनुपालन अपेक्षाओं को समाहित कर सकती है, साथ ही उसी विश्वास, सुरक्षा, लचीलेपन, मापनीयता और परिचालन उत्कृष्टता के साथ वास्तविक समय में 24/7 अंतर-बैंक सीमा-पार निर्देश संभव बनाती है, जिसके लिए Swift जाना जाता है। यह सब उस दृष्टिकोण के अनुरूप है जो हमने सदैव अपनाया है — उत्तरदायी नवाचार।"

अवसंरचना का विस्तार

साझा लेजर Swift की मौजूदा प्रणालियों का पूरक है; यह उनका स्थान नहीं लेता। इसे समन्वयन और अंतर-संचालनीयता का विस्तार करने के लिए डिज़ाइन किया गया है, ताकि वित्तीय संस्थान निर्देशों का आदान-प्रदान अधिक तेज़ी से, अधिक पूर्वानुमेयता के साथ और वास्तव में वैश्विक पैमाने पर कर सकें।

Sibos में, पेरेज़-टैसो ने इस दोहरे-मार्ग दृष्टिकोण को रेखांकित किया:
“वित्तीय अवसंरचनाओं को परिचालन उत्कृष्टता, विनियामक अनुपालन और शासन जैसे मूलभूत आधारों पर निरंतर ध्यान केंद्रित रखना चाहिए। साथ ही, उन्हें भविष्य के लिए भी तैयार रहना चाहिए। और Swift में हमारा दृष्टिकोण दो समानांतर मार्गों पर नवाचार करना है।”

उद्योग-व्यापी सहयोग

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

आगे की राह

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

पेरेज़-तास्सो ने इस दृष्टिकोण का सार इस प्रकार प्रस्तुत किया:
“यह भविष्य के लिए एक सशक्त मंच है। और भविष्य में यह और भी अधिक परिवर्तनकारी हो सकता है।”

अक्सर पूछे जाने वाले प्रश्न

Swift ब्लॉकचेन-आधारित साझा बहीखाता क्या है?
यह एक ब्लॉकचेन अवसंरचना है जो संस्थाओं के बीच वित्तीय निर्देशों का साझा, वास्तविक-समय अभिलेख उपलब्ध कराती है और निरंतर, अनुपालन-सम्मत सीमा-पार प्रसंस्करण को संभव बनाती है।

यह किनके लिए है?
वे बैंक और वित्तीय संस्थान जिन्हें डिजिटल भविष्य की तैयारी करते हुए अधिक तीव्र और पारदर्शी लेनदेन निर्देश प्रदान करने हैं।

इसके लाभ क्या हैं?

• निर्देशों की वास्तविक समय में दृश्यता और क्रमबद्धता
• स्मार्ट कॉन्ट्रैक्ट के माध्यम से स्वचालित अनुपालन
• पारंपरिक और डिजिटल नेटवर्क के बीच अंतर-संचालनीयता
• विनियमित टोकनीकृत मूल्य प्रवाहों का सुरक्षित संचालन

यह Swift के प्लेटफ़ॉर्म में कैसे फिट होता है?
यह Swift की विश्वसनीय अवसंरचना का विस्तार करता है, तथा सुदृढ़ता, सुरक्षा और अनुपालन बनाए रखते हुए डिजिटल निर्देश क्षमताओं को समाहित करता है।

पहला उपयोग-परिदृश्य क्या है?
सीमा-पार अंतरबैंक लेन-देन के लिए वास्तविक समय में, 24/7 निर्देश।

कौन शामिल है?
16 देशों के 30 से अधिक वित्तीय संस्थानों ने इसके डिज़ाइन को आकार देने में योगदान दिया; 17 बैंक पहले वास्तविक लेन-देनों का पायलट परीक्षण कर रहे हैं।

यह कब उपलब्ध होगा?
Swift ने 9 जुलाई 2026 को लेजर को प्रारंभिक उपयोग के लिए तैयार घोषित किया। पायलट बैंक नियंत्रित गो-लाइव चरण में प्रारंभिक लाइव लेन-देन चलाते हैं; अंतिम निपटान अब भी मौजूदा प्रणालियों के माध्यम से ही होता है। कार्यक्षमता और उपलब्धता का विस्तार इसके बाद किया जाना है।

यदि आप कॉरेस्पोंडेंट बैंकिंग प्रणाली के माध्यम से निधि अंतरण के बारे में अधिक जानना चाहते हैं, तो कृपया हमारे कॉरेस्पोंडेंट बैंकिंग प्रमुख श्री Amri Elarisse से संपर्क करें