SWIFT МТ103 — Детальный разбор (ч1)
В последнее время, в интернете развелось слишком много мошенников, которые пользуются неграмотностью людей (недостатком знаний), и разводят их на деньги, иногда не малые. Если разбирать платежи в системе SWIFT то особенно часто можно увидеть предложения про мануал доводку платежей (manual download), которую ставят хакеры (так вам будут объяснять ребята свою работу), в итоге максимум вы получите pdf файл, с непонятным набором символов, который выглядит логично, но ничего общего с SWIFT не имеющий. В данной статье будет описаны процедуры, благодаря которым вы действительно сможете составить платежное сообщение которое сможет пройти комплаенс на суммах до 500 тысяч евро, благодаря доверительным отношениям внутри системы СВИФТ. Также вы поймете общий принцип работы системы СВИФТ, и сможете проводить первичную проверку сообщений и выявлять подделки.
Все что описано в данной статье, представлено для ознакомления. Все данные связанные с фирмами, действующими лицами в статье обобщены, отредактированы или изменены. Статья не призывает к незаконным действиям. Представлена для ознакомления в обучающих целях.
Перейдем к сути:
Типичные атаки хакеров, имеющие отношения к системе СВИФТ, которые мы можем наблюдать в отчетах полиции или средствах массовой информации – следующие:
- Компрометация сети учреждения;
2. Использование критичных багов платежной системы;
3. Компрометация учетных данных оператора платежей СВИФТ;
4. Доступ к СВИФТ-интерфейсу обмена сообщений учреждения;
5. Авторизация платежных сообщения с использованием скомпрометированных учетных записей платежного оператора и интерфейса обмена сообщениями;
Чтобы выполнить данный вектор атаки вам потребуется компрометация нескольких пользователей, нескольких систем, понимания того, как работает целевое приложение, обход двухфакторной авторизации, затем вы обязаны скрыть журналы доступа во избежание предупреждения от легитимных операторов, настроить вредоносное ПО и .т.д. – что даже в кратком описании выглядит ОЧЕНЬ сложно.
Поэтому мы пойдем от простого к сложному, и опишем устройство системы в целом, которое поможет вам разобраться как работает система SWIFT, и разберем стандартное платежное поручение, а затем уже более внимательно изучим каждый вектор атаки по отдельности.
Для начала вам нужно полностью понять и разобраться с конкретным «разделом» платежной системы (СВИФТ) в целевом учреждения. Мы будем называть её просто СВИФТ.
СВИФТ принимает данные в произвольном формате и выводит начальные платежные инструкции в формате ISO 15022 / RJE / SWIFT MT.
Мы сосредоточимся на компрометации платежного поручения МТ103, а именно:
- MT — «тип сообщения»
- 1 — категория 1 (платежи и чеки клиентов)
- 0 — группа 0 (перевод финансовых учреждений)
- 3 — Тип 3 (уведомление)
Все вместе это классифицируется как MT103 «Single Customer Credit Transfer» (SCCT или ОДНОКРАТНЫЙ КРЕДИТОВЫЙ КЛИЕНТСКИЙ ПЕРЕВОД)
Помимо типа сообщения, нам нужно понять, как обрабатывается данный платеж. Он достаточно типичен, для таких видов перевода и выглядит так:
- Система (Приложение для работы с SWIFT) принимает данные от пользователя в удобном ему формате (например посредством заполнения полей в графическом интерфейсе приложения). Затем Система выводит начальную платежную инструкцию в формате SWIFT MT;
- Система отправляет данное сообщение дальше, в компонент именуемый Промежуточным Программным Обеспечением (ППО), который преобразует (при необходимости) полученное сообщение в современный формат SWIFT, понятный системе. По сути, это брокер сообщений предоставляемый для не институциональных финансовых организаций.
- ППО отсылает сформированное сообщение в Институциональное Финансовое Учреждение (Банк, Кредитная организация или иное, далее Банк для удобства), для обработки.
- Банк проверяет содержимое сообщения, производит ряд проверок (не находится ли компания в черном списке, проходит проверку системой борьбы по отмыванию денег, проверяет легальность операции при высоких объемах, делает запрос в антимонопольное ведомство или в валютный контроль, если такие опции есть в стране где находится Банк)
- Если сообщение сформировано верно, проходит внутрибанковскую проверку, то сообщение отправляется в Swift Alliance Gateway, где оно подписывается и отправляется в организацию/банк получателя через SwiftNet.
Углубимся немного глубже в эту технологию.
Разбираемся в деталях обмена данными
Зададимся вопросом: как эти сообщения передаются между всеми этими системами?
Чаще всего в любой Платежной Системе для передачи сообщений между различными компонентами используются так называемые Очереди Сообщений (ОС).
Существуют различные «адаптеры», которые могут быть использованы между системами обменивающиеся данными напрямую с Swift Alliance Gateway:
- Удаленный хост-адаптер API (HAPI)
- Хост адаптер Очереди Сообщений (MQHA)
- Хост-адаптер веб-служб (WSHA)
Из требований SWIFT CSP вы можете узнать, что для поддержания Очереди Сообщений вам нужен выделенный сервер Менеджер Очереди (МО), на котором будут размещаться различные Очереди Сообщений (МТ1хх, МТ2хх итд), из которых системы будут отправлять и извлекать сообщения.
Также в требованиях строго прописано, что должно присутствовать минимум два администратора очереди. Один управляет очередями в Зоне работы SWIFT, второй для общения в корпоративной сети и/или прочих системах учреждения (к примеру внутрибанковские операции должны быть ОТДЕЛЕНЫ от операций связанных с системой SWIFT, а также операции в других платежных системах, например VISA, MASTERCARD или SEPA).
Определяем жизнеспособный вектор для внедрения
Пришло время определится с задачей: «Поместить платежное поручение в очередь и успешно его обработать во всех системах (пройти валидацию)»
Задача простая, поэтому зададим правильные вопросы, которые помогут в реализации:
- Как получить доступ на запись в нужную очередь?
- Что защищает сообщения в очередях?
- Что защищает сообщение при транзите?
- В каком формате находятся сообщения?
- Как составить синтаксически верное сообщение для выбранного формата? (цель – 0 ошибок)
- Где находится PKI (Public Key Infrastructure или Инфраструктура открытых ключей)? Как, где и когда подписываются сообщения, производится их проверка?
- Можно ли как-нибудь обойти подпись сообщения?
- Какие значения в сообщениях зависят / контролируются / определяются системой, обрабатывают их вне моего контроля (или другого человека)?
- Какую максимальную сумму я могу перевести с помощью, не предупреждая учреждение / не требуя проверки вручную?
Теперь распишем саму задачу подробнее, по пунктам:
- Грамотно написать платежную инструкцию на 500 тысяч евро;
- Вставить данную платежную инструкцию в очередь;
- Сообщение должно пройти синтаксическую проверку (ACK or NACK);
- Сообщение должно пройти все дополнительные проверки, включая проверку AML;
- Сообщение должно быть успешно подписано;
- Пройти валидацию при проверки правилами SWIFTNet;
С точки зрения хакера оно выглядит так:
- Скомпрометировать сеть учреждения;
- Получить доступ к рабочей станции администратора Менеджера Очередей;
- Получить необходимые реквизиты фирмы;
- Провести требуемую работу.
Следует избегать следующего:
- Атака с участием платежного оператора SWIFT (самой системы);
- Атака с использованием доступа к SWIFT-приложению (прямой доступ к официальному банковскому приложению);
- Необходимость компрометации подписи ключей (подделка цифровых ключей);
- Необходимость компрометации учетных записей или сертификатов оператора SWIFTNet.
Нужно разобраться как сделать простейшую инструкцию по оплате в формате МТ103. Как правило, банковский оператор (или любой иной пользователь/оператор системы СВИФТ) пишет платежные сообщения также как и мы с вами, но с помощью удобного графического интерфейса (например, Alliance Access). В необработанном виде это выглядит примерно так:
Разберем каждое поле выделенное :ТАК: подробнее.
:20: Ссылка на транзакцию
16x — данное поле может быть размером только 16 символов. По этому ссылке, ваш банк может идентифицировать сообщение в своей сети, ровно также, как и банк отправитель.
:23B: Код операции банка
4!c — четыре заглавных буквы, отвечающие за операцию. В нашем случае это CRED — кредитование бенефициара.
:32A: Дата / Валюта / Сумма
6!n3!a15d — поле заполняется в строгой последовательности. Сначала дата (год/месяц/день), затем заглавными буквами валюта (например: EUR, USD, RUB), затем в произвольном порядке цифрами сумма.
Также к примеру, если комиссия в поле 71A — будет указана как BEN, то в таком случае добавляется поле 33B, где будет указана точная сумма к зачислению на счет.
:50K: Клиент
Данное поле содержит реквизиты приказодателя (юридическое лицо, физическое лицо, банк). Поле используется в сообщениях МТ103, МТ103+ с опциями ”A”, “K”, “F”. В зависимости от опции заполнение меняется, от банка к банку.
:59: Бенефициар
В данном поле указываются реквизиты клиента-бенефициара в пользу которого осуществляется платеж:
— номер счета клиента в банке бенефициара (При переводе средств в пользу клиентов банков стран, поддерживающих Директиву ЕС об обязательном указании IBAN, указание номера счета в формате IBAN является обязательным.(указывается без каких-либо разделительных символов)
— адрес (при наличии);
:70: Информация о денежном переводе
В данном поле размером 4 строки по 35 символов — указывается информация о переводе, включающая в себя: цель перевода (оплата контракта-договора/ обучения/ путевки, материальная помощь и т.д.), номер и дату договора-контракта, товарных документов, наименование выполненных работ/ оказанных услуг, товаров, др.
:71A: Детали комиссии
Указывается, за чей счет совершается оплата комиссий при осуществлении перевода. При этом отмечается один из возможных вариантов:
— OUR — общая сумма взимаемых комиссий Банка-клиента, а также комиссии других банков, участвующих в прохождении платежа, оплачиваются клиентом-плательщиком (поле 50A,K или F).
При этом существует вероятность зачисления средств бенефициару не в полном объеме.
— SHA — общая сумма взимаемых комиссий Банка-клиента оплачивается клиентом-плательщиком (поле 50A,K или F), а комиссии других банков, участвующих в прохождении платежа взимаются из суммы перевода;
— BEN — общая сумма взимаемых комиссий Банка-клиента, а также комиссии других банков, участвующих в прохождении платежа, взимаются из суммы перевода, указанной в поле 33B.
Теперь имея валидное тело сообщения, будь у нас был доступ к оператору SWIFT Alliance Access, мы могли бы вставить это сообщение в интерфейс создания необработанных сообщений и совершить перевод. Останется лишь дело за малым — добавить коды BIC отправителя и получателя, и выбрать подразделения банка откуда и куда.
Но мало изучить само тело сообщения (вы должны помнить что все поля должны заполнятся СТРОГО инструкций в чем грешат большинство мошенников которые рисуют вам платежки, нарушая элементарные правила заполнения документов). Поэтому перейдем к следующей части и разберем сообщение целиком, не только его тело.
Детальный разбор МТ103
Как выше уже говорилось мы разобрали лишь тело сообщения, которое является «Блоком №4» (именуемым «Текстовый блок») в стандарте сообщений СВИФТ МТ. Как следует из названия, вы сможете догадаться, что также имеются блоки 1-3, и будете правы.
Обычно данные блоки генерируются автоматически приложениями обработки платежей (тот же SWIFT Alliance Access), и не обязательно вводятся операторами.
«Полное» сообщение МТ103 состоит из 6 блоков:
- Блок 1 – Базовый заголовок;
- Блок 2 – Заголовок приложения;
- Блок 3 – Пользовательский заголовок;
- Блок 4 – Текстовый блок;
- Блок 5 – Хвост сообщения;
- Блок 6 – Системный блок.
БЛОК 1 (Базовый заголовок)
Согласно документации SWIFT, базовый заголовок имеет следующий вид.
Разберем его на составные части
Это порядковый номер блока (не может быть 2, 3 или любым другим в данном блоке).
Это тип приложения, в нашем случае это F — т.е. FIN
Это тип сообщения, в нашем случае это 01. Что эквивалетно FIN, т.е. не является сообщением ответом — по типу ACK или NACK.
Это БИК отправителя EBNKGB20, где EBNK (Код банка) GB (Код страны) 20 (Код территории).
Это номер терминала отправителя. Обычно указывается A, но в случае огромного институционального банка могут быть и иные терминалы.
Это филиал отправителя. В случае если указывать филиал банка указывать не требуется, то заполняется просто XXX.
Это номер сессии, в нашем случае это 0000
Это порядковый номер сообщения, в нашем случае 999999
Забегая вперед, стало видно первая проблема с которой столкнётся хакер: это номер сеанса и порядковый номер сообщения, достаточно сложно выгадать точные значения которые будут не выбиваться из общей канвы отправленных сообщений в автоматическом режиме.
БЛОК 2 (ЗАГОЛОВОК ПРИЛОЖЕНИЯ)
Также из документации, вы можете свободно понять что он выглядит таким образом:
Разберем его на составные части:
Это порядковый номер блока, может быть только 2.
Это идентификатор сообщения. В нашем случае это I (Input), но есть вариант Output или O. Тут важно не ошибиться, Input — несмотря на то что начинается на IN — исходящее сообщение, а Output — входящее сообщение. Тут часто ошибаются рисовальщики, выдавая со значением O.
Это тип сообщение, в нашем случае это 103, или кредитный перевод для одного клиента.
Это идентификатор банка клиента, FBNKFR20, где FBNK (Код банка) FR (Код страны) 20 (Код территории).
Далее идёт X — или номер терминала банка получателя. Обычно все не специализируемые терминалы маркируются X. И это даёт ещё одну ошибку в SWIFTах, художников. Обычно они пишут всего три X, когда всегда их было 4.
Это филиал получателя банка. Для обычных переводов, обычно филиал указывать не требуется. В отличии, например от переводов Банковских инструментов.
Это приоритет сообщения. В нашем случае это N (Normal), то есть не срочный. Может быть также U (Urgent), или срочный. Обычно за такие доплачивают дополнительные комиссии до 100 долларов.
БЛОК 3 (Пользовательский заголовок)
Третий блок используется для определения некоторых «специальных» правил обработки сообщения SWIFT. Используя данный заголовок, можно указать что сообщения должно обрабатываться с использованием так называемых правил «Сквозной обработки» (Straight Through Processing или STP), которые поясняют что сообщение идет end-to-end без вмешательства человека (например вы отправили деньги из онлайн банкинга, и оно обработано автоматически компьютером, без участия банковского офицера). Это можно указать следующим образом.
Однако, в таком виде заголовок не будет действительным, потому что с Ноября 2018 года теперь для данного заголовка требуется ОБЯЗАТЕЛЬНОЕ значение “Unique end-to-end transsation reference” или UETR, которое введено в рамках Swift Global Payments Innovation (GPI), а с Ноября 2020 года абсолютно все SWIFT MT1xx, 2xx — должны обрабатываться согласно директивы GPI во всех банках без исключений. (Это ещё один повод не верить в сказки людей, ищущих специфичные «приемки» GPI. Все SWIFT сейчас работают с этим протоколом.)
UETR код, по своей сути является, глобальный уникальный идентификатор (Globally Unique Identifier или GUID) соответствующий четвертой версии алгоритма генерации, используемого стандартом IETF “RFC4122”. Он состоит из 32 шестнадцатеричных символов, разделенных на 5 частей дефисами следующим образом:
- Х – любой шестнадцатеричный символ в нижнем регистре (от 0 до f)
- 4 – фиксированное значение;
- Y – либо 8, 9, а, b.
Данное значение реально сгенерировать, с приемлемым сгенерированным UETR наш третий блок выглядел бы так:
Это порядковый номер блока, может быть только 3.
Это тип проверки сообщения, в нашем случае 119 — указывает каким способом обработать FIN сообщения.
Это область проверки, в нашем случае — STP. Запрос SWIFT проверить сообщение по принципу Сквозной обработки.
Указывает на поле UETR.
Само значение UETR.
БЛОК 5 и 6 (ХВОСТ и СИСТЕМНЫЙ БЛОК)
Ранее мы уже обсуждали «Тело сообщения» или БЛОК 4, поэтому мы его пропускаем и рассмотрим два последних блока.
Прежде чем мы двигаться дальше, немного расскажу о бессмысленно сложной концепции сообщений в СВИФТ.
— Вводимое сообщение (Input message) – это сообщение, которое ОТПРАВЛЯЕТСЯ из учреждения, так как это сообщение «вводится» оператором и отправляется учреждением в другое учреждение.
— Выводимое сообщение (Output message) – это сообщение, которое «входит» в учреждение. Так что это сообщение выводится SWIFTNet и принимается учреждением.
Для вводимых сообщений эти блоки не проблема, потому что заголовки используются только для указания того, было ли сообщение предназначено для обучения/ тестирования, или это возможный дубликат (копия сообщения):
Где TNG – означает TRAINING (обучение), а SPD означает Possible Duplicate (Возможный дубликат).
Однако, для выводимых сообщений, все немного сложнее, и системный блок может выглядеть так:
Разбивая эти значения получим следующее.
Хвост (<5:>)
MAC – код аутентификации сообщения, рассчитанный на основе всего содержимого сообщения с использованием секретного ключа, который был получен от банка получателя, и секретного алгоритма;
CHK – это контрольная сумма PKI сообщения, используемая для гарантии того, что сообщение не было повреждено при передаче.
TNG – отметка, указывающая, является это сообщение тестовым или обучающим.
Системный блок (
SPD – возможный дубликат
SAC – отметка об успешном заверении и авторизации, она присутствует только в случаях если проверка подписи прошла успешно или авторизация и проверка RMA (Application Management) прошла спешно.
COP – указывает что это основная копия сообщения;
MDG – HMAC256 сообщения с использованием ключей LAU
И если вы понимаете логику, то указание того же MAC, или CHK в СВИФТе отправки — не возможно. Так как их вам может выдать и отпечатать только принимающий банк, банк отправитель эти значения знать не может.
Разобравшись с логикой сообщения SWIFT, перейдем непосредственно к отправке сообщений.
SWIFT — банковские технологии передачи информации. Типы и структура сообщений
В серии публикаций о системе SWIFT мы расскажем о возникновении самой популярной международной платёжной системы и некоторых особенностях перевода денежных средств с её помощью.
Через систему SWIFT ежедневно передаются около 22 млн сообщений, по общему назначению они делятся на 10 категорий.
К нулевой категории относятся системные сообщения, касающиеся обмена информацией между системой и её пользователями. Эти сообщения имеют, как правило, самый высокий приоритет и уведомляют подключенных участников о состоянии работоспособности системы и о её новых возможностях.
Сообщения от 1 до 9 категории относятся к тому или иному направлению финансовой деятельности:
Когда говорят о типах сообщениях, то употребляют, устойчивое сокращение, типа: MT103, где
MT — Message Type (тип сообщения);
1 — категория сообщения, связанная с обслуживанием клиента;
03 — классификация в рамках данной категории (в категориях около семидесяти различных классификаций)
Таким образом MT103 — это сообщение для передачи инструкции по переводу денежных средств от Отправителя — Получателю.
Само сообщение разбито на поля, которые ограничены по длине и набору символов, используемых для их заполнения. Каждое поле имеет номер, состоящий из двух цифр и/или латинской буквы. Чтобы иметь представление о структуре сообщения, давайте рассмотрим реальный пример свифтовки MT103 и расшифруем поля, которые могут представлять интерес для Получателя денежных средств.
SENT —— MT103 — Single Customer Credit Transfer ——————
ORIGINATOR PARXLV22XXX DATE SENT 29-Apr-2010 13:58
SEQU 340742 DATE ACKD 29-Apr-2010 13:58
RAIFFEISEN ZENTRALBANK OESTERREICH AG
:20 /Transaction Reference Number :RMO546057S-KP
:23B/Bank Operation Code :CRED
:32A/Value Date/Currency/Interbank Settled Amount
:29-Apr-2010 USD 4300,
:33B/Currency/Original Ordered Amount
:50F/Ordering Customer :/LV12345678912345678912345678912345
2/ Str. Builders, 25
:57A/Account With Institution : ICBKCNBJGSU
INDUSTRIAL AND COMMERCIAL BANK OF CHINA, LTD
:59 /Beneficiary Customer :/20337139900111400195151
Industrial Park of North YishuiShandong
:70 /Details of Payment :For Peanut In Shell inv. 7352 dd 28.04.2010
:71A/Details of Charges :OUR
В заголовке указан тип передаваемого сообщения — MT103.
Инициатор сообщения, это банк, имеющий BIC-код PARXLV22XXX. В справочнике SWIFT данному BIC (Bank Identifier Codes) соответствует Citadele Banka (страна Латвия, г. Рига).
Первые четыре буквы PARX — это сокращение фирменного названия банка (раньше он назывался PAREX BANKA, позже переименован в Citadele Banka),
В следующих двух буквах кода ВIC зашифрована страна банка. LV — Латвия,
Число 22 — указывает местоположения офиса на территории страны, а XXX — признак головного офиса банка. Если вместо ХХХ стоят другие символы, то они обозначают шифр филиала или отделения банка.
Далее в свифтовке mt 103 видим, что сообщение было отправлено 29 апреля 2010 года.
Банк-корреспондент, сформировавший SWIFT-сообщение — это Райффайзен Банк Аваль Аустрерих, который находится в городе Вена,
AT — это двухзначный буквенный код страны — Австрия.
Ниже следует текст самого сообщения. Каждая строка начинается с номера поля.
Поле 20: содержит уникальный референс — RMO546057S-KP. Номер, на который можно ссылаться при упоминании об этом сообщении.
Поле 23B: содержит тип операции CRED — это зачисление денежных средств.
Поле 32А: содержит дату, валюту и сумму расчетного документа.
В нашем случае Плательщик отправил 29.04.2010 доллары США, в сумме 4300,00 USD.
Поле 33B: содержит валюту и сумму, для зачисления. Если из суммы платежа не было удержаний комиссии и не проводилась конвертация одной валюты в другую, то поля 32А и 33В будут одинаковыми. В нашем случае на счет Получателя зачислится 4300,00 USD.
Поле 50F: Реквизиты Плательщика. В нашем примере деньги отправлены со счета Плательщика, который представлен в формате IBAN. Количество знаков в IBAN не должно превышать 34 символа. LV12345678912345678912345678912345 — это не настоящий IBAN, и поэтому реально не существует. Любой IBAN можно проверить на правильность в специальном справочнике. Первые две буквы кодируют страну банка, следом идут два контрольных символа, которые называются «ключевые», а остальные позиции используются для идентификации банка и номера счета клиента в этом банке.
TRADEPOINT LTD — это наименование Отправителя;
адрес Отправителя — Улица Строителей, дом 25;
Страна Отправителя — CY — Кипр, город Лимассол.
Поле 56А: Банк-посредник.
Можно определить его через справочник BIC-кодов (CITIUS33XXX — Citibank N.A, США, Нью-Йорк). В следующих двух строках прописывается название и месторасположения банка-корреспондента.
Поле 57А: Банк получатель. Этот BIC-код определяет банк получателя денежных средств. Это INDUSTRIAL AND COMMERCIAL BANK OF CHINA в городе Гуанджоу, СN — Китайская Народная Республика;
Поле 59: Реквизиты получателя. Так как Китай не пользуется системой счетов IBAN, то номер счета состоит из набора цифр: 20337139900111400195151, следующие строки содержат наименования китайской фирмы-Получателя средств: FOODSTUFF CO.,LTD. и его адрес.
Поле 70: Назначение платежа. Средства переведены в оплату за арахис в скорлупе, согласно инвойса № 7352 от 28.04.2010
Поле 71А: содержит тип комиссии. OUR — комиссия за перевод оплачена за счет Плательщика;
Тело сообщение заканчивается и далее содержится служебная информация о проверке контрольной суммы и целостности передачи информации.
По аналогии устроены свифт-сообщения всех других категорий. Значение и структура каждого поля описаны в специальном справочнике-инструкции, позволяющем прочитать и понять общий смысл всей информации.
Примечательно, что сама система SWIFT не занимается клирингом платежей, а только генерацией и передачей банковских сообщений/инструкций о платежах и о самой системе.
Подписывайтесь на ForkNews в telegram, чтобы всегда быть в курсе последних новостей из мира криптовалют
Последовательные и покрытые платежи SWIFT
В последний раз мы разобрали работу оффлайна. Сейчас я хотел бы затронуть более глубоко тему постановки платежей (МТ103+МТ202) с покрытием. Разобраться почему большинство SWIFT приходят пустыми и как банки определяют, что блокировать, а что нет?
Последовательные платежи SWIFT и платежи с покрытием — это два способа, которые используются для отправки транзакций в корреспондентские банки. Что это за два метода и как они работают? Сначала кратко опишем, как работает каждый, а затем сделаем подробный анализ.
Вот как работает каждый из методов
Метод покрытия: отправитель инициирует два сообщения для оплаты. Одно сообщение используется для информирования банка-кредитора о поступлении средств. Это называется объявлением. Другое сообщение, называемое сопроводительным сообщением, перемещает средства между корреспондентскими счетами.
Последовательный метод: отправитель инициирует только одно сообщение для расчета средств. Это сообщение перемещается от одной стороны к следующей в цепочке платежей, пока не достигнет банка-получателя.
Когда используется метод покрытия, сторона (обычно банк), которая переводит средства, инициирует два платежа: объявление (SWIFT MT103 для переводов клиентов или SWIFT MT202 для переводов финансовых учреждений) и покрытие (MT202 COV). На рисунке ниже показаны сообщения, отправляемые для перевода клиента. Для перевода финансового учреждения объявление MT202 будет обмениваться между банком-должником и банком-кредитором.
Обратите внимание какие SWIFT-ы реально отправляются в банк получателя, никаких MT202 там нет. Если это не прямые отношения между банками, то SWIFT 202 не ходит в банк получателя.
Когда банк-получатель получает объявление (MT103), он может уже кредитовать своего клиента, даже если средства (покрытие) еще не поступили. Это зависит от многих критериев.
Среди прочего:
- уровень доверия, который он имеет в схеме, используемой для перевода средств — банк может принять решение ожидать покрытия, если, например, перевод осуществляется в определенной валюте.
- сумма перевода — Платеж сверх определенного порога будет зачислен только после получения покрытия.
- сторона, инициирующая / получающая средства — насколько хороши отношения банка с этой стороной
- и так далее.
Средства переходят от одной стороны к другой, пока не достигнут конечного получателя. Для платежа отправитель отправляет своему корреспонденту серийный (последовательный) MT103. Его корреспондент дебетует свой счет и переводит средства учреждению-посреднику, которое в большинстве случаев является корреспондентом бенефициара. Учреждение-посредник, в свою очередь, кредитует счет банка-кредитора. И, наконец, банк-кредитор зачисляет бенефициарный счет.
Обратите внимание, что в последовательном сообщении SWIFT MT103 используются поля 56a и 57a, тогда как поля 53a и 54a используются в сообщении MT103 Annoucement Message (метод покрытия). Как упоминалось выше, посредническое учреждение и корреспондент получателя обычно — это два имени для обозначения одного и того же.
Счет в учреждении — это банк, в котором находится счет получателя, поэтому это просто другое название банка-кредитора.
Помните о различиях полей, но важнее принцип: отправитель и получатель, находящиеся в разных валютных зонах, отправляют или получают средства через своих корреспондентов.
Движение средств между корреспондентскими счетами в одной стране или одной денежной зоне может происходить через локальные клиринговые системы. SWIFT не является обязательным, но также может использоваться.
Что обязательно, так это движение средств. Способ перевода средств остается на усмотрение банка-отправителя.
Заключение
В заключение мы видим, что последовательные и покрытые платежи SWIFT играют ключевую роль в корреспондентском банкинге. Я надеюсь, что эта информация поможет вам понять, как они работают.
Подписывайтесь на Телеграм канал, чтобы всегда быть в курсе самых последних и горячих новостей @like_freedman
Руководство по сквозной обработке (STP) сообщений SWIFT для рублевых расчетов
В предыдущем номере журнала1 мы начали разговор о специфике использования системы SWIFT для расчетов в рублях Российской Федерации. Мы рассмотрели возникающие проблемы и пути их решения, одним из которых является соблюдение дополнительных правил формализации информации в сообщениях SWIFT. Во второй части статьи подробно рассматривается содержание этих правил.
1. Указание реквизитов расчетных документов
В сообщении МТ 103 «Однократное зачисление клиентских средств» реквизиты расчетного документа указываются в поле 72 «Информация отправителя получателю» с кодовыми словами RPP или RPO, заключенными в слэши.
RPP — реквизиты расчетного документа в соответствии с требованиями Банка России.
RPO — реквизиты платежного ордера.
Формат указания реквизитов расчетного документа:
При этом первое подполе 3n — «Номер расчетного документа».
Второе подполе 6!n — «Дата расчетного документа в формате ГГММДД».
Третье подполе 1!n — «Очередность платежа».
Четвертое подполе 4!а — «Вид платежа». Служит для инструкций получателю сообщения о способе дальнейшей передачи расчетного документа2.
Используется один из следующих кодов:
ELEK — электронными средствами связи;
BESP — по системе БЭСП. Используется только тогда, когда и получатель MT 103, и банк, следующий за ним в цепочке перевода средств, являются участниками системы БЭСП.
Пятое подполе (не обязательное) 6!n — «Дата проведения платежа».
Шестое подполе (не обязательное) 2!n — «Вид операции». Служит для указания шифра расчетного документа в соответствии с Перечнем условных обозначений (шифров) документов, проводимых по счетам в кредитных организациях. Данное подполе может иметь значение:
01 — платежное поручение;
06 — инкассовое поручение;
16 — платежный ордер.
Если подполе не используется, то по умолчанию считается, что документ представляет собой платежное поручение.
Все подполя информации после кодового слова RPP разделяются точками.
Формат указания реквизитов платежного ордера:
Первое подполе 3n — «Номер частичного платежа» — номер по порядку частичного платежа.
Второе подполе 2!n — «Шифр расчетного документа» — может иметь значение:
01 — платежное поручение;
06 — инкассовое поручение;
02 — платежное требование.
Третье подполе 6n — «Номер расчетного документа» — номер расчетного документа, частичная оплата которого осуществляется.
Четвертое подполе 6!n — «Дата расчетного документа» — дата расчетного документа, частичная оплата которого осуществляется.
Пятое подполе 18d — «Сумма остатка платежа» — разница между суммой расчетного документа, частичная оплата которого осуществляется, и суммой оплаченных платежных ордеров. При заполнении этого поля необходимо следовать следующим правилам:
— целая часть должна содержать по крайней мере одну цифру;
— максимальная длина включает запятую между целой и дробной частями;
— дробная часть может отсутствовать, но запятая, отделяющая целую часть от дробной, всегда должна присутствовать;
— не допускается наличие пробелов, а также любых других символов, отличных от запятой;
— подполя не должны быть пустыми.
Все подполя после кодового слова RPО разделяются точками.
В сообщении МТ 202 «Общий межбанковский перевод» реквизиты расчетного документа указываются в поле 72 с кодовым словом RPP, заключенным в слэши.
Формат указания реквизитов платежного поручения в МТ 202:
Первое подполе 3n — «Номер платежного поручения».
Второе подполе 6!n — «Дата платежного поручения в формате ГГММДД».
Третье подполе 1!n — «Очередность платежа».
Четвертое подполе 4!а — «Вид платежа». Служит для инструкций получателю о способе дальнейшей передачи платежного поручения.
Используется один из следующих кодов:
ELEK — электронными средствами связи.
BESP — по системе БЭСП. Используется только тогда, когда и банк-получатель МТ 202, и банк, следующий за ним в цепочке перевода средств, являются участниками системы БЭСП.
Пятое подполе (не обязательное) — 6!n — «Дата проведения платежа».
Шифр расчетного документа не указывается, так как сообщение МТ 202 может содержать в себе только платежное поручение.
Все подполя после кодового слова RPP разделяются точками.
В сообщении МТ 101, так как в нем отсутствует поле 72, реквизиты расчетных документов указываются в поле 23Е с кодовыми словами OTHR и RPP в следующем формате:
Первое подполе 3n — «Номер расчетного документа».
Второе подполе 6!n — «Дата расчетного документа в формате ГГММДД».
Третье подполе 1!n — «Очередность платежа».
Четвертое подполе 4!а — «Вид платежа». Служит для инструкций получателю сообщения о способе дальнейшей передачи расчетного документа.
Используется один из следующих кодов:
ELEK — электронными средствами связи;
BESP — по системе БЭСП. Используется только тогда, когда и банк плательщика, и банк, следующий за ним в цепочке перевода средств, являются участниками системы БЭСП.
Пятое подполе (не обязательное) 6!n — «Дата перечисления платежа».
Шифр расчетного документа не указывается, так как сообщение МТ 101 может содержать в себе только платежное поручение.
Все подполя после кодового слова RPP разделяются точками.
2. Указание дат расчетного документа
Даты из расчетного документа указываются в поле 72 «Информация отправителя получателю» с кодовым словом DAS, заключенным в слэши, в следующем формате:
Все подполя представляют собой даты в формате ГГММДД.
Первое подполе — «Дата списания со счета плательщика». Соответствует полю 71 «Списано со сч. плат.» расчетного документа Банка России3.
Второе подполе — «Поступило в банк плательщика». Соответствует полю 62 «Поступ. в банк плат.» расчетного документа Банка России.
Третье подполе — «Отметка банка получателя». Соответствует полю 48 «Отметка банка получателя» расчетного документа Банка России.
Четвертое подполе — «Дата помещения в картотеку». Соответствует полю 63 «Дата помещения в картотеку» расчетного документа Банка России.
В случае когда формат исходного расчетного документа не содержит каких-либо из указанных полей либо информация в них отсутствует, в сообщении SWIFT соответствующие подполя заполняются нулями.
Если исходный расчетный документ не содержит информации ни в одном из указанных полей, то в сообщении SWIFT кодовое слово DAS не используется.
Относительно содержания информации в полях «Поступило в банк плательщика» и «Списано со счета плательщика» существует разъяснение Банка России4.
Например, в платежном поручении, направляемом банком, обслуживающим корсчет получателя МТ 103, реквизиты расчетного документа и даты расчетного документа будут указаны следующим образом:
В инкассовом поручении, направляемом банком взыскателя в банк, обслуживающий плательщика, сообщение МТ 103 будет содержать следующие реквизиты:
3. Указание информации для налоговых органов в расчетных документах на перечисление и взыскание налоговых и иных обязательных платежей
Для информации, содержащейся в «налоговых полях» (поля 101–110) расчетных документов Банка России на перечисление и взыскание налоговых и иных обязательных платежей, в сообщении МТ 103 используются поля 26Т «Код типа операции» и 77В «Обязательная отчетность».
Содержание информации в этих полях определяется Приказом Министерства финансов Российской Федерации от 24.11.2004 № 106н «Об утверждении правил указания информации в полях расчетных документов на перечисление налогов, сборов и иных платежей в бюджетную систему Российской Федерации».
В SWIFT-RUR приводятся полный перечень кодов и их описание согласно упомянутому Приказу.
Так, поле 26T «Код типа операции» в МТ 103 содержит код, указывающий статус плательщика («статус, который определяет юридическое лицо, индивидуального предпринимателя, частного нотариуса, адвоката, учредившего адвокатский кабинет, главу крестьянского (фермерского) хозяйства, иное физическое лицо — клиента банка (владельца счета), кредитную организацию, орган государственной власти или орган местного самоуправления, осуществляющий администрирование платежа в соответствии с законодательством Российской Федерации, непосредственно оформивших расчетный документ»).
Информационно это поле соответствует полю 101 расчетных документов Банка России. Наличие поля 26Т «Код типа операции» в сообщении SWIFT, сформированном согласно SWIFT-RUR, обязательно требует наличия поля 77В «Обязательная отчетность».
Так как статус плательщика обозначается двузначным цифровым кодом, а формат поля 26Т требует обязательного заполнения трех позиций, то перед кодом статуса плательщика добавляется буква «S».
Таким образом, поле 26Т может содержать, например, следующие коды:
S02 — Налоговый агент и т.д.
Пример поля 26Т «Код типа операции» в сообщении МТ 103: :26Т:S08
Поле 77В «Обязательная отчетность» MT 103 информационно соответствует полям 104–110 расчетных документов Банка России. Согласно SWIFT-RUR присутствие поля 77В в сообщении МТ 103 обусловливается наличием в этом сообщении поля 26Т.
Формат поля 77В составляет 3 строки по 35 символов. Информация в поле формализуется посредством его разделения на подполя, имеющие идентификатор, который указывается в начале каждого подполя и имеет строгое соответствие с полем платежного поручения Банка России (табл. 2).
В SWIFT-RUR приводится подробное описание информации, которая должна указываться в каждом из подполей поля 77В «Обязательная отчетность».
Если поле 77В используется, то в нем должны присутствовать все подполя. Если подполе не содержит информации, то после соответствующего идентификатора обязательно проставляется нуль. Присутствие всех идентификаторов подполей в поле 72В обязательно.
Формат поля 77В не позволяет расположить подполя иначе, как в следующей последовательности:
строка 1 /N10/2!c/N4/20!n
строка 2 /N5/11!nIN6/2!c/N7/2!n.2!n.4!n
строка 3 /N8/15x/N9/2!n.2!n.4!n
Например, если налогоплательщик осуществляет перечисление налога за июнь 2008 года, то в сообщении SWIFT MT 103 эта информация будет отражена следующим образом:
В сообщении МТ 101 «Запрос на перевод средств», формат которого не содержит поля 26Т, для указания статуса плательщика используется поле 23Е «Код инструкций» с кодовым словом OTHR, если оно содержит расчетные документы на перечисление и налоговых, и иных обязательных платежей.
Таким образом, содержание поля 101 расчетного документа Банка России в сообщении МТ 101 указывается следующим образом:
И соответственно этот же пример в сообщении МТ 101 будет выглядеть следующим образом:
4. Указание российских кодов, содержащихся в расчетных документах: БИК, ИНН, КИО, КПП
В сообщениях SWIFT по операциям в российских рублях наряду с идентификационными кодами, применяемыми в международной практике, используются российские коды: банковский идентификационный код (БИК), идентификационный номер налогоплательщика (ИНН), код иностранной организации (КИО) и код причины постановки на учет (КПП).
Банковский идентификационный код (БИК)
Банковский идентификационный код (БИК) является уникальным идентификатором участников расчетов в платежной системе Банка России.
Присвоение БИК осуществляется Банком России при регистрации кредитной организации.
Структура БИК определена в Положении ЦБ РФ от 06.05.2003 № 225-П «О Справочнике банковских идентификационных кодов участников расчетов, осуществляющих платежи через расчетную сеть Центрального банка Российской Федерации (Банка России)» и представляет собой цифровую последовательность, имеющую длину 9 знаков.
Банковский идентификационный код указывается в формате:
При этом RU — обозначение кода национальной клиринговой системы РФ в стандартах SWIFT.
Идентификационный номер налогоплательщика (ИНН)
Идентификационный номер налогоплательщика (ИНН) является уникальным идентификатором юридического или физического лица, зарегистрированного в налоговых органах РФ.
В соответствии с требованиями Банка России ИНН, если он присвоен, указывается для инициатора платежа (плательщика, банка-плательщика) и для конечного получателя средств (бенефициара, банка-бенефициара).
ИНН в обязательном порядке должен быть указан в расчетных документах на перечисление налогов, сборов и других обязательных платежей в бюджетную систему Российской Федерации.
ИНН указывается в полях 50а «Плательщик» и 59 «Бенефициар» сообщений МТ 101 и МТ 103, а также в полях 52а «Банк-Плательщик» и 58а «Банк-Бенефициар» сообщения МТ 202. В описании этих сообщений в SWIFT-RUR подробно изложены правила указания ИНН.
Идентификационный номер налогоплательщика представляет собой цифровую последовательность, имеющую длину 10 знаков для юридических лиц и 12 знаков для физических лиц.
Идентификационный номер налогоплательщика указывается в формате:
3!а12n в одном из двух вариантов:
3!a10!n — для юридических лиц;
3!a12!n — для физических лиц.
При этом 3!a — кодовое слово ИНН (после транслитерации — INN).
Код иностранной организации (КИО)
Код иностранной организации (КИО) является уникальным идентификатором иностранной организации (в том числе банка или иного финансово-кредитного учреждения), зарегистрированной в Министерстве Российской Федерации по налогам и сборам.
КИО, если он присвоен, указывается в расчетных документах для идентификации инициатора платежа (плательщика, банка-плательщика), если ему не присвоен ИНН.
КИО указывается в поле 50а «Плательщик» сообщений МТ 101 и МТ 103, а также в поле 52а «Банк-Плательщик» сообщения МТ 202.
Код иностранной организации представляет собой цифровую последовательность, имеющую длину 5 знаков.
Код иностранной организации указывается в формате:
При этом 3!а — кодовое слово КИО (после транслитерации — KIO).
Так как КИО, если он присвоен, указывается только в случае отсутствия ИНН, то в тексте сообщения SWIFT он располагается в подполе, предназначенном для указания ИНН, формат которого обозначен 3!а12n.
Код причины постановки на учет (КПП)
Код причины постановки на учет (КПП) присваивается юридическому лицу в дополнение к идентификационному номеру налогоплательщика (ИНН) при регистрации в налоговых органах Российской Федерации.
КПП и ИНН в обязательном порядке должны быть указаны в расчетных документах на перечисление юридическими лицами налогов, сборов и других обязательных платежей в бюджетную систему Российской Федерации.
КПП указывается в полях 50а «Плательщик» и 59 «Бенефициар» сообщений МТ 101 и МТ 103.
Код причины постановки на учет представляет собой цифровую последовательность, имеющую длину 9 знаков.
Код причины постановки на учет указывается в формате:
При этом 3!a — кодовое слово КПП (после транслитерации — KPP).
1 Начало см.: Расчеты и операционная работа в коммерческом банке. 2008. № 4. С. 33–38.
2 Здесь и далее описания форматов полей сообщений SWIFT приведены в соответствии с условными обозначениями, применяемыми в Руководстве пользователя SWIFT (SWIFT User Handbook):
n — цифры от 0 до 9;
а — буквы в верхнем регистре;
с — буквы в верхнем регистре или цифры;
х — допустимые символы набора Х;
nn! — фиксированная длина поля (например, 10!a — не более и не менее десяти букв в верхнем регистре);
nn — максимальная длина поля (например, 10a — не более десяти букв в верхнем регистре);
nn*nn — максимальное количество строк ґ максимальная длина одной строки (например, 4*35 — не более 4-х строк по 35 символов).
3 Здесь и далее номера полей расчетных документов Банка России приведены в соответствии с Положением Банка России № 2-П.