SWIFT: стандарты, форматы полей - практика применения.

[hamster]

Vampess
А с форматом поля "наши" наврали: в русском варианте Стандартов
А это несущественно... Эта точность важна только при разработке софта, а грамотный разработчик всегда будет работать с оригиналом. А безграмотного к работе лучше вообще не допускать.

[Nickol]

Добрый день. Скажите, какие этапы, связанные с покупкой продажей драгоценных металлов на межбанке, имеет практический смысл подтверждать? (Например, оферта о согласии заключить такую сделку, расчеты по сделке и т.д.) Какие форматы MT при этом стоит применять?

[guestseug]

6xx

[Nickol]

Связанный вопрос. Каким форматом можно воспользоваться для подтверждения факта поставки драгоценных металлов контрагенту?

[Vampess]

Nickol
MT600 Подтверждение сделки с драгоценными металлами

[Nickol]

Спасибо. А можно ли для сделок с золотом и серебром использовать сообщение для конверсионной сделки MT300?

[Vampess]

Nickol А можно
Нельзя. Для сделок с драг.металлами специально предусмотрена 6 категория Стандартов S.W.I.F.T.

[Дм. А.]

Nickol А можно Можно все по согласованию с контрагентом.

[hamster]

А можно ли
В SWIFTе есть очень замечательный тип сообщения: MTn99 - как раз для тех случаев, когда либо непонятно, что использовать; либо в формате хитрого сообщения запутались; а также для тех случаев, когда нет уверенности, что Ваш контрагент, при всем к нему уважении, в состоянии разобраться в том, что Вы ему собираетесь написать. Практика показывает, что МТ399 прекрасно идет вместо МТ300 и МТ320, МТ299 - вместо МТ210... А уж МТ599 - вообще вместо почти всего.
Нередко выигрыш во времени стоит дороже точного выбора формата.

[Nickol]

Добрый день.
Спасибо за все предыдущие ответы!!
Формат MT600 является подтверждением сделки покупки/продажи драг. металла.
Было бы логично, если бы он содержал такие существенные условия сделки, как:
стандарт качества слитка,
проба драг. металла.
В описании MT600 таких полей нет. Существует ли какое либо расширение данного формата, содержащее доп. поля?

[Router]

Nickol В описании MT600 таких полей нет. Существует ли какое либо расширение данного формата, содержащее доп. поля? MT699 на референс которого вы делаете ссылку в Вашем MT6xx-м разве не может Вам подойти?

[YTBAlexander]

Nickol Было бы логично, если бы он содержал такие существенные условия сделки, как:
стандарт качества слитка,
проба драг. металла.
а почему бы не использовать для этого поле 71С или 72, тем более, если вы договоритесь со своими контрагентами, коих я думаю не так много, об обоюдном использовании в этих полях интересующей вас доп. информации, а для поля 72 вы со своими контрагентами можете договориться об использовании специальных кодов для каждого отдельного или группы интересующих вас условий сделки, например, предусмотреть использование в поле 72 кода /QUAL/а далее следует описание качества слитка и т.п.

[Nickol]

а почему бы не использовать для этого поле 71С или 72
Спасибо. Вариант, пожалуй, оптимальный.

[Everwhite]

Коллеги, возможно вопрос уже обсуждался, но найти не смогла. Как, по-вашему, наиболее корректно заполнить МТ 103, в случае, если средства в Usd перечисляются на счет бенефициара в российском банке, у которого корр. счет в Usd находится в Европе? В каком поле указывать американский банк, через который проводятся расчеты, в каком европейский банк-корреспондент, в каком сам банк бенефициара? В связи с последними событиями вопрос стал весьма актуален.
Заранее спасибо.

[Guestseug]

Коллеги, возможно вопрос уже обсуждался, но найти не смогла. Как, по-вашему, наиболее корректно заполнить МТ 103, в случае, если средства в Usd перечисляются на счет бенефициара в российском банке, у которого корр. счет в Usd находится в Европе? В каком поле указывать американский банк, через который проводятся расчеты, в каком европейский банк-корреспондент, в каком сам банк бенефициара? В связи с последними событиями вопрос стал весьма актуален.
Заранее спасибо.

56: американец
57: европеец
59: получатель
72:/ACC/российский банк

А лучше ключами меняйтесь.

[Router]

Everwhite

:56A:SWIFT американского корреспондента европейского банка
:57A:SWIFT европейского банка
:59:/N счета бененициара
наименование и адрес бенефициара
:72:/ACC/FFC SWIFT российского банка получателя

в случае отсутствия свифта у российского банка

:56A:SWIFT американского корреспондента европейского банка
:57A:SWIFT европейского банка
:59:N счета банка-бенефициара
наименование и адрес банка-бенефициара
:70:в назначении указать N счета и наименование получателя

либо использовать поле 72 с кодовым словом /BNF/и в нем указать то же,
что вышеуказано в 70 поле

[Router]

А лучше ключами меняйтесь. Объясните Вашу позицию? имеется в виду платеж с
покрытием - тогда лучше не надо, если иное то что?

[Guestseug]

А лучше ключами меняйтесь. Объясните Вашу позицию? имеется в виду платеж с
покрытием - тогда лучше не надо, если иное то что?

Именно с покрытием. Что здесь собственно объяснять?
Лучше вы объясните, почему "лучше не надо" и какая разница есть ли СВИФТ у банка или нет?

[Router]

Именно с покрытием. Что здесь собственно объяснять?
Лучше вы объясните, почему "лучше не надо"
На тему платежей с покрытием я имею авторитетное мнение нескольких американских банков
об их недопустимости со стороны сторонних банков участвующих в осуществлении платежа,
вплоть до закрытия кор. счета. Правда, за собой они такое право оставляют, т.к.
это не противоречит их AML, и т.д. и т.п.

и какая разница есть ли СВИФТ у банка или нет?
при указании :72:/ACC/FFC SWIFT (банка-получателя) как правило
в банках (европейских и пр.) происходит автоматическое преобразование и перенаправление сообщения в соответствии с указанным маршрутом. При отсутствии SWIFT
у банка - см. предложенный второй вариант.

[Lexx]

Router при указании :72:/ACC/FFC SWIFT (банка-получателя) как правило
в банках (европейских и пр.) происходит автоматическое преобразование и перенаправление сообщения

А зачем писать FFC? Ведь по формату 72 поля /acc/ и есть инфа для 57 поля о дальнейшем зачислении средств. Насколько я знаю, в том числе и из опыта, наличие 72 поля исключает автоматическую обработку, поэтому в принципе нет разницы, указать ли свифт :72:/ACC/ ААААВВDD072, или счет и наименование :72:/ACC/ 101111...1 of Moscow Bank, Moscow.
Сами всегда подобным образом отправляем платежи с длинной цепочкой корбанков, проблем никогда не было. А вот когда использовали 70 поле - проблемы были, т.к. зависело от оператора посмотреть ли в 70 поле и задуматься!

[Router]

Lexx А зачем писать FFC? дело вкуса
Насколько я знаю, в том числе и из опыта, наличие 72 поля исключает автоматическую обработку все зависит от настроек системы, как правило любой мало-мальски уважающий себя банк, открывающий корсчета настраивает систему на автоматическую идентификацию 72 поля, преобразование и переадресацию платежного сообщения.
в принципе нет разницы, указать ли свифт :72:/ACC/ ААААВВDD072, или счет и наименование :72:/ACC/ 101111...1 of Moscow Bank, Moscow. в ПРИНЦИПЕ нет, но я бы предпочел :72:/ACC/ААААВВDD072 (без пробела), а на примере :72:/ACC/ 101111...1 of Moscow Bank, Moscow больше шансов уж точно попасть на repair.
Сами всегда подобным образом отправляем платежи с длинной цепочкой корбанков, проблем никогда не было Согласен, только все зависит от времени обработки.
А вот когда использовали 70 поле - проблемы были, т.к. зависело от оператора посмотреть ли в 70 поле и задуматься!Ну если орератор российского банка не в состоянии идентифицировать своего клиента-получателя (касаемо рассматриваемого примера) тогда без комментариев.

[Vacuum]

Уважаемые коллеги есть вопрос:

Вопрос: насколько оправдано писать номер счета банка-получателя в банке-корреспонденте совместно со со SWIFT-кодом (опция А) в поле 57А (для МТ103) или 58А (для МТ202/200)- с точки зрения скорости зачисления средств банком-корреспондентом на счет банка-получателя?
В предыдущем банке, где я работал, я всегда ограничивался только SWIFT-кодом банка-получателя и никаких задержек я не замечал. На новом же месте работы мне утверждают, что в частности, BKTRUS33 зачисляет деньги значительно быстрее.Так ли это? Ведь кроме всего прочего возникает риск ошибки в номере счета.Кстати, как будет реагировать банк-корреспондент, если номер счета будет указан неправильно, а SWIFT-код в том же поле правильно?

С уважением,

Vacuum

[hamster]

Vacuum
оправдано писать номер счета банка-получателя в банке-корреспонденте совместно со со SWIFT-кодом
Теория вопроса следующая.
Во-первых, если некий банк (для простоты рассматриваем западный, ибо он только и интересен для данной темы) получает для обработки поле, в котором одновременно указаны SWIFT-код и номер счета (пока предположим, что оба кода указаны абсолютно на месте и указывают на один и тот же банк), то алгоритм дальнейших действий будет зависеть от методики обработки, принятой в данном банке и реализованной в его софте.
Примеры:
BKTRUS33 зачислит средства на основании номера счета.
IRVTUS3N отправит перевод на ручную доработку.
Сами понимаете, возможны варианты. Отмечались случаи, когда приоритет при обработке отдавался SWIFT-коду.
Далее, международные правила, в частности, ЕТК, разрешает банкам при обработке полагаться только на указанный номер счета, фактически не принимая во внимание остальную указанную информацию.
кроме всего прочего возникает риск ошибки в номере счета
Этот риск устраняется внедрением систем подготовки платежей, в которых ввод информации о всей цепочке банков, необходимой для реализации перевода, осуществляется с помощью встроенных справочников корр.отношений, в которых SWIFT-коды, BLZ, ABA, номера счетов и т.д. уже введены и принимаются при подготовке перевода правильными.
как будет реагировать банк-корреспондент, если номер счета будет указан неправильно, а SWIFT-код в том же поле правильно?
См. выше. BKTRUS33 зачислит по неправильному номеру счета. Проверено неоднократно.

[Дм. А.]

Что-то уважаемый модератор молчит.

[Vacuum]

Примеры:
BKTRUS33 зачислит средства на основании номера счета.
IRVTUS3N отправит перевод на ручную доработку.
Меня интересует,будут-ли более быстро зачислены средства на счет банка-получателя если
в платежке указан вариант а):
:57A:IRVTUS3N
:58A:/8900439599
EVRFRUMM
по сравнению с вариантом б):
:57A:IRVTUS3N
:58A:EVRFRUMM
Вроде в обоих вариантах соблюдено требование STP (естественно,при условии, что номер счета в варианте а)-правильный). Я предполагаю, что вариант а)не ускорит зачисления средств на счет банка-получателя по сравнению с вариантом б). Какие мнения? И почему IRVTUS3N направит платеж на ручную доработку при варианте а)?

С уважением,
Vacuum

[Дм. А.]

hamster в частности, ЕТК, Ссылочки нет под рукой?
Vacuum Автоматическая обработка не может быть более быстрой или более медленной (на осознаваемом уровне). Она либо есть, либо ее нет.
BKTRUS33 зачисляет деньги значительно быстрее. Это в чем измеряется?
Вариант а в вашем примере в IRVTUS3N будет отправлен на ручную обработку. Так уж у него настроен алгоритм. Наличие двух идентификаторов - на ручник. У BKTR другой алгоритм. Но, повторюсь, что если обработка автоматом, то она не может быть скорее или медленнее.

[hamster]

Vacuum
в платежке указан вариант а):
:57A:IRVTUS3N
:58A:/8900439599
EVRFRUMM
по сравнению с вариантом б):
:57A:IRVTUS3N
:58A:EVRFRUMM


Два варианта:
1. MT202 в IRVTUS3N.
Тут repair по наличию IRVTUS3N в поле 57A. Если это поле убрать, то repair в 1-м случае и STP во 2-м. Соответственно и разница в скорости обработки.
2. МТ202 идет не в IRVT, а, к примеру, в BKTR
Ситуация существенно меняется. BKTR отправляет перевод далее по CHIPS, преобразуя EVRFRUMM в текст. В первом случае в качестве идентификатора в IRVT передается номер счета, указанный в исходном МТ202; во втором - CHIPS UID, полученный в BKTR на основании кода EVRFRUMM. Таким образом, в обоих случаях IRVT получит сообщение с единственным уникальным идентификатором, и, соответственно, в обоих случаях будет STP с равной скоростью обработки.
И почему IRVTUS3N направит платеж на ручную доработку при варианте а)?
Система у него так устроена (по крайней мере, была, когда я еще работал с ними).
Вроде в обоих вариантах соблюдено требование STP
Имейте в виду, что STP вообще (как в справочниках) и STP, реализованная в конкретном банке - это не обязательно одно и то же.

[hamster]

Дм. А.
ЕТК, Ссылочки нет под рукой?
Ссылки нет, есть текст (подарок от Vampess). У нее, видимо, сохранился и файл.

[Дм. А.]

Подарок и у меня был. Да вот никак не найду...

[Vampess]

hamster Дм. А. Подарок и у меня был. Да вот никак не найду...
Щас вывешу, тока флудить прекращайте.