ट्रेज़रर, भुगतान संचालन, इंजीनियर और ऑडिटर के लिए सीधे जवाब। प्रश्न उसी तरह लिखे गए हैं जैसे लोग वास्तव में पूछते हैं। गहरे तकनीकी विवरण के लिए तकनीकी संदर्भ देखें।
ट्रेज़री और वित्त प्रमुखों के लिए#
एक अनुच्छेद में, pain.001 क्या है?
pain.001 वह ISO 20022 संदेश है जो ग्राहक क्रेडिट ट्रांसफ़र शुरू करने के लिए अपने बैंक को भेजता है — SWIFT MT101 और घरेलू फ़्लैट फ़ाइलों जैसे प्रारूपों का XML उत्तराधिकारी। आपका बैंक स्वीकार करने से पहले इसे एक स्कीमा और एक स्कीम नियमपुस्तिका के विरुद्ध सत्यापित करता है। Pain001 (सॉफ़्टवेयर) आपके मौजूदा डेटा से वे फ़ाइलें बनाता है और सबमिट करने से पहले उनकी वैधता सिद्ध करता है।
pain.001 और pain.008 में क्या अंतर है?
प्रवाह की दिशा। pain.001 क्रेडिट ट्रांसफ़र शुरू करता है — आप पैसा बाहर भेजते हैं। pain.008 डायरेक्ट डेबिट शुरू करता है — आप मैंडेट के अंतर्गत अपना बकाया पैसा वसूलते हैं। Pain001 दोनों जनरेट करता है: pain.001 के दस संस्करण (.001.03 से .001.12) और pain.008.001.02।
हम अब भी MT101 फ़ाइलें भेजते हैं। माइग्रेशन कितना अत्यावश्यक है?
अत्यावश्यक। SWIFT ने नवंबर 2025 में सीमा-पार इंटरबैंक भुगतान निर्देशों के लिए MT श्रेणी 1, 2 और 9 संदेश सेवामुक्त कर दिए; जो कॉर्पोरेट चैनल अब भी MT स्वीकार करते हैं, वे हर बैंक के विवेक पर और उधार के समय पर ऐसा करते हैं। MT101 लोडर मौजूदा MT101 प्रवाहों को बिना कुछ दोबारा टाइप किए सत्यापित pain.001 में बदलता है।
नवंबर 2026 की संरचित पता समय-सीमा का हमारे लिए क्या अर्थ है?
नवंबर 2026 के अंत से, CBPR+ सीमा-पार भुगतानों में पूर्णतः असंरचित डाक पते स्वीकार नहीं किए जाएँगे; पते संरचित या हाइब्रिड होने चाहिए — मुक्त-पाठ पंक्तियों के बजाय शहर (
Pain001 की लागत क्या है?
कुछ नहीं। कोर Apache-2.0 / MIT के तहत दोहरे लाइसेंस वाला है; सहयोगी पैकेज Apache-2.0 हैं। व्यावसायिक उपयोग, संशोधन और पुनर्वितरण सभी अनुमत हैं। तुलना के लिए, अकेले SWIFT के अनुवाद SDK की सूचीबद्ध कीमत €10,000–30,000 प्रति वर्ष है।
भुगतान संचालन के लिए#
बैंक भुगतान फ़ाइलें क्यों अस्वीकारते हैं?
चार बार-बार होने वाले कारण: स्कीमा उल्लंघन (ग़लत तत्व, ग़लत संस्करण, ग़लत नेमस्पेस), ख़राब पहचानकर्ता (IBAN चेकसम विफलताएँ, विकृत BIC), टूटे नियंत्रण योग (NbOfTxs / CtrlSum लेनदेन से मेल नहीं खाते), और ISO 20022 लैटिन समूह से बाहर के वर्ण। Pain001 फ़ाइल बनने से पहले चारों की जाँच करता है: प्रति रिकॉर्ड JSON Schema सत्यापन, mod-97 IBAN और ISO 9362 BIC जाँच, पुनर्गणित नियंत्रण योग, वर्ण-समूह लिप्यंतरण, और रेंडर किए गए XML का अंतिम XSD सत्यापन।
क्या हम कुछ भी जनरेट किए बिना फ़ाइल सत्यापित कर सकते हैं?
हाँ — pain001 --dry-run (या validate सबकमांड, या POST /api/v1/validate)। एग्ज़िट कोड 0 का अर्थ है वैध; 1 का अर्थ है कि सत्यापन फ़ील्ड-स्तरीय त्रुटियों के साथ विफल हुआ। इसे CI या प्री-सबमिशन चेकलिस्ट में जोड़ें।
कौन-सी SEPA नियमपुस्तिकाएँ कवर हैं?
पाँच स्कीम नियमपुस्तिकाएँ बिल्ट-इन आती हैं: SEPA Credit Transfer (sepa-sct), SEPA Instant (sepa-inst), SEPA Direct Debit Core (sepa-sdd), SEPA B2B (sepa-b2b), और सीमा-पार क्रेडिट ट्रांसफ़र (xborder-ct)। पास या फ़ेल हुए हर नियम को देखने के लिए --scheme का उपयोग करें।
हमारा डेटा Excel में रहता है। इसमें क्या पेच है?
Excel IBAN-जैसी स्ट्रिंग्स को चुपचाप संख्याओं में बदल देता है। Excel लोडर .xlsx/.xlsm को सीधे पढ़ता है और यदि IBAN कॉलम में संख्यात्मक सेल हों तो तुरंत रुक जाता है — गड़बड़ी लोड के समय पकड़ी जाती है, बैंक में नहीं।
यह 500,000-पंक्तियों के बैच को कैसे संभालता है?
--streaming इनपुट को मेमोरी-सीमित चंक (डिफ़ॉल्ट 1,000 लेनदेन) में प्रोसेस करता है, और हर चंक सही पुनर्गणित नियंत्रण योग के साथ अपनी अलग XML फ़ाइल के रूप में निकलता है। इसी कारण REST API जॉब पोलिंग के साथ POST /api/v1/generate/async प्रदान करता है।
इंजीनियरों और आर्किटेक्टों के लिए#
हम इसे कैसे एकीकृत करें — लाइब्रेरी, CLI या API?
तीनों प्रथम-श्रेणी सतहों के रूप में मौजूद हैं: एक टाइप्ड Python API, CI-अनुकूल एग्ज़िट कोड वाला CLI, और सिंक, async-जॉब, हेल्थ तथा Prometheus मेट्रिक्स एंडपॉइंट वाली एक FastAPI माइक्रोसर्विस (pain001 serve)। नीचे वही सत्यापन पाइपलाइन है, इसलिए परिणाम सतहों के बीच कभी भिन्न नहीं होते।
क्या XML जनरेशन वास्तव में फ़्लोट राउंडिंग से सुरक्षित है?
जनरेशन और स्कीम सत्यापन में राशियाँ शुरू से अंत तक decimal.Decimal हैं — सटीक दशमलव के रूप में पार्स की गईं, सटीक दशमलव के रूप में जोड़ी गईं, बिना फ़्लोट प्रतिनिधित्व के रेंडर की गईं। नियंत्रण योग सत्यापित रिकॉर्ड से पुनर्गणित होते हैं, इनपुट से कभी भरोसे पर नहीं लिए जाते।
सुरक्षा स्थिति क्या है?
सारी XML पार्सिंग defusedxml से होकर गुज़रती है (जो XXE और entity-expansion हमलों को रोकता है); निर्भरता वृक्ष में कोई lxml नहीं है। इनपुट एक path-traversal सत्यापक से गुज़रते हैं। Docker इमेज non-root चलती है। कोर रिलीज़ के लिए CycloneDX SBOM जनरेट होता है, और PAIN001_DISABLE_PLUGINS=1 से तृतीय-पक्ष प्लगइन खोज पूरी तरह अक्षम की जा सकती है।
गुणवत्ता कैसे लागू की जाती है?
कोर पर कठोर CI गेट के रूप में 100% लाइन और ब्रांच कवरेज (सत्यापन-योग्य रूप से: 3,828 लाइनें, 926 ब्रांच 100% पर), सख़्त mypy, 100% docstring कवरेज, Bandit और pip-audit सुरक्षा लिंटिंग, तथा CodeQL स्कैनिंग। सहयोगी पैकेज वही 100% कवरेज अनुशासन अपनाते हैं।
क्या हम इसे किसी स्वामित्व वाले प्रारूप के लिए विस्तारित कर सकते हैं?
हाँ — चार प्लगइन एंट्री-पॉइंट समूह (pain001.loaders, pain001.validators, pain001.schemes, pain001.writers)। Excel लोडर स्वयं सार्वजनिक प्रोटोकॉल का उपयोग करने वाला एक प्लगइन है, इसलिए वह संदर्भ कार्यान्वयन का भी काम करता है।
ऑडिटरों और अनुपालन के लिए#
क्या हम पिछली तिमाही में जनरेट की गई फ़ाइल पुनरुत्पादित कर सकते हैं?
हाँ। पैकेज संस्करण पिन करें, वही इनपुट दोबारा चलाएँ, और आउटपुट नियतात्मक होगा। चूँकि टूलचेन ओपन सोर्स है, ऑडिट ट्रेल कोड पथ तक जाती है — केवल वेंडर के प्रमाणन तक नहीं।
क्या भुगतान डेटा हमारे वातावरण से बाहर जाता है?
नहीं। हर घटक — CLI, लाइब्रेरी, REST API, MCP सर्वर, LSP — स्थानीय रूप से चलता है। कोई टेलीमेट्री नहीं, कोई SaaS कॉलबैक नहीं, कोई बाहरी सत्यापन सेवा नहीं। MCP सर्वर केवल stdio पर संवाद करता है और इसके सभी 17 टूल read-only और idempotent के रूप में एनोटेट हैं।
Pain001 का रखरखाव कौन करता है?
Sebastien Rousseau, लंदन-स्थित फ़िनटेक इंजीनियरिंग लीडर, सामुदायिक योगदानकर्ताओं के साथ। विकास GitHub पर सार्वजनिक है, रिलीज़ PyPI पर प्रकाशित होती हैं, और चेंजलॉग हर रिलीज़ के साथ संस्करणबद्ध है।