תשובות ישירות לגזברים, לתפעול התשלומים, למהנדסים ולמבקרים. השאלות מנוסחות כפי שאנשים באמת שואלים אותן. לפירוט טכני מעמיק יותר ראו את המדריך הטכני.
לגזברות ולמנהלי כספים#
מהו 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 מאומת ללא הקלדה מחדש של דבר.
מה משמעות המועד האחרון של נובמבר 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 לכל רשומה, בדיקות IBAN לפי mod-97 ובדיקות BIC לפי ISO 9362, סכומי בקרה מחושבים מחדש, תעתיק ערכת התווים ואימות 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 כדי לראות כל כלל שעבר או נכשל.
הנתונים שלנו נמצאים ב-Excel. מה המלכוד?
Excel ממיר בשקט מחרוזות הדומות ל-IBAN למספרים. טוען ה-Excel קורא קובצי .xlsx/.xlsm ישירות ועוצר לחלוטין אם עמודות IBAN מכילות תאים מספריים — השיבוש נתפס בשלב הטעינה, ולא אצל הבנק.
כיצד המערכת מטפלת באצווה של 500,000 שורות?
--streaming מעבד את הקלט במקטעים עם צריכת זיכרון חסומה (ברירת מחדל 1,000 עסקאות), וכל מקטע נפלט כקובץ XML נפרד עם סכומי בקרה מחושבים מחדש כהלכה. ה-REST API מציע את POST /api/v1/generate/async עם תשאול משימות מאותה סיבה.
למהנדסים ולארכיטקטים#
כיצד משלבים את זה — כספרייה, כ-CLI או כ-API?
שלושת המשטחים קיימים כאזרחים שווי זכויות: Python API מטופס, CLI עם קודי יציאה ידידותיים ל-CI ומיקרו-שירות FastAPI (pain001 serve) עם נקודות קצה סינכרוניות, נקודות קצה למשימות אסינכרוניות, לבדיקת בריאות ולמדדי Prometheus. מתחת לכולם פועל אותו צינור אימות, ולכן התוצאות לעולם אינן נבדלות בין המשטחים.
האם יצירת ה-XML באמת מוגנת מפני עיגול נקודה צפה?
הסכומים הם decimal.Decimal מקצה לקצה ביצירה ובאימות המסלול — מנותחים כעשרוניים מדויקים, מסוכמים כעשרוניים מדויקים ומוצגים ללא ייצוג נקודה צפה. סכומי הבקרה מחושבים מחדש מתוך הרשומות המאומתות ולעולם אינם נלקחים כנתון מהקלט.
מהי עמידות האבטחה?
כל ניתוח XML עובר דרך defusedxml (החוסם התקפות XXE והתפשטות ישויות); אין lxml בעץ התלויות. הקלטים עוברים מאמת מפני מעבר נתיבים. תמונת ה-Docker רצה ללא הרשאות root. עבור גרסאות הליבה נוצר SBOM בפורמט CycloneDX, ואיתור תוספים של צד שלישי ניתן להשבתה מוחלטת באמצעות PAIN001_DISABLE_PLUGINS=1.
כיצד נאכפת האיכות?
100% כיסוי שורות והסתעפויות כשער CI נוקשה בליבה (בבדיקה: 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 הכלים שלו מסומנים כקריאה בלבד וכאידמפוטנטיים.
מי מתחזק את Pain001?
Sebastien Rousseau, מוביל הנדסה בתחום הפינטק מלונדון, יחד עם תורמים מהקהילה. הפיתוח מתנהל בפומבי ב-GitHub, הגרסאות מתפרסמות ב-PyPI, ויומן השינויים מתעדכן בכל שחרור.