SWIFT

Переводы SWIFT и обмен сообщениями в форматах MT и MX

SWIFT (Society for Worldwide Interbank Financial Telecommunication) — защищённая сеть обмена сообщениями, позволяющая финансовым организациям, в частности банкам, отправлять и получать стандартизированные сообщения о финансовых операциях, такие как платёжные инструкции и подтверждения. SWIFT не ведёт счетов и не переводит средства; она лишь предоставляет защищённую и надёжную платформу для обмена информацией.

Обычные переводы SWIFT используют ряд стандартизированных типов сообщений, известных как сообщения MT (Message Type). Эти сообщения имеют заранее определённые форматы и поля, что позволяет финансовым учреждениям без затруднений понимать и обрабатывать содержащуюся в них информацию.

Сообщения MX (ISO 20022) представляют собой более новый стандарт финансовых сообщений на основе XML (eXtensible Markup Language). Они обеспечивают более богатый и структурированный формат, позволяющий расширить обмен данными и улучшить сквозную обработку платежей. Сообщения MX постепенно заменяют сообщения MT в сети SWIFT, что направлено на повышение совместимости и качества обработки данных.

Традиционные переводы SWIFT десятилетиями составляли основу международных платежей, однако им присущи определённые ограничения, включая ограниченную прозрачность, более медленную обработку и неструктурированность данных.

Swift 103+ STP (сквозная обработка платежей)

Swift 103+ STP — прежний формат MT, оптимизированный для сквозной обработки платежей (Straight Through Processing, STP); после завершения периода сосуществования его роль выполняет руководство по использованию pacs.008 STP. Сквозная обработка позволяет проводить весь платёжный процесс, от инициирования до окончательного расчёта, в электронном виде без ручного вмешательства.

Дополнительные возможности:

1. Стандартизированный формат: требует строгого соблюдения стандартизированного формата, что сокращает количество ошибок и задержек.
2. Автоматизированная обработка: транзакции обрабатываются автоматически, что обеспечивает более быструю и эффективную обработку.
3. Сокращение ручного вмешательства: потребность в ручном вводе и проверке данных снижается, что уменьшает риск ошибок и задержек.
4. Ускоренные расчёты: операции проводятся быстрее, чем при использовании традиционных методов.

Соображения, касающиеся STP:

1. Точный ввод данных: данные должны вводиться точно, чтобы избежать задержек или отклонения.
2. Соблюдение требований к формату: банки должны обеспечить строгое соблюдение требований к формату 103+ STP.
3. Программное обеспечение и системы: для эффективной обработки платежей в режиме сквозной обработки (STP) банкам необходимо располагать соответствующим программным обеспечением и системами

Необходимо различать обмен сообщениями и расчёты. SWIFT передаёт структурированные финансовые сообщения между организациями, но сам не осуществляет перевод средств и не ведёт остатки. Подтверждение SWIFT, включая сообщение pacs.008, имеет силу только тогда, когда оно соответствует реальной операции, проведённой и сверенной в банковских системах участвующих организаций.

Любой отдельный документ SWIFT, снимок экрана или сообщение, представленные без институционального подтверждения, не следует рассматривать как доказательство завершённых расчётов.

Переводы SWIFT gpi.

SWIFT gpi (Global Payments Innovation):

Запущенная в 2017 году инициатива SWIFT gpi призвана устранить ограничения традиционных переводов SWIFT за счёт повышения скорости, прозрачности и отслеживаемости трансграничных платежей. SWIFT gpi использует существующие форматы сообщений MT и MX для совершенствования платёжных услуг. К основным особенностям SWIFT gpi относятся:

• Более быстрые платежи: gpi упрощает процессы и устанавливает более жёсткие соглашения об уровне обслуживания (SLA) между банками, что сокращает сроки проведения операций, зачастую до нескольких минут или секунд.
• Отслеживание платежей: gpi Tracker позволяет отслеживать операции в режиме реального времени, повышая прозрачность и сокращая объём ручных расследований.
• Прозрачность комиссий: банки могут заранее предоставлять клиентам информацию о комиссиях за операции, что позволяет принимать более взвешенные решения.
• Более богатые данные: gpi поддерживает обмен более подробной и структурированной информацией, что облегчает сверку и соблюдение регуляторных требований.

SWIFT gpi устраняет ограничения традиционных переводов SWIFT, совершенствуя трансграничные платежи за счёт сквозного отслеживания, ускоренной обработки и более насыщенных данных.

Ключевые параметры для участников, не подключённых к SWIFT gpi

Когда участник, не входящий в SWIFT gpi (например, банк или финансовая организация, напрямую не подключённые к gpi), направляет платёжное поручение банку — участнику gpi, банк-участник gpi может преобразовать его в необходимые форматы сообщений SWIFT (pacs.008 для кредитовых переводов клиентов, pacs.009 COV для покрывающих переводов и pacs.009 для кредитовых переводов финансовых организаций). Такое преобразование позволяет обрабатывать и отслеживать платёж в сети gpi при условии, что поручение содержит достаточно данных для заполнения обязательных полей и соответствует правилам gpi, в частности требованию сквозной прослеживаемости.

Участники, не входящие в gpi, как правило, передают эти параметры через национальные платёжные схемы, API или устаревшие форматы, а банк — участник gpi добавляет специфические для gpi элементы (например, формирует UETR, если он не передан, хотя его передача для участников, не входящих в gpi, необязательна). Точные требования могут различаться в зависимости от юрисдикции, валюты и двусторонних соглашений, однако основные параметры определены руководящими принципами CBPR+ (Cross-Border Payments and Reporting Plus) и стандартами ISO 20022. После завершения периода сосуществования 22 ноября 2025 года обмен инструкциями по трансграничным платежам осуществляется в формате ISO 20022; ссылки на поля устаревших сообщений MT приведены ниже лишь для ориентира.
1. Идентификация сторон (сведения о плательщике и получателе)
Эти данные идентифицируют инициатора платежа и бенефициара и обеспечивают соблюдение Рекомендации 16 FATF в части требований «правила передачи информации» (travel rule).

• Должник/Заказчик платежа: полное наименование, структурированный адрес (улица, город, почтовый индекс, страна) и идентификация счёта (например, IBAN или номер счёта). В прежних форматах MT 103/MT 202 COV это соответствует полю 50a; для pacs.008/pacs.009 — элементам <Dbtr> и <DbtrAcct>.
• Кредитор/клиент-бенефициар: полное наименование, структурированный адрес и идентификация счёта. Соответствует полю 59a прежних сообщений MT 103/MT 202 COV; элементам <Cdtr> и <CdtrAcct> в pacs.008/pacs.009.
• Конечный должник/кредитор (при наличии): если он отличается от основных сторон, укажите его реквизиты для повышения прозрачности (необязательно, но рекомендуется для отслеживания gpi). Соответствует элементам <UltmtDbtr>/<UltmtCdtr> в pacs.008/pacs.009.

Причина необходимости: обеспечивает точную маршрутизацию и проведение регуляторных проверок; неполные данные могут привести к отклонению платежа или задержкам.

2. Информация об агентах и маршрутизации
Определяет финансовые учреждения, участвующие в цепочке.

• Агент дебитора: BIC (Bank Identifier Code) или иной идентификатор банка-отправителя. Соответствует полю 52a прежнего формата MT 103; <DbtrAgt> в pacs.008/pacs.009.
• Банк получателя (Creditor Agent): BIC банка-получателя. Соответствует полю 57a прежних сообщений MT 103/MT 202 COV; элемент <CdtrAgt> в pacs.008/pacs.009.
• Посреднические агенты (если известны): BIC любых корреспондентов (до 3 уровней). Соответствует полю 56a прежнего формата MT; <IntrmyAgt1-3> в pacs.008/pacs.009.
• Инструктирующие/инструктируемые агенты: коды BIC непосредственного отправителя и получателя в цепочке. Указание необязательно, но облегчает применение последовательного метода и метода с покрытием.
• Предыдущие инструктирующие агенты (при наличии): для цепочек с несколькими звеньями — до 3 предыдущих агентов.

Причина обязательности: обеспечивает корректную маршрутизацию через посредников; для точности в pacs.009 COV следует использовать BICFI вместо наименований.

3. Сведения об операции
Основные финансовые элементы для расчётов.

• Сумма и валюта: сумма межбанковского расчёта и код валюты по ISO 4217 (например, USD, EUR). Соответствует полю 32A в прежних сообщениях MT 103/MT 202 COV; элемент <IntrBkSttlmAmt> в pacs.008/pacs.009.
• Сумма по поручению (Instructed Amount), если отличается: первоначальная сумма до вычетов.
• Дата межбанковского расчёта: дата валютирования расчёта. Соответствует части поля 32A в MT; <IntrBkSttlmDt> в pacs.008/pacs.009.
• Способ расчётов: укажите, осуществляются ли расчёты через RTGS (CLRG), по схеме покрытия (COVE) или через агента (INDA/INGA). Прямого эквивалента в MT нет, но он подразумевается.

Почему обязательно: определяет переводимую стоимость; обязательно для всех форматов.

4. Справочные и отслеживающие идентификаторы
Для обеспечения прослеживаемости, в особенности в gpi.

• Сквозной идентификатор: ссылка, связывающая всю цепочку операции (например, номер счёта-фактуры или идентификатор операции). <EndToEndId> в pacs.008/pacs.009.
• Идентификатор инструкции: ссылка отправителя (в формате MT ограничена 16 символами). Соответствует полю 20 прежнего формата MT; <InstrId> в pacs.008/pacs.009.
• Unique End-to-End Transaction Reference (UETR): UUID для сквозного отслеживания платежа. Обязателен в pacs.008/pacs.009 и, в прежних MT 103/MT 202, в поле 121; если инициирующий канал его не передаёт, его формирует первый банк сети Swift в цепочке.
• Идентификатор операции: дополнительный внутренний референс.

Для чего требуется: обеспечивает отслеживание и увязку по gpi (например, pacs.008 с pacs.009 COV); UETR является ключевым элементом универсальных подтверждений.

5. Информация о назначении и услуге
Определяет тип платежа.

• Коды назначения и категории назначения платежа: коды ISO (например, SALA для заработной платы), указывающие на характер операции. Обязательны в отдельных платёжных коридорах; элементы <Purp> и <CtgyPurp> в pacs.008.
• Код уровня обслуживания: определяет услугу gpi (например, G001 для клиентского кредитового перевода gpi); банки, не участвующие в gpi, не должны указывать коды, специфичные для gpi, если это не согласовано. Соответствует полю 23E в MT; элементу <SvcLvl> в pacs.008/pacs.009.
• Локальный код инструмента: для отдельных схем (например, внутригрупповых переводов).

Для чего требуется: обеспечивает соблюдение нормативных требований и приоритет при обработке платежа; после перехода на ISO всё чаще становится обязательным.

6. Платёжные реквизиты и дополнительные инструкции

• Информация о платеже: неструктурированная (до 140 символов) или структурированная (например, реквизиты счёта-фактуры). Соответствует полю 70 прежнего сообщения MT 103; <RmtInf> в pacs.008/pacs.009.
• Инструкции для агентов: например, /REC/ для получателя, /ACC/ для счёта или телефонные инструкции (PHOB). Соответствует полю 72 прежнего формата MT; элементам <InstrForNxtAgt>/<InstrForCdtrAgt> в pacs.008/pacs.009.
• Индикаторы времени расчётов: запрашиваемое время (например, CLSTm для времени CLS).

Почему требуется: предоставляет контекст и инструкции по обработке; необходимо для методов покрытия в pacs.009 COV.

7. Регуляторные данные и данные в сфере комплаенс

• Регуляторная отчётность: коды или сведения (например, идентификационный номер налогоплательщика, индикатор отчётности, такой как CRED/DEB). Соответствует полю 77B в MT; <RgltryRptg> в pacs.008/pacs.009.
• Коды причин возврата (если применимо к возвратам): например, AC04 — закрытый счёт; в pacs.004 привязываются к исходным сообщениям.

Для чего требуется: Обеспечивает соблюдение обязательств по AML/KYC и отчётности; обязательно в регулируемых платёжных коридорах.

В качестве передовой практики участникам, не входящим в gpi, следует структурировать данные таким образом, чтобы избежать усечения при преобразовании MT в MX, и обращаться в банк — участник gpi по конкретным вопросам. Если платёж осуществляется методом покрытия, сведения о клиентах по базовой операции должны совпадать во всех сообщениях (например, от pacs.008 к pacs.009 COV).

Платёжные сообщения в SWIFT gpi

В рамках SWIFT gpi (Global Payments Innovation) исходные платёжные сообщения (например, pacs.008 для клиентских переводов или pacs.009 COV для покрывающих переводов) после отправки считаются неизменяемыми. Банки-получатели не могут напрямую изменять содержание этих сообщений, поскольку сообщения SWIFT разработаны таким образом, чтобы обеспечивать целостность и возможность аудита на всём протяжении платёжной цепочки. Любые изменения, исправления или отмены осуществляются посредством отдельных последующих сообщений, обновлений статуса через gpi Tracker либо специализированных сервисов, таких как gSRP (gpi Stop and Recall Payment). Это обеспечивает сквозную прослеживаемость с использованием уникального сквозного идентификатора транзакции (UETR).

Банки-получатели (как правило, выступающие в качестве банка кредитора или банка-посредника) могут, однако, реагировать на запросы отправителя об изменении платежа либо инициировать действия, фактически влекущие изменение результата платежа (например, возврат или приостановление). Они также вправе при определённых условиях запрашивать у отправителя уточнения или изменения. Эти процессы регулируются сводами правил SWIFT, рекомендациями по рыночной практике (например, разработанными Payments Market Practice Group – PMPG) и нормативными требованиями, в которых приоритет отдаётся автоматизации, прозрачности и предотвращению мошенничества.

Условия, при которых банки-получатели могут запрашивать изменения или способствовать их внесению
Банки-получатели могут запрашивать изменения (например, исправление реквизитов) или предпринимать действия, предполагающие необходимость внесения изменений, если исходный платёж не может быть обработан в соответствии с инструкцией. Как правило, это осуществляется посредством запросных сообщений (например, MT 195/199) или ответов на запросы, инициированные отправителем. К основным условиям относятся:

• Ошибки в платёжных реквизитах: при наличии неточностей, таких как неверный счёт бенефициара (например, закрытый счёт — код AC04), неверная валюта (код CURR), неверная маршрутизация через агента (код AGNT) или технические проблемы (код TECH), банк-получатель может приостановить платёж и запросить у отправителя исправленные данные либо новый платёж. Это позволяет избежать прямого отклонения и одновременно даёт возможность устранить ошибку.
• Невозможность зачисления платежа: в соответствии с кодом CUTA (Cancel Upon Unable to Apply), если платёж не может быть зачислен из-за несоответствий (например, расхождения в наименовании или номере счёта либо недостаточности реквизитов), банк-получатель вправе запросить у отправителя отмену платежа или сведения для внесения изменений в целях устранения расхождений.
• Подозрение на мошенничество или несанкционированные операции: при мошенничестве (код FRAD) банк-получатель может самостоятельно выявить нарушения и инициировать возврат средств без предварительного запроса отправителя. Он также может реагировать на запросы отправителя об отзыве платежа, блокируя средства и запрашивая гарантию возмещения (код INDM), если средства уже зачислены, чтобы снизить риск до возврата.
• Дублирующие или необоснованные платежи: коды, такие как DUPL (дублирующий платёж) или UPAY (необоснованный платёж), позволяют банку-получателю отметить операцию и запросить её отмену, если она ошибочна или не имеет оснований.
• Регуляторные вопросы и вопросы комплаенса: если платёж нарушает местное законодательство, санкционные ограничения или требования AML (код LEGL), банк-получатель вправе отклонить или приостановить его и запросить у отправителя дополнительные документы или изменения.
• Решения клиента или бенефициара: если бенефициар отклоняет платёж (код CUST или NOAS — ответ от бенефициара не получен), банк-получатель может вернуть его и уведомить отправителя, при необходимости запросив подтверждение изменений.
• Нерешённые вопросы: По платежам в статусе ожидания (код PDCR), например при ожидании полномочий на дебетование (RQDA) или ответа следующего агента (PTNA), банк-получатель может приостановить платёж и запросить дополнительные инструкции или изменения для продолжения обработки.

Во всех случаях запросы должны быть структурированы для автоматической обработки (например, содержать UETR, исходные ссылки, такие как поля 20/32A/50/59, и определённые коды в поле 79 сообщений) для обеспечения сквозной обработки. Двусторонние соглашения о возмещении убытков могут потребоваться в случае зачисления средств; банк-получатель не обязан принимать запросы, но должен в приоритетном порядке рассматривать срочные (например, связанные с мошенничеством).

Задействованные процессы

• Ответ на запросы об отзыве, инициированные отправителем: отправитель (банк плательщика) обычно инициирует отзыв с помощью сообщения MT 192/292 (или эквивалентов ISO 20022, таких как camt.056) через сервис gSRP, направляя его последовательно или напрямую банку-получателю. Банк-получатель обязан немедленно подтвердить получение и ответить сообщением MT 196/296 (или MT 199/299 при использовании структурированного формата) с применением таких кодов, как CNCL (отменён), RJCR (отклонён с указанием причины) или PDCR (в обработке). В случае принятия запроса средства возвращаются с помощью pacs.004 (возврат платежа).
• Самостоятельные действия банков-получателей: Если мошенничество выявлено внутри банка, банк-получатель может вернуть средства с помощью pacs.004 со структурированными данными, уведомив об этом через Tracker для получения статуса в режиме реального времени.
• Запросы об изменении или уточнении: банки-получатели используют сообщения-запросы (например, MT 195/295) для запроса изменений, в частности дополнительных сведений. Это обычная практика для платежей, приостановленных до выяснения обстоятельств.
• Интеграция с Tracker: все действия в режиме реального времени обновляют gpi Tracker, доступный через API или графический интерфейс, что обеспечивает прозрачность для всех сторон. Участники gpi обязаны соблюдать обязательные своды правил для gCCT (Customer Credit Transfer), gCOV (Cover) и gSRP.
• Ограничения и факторы успеха: изменения не гарантируются; результат зависит от стадии платежа (проще до зачисления), содействия бенефициара и юрисдикции. Нормативные требования всегда имеют приоритет над рекомендациями. Если средства уже зачислены, для их возврата требуется согласие бенефициара или гарантия возмещения.

Эти практики применяются главным образом к участникам gpi, однако банки, не входящие в gpi, могут участвовать через шлюзы. Актуальные сведения следует уточнять в официальных сводах правил SWIFT, поскольку процессы развиваются (например, в связи с миграцией на ISO 20022).

Разделение обмена сообщениями и расчётов в SWIFT gpi

SWIFT gpi в первую очередь обрабатывает платёжные инструкции и их отслеживание посредством обмена сообщениями (например, в форматах ISO 20022, таких как pacs.008 для клиентских переводов и pacs.009 для межбанковских переводов, либо в прежних форматах MT103/MT202), тогда как фактическое движение денежных средств происходит отдельно, на уровне расчётов. Расчёты, как правило, осуществляются через корреспондентские отношения (счета «Ностро»/«Востро»), двусторонний неттинг или механизмы клиринга и расчётов (CSM), такие как системы валовых расчётов в режиме реального времени (RTGS) (например, T2, ранее TARGET2, в Европе, Fedwire в США или CHAPS в Великобритании). Сервис gpi Tracker обеспечивает видимость статуса сообщений в режиме реального времени, однако перевод средств опирается на эти базовые системы.

Период параллельного использования форматов для трансграничных платёжных инструкций завершился 22 ноября 2025 года: платёжные инструкции, такие как MT103 и MT202, заменены сообщениями ISO 20022 (MX), такими как pacs.008 и pacs.009, а прочие категории MT будут выведены из обращения в более поздние даты. Ниже поясняется, как осуществляются возвраты и снятие блокировок на уровне счетов, клиринга и расчётов.

Как деньги возвращаются на уровне счетов, клиринга и расчётов
Возврат инициируется после успешного запроса на отзыв платежа (через сервис gSRP — gpi Stop and Recall Payment) либо после самостоятельного выявления проблемы (например, мошенничества или ошибок). Сервис gSRP использует сообщение camt.056 (запрос на отмену платежа) от отправителя, на которое отвечает сообщение camt.029 (решение по расследованию). После принятия возврат средств выполняется новым платёжным поручением, которое обращает поток платежа: дебетуется счёт банка-получателя, и средства возвращаются по цепочке. Это не изменение первоначального сообщения, а отдельная операция.

Основные методы расчётов и порядок возврата средств
Методы расчётов определяют порядок возврата средств:

• CLRG (клиринг через инфраструктуру рынка): расчёты через RTGS или CSM (например, через центральный банк). Возвраты оформляются сообщением pacs.004, которым инфраструктуре рынка поручается списать средства со счёта получающего агента и зачислить их на счёт предыдущего агента, зачастую в режиме реального времени или в тот же операционный день.
• INGA (Instructing Agent Settles First): отправитель проводит расчёт средств до направления сообщения. Возвраты по pacs.004 дебетуют счёт получающего поручение агента после расчёта.
• INDA (Instructed Agent Settles on Receipt): получатель проводит расчёт при получении сообщения. Если расчёт не проведён, сообщение отклоняется через pacs.002 (средства не перемещаются); если расчёт проведён, возврат осуществляется через pacs.004.
• COVE (покрывающий метод): Используется для платежей на крупные суммы с покрывающим переводом (pacs.009 COV). Возвраты проходят по обратной цепочке: pacs.004 от банка бенефициара к банкам-посредникам с соответствующим дебетованием и кредитованием корреспондентских счетов.

Пошаговый процесс возврата на уровне расчётов

1. Инициирование и принятие: отправитель направляет запрос на отзыв (например, сообщением camt.056 с указанием UETR). Получатель отвечает (camt.029) и принимает запрос, если средства имеются в наличии и ещё не зачислены бенефициару (до зачисления сделать это проще). Если средства уже зачислены, может потребоваться согласие бенефициара либо письменное обязательство о возмещении убытков.

2. Инструкция о возврате средств: получатель направляет сообщение pacs.004 (Payment Return) либо сообщение прежних форматов MT 103/MT 202 с кодами возврата (например, RETN). Это сообщение содержит:

• Исходные ссылки (UETR, End-to-End ID, Instruction ID).
• Роли меняются местами: первоначальный кредитор становится должником; банк первоначального должника становится кредитором.
• Параметры расчётов: первоначальная межбанковская сумма расчёта и дата расчёта, обменный курс (при наличии конвертации), комиссии (если удержаны).
• Код причины возврата (например, AC04 — счёт закрыт, FRAD — мошенничество).
• Поле «Settlement Account» (если присутствует в исходном сообщении) для указания счёта зачисления.

3. Исполнение расчётов:

• Сообщение pacs.004 инициирует списание со счёта «Ностро»/«Востро» банка-получателя (открытого у предыдущего агента или в инфраструктуре финансового рынка (MI)).
• Средства зачисляются обратно последовательно по всей цепочке с использованием того же метода расчётов (например, перевод через систему RTGS в CLRG).
• При частичном возврате укажите «PART» в поле дополнительной информации с пропорционально рассчитанной суммой.
• Трекер обновляет статус (например, «Возвращён») в режиме реального времени; статус доступен через API или графический интерфейс.

4. Окончательное зачисление: счёт первоначального отправителя кредитуется, зачастую с удержанием комиссий. При проведении через CSM расчёт является атомарным; при двусторонних схемах он может предполагать неттинг по итогам операционного дня.

5. Уведомления после возврата: используйте camt.053/054 (выписка по счёту / уведомление о дебетовании и кредитовании) для подтверждения обновления учётных записей. Дополнительное сообщение pacs.004 для «возврата возврата» не используется: применяйте запросы.
Возвраты по возможности автоматизируются, однако в случаях, связанных с комплаенсом, или при блокировании средств может потребоваться ручное вмешательство. Возврат средств не гарантируется; он зависит прежде всего от того, насколько быстро направлен отзыв платежа и были ли средства уже зачислены. Если платёж не рассчитан (например, отклонён до расчёта), движение средств не происходит: в этом случае используйте pacs.002.

Как удержанные платежи освобождаются (разрешаются к исполнению) на уровне счёта, клиринга и расчётов

Приостановка возникает, когда платёж не может быть обработан немедленно (например, из-за ошибок, комплаенс-проверок или в ожидании уточнений) и переходит в статус «в ожидании» без расчёта. До разрешения ситуации средства не дебетуются и не кредитуются. Трекер gpi отображает статусы «On Hold» или «Pending» (например, код PDCR), а для урегулирования используются запросные сообщения (MT 195/199 или camt.029).

Условия, приводящие к блокировке средств

• Несоответствия (например, расхождение между номером счёта и именем получателя — код CUTA).
• Регуляторные проверки (например, санкционные — код LEGL).
• Ожидается ответ бенефициара (код NOAS) или полномочие на списание (RQDA).
• Нерабочие часы или пакетная обработка в банке бенефициара.

Порядок разблокирования на уровне расчётов
1. Уведомление о блокировке: получатель направляет pacs.002 (обновление статуса) или MT 199 с кодом ожидания, удерживая средства на транзитном/эскроу-счёте в случае частичного расчёта (например, при использовании покрытия).
2. Урегулирование: отправитель предоставляет изменения/пояснения (например, ответом MT 195 или сообщением camt.029). После урегулирования получатель «даёт добро», обрабатывая первоначальное поручение.
3. Исполнение расчёта:

• Исходное сообщение pacs.008/pacs.009 снимается с удержания.
• Расчёты проводятся указанным способом: дебетование счёта отправителя, кредитование счёта получателя (например, через RTGS в CLRG), затем окончательное зачисление на счёт бенефициара.
• Именно на этапе бенефициара (от банка-получателя до конечного клиента) чаще всего возникают задержки, особенно на рынках с валютными ограничениями или недостаточно развитой инфраструктурой.
• Статус в трекере меняется на «Зачислено» (Credited) или «Завершено» (Completed), что подтверждается сообщением pacs.002 (отчёт о статусе платежа).

4. Если средства не высвобождены: если вопрос не урегулирован (например, по истечении срока), возврат осуществляется через pacs.004, как указано выше, либо отклонение через pacs.002 (без расчёта).

Правила gpi требуют зачисления в тот же день, когда это возможно; по данным Swift за 2018 год, почти 50 % платежей gpi были зачислены в течение 30 минут и почти 100 % — в течение 24 часов. Такие факторы, как валютные ограничения или нерабочие часы банков, могут увеличить срок удержания средств, однако gpi делает упор на автоматизацию для его сокращения.

SwiftNet Instant

SwiftNet Instant. Это платформа обмена сообщениями в режиме реального времени с низкой задержкой, доступная 24/7 и обеспечивающая безопасный обмен потоками мгновенных платежей между клиринговыми и расчётными механизмами (CSM) и их участниками.

Клиенты могут подключаться к SwiftNet Instant через существующую инфраструктуру подключения и безопасности Swift, включая VPN-устройства, выделенные линии и аппаратные модули безопасности. Интеграция с ИТ-средой банка осуществляется через Alliance Gateway Instant (AGI).

Все участники цепочки мгновенных платежей могут использовать AGI и обмен сообщениями SwiftNet Instant. Сферы применения включают инициирование платежа через надстроечный сервис, обмен сообщениями между косвенными участниками и спонсирующим участником или получение корпоративным клиентом подтверждения платежа.

SWIFT Instant взаимодействует с национальными системами мгновенных платежей, обеспечивая обработку транзакций в режиме реального времени как внутри страны, так и на международном уровне на основе стандарта ISO 20022. Эти системы отражают непрерывные усилия по модернизации и упрощению платёжных процессов в финансовой отрасли.

Прямое дебетование SWIFT

Прямое дебетование в системе SWIFT — это способ платежа, позволяющий компаниям и физическим лицам списывать средства со счетов должников в банках в различных валютах и в разных странах. В отличие от SEPA Direct Debit, который предназначен специально для зоны SEPA и ограничен операциями в евро, прямое дебетование в SWIFT имеет глобальный охват и поддерживает широкий перечень валют.

Процесс инициирования операции прямого дебетования в системе SWIFT, как правило, включает следующие этапы:

1. Соглашение между кредитором и должником: между кредитором и должником должно существовать предварительное соглашение, определяющее условия операций прямого дебетования. Это соглашение может также предусматривать оформление мандата или разрешения, позволяющего кредитору списывать платежи с банковского счёта должника.
2. Обмен сообщениями: банк кредитора инициирует прямое дебетование, направляя сообщение SWIFT банку дебитора: в ISO 20022 это pacs.003 (прямое дебетование по поручению клиента) или pacs.010 (прямое дебетование между финансовыми учреждениями), ранее MT 104 или MT 204. Это сообщение содержит сведения об операции, такие как сумма, валюта, реквизиты счёта дебитора и иная необходимая информация.
3. Проверка и авторизация: банк плательщика проверяет реквизиты операции, наличие средств на счёте плательщика и подтверждает разрешение на проведение операции. Если все условия выполнены, банк плательщика списывает средства со счёта плательщика.
4. Перевод средств: расчёты между банком должника и банком кредитора осуществляются через корреспондентские счета либо через систему клиринга и расчётов.
5. Подтверждение: после получения средств банк кредитора направляет кредитору подтверждение об успешном выполнении операции прямого дебетования.

Условия для инициирования операции прямого дебетования в системе SWIFT следующие:

1. Банковские счета: и кредитор, и должник должны иметь счета в финансовых учреждениях, входящих в сеть SWIFT.
2. Соглашение и полномочия: для проведения операций прямого дебетования необходимо наличие предварительного соглашения и полномочий (мандата) между кредитором и должником.
3. Форматы сообщений SWIFT: Кредитор и его банк должны использовать соответствующие форматы сообщений: pain.008 для инициирования прямого дебетования, pacs.003 или pacs.010 для обмена между банками.
4. Банковские комиссии: кредитору и должнику следует учитывать возможные комиссии за операции прямого дебетования в системе SWIFT, поскольку их размер может различаться в зависимости от банков и стран, участвующих в операции.

RMA в межбанковском обмене сообщениями SWIFT

В банковской сфере и финансах безопасная и эффективная связь между банками имеет первостепенное значение. Именно здесь ключевую роль играет SWIFT (Society for Worldwide Interbank Financial Telecommunication), по каналам которого передаётся большинство международных межбанковских сообщений. Важнейшим компонентом, обеспечивающим безопасность и избирательность этих коммуникаций, является приложение управления корреспондентскими отношениями — Relationship Management Application (RMA).

Что такое RMA?

Relationship Management Application (RMA) — программное приложение SWIFT, позволяющее финансовым институтам определять, какие контрагенты вправе направлять им сообщения SWIFT, и обеспечивающее ограничение обмена данными в сети SWIFT только аутентифицированными пользователями. RMA является базовым уровнем защиты при управлении межбанковской коммуникацией, поскольку отсеивает несанкционированные сообщения и снижает риск мошенничества.

Значение RMA

Для банков, осуществляющих международную финансовую деятельность, таких как IFB, инструмент RMA незаменим. Он не только усиливает протоколы безопасности, но и обеспечивает соблюдение глобальных банковских норм. Управляя тем, какие учреждения вправе направлять им сообщения, банки могут предотвращать несанкционированные запросы информации и финансовые инструкции, защищая как собственные интересы, так и интересы своих клиентов.

Как работает RMA

Процесс RMA включает несколько ключевых этапов:

1. Установление отношений RMA: прежде чем два банка смогут обмениваться информацией через SWIFT, они должны договориться об установлении RMA. Такое соглашение подобно цифровому рукопожатию: оно означает доверие и согласие на взаимодействие.
2. Обмен ключами: каждый банк направляет разрешение RMA через приложение RMA, которое контрагент принимает. RMA заменило прежний двусторонний обмен ключами (BKE); сами сообщения аутентифицируются с помощью SWIFTNet PKI (инфраструктура открытых ключей).
3. Настройка параметров RMA: каждый банк использует инструмент RMA для настройки разрешений и определения типов сообщений, принимаемых от другого банка. Настройка может быть общей или детальной, с указанием конкретных типов и подклассов сообщений.
4. Активация и мониторинг. После настройки и активации параметров RMA банки могут отслеживать входящие сообщения на соответствие установленным разрешениям. RMA также предоставляет инструменты для изменения или отзыва разрешений, если этого требуют деловые потребности или соображения безопасности.

Практическое применение

Для IFB, специализирующегося на инвестиционном обслуживании и управлении капиталом состоятельных частных лиц и корпоративных клиентов, RMA предоставляет ряд преимуществ:

• Повышенная безопасность: контролируя потоки сообщений, IFB может защищать операции клиентов и конфиденциальную информацию от несанкционированного доступа.
• Операционная эффективность: упорядоченный обмен сообщениями с доверенными организациями обеспечивает более быструю обработку легитимных сообщений, сокращая время реакции и повышая удовлетворённость клиентов.
• Соблюдение нормативных требований: RMA способствует соблюдению международных банковских норм, которые требуют строгого контроля за обменом информацией в целях предотвращения финансовых преступлений, таких как отмывание денег и мошенничество.

RMA и MT799. Банки могут использовать MT799 для запроса или согласования отношений RMA при условии, что канал это допускает. Само разрешение RMA предоставляется в системе RMA; один лишь MT799 не активирует никакого разрешения. Если необходимое для MT799 разрешение RMA отсутствует, его нельзя обойти прямой отправкой MT799. В таком случае настройка согласовывается с помощью функции коммуникации RMA в Relationship Management Portal Swift, предназначенной для согласования с контрагентами до обмена разрешениями, либо по другому допустимому каналу. Таким образом, «RMA через MT799» может обозначать сопутствующую банковскую переписку; техническое разрешение RMA представляет собой отдельный этап.

Коротко

Для IFB эффективное внедрение RMA является не просто технической необходимостью, а стратегическим активом в его глобальной деятельности. Оно подтверждает приверженность банка безопасности и соблюдению регуляторных требований, а также повышает эффективность его коммуникационных сетей. По мере развития международной финансовой среды такие инструменты, как RMA, остаются неотъемлемой частью арсенала банков, стремящихся поддерживать наивысшие стандарты операционной добросовестности и клиентского обслуживания.

Соглашения RMA составляют основу защищённого и избирательного межбанковского обмена сообщениями, обеспечивая, чтобы каждое сообщение, передаваемое через сеть SWIFT, отвечало самым высоким стандартам безопасности и было полностью аутентифицировано. Для таких банков, как IFB, понимание соглашений RMA и управление ими имеют решающее значение для защиты их операций и укрепления доверия глобальных партнёров.

Цифровые блокчейн-инструкции Swift по финансовым операциям

В сентябре 2025 года Swift объявила, что совместно с более чем 30 финансовыми организациями приступила к проектированию и разработке общего цифрового реестра. 9 июля 2026 года Swift заявила о готовности реестра к первоначальному использованию: 17 банков готовятся к пилотному проведению реальных операций с токенизированными депозитами: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB и Wells Fargo. Первое применение будет направлено на обеспечение трансграничных межбанковских инструкций в режиме реального времени, 24/7 — существенное усовершенствование инфраструктуры международной обработки операций.

Первый концептуальный прототип был создан совместно с Consensys. Реестр задуман как защищённый, неизменяемый регистр финансовых инструкций между институтами, ведущийся в режиме реального времени. Он будет фиксировать, упорядочивать и проверять транзакционные сообщения, обеспечивая при помощи смарт-контрактов соблюдение операционных требований и требований комплаенс. Центральным принципом является совместимость: реестр будет взаимодействовать как с действующей, так и с формирующейся инфраструктурой, сохраняя присущие Swift устойчивость, доверие и соблюдение регуляторных требований.

Как пояснил главный исполнительный директор Swift Хавьер Перес-Тассо:
«Сочетание общего реестра с существующими решениями Swift в области обмена сообщениями, API и стандартом ISO 20022 создаёт ещё более мощную конструкцию, которая позволяет изначально встраивать требования к управлению рисками, контролю и комплаенсу в потоки транзакций, обеспечивая при этом межбанковские трансграничные распоряжения в режиме реального времени 24/7 с тем же уровнем доверия, безопасности, устойчивости, масштабируемости и операционного совершенства, которым известна Swift. Всё это — в русле нашего неизменного подхода ответственных инноваций».

Расширение инфраструктуры

Общий реестр дополняет существующие каналы Swift, но не заменяет их. Он призван расширить возможности оркестрации и функциональной совместимости, чтобы финансовые институты могли обмениваться инструкциями быстрее, с большей предсказуемостью и в действительно глобальном масштабе.

На конференции Sibos Перес-Тассо подчеркнул двуединый подход:
«Финансовым инфраструктурам необходимо неизменно уделять первостепенное внимание основам: операционному совершенству, соблюдению регуляторных требований и управлению. В то же время они должны быть готовы к будущему. Подход Swift состоит в том, чтобы внедрять инновации по двум параллельным направлениям».

Сотрудничество в масштабах отрасли

Финансовые институты из 16 стран с самого начала участвовали в формировании архитектуры, системы управления и пути развития общего реестра. Эти совместные усилия отражают общее понимание: развитие глобальной инфраструктуры межбанковских инструкций требует масштаба и сотрудничества.

Взгляд в будущее

Общий реестр — закономерное продолжение предыдущих экспериментов Swift с цифровыми активами и часть более масштабных усилий по обеспечению совместимости публичных и частных сетей. Это позволит как токенизированным активам, подпадающим под регулирование, так и традиционным инструментам беспрепятственно перемещаться между системами.

Перес-Тассо кратко сформулировал это видение:
«Это мощная платформа для будущего. И в дальнейшем она может стать ещё более преобразующей».

Часто задаваемые вопросы

Что такое общий реестр Swift на основе блокчейна?
Блокчейн-инфраструктура, обеспечивающая общий учёт финансовых инструкций между учреждениями в режиме реального времени и позволяющая осуществлять непрерывную трансграничную обработку платежей с соблюдением нормативных требований.

Для кого предназначено?
Для банков и финансовых институтов, которым необходимо обеспечивать более быструю и прозрачную передачу платёжных инструкций, одновременно готовясь к цифровому будущему.

Каковы преимущества?

• Отслеживание инструкций в режиме реального времени и контроль их очерёдности
• Автоматизированный комплаенс с помощью смарт-контрактов
• Взаимодействие традиционных и цифровых сетей
• Защищённое проведение регулируемых потоков токенизированной стоимости

Как это вписывается в платформу Swift?
Решение расширяет надёжную инфраструктуру Swift, добавляя возможности цифровой передачи инструкций при сохранении устойчивости, безопасности и соответствия требованиям.

Каков первый сценарий применения?
Межбанковские трансграничные платёжные инструкции в режиме реального времени, 24/7.

Кто участвует?
Более 30 финансовых учреждений из 16 стран принимали участие в разработке концепции; 17 банков проводят пилотное тестирование первых реальных операций.

Когда это станет доступно?
Swift объявила о готовности реестра к начальному использованию 9 июля 2026 года. Банки-участники пилотного проекта проводят первые реальные операции на контролируемом этапе запуска; окончательный расчёт по-прежнему осуществляется через существующие системы. Впоследствии функциональные возможности и доступность будут расширены.

Если Вы хотите узнать больше о переводе средств через корреспондентскую банковскую систему, пожалуйста, свяжитесь с руководителем направления корреспондентских банковских услуг г-ном Амри Эларисом (M. Amri Elarisse).