Часто задаваемые вопросы об 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 указывает на успех или ошибку валидации.