Как можно проверить поля мт в свифте
Перейти к содержимому

Как можно проверить поля мт в свифте

  • автор:

Последовательные и покрытые платежи SWIFT

В последний раз мы разобрали работу оффлайна. Сейчас я хотел бы затронуть более глубоко тему постановки платежей (МТ103+МТ202) с покрытием. Разобраться почему большинство SWIFT приходят пустыми и как банки определяют, что блокировать, а что нет?

Последовательные платежи SWIFT и платежи с покрытием — это два способа, которые используются для отправки транзакций в корреспондентские банки. Что это за два метода и как они работают? Сначала кратко опишем, как работает каждый, а затем сделаем подробный анализ.

Вот как работает каждый из методов

Метод покрытия: отправитель инициирует два сообщения для оплаты. Одно сообщение используется для информирования банка-кредитора о поступлении средств. Это называется объявлением. Другое сообщение, называемое сопроводительным сообщением, перемещает средства между корреспондентскими счетами.

Последовательный метод: отправитель инициирует только одно сообщение для расчета средств. Это сообщение перемещается от одной стороны к следующей в цепочке платежей, пока не достигнет банка-получателя.

Когда используется метод покрытия, сторона (обычно банк), которая переводит средства, инициирует два платежа: объявление (SWIFT MT103 для переводов клиентов или SWIFT MT202 для переводов финансовых учреждений) и покрытие (MT202 COV). На рисунке ниже показаны сообщения, отправляемые для перевода клиента. Для перевода финансового учреждения объявление MT202 будет обмениваться между банком-должником и банком-кредитором.

Последовательные и покрытые платежи SWIFT

Обратите внимание какие SWIFTреально отправляются в банк получателя, никаких MT202 там нет. Если это не прямые отношения между банками, то SWIFT 202 не ходит в банк получателя.

Когда банк-получатель получает объявление (MT103), он может уже кредитовать своего клиента, даже если средства (покрытие) еще не поступили. Это зависит от многих критериев.

Среди прочего:

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

Средства переходят от одной стороны к другой, пока не достигнут конечного получателя. Для платежа отправитель отправляет своему корреспонденту серийный (последовательный) MT103. Его корреспондент дебетует свой счет и переводит средства учреждению-посреднику, которое в большинстве случаев является корреспондентом бенефициара. Учреждение-посредник, в свою очередь, кредитует счет банка-кредитора. И, наконец, банк-кредитор зачисляет бенефициарный счет.

Обратите внимание, что в последовательном сообщении SWIFT MT103 используются поля 56a и 57a, тогда как поля 53a и 54a используются в сообщении MT103 Annoucement Message (метод покрытия). Как упоминалось выше, посредническое учреждение и корреспондент получателя обычно — это два имени для обозначения одного и того же.

Счет в учреждении — это банк, в котором находится счет получателя, поэтому это просто другое название банка-кредитора.
Помните о различиях полей, но важнее принцип: отправитель и получатель, находящиеся в разных валютных зонах, отправляют или получают средства через своих корреспондентов.

Движение средств между корреспондентскими счетами в одной стране или одной денежной зоне может происходить через локальные клиринговые системы. SWIFT не является обязательным, но также может использоваться.
Что обязательно, так это движение средств. Способ перевода средств остается на усмотрение банка-отправителя.

Заключение

В заключение мы видим, что последовательные и покрытые платежи SWIFT играют ключевую роль в корреспондентском банкинге. Я надеюсь, что эта информация поможет вам понять, как они работают.

Подписывайтесь на Телеграм канал, чтобы всегда быть в курсе самых последних и горячих новостей @like_freedman

How to define an MT format

The Usage Guideline Editor allows the formalization of a field/element format as an MT Format. The MT format language is defined by Swift. It describes how a field is structure by specifying :

  • which type of characters can be used in that field
  • what are the restrictions on the length of the field (i.e. how many times each type of character can appear and in which order)

Here is a simplified definition of those two attributes:

SWIFT МТ103 — Детальный разбор (ч1)

В последнее время, в интернете развелось слишком много мошенников, которые пользуются неграмотностью людей (недостатком знаний), и разводят их на деньги, иногда не малые. Если разбирать платежи в системе SWIFT то особенно часто можно увидеть предложения про мануал доводку платежей (manual download), которую ставят хакеры (так вам будут объяснять ребята свою работу), в итоге максимум вы получите pdf файл, с непонятным набором символов, который выглядит логично, но ничего общего с SWIFT не имеющий. В данной статье будет описаны процедуры, благодаря которым вы действительно сможете составить платежное сообщение которое сможет пройти комплаенс на суммах до 500 тысяч евро, благодаря доверительным отношениям внутри системы СВИФТ. Также вы поймете общий принцип работы системы СВИФТ, и сможете проводить первичную проверку сообщений и выявлять подделки.

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

Перейдем к сути:

Типичные атаки хакеров, имеющие отношения к системе СВИФТ, которые мы можем наблюдать в отчетах полиции или средствах массовой информации – следующие:

  1. Компрометация сети учреждения;

2. Использование критичных багов платежной системы;

3. Компрометация учетных данных оператора платежей СВИФТ;

4. Доступ к СВИФТ-интерфейсу обмена сообщений учреждения;

5. Авторизация платежных сообщения с использованием скомпрометированных учетных записей платежного оператора и интерфейса обмена сообщениями;

Чтобы выполнить данный вектор атаки вам потребуется компрометация нескольких пользователей, нескольких систем, понимания того, как работает целевое приложение, обход двухфакторной авторизации, затем вы обязаны скрыть журналы доступа во избежание предупреждения от легитимных операторов, настроить вредоносное ПО и .т.д. – что даже в кратком описании выглядит ОЧЕНЬ сложно.

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

Для начала вам нужно полностью понять и разобраться с конкретным «разделом» платежной системы (СВИФТ) в целевом учреждения. Мы будем называть её просто СВИФТ.

СВИФТ принимает данные в произвольном формате и выводит начальные платежные инструкции в формате ISO 15022 / RJE / SWIFT MT.

Мы сосредоточимся на компрометации платежного поручения МТ103, а именно:

  • MT — «тип сообщения»
  • 1 — категория 1 (платежи и чеки клиентов)
  • 0 — группа 0 (перевод финансовых учреждений)
  • 3 — Тип 3 (уведомление)

Все вместе это классифицируется как MT103 «Single Customer Credit Transfer» (SCCT или ОДНОКРАТНЫЙ КРЕДИТОВЫЙ КЛИЕНТСКИЙ ПЕРЕВОД)

Помимо типа сообщения, нам нужно понять, как обрабатывается данный платеж. Он достаточно типичен, для таких видов перевода и выглядит так:

  1. Система (Приложение для работы с SWIFT) принимает данные от пользователя в удобном ему формате (например посредством заполнения полей в графическом интерфейсе приложения). Затем Система выводит начальную платежную инструкцию в формате SWIFT MT;
  2. Система отправляет данное сообщение дальше, в компонент именуемый Промежуточным Программным Обеспечением (ППО), который преобразует (при необходимости) полученное сообщение в современный формат SWIFT, понятный системе. По сути, это брокер сообщений предоставляемый для не институциональных финансовых организаций.
  3. ППО отсылает сформированное сообщение в Институциональное Финансовое Учреждение (Банк, Кредитная организация или иное, далее Банк для удобства), для обработки.
  4. Банк проверяет содержимое сообщения, производит ряд проверок (не находится ли компания в черном списке, проходит проверку системой борьбы по отмыванию денег, проверяет легальность операции при высоких объемах, делает запрос в антимонопольное ведомство или в валютный контроль, если такие опции есть в стране где находится Банк)
  5. Если сообщение сформировано верно, проходит внутрибанковскую проверку, то сообщение отправляется в Swift Alliance Gateway, где оно подписывается и отправляется в организацию/банк получателя через SwiftNet.

Углубимся немного глубже в эту технологию.

Разбираемся в деталях обмена данными

Зададимся вопросом: как эти сообщения передаются между всеми этими системами?

Чаще всего в любой Платежной Системе для передачи сообщений между различными компонентами используются так называемые Очереди Сообщений (ОС).

Существуют различные «адаптеры», которые могут быть использованы между системами обменивающиеся данными напрямую с Swift Alliance Gateway:

  • Удаленный хост-адаптер API (HAPI)
  • Хост адаптер Очереди Сообщений (MQHA)
  • Хост-адаптер веб-служб (WSHA)

Из требований SWIFT CSP вы можете узнать, что для поддержания Очереди Сообщений вам нужен выделенный сервер Менеджер Очереди (МО), на котором будут размещаться различные Очереди Сообщений (МТ1хх, МТ2хх итд), из которых системы будут отправлять и извлекать сообщения.

Также в требованиях строго прописано, что должно присутствовать минимум два администратора очереди. Один управляет очередями в Зоне работы SWIFT, второй для общения в корпоративной сети и/или прочих системах учреждения (к примеру внутрибанковские операции должны быть ОТДЕЛЕНЫ от операций связанных с системой SWIFT, а также операции в других платежных системах, например VISA, MASTERCARD или SEPA).

Определяем жизнеспособный вектор для внедрения

Пришло время определится с задачей: «Поместить платежное поручение в очередь и успешно его обработать во всех системах (пройти валидацию)»

Задача простая, поэтому зададим правильные вопросы, которые помогут в реализации:

  1. Как получить доступ на запись в нужную очередь?
  2. Что защищает сообщения в очередях?
  3. Что защищает сообщение при транзите?
  4. В каком формате находятся сообщения?
  5. Как составить синтаксически верное сообщение для выбранного формата? (цель – 0 ошибок)
  6. Где находится PKI (Public Key Infrastructure или Инфраструктура открытых ключей)? Как, где и когда подписываются сообщения, производится их проверка?
  7. Можно ли как-нибудь обойти подпись сообщения?
  8. Какие значения в сообщениях зависят / контролируются / определяются системой, обрабатывают их вне моего контроля (или другого человека)?
  9. Какую максимальную сумму я могу перевести с помощью, не предупреждая учреждение / не требуя проверки вручную?

Теперь распишем саму задачу подробнее, по пунктам:

  1. Грамотно написать платежную инструкцию на 500 тысяч евро;
  2. Вставить данную платежную инструкцию в очередь;
  3. Сообщение должно пройти синтаксическую проверку (ACK or NACK);
  4. Сообщение должно пройти все дополнительные проверки, включая проверку AML;
  5. Сообщение должно быть успешно подписано;
  6. Пройти валидацию при проверки правилами SWIFTNet;

С точки зрения хакера оно выглядит так:

  1. Скомпрометировать сеть учреждения;
  2. Получить доступ к рабочей станции администратора Менеджера Очередей;
  3. Получить необходимые реквизиты фирмы;
  4. Провести требуемую работу.

Следует избегать следующего:

  1. Атака с участием платежного оператора SWIFT (самой системы);
  2. Атака с использованием доступа к SWIFT-приложению (прямой доступ к официальному банковскому приложению);
  3. Необходимость компрометации подписи ключей (подделка цифровых ключей);
  4. Необходимость компрометации учетных записей или сертификатов оператора 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-перевод или ожидаете входящий международный банковский перевод и отправитель поделился с Вами формой МТ103, то в этой статье Вы узнаете какие поля являются обязательными, а какие опциональными и какие правила заполнения каждого поля.

Учтите, что большинство полей в SWIFT-сообщении заполняются автоматически. Примеры заполненных SWIFT-сообщений можно посмотреть в нашей статье про образцы формы МТ103.

В этом поле содержится номер SWIFT платежа. Он же часто называется Sender’s Reference Number или SWIFT Reference Number. Данное поле присваивается каждым банком самостоятельно, поэтому в какой-то момент SWIFT ввёл дополнительный идентификатор — UETR. Он универсален и содержится обычно в заголовке SWIFT-сообщения в поле 121.

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

  • CRED for a credit transfer that involves no SWIFT Service Level (the most popular value).
  • SPAY for a credit transfer to be processed according to the SWIFT Pay Service Level;
  • SSTD for a credit transfer to be processed according to the SWIFT Standard Service Level; and
  • SPRI for a credit transfer to be processed according to the SWIFT Priority Service Level.

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

Вариант A: (Account) (Identifier Code)

Вариант F: (Party Identifier) (Number/Name and Address)

Вариант K: (Account) (Name and Address)

Банк или финансовая организация, которая отправила перевод. Вот пример для перевода с Wise в Черногорию:

52D:/6161645269
WISE PAYMENTS LIMITED
6TH FLOOR,TEA BUILDING,
56 SHOREDITCH HIGH STREET
GB/LONDON LN E1 6JJ

Кто оплачивает перевод:

BEN — Получатель перевода.

OUR — Отправитель перевода.

SHA — Shared — частично отправитель и частично получатель.

Информация о резидентстве отправителя или получателя перевода

BENEFRES — Адрес получателя.

ORDERRES — Адрес отправителя.

Пример :77B:/ORDERRES/BE//MEILAAN 1, 9000 GENT

MT103 — самая распространённая форма передачи информации о трансграничном платеже, подробнее о ней можно почитать в официальном SWIFT Message Reference Guide.

Уже много прочитали про международные переводы, но остаются сомнения? Запишитесь на консультацию. Поможем выбрать банки, валюту и сопроводим перевод до зачисления.

Подпишитесь на новости SWIFT-переводов и релокации капитала @ohmyswiftblog

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *