Поширені запитання про ISO 20022 Поширені запитання про ISO 20022
Common questions about ISO 20022 pacs messages, how they work together, and how pacs008 helps teams implement them.
Загальні питання Загальні питання
Що таке ISO 20022?
ISO 20022 — міжнародний стандарт фінансових повідомлень. Визначає спільну мову та модель для платіжних повідомлень, якими обмінюються фінансові установи. На відміну від застарілих форматів, таких як SWIFT MT, ISO 20022 використовує XML та підтримує більш повні та структуровані дані про сторони, суми та посилання.
Що таке повідомлення pacs?
Сімейство повідомлень pacs (payments clearing and settlement) охоплює міжбанківські платіжні інструкції, звіти про статус, повернення, скасування та запити. Включає pacs.002, pacs.003, pacs.004, pacs.007, pacs.008, pacs.009, pacs.010 та pacs.028. Кожне повідомлення виконує визначену роль у життєвому циклі платежу.
Чим повідомлення pacs відрізняються від повідомлень SWIFT MT?
Повідомлення SWIFT MT використовують плоский формат із тегами полів (наприклад, MT103 для клієнтських кредитових переказів). Повідомлення pacs використовують ієрархічний XML із багатшими структурами даних. Ключові відмінності: підтримка кількох транзакцій в одному повідомленні, структурована ідентифікація сторін (LEI, множинні ідентифікатори), структуровані поштові адреси та структурована інформація про призначення платежу. MT103 відповідає pacs.008, MT202 — pacs.009, текст статусу MT199 замінюється pacs.002.
Який зв'язок між повідомленнями pain та pacs?
Повідомлення pain (payment initiation) передаються між клієнтом та банком. Повідомлення pacs передаються між банками. Ініціювання кредитового переказу pain.001 від банку боржника перетворюється на міжбанківську інструкцію pacs.008. Обидва домени використовують спільні елементи даних, але обслуговують різні ділянки платіжного ланцюга.
Вибір повідомлення Вибір повідомлення
Коли використовувати pacs.008?
pacs.008 призначений для інструкцій клієнтського кредитового переказу між банками. Містить дані сторін — боржника та кредитора, суми, інформацію про призначення платежу та деталі розрахунку. Це основне повідомлення для надсилання клієнтських платежів через міжбанківську мережу, як всередині країни (SEPA), так і транскордонно (CBPR+).
Коли використовувати pacs.009 замість pacs.008?
pacs.009 призначений для переказів власних коштів між установами, етапів фінансування та покриваючих платежів. На відміну від pacs.008, який несе клієнтський платіж від імені боржника, pacs.009 переміщує кошти між банками за власний рахунок. У покриваючих потоках pacs.009 забезпечує фінансування, а pacs.008 передає клієнтську інструкцію окремим маршрутом.
У чому різниця між pacs.004 та pacs.007?
pacs.004 повертає розраховані кошти від приймаючої сторони назад по ланцюгу. pacs.007 скасовує платіж від вихідної інструктуючої сторони вперед по ланцюгу. pacs.004 — коли банк бенефіціара не може зарахувати кошти після розрахунку. pacs.007 — коли відправник виявляє помилку, дублікат або шахрайство.
Коли використовувати pacs.028 замість очікування pacs.002?
pacs.028 використовується для активного запиту статусу платежу, який не отримав своєчасного оновлення pacs.002. pacs.002 ініціюється подією (приймаючий агент надсилає його проактивно), тоді як pacs.028 ініціюється винятком (інструктуючий агент запитує його). pacs.028 — для затриманих, неясних або відсутніх оновлень, а не для рутинного трафіку.
Для чого призначений pacs.003?
pacs.003 передає інструкції прямого дебету клієнта між банками. Агент кредитора надсилає його агенту боржника для збору коштів. Потрібне дійсне посилання на мандат. Підтримуються схеми SEPA Core та B2B прямого дебету. Не використовується для кредитових переказів або дебетування власних рахунків установ.
Для чого призначений pacs.010?
pacs.010 обробляє прямі дебети між фінансовими установами за власними рахунками. Застосовується для міжбанківських зборів, маржинальних вимог та аналогічних зобов'язань у рамках двосторонніх угод. Не використовується для клієнтських прямих дебетів або кредитових переказів.
Структура повідомлення Структура повідомлення
Що таке заголовок групи (GrpHdr)?
Заголовок групи з'являється рівно один раз у кожному повідомленні pacs. Містить ідентифікатор повідомлення (MsgId), часову мітку створення (CreDtTm), кількість транзакцій (NbOfTxs), інформацію про розрахунок (SttlmInf) та опціонально загальну суму міжбанківського розрахунку та інформацію про тип платежу. Визначає конверт повідомлення, а не окремі бізнес-транзакції.
Які ідентифікатори платежу використовуються в pacs.008?
pacs.008 використовує чотири основні ідентифікатори. MsgId ідентифікує конверт повідомлення та змінюється на кожному кроці. InstrId — посилання між суміжними агентами, може змінюватися на кожному кроці. EndToEndId встановлюється відправником та не повинен змінюватися жодним агентом у ланцюгу. TxId призначається першим інструктуючим агентом та залишається постійним у міжбанківському просторі. UETR — UUID, незмінний на всіх сегментах для наскрізного відстеження.
Які методи розрахунку доступні?
Визначено чотири методи розрахунку. CLRG — через клірингову систему, таку як TARGET2, EURO1 або CHIPS. INDA — на рахунках інструктованого агента, де агент боржника має рахунок «ностро». INGA — на рахунках інструктуючого агента, де інструктований агент має рахунок «ностро». COVE — через окремий покриваючий платіж, що передається pacs.009.
Що означають коди несення витрат?
DEBT — усі витрати несе боржник (еквівалент MT103 OUR). CRED — усі витрати несе кредитор (еквівалент BEN). SHAR — витрати розподіляються між агентами боржника та кредитора (еквівалент SHA). SLEV — витрати визначаються рівнем сервісу, обов'язковий для переказів SEPA.
CBPR+ та міграція CBPR+ та міграція
Що таке CBPR+?
CBPR+ (Cross-Border Payments and Reporting Plus) — програма SWIFT із впровадження ISO 20022 у транскордонній платіжній системі повідомлень. Запущена у березні 2023 та замінює повідомлення MT еквівалентами pacs. CBPR+ вимагає pacs.002 для всіх комунікацій про статус платежу, підтримує розширені дані сторін та структуровані адреси, використовує відстеження на основі UETR через gpi.
Що сталося з періодом співіснування MT/MX?
Період співіснування для транскордонних платіжних інструкцій завершився у листопаді 2025 року. Відтоді повідомлення CBPR+ використовують формат ISO 20022 (MX). Сервіси трансляції між MT та MX, що працювали в період переходу, більше недоступні для нових потоків. Банки зобов'язані надсилати та отримувати нативні повідомлення pacs.
Який граничний термін листопада 2026 для структурованих адрес?
З листопада 2026 року SWIFT CBPR+ вимагає структуровані поштові адреси в транскордонних платіжних повідомленнях. Неструктуровані рядки адреси (лише AdrLine) більше не приймаються для ключових полів сторін. Мінімально потрібні TwnNm та Ctry, рекомендуються StrtNm та BldgNb або PstBx. Це покращує фільтрацію санкцій та скорочує ручні виправлення.
Як pacs.008 замінює MT103?
pacs.008 замінює MT103 та MT103+ для клієнтських кредитових переказів. Основні відповідності: поле 20 MT103 — MsgId або InstrId; поле 32A розділяється на IntrBkSttlmDt та IntrBkSttlmAmt; поле 50a — Dbtr та DbtrAcct; поле 59a — Cdtr та CdtrAcct; поле 70 — RmtInf; поле 71A — ChrgBr. pacs.008 додає UETR, структуровану інформацію про призначення платежу, ідентифікацію LEI та підтримує кілька транзакцій в одному повідомленні.
Технічні деталі Технічні деталі
Що таке структуровані та неструктуровані адреси?
Структуровані адреси використовують окремі XML-елементи для кожного компонента: StrtNm (вулиця), BldgNb (номер будинку), PstCd (поштовий індекс), TwnNm (місто), Ctry (країна) та опціональні елементи Flr, Room, DstrctNm. Неструктуровані адреси використовують до семи елементів AdrLine із вільним текстом. Гібридні адреси поєднують обидва формати в перехідний період. Після листопада 2026 CBPR+ вимагає структурований формат.
Що таке UETR і як працює відстеження gpi?
UETR (Unique End-to-End Transaction Reference) — ідентифікатор UUID v4, згенерований агентом боржника та переданий без змін на всіх сегментах платежу. Присутній у pacs.008, pacs.009, pacs.002, pacs.004, pacs.007 та pacs.028. SWIFT gpi використовує UETR для відстеження платежів через хмарну базу даних Tracker. Кожен агент підтверджує отримання та обробку, забезпечуючи наскрізну видимість та контроль SLA.
Які коди статусу використовуються в pacs.002?
ACCP — прийнято після перевірки профілю клієнта. ACSP — прийнято, розрахунок виконується. ACSC — розрахунок на рахунку боржника завершено. RJCT — відхилено (з кодом причини в StsRsnInf). PDNG — очікує подальшої обробки. RCVD — отримано, але ще не оброблено. Кожен статус може включати структурований код причини, такий як AC01 (невірний номер рахунку), AM04 (недостатньо коштів) або RC01 (невірний BIC).
Які коди причин повернення використовуються в pacs.004?
Часті коди причин повернення: AC01 (невірний номер рахунку), AC04 (рахунок закрито), AC06 (рахунок заблоковано), AM04 (недостатньо коштів), BE04 (відсутня адреса кредитора), CUST (запит клієнта), DUPL (дублюючий платіж), FOCR (за запитом на скасування) та FR01 (шахрайство). Повний перелік визначено в External Code Sets ISO 20022.
Що таке структурована інформація про призначення платежу?
Структурована інформація в pacs.008 використовує елемент RmtInf/Strd для передачі посилань на документи (номери рахунків-фактур, кредитових авізо), сум (належних, перерахованих, податків, знижок) та посилань кредитора (посилання RF за ISO 11649). Це дозволяє автоматизувати звірку рахунків-фактур. Поширені коди типів документів: CINV (комерційний рахунок-фактура), CREN (кредитове авізо) та SOAC (виписка за рахунком).
Що таке LEI і коли він використовується?
LEI (Legal Entity Identifier) — 20-символьний буквено-цифровий код за ISO 17442. Однозначно ідентифікує юридичних осіб, що беруть участь у фінансових транзакціях. У повідомленнях pacs LEI вказується в OrgId/LEI для сторін та FinInstnId/LEI для агентів. CBPR+ дедалі активніше просуває використання LEI для ідентифікації сторін та агентів. Покращує розв'язання неоднозначності юридичних осіб та відповідає вимогам регуляторної звітності.
Про інструментарій pacs008 Про інструментарій pacs008
Що робить pacs008?
pacs008 — інструментарій мовою Python для генерації, валідації та відправки платіжних повідомлень ISO 20022. Зчитує платіжні дані з джерел CSV, JSON, JSONL, SQLite та Parquet, виконує валідацію за JSON Schema та XSD, перевіряє ідентифікатори IBAN та BIC, очищує дані для відповідності вимогам SWIFT до символів та формує XML-файли. Надає REST API, CLI та бібліотеку Python.
Які типи повідомлень підтримує pacs008?
pacs008 підтримує вісім типів повідомлень: pacs.002.001.12 (звіт про статус), pacs.003.001.09 (клієнтський прямий дебет), pacs.004.001.11 (повернення платежу), pacs.007.001.11 (скасування платежу), pacs.008.001.13 (клієнтський кредитовий переказ), pacs.009.001.10 (переказ між фінансовими установами), pacs.010.001.05 (прямий дебет між фінансовими установами) та pacs.028.001.05 (запит статусу платежу).
Як pacs008 допомагає з граничним терміном листопада 2026 для структурованих адрес?
pacs008 перевіряє поля структурованих та гібридних поштових адрес перед генерацією XML. Виявляє неструктуровані адресні дані, які будуть відхилені після граничного терміну листопада 2026, підтримує гібридні формати до настання терміну та виключно структуровані — після, інтегрує контроль якості адрес у пайплайни CI та пакетні процеси валідації.
Чи може pacs008 валідувати дані без генерації XML?
Так. Використовуйте прапорець CLI --dry-run або ендпоінт API POST /validate для валідації платіжних даних без генерації XML. Конвеєр валідації перевіряє відповідність JSON Schema, формат та контрольну суму IBAN, структуру BIC та відповідність вимогам SWIFT до символів. Код завершення або відповідь API вказує на успіх або помилку валідації.