Fin 103 single customer credit transfer что это
Description of the message MT103.STP
MT 103 STP Single Customer Credit Transfer
The MT 103 STP is a general use message, that is, no registration in a Message User Group is necessary to send and receive this message. It allows the exchange of single customer credit transfers using a restricted set of fields and format options of the core MT 103 to make it straight through processable. The MT 103 STP is a compatible subset of the core MT 103 that is documented separately.
The differences with the core MT 103 are:
To trigger the MT 103 STP format validation, the user header of the message (block 3) is mandatory and must contain the code STP in the validation flag field 119 (<3:<119:STP>>).
Purpose of the message MT103.STP
Scope of the message MT103.STP
This message type is sent by or on behalf of the financial institution of the ordering customer, directly or through (a) correspondent(s), to the financial institution of the beneficiary customer.
It is used to convey a funds transfer instruction in which the ordering customer or the beneficiary customer, or both, are non-financial institutions from the perspective of the Sender.
This message may only be used for clean payment instructions. It must not be used to advise the remitting bank of a payment for a clean, for example, cheque, collection, nor to provide the cover for a transaction whose completion was advised separately, for example, via an MT 400.
Платежи stp и «ручная доработка» денежных переводов в иностранных банках
«Международные банковские операции», 2011, N 1
Как правило, платежные инструкции, посылаемые в иностранный банк, в достаточной степени формализованы и заложены в стандарты SWIFT. И, хотя любой алгоритм обработки строится в целом в соответствии с этими стандартами, конкретные реализации могут различаться. Причины могут быть разными: от различного представления о качестве сервиса для клиентов до использования разных расчетных систем, форматы сообщений в которых могут отличаться от стандартов SWIFT.
Решение такой задачи можно разложить на несколько составляющих:
Вторая часть этого процесса, выбор способа перевода (если не рассматривать частный случай, когда полученные платежные инструкции сводятся к распоряжению кредитовать некий счет на балансе получателя этих инструкций), определяется валютой платежа: получатель платежных инструкций просто перенаправит их в банк или платежную систему, которые являются для него основными корреспондентами для выполнения переводов в заданной валюте. Таким образом, задача системы обработки заключается в распознавании адресата перевода и форматировании исходящих платежных инструкций в соответствии с теми требованиями, которые предъявляют к банку его корреспонденты, будь то банки или расчетные системы.
Решение этой задачи требует выполнения нескольких очевидных условий, которые можно считать основными принципами, положенными в основу STP:
Идентификация банка, в который необходимо направить средства
Как следствие, возникает задача выбора универсального идентификатора банка, который можно было бы использовать независимо от того, через какие расчетные системы или банки будет проходить перевод.
Использование почтового идентификатора в качестве эквивалента номера счета имеет и еще один недостаток, связанный уже с определенной бессистемностью его использования банками. Нередко банк регистрирует несколько кодов для своих не только филиалов или отделений в одном городе, но и отдельных подразделений, то есть многие коды BIC являются действительно всего лишь почтовыми адресами в сети SWIFT, которые не относятся ни к каким счетам банка. По существу, это означает, что использования только BIC Directory в общем случае недостаточно для формирования перевода, нужна дополнительная информация о том, какие именно коды являются идентификаторами корреспондентских счетов банков.
Полнота платежных инструкций
Значительная часть переводов требует использования на одном из этапов какой-либо расчетной системы; соответственно, цепочка платежа в данном платежном поручении должна начинаться с участника такой расчетной системы, который уже будет кредитовать счет банка бенефициара или его корреспондента. Любая расчетная система будет требовать явного указания ее участника; любой ее участник будет требовать явного указания банка или конечного бенефициара, счет которого он должен будет кредитовать.
Здесь необходимо подчеркнуть, что для платежных поручений, поступающих из расчетных систем, допустимым способом дальнейшего перевода считается только кредитование счета на балансе банка, получившего платежные инструкции. Если такой способ невозможен, перевод возвращается. С другой стороны, аналогичное по сути платежное поручение, содержащее инструкцию отправить средства в некий произвольный для получателя этих инструкций банк, но поступившее от банка-корреспондента, может рассматриваться как распоряжение выполнить перевод в указанный банк любым удобным способом; такие платежные поручения нередко выполняются.
Отсюда следует основное правило формирования платежных поручений: построение цепочки перевода, начинающейся с банка бенефициара, должно завершаться либо банком, в который направляется платежное поручение, либо банком, расположенным в стране происхождения валюты платежа, и банки, входящие в цепочку, должны быть связаны друг с другом корреспондентскими счетами в валюте платежа. Это правило неявно предполагает, что любой банк, расположенный в стране происхождения валюты, подключен к соответствующей расчетной системе и, соответственно, любой другой банк, расположенный в той же стране, который будет выполнять готовящееся платежное поручение, сможет отправить средства в указанный банк с использованием такой расчетной системы. Разумеется, из каждого правила теоретически могут быть исключения, но банки, оказывающие стандартные расчетные услуги своим корреспондентам, к таким исключениям не относятся.
Если платежное поручение направляется в банк, который расположен за пределами страны происхождения валюты, то оно, как правило, без изменений пересылается далее в следующий банк-корреспондент по выбору этого банка до тех пор, пока не попадет в банк, подключенный к необходимой расчетной системе.
Указание участников перевода средств в отдельных полях
Разделение платежного поручения на последовательность полей, содержащих цепочку платежа, призвано обеспечить однозначность процесса идентификации банка. Указание двух банков (или филиалов) в одном поле фактически означает необходимость выбора для перечисления средств одного из двух формально равноправных счетов. Различные вспомогательные инструкции типа «для дальнейшего зачисления на счет» могут обрабатываться только вручную.
Между тем в реальной практике расчетов, в первую очередь в долларах США (впрочем, практически исключительно в этом случае), цепочка платежа, которую необходимо указать в платежном поручении (в соответствии с принципами, изложенными в разделе «Полнота платежных инструкций»), достаточно часто состоит из трех банков (один из которых зачастую всего лишь филиал предыдущего, но это в общем случае дела не меняет). Цепочки из большего числа банков встречаются довольно редко, но и трех банков достаточно, чтобы принципы автоматической обработки переводов, заложенные в стандарты SWIFT, уже не работали на протяжении всей цепочки платежа.
Использование IBAN
При формировании МТ103 поле 72 используется на практике главным образом для указания филиала банка бенефициара или его адреса, во-первых, в случаях, когда такой филиал является третьим банком в цепочке перевода (после своей головной конторы и ее корреспондента), и, во-вторых, в тех случаях, когда этот филиал либо не имеет своего BIC, либо определить этот BIC по указанному адресу затруднительно, вследствие чего в качестве однозначного идентификатора банка приходится использовать в поле 57А BIC его головной конторы.
В задачу данной статьи не входит подробный рассказ о структуре IBAN; всю текущую информацию об этом стандарте можно найти на официальном сайте ECBS, Европейского комитета по банковским стандартам (http://www.ecbs.org).
Введение IBAN теоретически позволяет обойтись в платежном поручении вообще без явного указания банка бенефициара, поскольку вся информация о нем содержится внутри IBAN; однако в настоящее время нормативные документы ЕС требуют, чтобы банк бенефициара был указан явно. Одно из следствий избыточности информации о банке бенефициара при наличии IBAN: многие европейские банки рассматривают сам факт наличия поля 72 при переводах евро в качестве основания для ручной доработки и взятия дополнительной комиссии вместо того, чтобы закладывать какие-либо алгоритмы обработки этого поля в свои системы автоматической обработки.
Это относится не ко всем банкам, как минимум некоторые допускают использование поля 72. Однако при наличии IBAN целесообразно минимизировать использование поля 72, для того чтобы максимально уменьшить вероятность ручной доработки переводов и тем самым ускорить их обработку на всех этапах. Это относится к переводам в любых валютах, не только в евро.
При использовании IBAN возникает еще один практический вопрос: необходимо ли указывать в поле 57А BIC именно того филиала, банковский код которого входит в IBAN, или достаточно указать BIC головной конторы, которая уже сама на основании кода в IBAN перечислит средства в необходимый свой филиал? Проблема актуальна не только потому, что во многих случаях требуемый филиал просто не имеет своего BIC, но и потому, что зачастую по представленным клиентом реквизитам определить точный BIC филиала затруднительно, справочников национальных банковских кодов нередко под руками нет.
Практика работы через VTB Bank (Deutschland) AG показывает следующее: если в поле 57А указан BIC головной конторы немецкого банка и ее BLZ не соответствует включенному в IBAN, то перевод попадает на ручную доработку. Если же перевод направляется за пределы Германии, то аналогичные расхождения не контролируются и перевод обрабатывается как STP. Возможное объяснение очевидно: перевод в пределах Германии отправляется через RTGS+ непосредственно в нужный филиал банка бенефициара, соответственно, необходима коррекция указанного в МТ103 кода. Для перевода же за пределы Германии VTB Bank (Deutschland) AG обычно использует сеть своих корреспондентов, взимая дополнительную комиссию, включающую в себя их усредненные расходы. Можно предположить, что расходы на доработку переводов, которую при необходимости должны будут проводить его корреспонденты, также включены в эту комиссию.
Вышесказанное призвано в первую очередь проиллюстрировать тот факт, что каждый банк работает в своих условиях и по своим методикам и степень необходимого контроля платежных реквизитов определяется этими условиями работы, которые, к сожалению, обычно не видны со стороны. Общедоступные правила STP, которые отдельные банки публикуют на своих сайтах, как правило, ограничиваются указаниями использовать только опцию A в соответствующих полях без указания, насколько точной должна быть такая адресация. Таким образом, указание BIC головной конторы вместо BIC филиала, обслуживающего бенефициара, может быть допустимо, но в общем случае может зависеть от правил, устанавливаемых банком-корреспондентом.
Стандартизация STP
В связи с этим актуальной становится стандартизация платежных поручений, удовлетворяющих типовым требованиям STP, как отдельной категории сообщений, пусть и с ограниченными возможностями, но обеспечивающими эффективную обработку большинства стандартных переводов.
В качестве примера стандарта платежного поручения, предназначенного для STP, можно привести МТ103+, сокращенный вариант базового МТ103. Сокращения коснулись тех полей и кодовых слов, которые заведомо должны вызывать ручную обработку перевода. Большая часть отброшенных полей и кодов в обычной практике не используется.
Если вернуться к основным принципам STP, перечисленным выше, можно отметить, что одно лишь ограничение на указание банков с помощью только BIC уже обеспечивает выполнение немалой их части. Открытыми остаются вопросы распознаваемости BIC системами обработки и полноты цепочки платежа.
Однако возможности МТ103+ явно недостаточны для обеспечения переводов в долларах США. Во-первых, для таких переводов достаточно характерны цепочки платежа из трех или даже большего числа банков; в ряде случаев банки могут не иметь BIC; наконец, использование американских расчетных систем CHIPS и Fedwire тоже вносит свои особенности. В связи с этим задача разработки если не нового стандарта, то по крайней мере стандартных приемов оформления МТ103, обеспечивающих STP, представляется актуальной.
В первую очередь необходимо отметить основные особенности обработки платежных поручений в зарубежных банках и расчетных системах, которые так или иначе могут влиять на выбор рекомендаций. Наибольший практический интерес представляют здесь некоторые особенности работы основных американских расчетных систем, CHIPS и Fedwire; многие требования, предъявляемые банками к оформлению платежных поручений в долларах США, так или иначе вытекают из этих особенностей.
Преобразование платежных поручений в расчетных системах
Как отмечалось в начале статьи, в данном изложении предполагается использование SWIFT для пересылки платежных поручений между банками, что позволяет не рассматривать вопросы преобразования платежных поручений при их пересылке. Однако при расчетах в долларах США значительная часть переводов осуществляется с использованием американских расчетных систем, CHIPS или Fedwire, и здесь указанное предположение некорректно; при таких переводах могут возникать некоторые проблемы, связанные с необходимостью преобразования сообщений SWIFT в сообщения CHIPS или Fedwire и обратно. При расчетах в евро подобные вопросы не возникают в силу того, что значительная часть европейских расчетных систем построена на платформе SWIFT (которая, в свою очередь, является европейской разработкой, учитывающей в первую очередь европейские представления о методике расчетов).
Далее будут отмечены только те особенности форматов CHIPS и Fedwire, которые нередко приводят к заметным искажениям передаваемой информации, а иногда и к задержкам в обработке переводов на том или ином этапе.
Преобразования в CHIPS
Основными особенностями формата сообщений CHIPS, влияющими на конечный результат обработки перевода, являются:
После перехода к МТ103 американские банки стали включать в формируемые ими сообщения CHIPS информацию об указателях расходов, списанных комиссиях и изначально отправленных суммах (информацию из полей 33B, 71A и 71F получаемых ими МТ103) как текстовую информацию в поле 600 сообщений CHIPS, то есть как часть деталей платежа. Фрагмент одного такого сообщения приведен ниже:
Видно, что к деталям платежа просто добавлено содержимое полей исходного МТ103. Комиссия самого американского банка, равная 20 USD, явно не отражена, о ее существовании и величине можно лишь догадываться, исходя из имеющихся данных.
В данном случае задача определения суммы комиссии и ее источника проста, так как было известно содержание отправленного американскому корреспонденту МТ103. Сложнее обстоит дело с получаемыми из американских банков МТ103, поскольку в этих случаях, на основании только таких МТ103, не всегда можно определить точный и полный путь платежа, да и тарифы участвовавших в процессе банков обычно неизвестны. Более того, приходится учитывать, что в общем случае неизвестны ни алгоритмы переводов информации из исходных МТ103 в сообщения CHIPS американскими банками, ни алгоритмы считывания этой информации и перевода ее в конечные МТ103 участниками CHIPS, получающими эти сообщения. Некоторые примеры МТ103, полученных из американских банков, приведены в табл. 1.
Примеры сообщений МТ103, полученных из американских банков
Эти примеры демонстрируют несоответствие реальных МТ103, получаемых из американских банков, формальным правилам SWIFT: суммы указанных комиссий, даже с учетом тех, которые отражены в не предназначенных для этого полях, не всегда равны разности сумм, указанных в полях 33B и 32A. Из них, однако, можно по крайней мере догадаться, какая сумма была отправлена изначально.
Следующий пример МТ103, полученного из VTB Bank (Deutschland) AG, показывает, что в процессе переработки платежного поручения американскими банками информация о первоначально отправленной сумме может пропасть безвозвратно:
Указанная здесь комиссия в 10 USD является комиссией VTB Bank (Deutschland) AG, комиссия его американского корреспондента (в данном случае Citibank, NA) списывается со счета этого банка и на сумму перевода не влияет. Первоначально же отправленная сумма была равна 5000 USD, указатель расходов в исходном МТ103 был OUR. В данном случае 15 USD являлись комиссией American Express Bank Ltd., корреспондента Investbank PLC, списанной на основании соглашения типа bene deduct, но вся информация об этом в итоге пропала.
В полях платежных поручений SWIFT (MT103, MT202 и т.д.) предусмотрена возможность указания банков с помощью BIC и различных цифровых кодов одновременно. Для переводов, которые должны выполняться через CHIPS, в качестве таких идентификаторов могут использоваться номера корреспондентских счетов банков, коды участников (//CP) и UID (//CH).
Исходя из того что вероятность ошибки при вводе числового кода выше, чем при вводе BIC, обычно рекомендуется указывать банк с помощью только BIC. Однако такой подход в некоторых частных случаях вызывает проблемы.
Рассмотрим частный случай, который тем не менее демонстрирует реальное состояние нынешних систем обработки платежных поручений в ведущих мировых банках; состояние, надо отметить, несколько неожиданное.
В настоящее время многие небольшие российские банки вынуждены проводить расчеты в долларах США через свои корреспондентские счета в российских или европейских банках, поскольку открыть счет в американском банке достаточно сложно. Наиболее популярные среди них европейские банки-корреспонденты, такие как, например, VTB Bank (Deutschland) AG, имеют достаточно высокий уровень автоматизации, и априори такие расчеты не должны вызывать особых проблем, за исключением разве что относительно раннего времени отсечения и почти неизбежно возникающей ручной обработки МТ103 по переводам в пользу клиентов российских банков, поскольку в первоначальных МТ103 российский банк в большинстве случаев, при стандартных методиках форматирования, будет размещаться в поле 72.
Тем не менее на практике довольно часто отмечалось, что не только коммерческие, но и межбанковские переводы в пользу российских банков попадают на ручную доработку в европейских банках-корреспондентах.
Потеря нескольких часов иногда бывает заметной. Анализ нескольких таких случаев обнаружил неожиданное.
Переводы в адрес российских банков оформлялись в полном соответствии со стандартными рекомендациями, например:
На практике, однако, OWHBDEFF нередко получал MT202, в которых бенефициар указывался в поле 58 с опцией D вместо опции A. Несколько различных примеров таких MT202 приведены в табл. 2 (сохранены только поля 58D).
Примеры заполнения поля 58D в сообщениях MT202
Таких примеров набралось достаточно много, причем способ заполнения поля 58D явно зависел от того, через какую именно пару американских банков поступали средства в OWHBDEFF; по одному и тому же маршруту из раза в раз получался один и тот же вариант.
В результате проведенных переговоров как минимум один американский банк признал, что в его системе действительно существуют ошибки при формировании сообщения CHIPS в тех случаях, когда для BIC невозможно найти UID (т.е., проще говоря, когда указанный банк не имеет счета ни в одном из американских банков). Источник ошибки явно связан с историей развития CHIPS: видимо, система обработки создавалась во времена, когда UID был основным идентификатором; BIC, вероятно, появился в качестве допустимого позднее. У автора, к сожалению, нет возможности проследить в подробностях всю историю развития CHIPS. Имеющиеся обрывочные данные позволяют, однако, предположить, что по крайней мере в 1995 г. BIC уже был стандартизован в CHIPS в качестве допустимого идентификатора.
Решение задачи очевидно уже из вида вышеприведенных МТ202: необходимо в исходном МТ202 предоставить американским банкам информацию, которую их системы могли бы автоматически подставить в поле числового идентификатора так, чтобы в итоге был получен корректный результат, то есть явно указать номер корреспондентского счета MEZTRUMM в OWHBDEFF. И проблема действительно исчезает.
Преобразования в Fedwire
Fedwire обычно используется, если перевод направляется в пользу клиента американского банка. Такие переводы относятся к простейшим, и проблемам здесь возникать просто неоткуда. Переводы за пределы США с помощью Fedwire выполняются крайне редко, хотя время от времени встречаются рекомендации использовать именно Fedwire для выполнения крупных межбанковских переводов.
Здесь следует отметить, что механизм разделения переводов в Fedwire на коммерческие и межбанковские не совсем ясен. С одной стороны, в сообщениях Fedwire предусмотрено поле 3600 (Business Function), в котором можно явно указать код перевода, который может принимать в числе прочих значения CTR (коммерческий перевод) или BTR (межбанковский перевод). С другой стороны, есть поле 1510 (Type Code, Subtype Code), в котором Type Code может принимать значения 10 (перевод, отправитель и получатель которого могут быть третьими сторонами), 15 (так называемый Foreign Transfer, перевод от или в пользу зарубежных центральных банков и других международных учреждений, счета которых находятся в ФРБ Нью-Йорка) или 16 (так называемый Settlement Transfer, перевод, отправитель и получатель которого либо (1) депозитарный институт, являющийся субъектом требований к резервам, либо (2) участник соглашения об урегулировании требований, который признается ФРС). При этом согласно Fedwire Reference Card значение BTR может относиться только к переводам, тип которых 15 или 16. Из приведенных здесь описаний видно, что межбанковские переводы российских банков друг другу или зарубежным контрагентам в огромном большинстве случаев должны иметь тип 10 и, следовательно, код CTR, то есть обозначаться в Fedwire как коммерческие переводы.