Прямі відповіді для казначеїв, платіжних операцій, інженерів та аудиторів. Питання сформульовані так, як їх насправді ставлять. Глибші технічні деталі — у технічному довіднику.
Для керівників казначейства та фінансів#
Що таке 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. Наскільки термінова міграція?
Термінова. У листопаді 2025 року SWIFT вивів з експлуатації повідомлення MT категорій 1, 2 і 9 для транскордонних міжбанківських платіжних інструкцій; корпоративні канали, що досі приймають 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 для кожного запису, перевірки 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, CLI зі зручними для CI кодами виходу та мікросервіс FastAPI (pain001 serve) з ендпоінтами синхронної генерації, асинхронних завдань, перевірки стану та метрик Prometheus. Під ними один і той самий конвеєр валідації, тому результати ніколи не розходяться між інтерфейсами.
Чи справді генерація XML захищена від округлення float?
Суми — це decimal.Decimal від початку до кінця в генерації та перевірці правил схем: розбираються як точні десяткові числа, підсумовуються як точні десяткові числа, записуються без рухомого подання. Контрольні підсумки переобчислюються з перевірених записів і ніколи не беруться на віру з вхідних даних.
Який стан безпеки?
Увесь розбір XML іде через defusedxml (що блокує атаки XXE та розширення сутностей); у дереві залежностей немає lxml. Вхідні дані проходять валідатор обходу шляхів. Образ Docker працює не від root. Для релізів ядра генерується CycloneDX SBOM, а виявлення сторонніх плагінів можна повністю вимкнути через 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 інструментів позначені як read-only та ідемпотентні.
Хто підтримує Pain001?
Sebastien Rousseau, лондонський керівник фінтех-інжинірингу, разом з учасниками спільноти. Розробка відкрита на GitHub, релізи публікуються в PyPI, а журнал змін версіонується з кожним релізом.