پاسخهای روشن برای خزانهداران، عملیات پرداخت، مهندسان و حسابرسان. پرسشها به همان شکلی نوشته شدهاند که مردم واقعاً میپرسند. برای جزئیات فنی بیشتر، مرجع فنی را ببینید.
برای مدیران خزانهداری و مالی#
pain.001 در یک پاراگراف چیست؟
pain.001 همان پیام ISO 20022 است که مشتری برای آغاز انتقالهای اعتباری به بانک خود میفرستد — جانشین XML قالبهایی مانند SWIFT MT101 و فایلهای تخت داخلی. بانک شما پیش از پذیرش، آن را در برابر یک طرحواره و یک آییننامه طرح اعتبارسنجی میکند. Pain001 (نرمافزار) این فایلها را از دادهای که هماکنون در اختیار دارید میسازد و پیش از ارسال ثابت میکند که معتبرند.
تفاوت pain.001 و pain.008 چیست؟
جهت جریان پول. pain.001 انتقال اعتباری را آغاز میکند — پول را بیرون میفرستید. pain.008 برداشت مستقیم را آغاز میکند — پولی را که بر پایه یک مجوز به شما بدهکارند وصول میکنید. Pain001 هر دو را تولید میکند: ده نسخه pain.001 (.001.03 تا .001.12) و pain.008.001.02.
ما هنوز فایلهای MT101 میفرستیم. مهاجرت چقدر فوری است؟
فوری. SWIFT پیامهای دسته 1، 2 و 9 از خانواده MT را برای دستورهای پرداخت برونمرزی بینبانکی در نوامبر 2025 بازنشسته کرد؛ کانالهای شرکتی که هنوز MT را میپذیرند، این کار را به صلاحدید هر بانک و در فرصتی عاریتی انجام میدهند. بارگذار MT101 جریانهای موجود MT101 را بدون بازتایپ هیچ دادهای به pain.001 معتبر تبدیل میکند.
مهلت نوامبر 2026 برای نشانی ساختیافته چه معنایی برای ما دارد؟
از پایان نوامبر 2026، نشانیهای پستی کاملاً بدون ساختار دیگر در پرداختهای برونمرزی CBPR+ پذیرفته نمیشوند؛ نشانیها باید ساختیافته یا ترکیبی باشند — عناصری مجزا مانند شهر (
هزینه Pain001 چقدر است؟
هیچ. هسته با مجوز دوگانه Apache-2.0 / MIT عرضه میشود؛ بستههای همراه Apache-2.0 هستند. استفاده تجاری، تغییر و بازتوزیع همگی مجازند. برای درک مقیاس، تنها SDK ترجمه SWIFT سالانه €10,000–30,000 قیمتگذاری شده است.
برای عملیات پرداخت#
چرا بانکها فایلهای پرداخت را رد میکنند؟
چهار علت تکرارشونده: نقض طرحواره (عنصر نادرست، نسخه نادرست، فضای نام نادرست)، شناسههای معیوب (شکست رقم کنترلی IBAN، BIC بدشکل)، مجموعهای کنترلی ناسازگار (NbOfTxs / CtrlSum که با تراکنشها نمیخواند) و نویسههای بیرون از مجموعه لاتین ISO 20022. Pain001 هر چهار مورد را پیش از آنکه فایلی وجود داشته باشد بررسی میکند: اعتبارسنجی JSON Schema برای هر رکورد، بررسی باقیمانده بر 97 برای IBAN و ساختار ISO 9362 برای BIC، بازمحاسبه مجموعهای کنترلی، حرفنگاری نویسهها و اعتبارسنجی نهایی XSD روی XML رندرشده.
آیا میتوانیم فایلی را بدون تولید چیزی اعتبارسنجی کنیم؟
بله — pain001 --dry-run (یا زیرفرمان validate، یا POST /api/v1/validate). کد خروج 0 یعنی معتبر؛ 1 یعنی اعتبارسنجی با خطاهای سطح فیلد شکست خورده است. آن را در CI یا در سیاهه بررسی پیش از ارسال بگنجانید.
کدام آییننامههای SEPA پوشش داده شدهاند؟
پنج آییننامه طرح بهصورت درونساخت عرضه میشوند: انتقال اعتباری SEPA (sepa-sct)، SEPA Instant (sepa-inst)، برداشت مستقیم SEPA Core (sepa-sdd)، SEPA B2B (sepa-b2b) و انتقال اعتباری برونمرزی (xborder-ct). با --scheme میتوانید هر قاعده موفق یا ناموفق را ببینید.
دادههای ما در Excel نگهداری میشود. مشکل کجاست؟
Excel رشتههای شبیه IBAN را خاموشانه به عدد تبدیل میکند. بارگذار Excel فایلهای .xlsx/.xlsm را مستقیماً میخواند و اگر ستونهای IBAN حاوی سلول عددی باشند، کار را قاطعانه متوقف میکند — خرابی هنگام بارگذاری گرفته میشود، نه در بانک.
یک دسته 500,000 سطری را چگونه مدیریت میکند؟
--streaming ورودی را در تکههایی با مصرف حافظه کراندار پردازش میکند (پیشفرض 1,000 تراکنش) و هر تکه بهعنوان فایل XML مستقل خود، با مجموعهای کنترلی درست و بازمحاسبهشده، منتشر میشود. رابط REST نیز به همین دلیل POST /api/v1/generate/async را همراه با پرسوجوی وضعیت کار ارائه میدهد.
برای مهندسان و معماران#
چگونه آن را یکپارچه کنیم — کتابخانه، CLI یا API؟
هر سه بهعنوان سطوح درجهیک در دسترساند: یک رابط Python نوعدار، یک CLI با کدهای خروج مناسب CI، و یک ریزخدمت FastAPI (pain001 serve) با نقاط انتهایی همگام، کار ناهمگام، سلامت و سنجههای Prometheus. خط لوله اعتبارسنجی زیرین یکی است، بنابراین نتایج میان این سطوح هرگز واگرا نمیشود.
آیا تولید XML واقعاً در برابر گرد شدن اعشاری شناور ایمن است؟
مبالغ در تولید و اعتبارسنجی طرح، سرتاسر بهصورت decimal.Decimal هستند — بهشکل اعشاری دقیق تجزیه میشوند، بهشکل اعشاری دقیق جمع میشوند و بدون بازنمایی شناور رندر میگردند. مجموعهای کنترلی از روی رکوردهای اعتبارسنجیشده بازمحاسبه میشوند و هرگز از ورودی پذیرفته نمیشوند.
وضعیت امنیتی چگونه است؟
همه تجزیههای XML از مسیر defusedxml میگذرند (که حملههای XXE و انفجار موجودیت را مسدود میکند)؛ lxml در درخت وابستگیها وجود ندارد. ورودیها از یک اعتبارسنج پیمایش مسیر عبور میکنند. تصویر Docker با کاربر غیرروت اجرا میشود. برای انتشارهای هسته یک SBOM با قالب CycloneDX تولید میشود و شناسایی افزونههای شخص ثالث را میتوان بهکلی با PAIN001_DISABLE_PLUGINS=1 غیرفعال کرد.
کیفیت چگونه تضمین میشود؟
پوشش 100% خطوط و شاخهها بهعنوان دروازه سخت CI روی هسته (بهشکل قابل راستیآزمایی: 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 منتشر میگردد و سیاهه تغییرات با هر انتشار نسخهگذاری میشود.