إجابات مباشرة لأمناء الخزانة وفرق عمليات الدفع والمهندسين والمدققين. الأسئلة مصاغة كما يطرحها الناس فعلًا. ولمزيد من التفصيل التقني، راجع المرجع التقني.
لقادة الخزانة والمالية#
ما هو 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 رسائل MT من الفئات 1 و2 و9 لتعليمات الدفع بين البنوك عبر الحدود في نوفمبر 2025؛ والقنوات المؤسسية التي ما زالت تقبل MT تفعل ذلك وفق تقدير كل بنك وعلى وقت مستعار. يحوّل محمّل MT101 تدفقات MT101 القائمة إلى pain.001 متحقَّق منه دون إعادة إدخال أي شيء.
ماذا يعني لنا متطلب العناوين المهيكلة؟
كانت Swift تعتزم التوقف عن قبول العناوين البريدية غير المهيكلة كليًا في مدفوعات CBPR+ عبر الحدود في نوفمبر 2026. وفي أغسطس 2026 أجّلت ذلك الموعد وستعلن الموعد الجديد بحلول ديسمبر 2026، لكن القاعدة لم تتغير: يجب أن تكون العناوين مهيكلة أو هجينة، أي عناصر منفصلة مثل المدينة (<TwnNm>) والبلد (<Ctry>) بدلًا من أسطر نص حر. وإذا كانت بياناتك الرئيسية تخزّن العناوين ككتل نصية، فالعمل يكمن في بياناتك لا في اتصالك البنكي. ابدأ من هناك. وتغطي إحاطة 2026 الجدول الزمني بالتفصيل.
كم يكلّف Pain001؟
لا شيء. النواة مرخّصة ترخيصًا مزدوجًا Apache-2.0 / MIT؛ والحزم المصاحبة مرخّصة Apache-2.0. الاستخدام التجاري والتعديل وإعادة التوزيع كلها مسموح بها. وللمقارنة، تُدرج SDK الترجمة من SWIFT وحدها بسعر €10,000–30,000 سنويًا.
لعمليات الدفع#
لماذا ترفض البنوك ملفات الدفع؟
أربعة أسباب متكررة: مخالفات المخطط (عنصر خاطئ، أو إصدار خاطئ، أو نطاق أسماء خاطئ)، ومعرّفات سيئة (إخفاقات مجموع تحقق IBAN، ورموز BIC مشوّهة)، ومجاميع ضبط مكسورة (NbOfTxs / CtrlSum لا تطابق المعاملات)، ومحارف خارج مجموعة ISO 20022 اللاتينية. يفحص Pain001 الأربعة كلها قبل أن يوجد الملف: تحقق JSON Schema لكل سجل، وفحوص mod-97 لـ IBAN وISO 9362 لـ BIC، ومجاميع ضبط معاد حسابها، ونقل حرفي لمجموعة المحارف، وتحقق نهائي وفق XSD لملف XML المولَّد.
هل يمكننا التحقق من ملف دون توليد أي شيء؟
نعم. استخدم 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 البرمجية 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 البرمجية وخادم MCP وLSP) يعمل محليًا. لا قياس عن بُعد، ولا استدعاء لخدمة SaaS، ولا خدمة تحقق خارجية. يتخاطب خادم MCP عبر stdio فقط، وأدواته الـ 17 كلها موسومة بأنها للقراءة فقط وآمنة عند التكرار.
من يصون Pain001؟
Sebastien Rousseau، قائد هندسة تقنية مالية مقيم في لندن، مع مساهمين من المجتمع. التطوير علني على GitHub، والإصدارات تُنشر على PyPI، وسجل التغييرات مُرقَّم مع كل إصدار.