ट्रेझरर, पेमेंट ऑपरेशन्स, अभियंते आणि ऑडिटर यांच्यासाठी थेट उत्तरे. प्रश्न लोक प्रत्यक्षात जसे विचारतात तसेच मांडले आहेत. अधिक सखोल तांत्रिक तपशिलासाठी तांत्रिक संदर्भ पाहा.
ट्रेझरी व वित्त प्रमुखांसाठी#
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 मध्ये रूपांतरित करतो.
संरचित पत्त्याची आवश्यकता आमच्यासाठी काय अर्थ ठेवते?
Swift ने नोव्हेंबर 2026 मध्ये CBPR+ सीमापार पेमेंटमध्ये पूर्णपणे असंरचित टपाल पत्ते स्वीकारणे थांबवण्याची योजना आखली होती. ऑगस्ट 2026 मध्ये ती तारीख पुढे ढकलण्यात आली आणि नवीन तारीख डिसेंबर 2026 पर्यंत जाहीर केली जाईल, पण नियम बदललेला नाही: पत्ते संरचित किंवा संमिश्र असावे लागतील, म्हणजे मुक्त-मजकूर ओळींऐवजी शहर (<TwnNm>) व देश (<Ctry>) यांसारखे स्वतंत्र घटक. तुमच्या मास्टर डेटामध्ये पत्ते एकसंध मजकूर म्हणून साठवलेले असतील, तर काम तुमच्या डेटामध्ये आहे, बँक जोडणीत नाही. तिथूनच सुरुवात करा. 2026 चे विवरण या कालरेषेचा तपशीलवार आढावा घेते.
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 <name> --explain वापरा.
आमचा डेटा 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, आणि सिंक्रोनस, असिंक्रोनस-जॉब, हेल्थ व Prometheus मेट्रिक्स एंडपॉइंट असलेली FastAPI मायक्रोसर्व्हिस (pain001 serve). तिन्हींखाली एकच प्रमाणीकरण पाइपलाइन असल्याने निकाल कधीही वेगळे येत नाहीत.
XML निर्मिती खरोखरच फ्लोट पूर्णांकनापासून सुरक्षित आहे का?
निर्मिती व स्कीम प्रमाणीकरणात रकमा आद्यंत decimal.Decimal असतात. त्या अचूक दशांश म्हणून पार्स केल्या जातात, अचूक दशांश म्हणून बेरीज होते आणि फ्लोट स्वरूपाशिवाय सादर केल्या जातात. नियंत्रण एकूणे इनपुटवर विश्वास न ठेवता प्रमाणित नोंदींमधून पुन्हा मोजली जातात.
सुरक्षा स्थिती कशी आहे?
सर्व XML पार्सिंग defusedxml मार्फत होते (XXE व एंटिटी-विस्तार हल्ले रोखून); डिपेंडन्सी ट्रीमध्ये lxml नाही. इनपुट पाथ-ट्रॅव्हर्सल व्हॅलिडेटरमधून जातात. Docker प्रतिमा नॉन-रूट म्हणून चालते. मुख्य रिलीजसाठी CycloneDX SBOM तयार केला जातो आणि PAIN001_DISABLE_PLUGINS=1 ने तृतीय-पक्ष प्लगइन शोध पूर्णपणे बंद करता येतो.
गुणवत्ता कशी राखली जाते?
मुख्य घटकावर CI मध्ये कठोर निकष म्हणून 100% लाइन व ब्रँच कव्हरेज (पडताळणीयोग्य: 3,828 लाइन, 926 ब्रँच 100% वर), कठोर mypy, 100% डॉकस्ट्रिंग कव्हरेज, Bandit व pip-audit सुरक्षा लिंटिंग आणि CodeQL स्कॅनिंग. सहयोगी पॅकेजेसमध्येही तीच 100% कव्हरेज शिस्त पाळली जाते.
मालकीहक्क असलेल्या स्वरूपासाठी आम्ही ते विस्तारू शकतो का?
होय, चार प्लगइन एंट्री-पॉइंट गटांद्वारे (pain001.loaders, pain001.validators, pain001.schemes, pain001.writers). Excel लोडर स्वतःच सार्वजनिक प्रोटोकॉल वापरणारा प्लगइन आहे, त्यामुळे तो संदर्भ अंमलबजावणी म्हणूनही उपयोगी पडतो.
ऑडिटर व अनुपालनासाठी#
मागील तिमाहीत तयार झालेली फाइल आम्ही पुन्हा तयार करू शकतो का?
होय. पॅकेजची आवृत्ती निश्चित करा, तोच इनपुट पुन्हा चालवा आणि आउटपुट निर्धारित (डिटर्मिनिस्टिक) राहते. टूलचेन ओपन सोर्स असल्याने ऑडिट ट्रेल केवळ पुरवठादाराच्या प्रमाणपत्रापुरता न राहता थेट कोड मार्गापर्यंत पोहोचतो.
पेमेंट डेटा आमच्या वातावरणाबाहेर जातो का?
नाही. प्रत्येक घटक (CLI, लायब्ररी, REST API, MCP सर्व्हर, LSP) स्थानिक पातळीवरच चालतो. कोणतीही टेलिमेट्री नाही, SaaS कॉलबॅक नाही, बाह्य प्रमाणीकरण सेवा नाही. MCP सर्व्हर केवळ stdio वापरतो आणि त्याची सर्व 17 साधने रीड-ओन्ली व आयडेम्पोटंट म्हणून नोंदवलेली आहेत.
Pain001 ची देखभाल कोण करते?
Sebastien Rousseau, लंडनस्थित फिनटेक अभियांत्रिकी प्रमुख, समुदायातील योगदानकर्त्यांसह. विकास GitHub वर सार्वजनिक आहे, रिलीज PyPI वर प्रकाशित होतात आणि प्रत्येक रिलीजसोबत चेंजलॉगची आवृत्ती नोंदवली जाते.