"Расчеты и операционная работа в коммерческом банке", 2007, N 2

РАССЛЕДОВАНИЯ ПО ПЕРЕВОДАМ

В предлагаемой статье рассматриваются методы так называемых расследований по переводам (Money Transfer Investigations), то есть методы ведения разнообразной дополнительной переписки, которой приходится время от времени заниматься в связи с ошибками или неточностями в оформлении или выполнении переводов.

Введение

Расследования по переводам, вероятно, наименее стандартизируемая часть безналичных расчетов. Едва ли стоит пытаться создать универсальное руководство на все возможные случаи. Задачей данной статьи является изложение основных правил, которыми рекомендуется руководствоваться. Даже в совершенно нестандартных и, казалось бы, совершенно безвыходных ситуациях следование общим принципам нередко дает нужные результаты. Наконец, помимо доведения до конца отдельных переводов задачей расследований должны быть выявление типичных ошибок при проведении расчетов и разработка методов их устранения или хотя бы минимизации.

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

1. Основные причины расследований

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

Итак, во-первых, расследования по переводам составили около 42%, по поступлениям - соответственно около 58% от общего их числа. Отметим сразу, что в рассматривавшийся период (более двух лет) были отмечены ошибки только по коммерческим переводам, поэтому далее это подчеркиваться не будет. Эти цифры, однако, не в полной мере характеризуют относительный уровень проблем, поскольку общее число выполненных за рассматривавшийся период времени переводов превысило общее число поступлений более чем вдвое. Таким образом, переводы, по которым возникала переписка, составили 0,53% от общего числа переводов, а поступления с перепиской - 1,59% от общего числа поступлений.

1.1. Основные причины расследований по переводам

Из таблицы 1 видно, что основной причиной возникающей переписки являются ошибки клиента в заявлениях на перевод (п. п. 1, 2 и 3, которые в сумме дали около 64% всех ошибок). С одной стороны, эта часть ошибок является неизбежным злом. С другой стороны, ошибок, связанных с неверным счетом получателя, могло бы быть и больше: приведенные наблюдения относятся к периоду 2004 - 2006 гг., когда в Европе практически повсеместно уже произошел переход к IBAN, а в системе подготовки переводов рассматриваемого банка был реализован автоматический контроллер, который прерывал обработку перевода в случае ввода неверного IBAN. Статистика таких прерываний не велась, поэтому невозможно оценить, на сколько изменились бы приведенные в таблице цифры, но ошибки клиентов при указании IBAN отмечались неоднократно и практически всегда исправлялись до отправки перевода.

Таблица 1

     
   ——T—————————————————————————————————————————————T—————————————————
   

N¦ Причина возникновения расследования ¦ Процент

¦ ¦(в целых числах)

     
   ——+—————————————————————————————————————————————+—————————————————
   

1¦Ошибки клиента в исходных инструкциях: ¦ 38

¦неверное имя или неверный номер счета ¦

¦бенефициара, неверно указанное назначение ¦

¦платежа и другие подобные ошибки, которые ¦

¦банк не может предвидеть в процессе ¦

¦подготовки перевода ¦

     
   ——+—————————————————————————————————————————————+—————————————————
   

2¦Запросы, связанные с якобы неточными ¦ 16

¦реквизитами или непоступлением средств ¦

¦бенефициару, которые в итоге урегулировались ¦

¦без вмешательства банка ¦

     
   ——+—————————————————————————————————————————————+—————————————————
   

3¦Отмены переводов по просьбе отправителя ¦ 10

     
   ——+—————————————————————————————————————————————+—————————————————
   

4¦Различные случайные технические ошибки ¦ 10

     
   ——+—————————————————————————————————————————————+—————————————————
   

5¦Ошибки форматирования, которые можно было ¦ 7

¦предвидеть (включая неверный выбор ¦

¦посредника) ¦

     
   ——+—————————————————————————————————————————————+—————————————————
   

6¦Уточнения, связанные с требованиями ¦ 3

¦законодательства в стране получателя ¦

     
   ——+—————————————————————————————————————————————+—————————————————
   

7¦Прочее ¦ 13

     
   ——+—————————————————————————————————————————————+—————————————————
   

Отдельно можно отметить п. 5, в котором сведены различные ошибки, связанные с неверным выбором посредника, неверным указанием номера корреспондентского счета банка получателя и т.д. Часть этих ошибок была связана с особенностями технологического процесса подготовки переводов в данном банке, и рассматривать эти особенности в узких рамках темы расследований будет некорректно. Отметим лишь, что среди этих ошибок была отмечена одна ошибка выбора посредника для перевода в USD; вскоре после этого, в начале 2004 г., в банке была внедрена система автоматического контроля выбора посредника по базе данных CHIPS, что позволило практически полностью исключить такие ошибки. Теоретически эта база данных не решает проблему полностью, но, как будет показано ниже, позволяет существенно снизить брак.

Остальные отмеченные ошибки носили в целом случайный характер; появление подобных ошибок неизбежно в реальной работе. Например, среди технических ошибок (п. 4) отмечались: сбой ключей SWIFT в банке-корреспонденте, который привел к задержке перевода на день; искажение по неизвестной причине на каком-то этапе перевода длинного имени получателя; неверное указание банком-корреспондентом связанной ссылки (REF) в поле 21 межбанковского перевода.

Уточнения, вызванные требованиями законодательства страны получателя (п. 6), в рассматривавшемся примере относились исключительно к переводам в UAH, когда по требованию украинского корреспондента приходилось, например, уточнять, каким именно видом транспорта осуществлялись грузовые перевозки, за которые шла оплата. При большом количестве соответствующих операций часть таких ошибок можно исключить за счет накапливаемого опыта, но при малом количестве подобные проблемы неизбежны.

1.2. Основные причины расследований по поступлениям

Как ни удивительно, но большинство ошибок в отмеченном примере можно считать чисто техническими: п. п. 1, 2 и 4, в сумме дающие около 58% всех проблем, содержат ошибки, которых вроде бы просто не должно быть при правильной организации работы. В частности, в п. 1 сведены попытки выполнения переводов с покрытием при отсутствии двусторонних ключей; переводы, в которых MT103 отправлялось в один банк, а средства с помощью MT202 - в другой банк той же цепочки перевода. Ошибки, указанные в п. 4, можно практически полностью исключить, организовав контроль цепочки платежа с помощью базы CHIPS.

Отметим, что ошибок, указанных в п. п. 2 и 3, могло бы быть зарегистрировано и больше, поскольку во многих случаях - когда это признавалось возможным исходя из обстоятельств - зачисления проводились по формально неполным реквизитам.

Таблица 2

     
   ——T—————————————————————————————————————————————T—————————————————
   

N¦ Причина возникновения расследования ¦ Процент

¦ ¦(в целых числах)

     
   ——+—————————————————————————————————————————————+—————————————————
   

1¦Неверное выполнение перевода с покрытием ¦ 22

     
   ——+—————————————————————————————————————————————+—————————————————
   

2¦"Лоро"-корреспондент не указан, ошибки ¦ 19

¦форматирования при длинной цепочке перевода ¦

     
   ——+—————————————————————————————————————————————+—————————————————
   

3¦Неверный счет или неверное имя получателя, ¦ 18

¦неверное назначение платежа ¦

     
   ——+—————————————————————————————————————————————+—————————————————
   

4¦Счет банка в американском банке- ¦ 18

¦корреспонденте закрыт ¦

     
   ——+—————————————————————————————————————————————+—————————————————
   

5¦Запрос о непоступлении средств получателю ¦ 6

     
   ——+—————————————————————————————————————————————+—————————————————
   

6¦Прочее ¦ 11

     
   ——+—————————————————————————————————————————————+—————————————————
   

2. Общие принципы составления запросов

Запрос по переводу или уточнение реквизитов должны в первую очередь содержать информацию, которая позволяла бы получателю сообщения быстро и однозначно определить, о каком переводе идет речь. Формально для этого достаточно указать уникальный ссылочный номер перевода (REF). Если запрос обрабатывается автоматически (некоторые банки разработали системы такой обработки для различных вариантов стандартных запросов), этого действительно достаточно, нужно только сформатировать сообщение в соответствии с требованиями такой системы обработки. Однако в большинстве случаев приходится учитывать, что сообщение будет обрабатываться вручную. И в этом случае целесообразно включить в текст запроса помимо REF перевода (причем, если запрос касается своего перевода, стоит указать не только свой REF, но и REF корреспондента) достаточно подробное описание самого перевода, включая его сумму, отправителя и всю цепочку дальнейшего платежа, содержавшуюся в исходных инструкциях. Такой текст в большинстве случаев позволит сотруднику, который будет обрабатывать этот запрос, сразу представить себе суть проблемы и свои дальнейшие действия. Разумеется, при идеальной системе обработки сообщений можно по одному только REF быстро вывести на экран всю информацию об этой операции - однако заранее неизвестно, насколько близка к идеалу система адресата...

Стоит отметить среди банков, наиболее полно следующих такому стилю составления запросов и ответов, Bank of New York, который по качеству работы с запросами можно считать одним из лучших банков в мире.

В таблице 3 приведены два примера запроса, составленные на основе одного и того же перевода. Подчеркнем, что эти примеры относятся к случаю, когда запрос отправляется не в банк-корреспондент, со счета в котором был отправлен перевод, а в банк-посредник. Поэтому в качестве уникального идентификатора перевода был выбран не свой REF (хотя в первом варианте этот параметр и цитируется) и не REF адресата, который не был известен в момент отправки запроса, а CHIPS SSN - параметр, известный из выписки, полученной от корреспондента, который должен быть известен и адресату запроса, который в свое время получил перевод по CHIPS именно с указанным значением SSN.

Таблица 3

     
   ——————————————————————————————————————T——————————————————————————————————————
   

Сообщение в формате MT199, ¦ Сообщение в формате MT199,

сформированное с помощью системы ¦ сформированное вручную

подготовки запросов ¦

     
   ——————————————————————————————————————+——————————————————————————————————————
   

:20:MINV030515010603 ¦:20:MINV030515010603

:21:NONREF ¦:21:NONREF

:79:ATTN MT INVESTIGATIONS ¦:79:ATTN MT INVESTIGATIONS

RE OUR TRANSFER THRU ABNAUS33 FOR ¦RE OUR TRANSFER THRU ABNAUS33 FOR

1000.00 USD VALUE 030515 ¦1000.00 USD VALUE 030515 B/O RUSSIAN

AS FOLLOWS. QUOTE ¦TRADE COMPANY, MOSCOW, F/O PKOPPLPW

:20:MTRN050510123400 ¦FOR FURTHER CREDIT

32A:050510USD10000, ¦ACC.12345678901234567890 POLISH TRADE

50:RUSSIAN TRADE COMPANY ¦COMPANY, KRAKOW,

MOSCOW, RUSSIAN FEDERATION ¦WITH PKOPPLPWKR1, KRAKOW BRANCH

56A://CP0001 ¦CHIPS SSN 0123456.

IRVTUS3N ¦PLS BE ADVISED THAT THE PAYEE BANK IS

57A://CH200166 ¦UNABLE TO LOCATE OUR TRANSFER. SO PLS

PKOPPLPW ¦CONFIRM US YR CREDIT AN ACCOUNT OF

59:/12345678901234567890 ¦BANK PEKAO SA STATING YR REF FOR THIS

POLISH TRADE COMPANY ¦OPERATION IN ORDER TO INVESTIGATE THE

KRAKOW, POLAND ¦MATTER.

70:CONTRACT N1 DD 030301 ADD AGR.1 ¦THANKS IN ADVANCE.

DD 030401 INV 123 DD 050506 ¦REGARDS, VLADIMIR KOPALOV, FUNDS

71A:OUR ¦TRANSFER DEPT.

72:/ACC/FOR BIC:PKOPPLPWKR1, YR ¦

//KRAKOW BRANCH ¦

UNQUOTE. ¦

CHIPS SSN 0123456. ¦

PLS BE ADVISED THAT THE PAYEE BANK IS¦

UNABLE TO LOCATE OUR TRANSFER. SO PLS¦

CONFIRM US YR CREDIT AN ACCOUNT OF ¦

BANK PEKAO SA STATING YR REF FOR THIS¦

OPERATION IN ORDER TO INVESTIGATE ¦

THE MATTER. ¦

THANKS IN ADVANCE. ¦

REGARDS, VLADIMIR KOPALOV, FUNDS ¦

TRANSFER DEPT. ¦

     
   ——————————————————————————————————————+——————————————————————————————————————
   

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

Второй основной принцип, которым следуют руководствоваться при составлении запросов и ответов, - выделение, подчеркивание, повторение и т.д. ключевых фраз, которые могут быть распоряжениями или, напротив, запретами на проведение каких-либо операций по счету (например, возвратов полученных сумм). Подробно этот принцип будет иллюстрироваться далее, здесь же следует лишний раз подчеркнуть, что практика, к сожалению, показывает, что иногда письма читаются не настолько внимательно, как хотелось бы.

2.1. Выбор адресата для запроса

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

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

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

2.2. Форматы сообщений для запросов и ответов на запросы

Вышеприведенные примеры демонстрируют только стиль, но не формат запросов. Для обеспечения возможности автоматизации обработки запросов SWIFT разработал несколько специализированных форматов: MTn92 - для отзыва сообщения, MTn95 - для запроса по ранее отправленному сообщению, MTn96 - для ответа на запрос. (Далее в этой статье сообщения этих типов будут обобщенно называться запросами; при необходимости конкретизации будет указываться определенный тип сообщения.) Подробное описание этих форматов изложено в Руководстве пользователя SWIFT, здесь приведем в качестве иллюстрации пример MT195 (табл. 4).

Таблица 4

     
   ——————————————————————————————————————T——————————————————————————————————————
   

MT195 без кода для автоматической ¦ MT195 с кодом для автоматической

обработки запроса ¦ обработки запроса

     
   ——————————————————————————————————————+——————————————————————————————————————
   

:20:MINV020701009601 ¦:20:MINV020701009601

:21:MDIR020625032500 ¦:21:MDIR020625032500

:75:PLS BE ADVISED THAT THE REMITTER ¦:75:/3/

CLAIMS NON-RECEIPT. PLS CONFIRM US ¦:77A:PLS BE ADVISED THAT THE REMITTER

DATE OF CREDIT THE BENEFICIARY. ¦CLAIMS NON-RECEIPT. PLS CONFIRM US

REGARDS, V.KOPALOV, FTD ¦DATE OF CREDIT THE BENEFICIARY.

:11S:103 ¦REGARDS, V.KOPALOV, FTD

020625 ¦:11S:103

:20:MDIR020625032500 ¦020625

:23B:CRED ¦:20:MDIR020625032500

:32A:020625USD50000,00 ¦:23B:CRED

:50:/40702840100000000001 ¦:32A:020625USD50000,00

RUSSIAN TRADE COMPANY ¦:50:/40702840100000000001

MOSCOW, RUSSIAN FEDERATION ¦RUSSIAN TRADE COMPANY

:52A:AAAARUMM ¦MOSCOW, RUSSIAN FEDERATION

:53A:ABNAUS33 ¦:52A:AAAARUMM

:54A://CP0103 ¦:53A:ABNAUS33

BKTRUS33 ¦:54A://CP0103

:59:/1234567890 ¦BKTRUS33

SINGAPORE TRADE COMPANY ¦:59:/1234567890

SINGAPORE, SINGAPORE ¦SINGAPORE TRADE COMPANY

:70:PYMT FOR CONTRACT DD ¦SINGAPORE, SINGAPORE

10.05.2002 ¦:70:PYMT FOR CONTRACT DD

¦10.05.2002

     
   ——————————————————————————————————————+——————————————————————————————————————
   

В основу всех специализированных запросов положены два принципа:

1) включение в состав запроса элементов, позволяющих - по крайней мере в принципе - в автоматическом режиме не только однозначно идентифицировать сообщение, к которому относится данный запрос (связанный REF в поле 21, а также поле 11, которое на первый взгляд является избыточным и необязательным, но разработчики стандартов явно не полагаются на то, что все банки в состоянии обеспечить уникальность REF для отправляемых ими сообщений, и их примеру целесообразно на всякий случай следовать и включать поле 11 в свои запросы), но и произвести определенные действия (код /3/ в поле 75 в правом примере);

2) включение в состав запроса полного текста сообщения, к которому относится запрос, то есть одновременно реализуется описанный выше принцип: "текст в большинстве случаев позволит сотруднику, который будет обрабатывать этот запрос, сразу представить себе суть проблемы и свои дальнейшие действия".

Таким образом, структура запросов максимально учитывает все возможные варианты обработки запроса в банке, который его получает: если в этом банке есть автоматизированная система обработки - в запросе содержатся средства доступа к этой системе; нет такой системы - в запросе содержится все необходимое для эффективной ручной обработки.

Но нет добра без худа. Замечательная структура запроса на порядок сложнее MTn99, поэтому при ручной подготовке запроса, как правило, используется именно MTn99. И если оценить число сообщений специализированных типов во всей переписке по поводу переводов-поступлений, то напрашивается вывод о том, что сколько-нибудь автоматизированных систем подготовки запросов в банках не так уж много. В частности, среди полученных по разным поводам и зарегистрированных в переписке по расследованиям сообщений из самых разных банков оказалось только 6% специализированных запросов, остальные 94% представляли собой обычные сообщения свободного формата MTn99.

Более того, реализуемые банками системы обработки запросов совсем не обязательно ориентированы на обработку тех типов сообщений, которые предлагает для этой цели SWIFT. В частности, подобная система Bank of New York в конце 1990-х годов (ссылка на годы здесь подчеркивает, что в настоящее время эта система может быть уже другой: жизнь может и не стоять на месте...) успешно обрабатывала некоторые запросы в чрезвычайно простом формате, аналогичном MT199 (данная обтекаемая формулировка означает, что доступ к данной системе обеспечивался не только с помощью SWIFT, но и с помощью MicroCASH Register, системы типа "банк - клиент"). Необходимый перевод идентифицировался по связанному REF, необходимое действие - по символьному коду в поле 79. Система была предназначена для обработки большинства стандартных запросов. Например, с ее помощью можно было направить в банк получателя стандартный запрос подтверждения поступления средств бенефициару.

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

В общем случае при отсутствии какой-либо информации о возможной системе обработки у адресата запрос - в любом формате: MTn92, MTn95, MTn96 или MTn99 - следует рассматривать как предназначенный для ручной обработки. Но если уж использовать стандартные формы, то, разумеется, желательно в строгом соответствии с правилами SWIFT: а вдруг система обработки есть и настроена именно под эти правила? По крайней мере в условиях неопределенности более разумного предположения сделать нельзя.

3. Проведение расследований в типичных ситуациях

В данном разделе будут подробно рассматриваться типичные ситуации, вызывающие необходимость переписки, возможные варианты поведения, которые могут повысить эффективность процесса в целом, а также, по мере возможности, общие методы профилактики таких ситуаций. Разумеется, все возможные случаи описать невозможно; согласно Льву Толстому "каждая несчастливая семья несчастлива по-своему". Тем не менее опыт обработки относительно стандартных ситуаций помогает проще ориентироваться и в нестандартных ситуациях.

В первую очередь рассмотрим те ситуации, которые согласно полученной для частного случая статистике (см. разд. 1.1) встречаются чаще всего.

3.1. Неверный выбор банка-посредника

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

Во-первых, отметим, что все зарегистрированные в приведенном в разд. 1 примере ошибки относились к выбору корреспондента - участника CHIPS, что также не удивительно: такие переводы составляют большую часть расчетов в долларах США, да и приведенная статистика относится к периоду, когда американские банки - сначала ABN AMRO Bank NV, затем Union Bank of California International - активно закрывали счета российским банкам. Как ни предупреждай клиентов заранее, платежные поручения со старыми реквизитами все равно будут время от времени появляться. Такие поручения с давно закрытыми корреспондентскими счетами самых разных банков клиенты, если их явно не предупредить, могут носить в банк годами.

Удивительно другое: наличие общедоступной базы CHIPS в Интернете позволяет свести такие ошибки практически к нулю при реализации элементарных процедур контроля обрабатываемых переводов. Тем не менее, как показывает практика, такие процедуры часто не реализуются ни в банках, отправляющих исходные платежные поручения, ни в американских банках, пересылающих такие переводы по CHIPS на закрытые счета. Хотя, казалось бы, по крайней мере у американцев такой контроль мог бы быть и внедрен - база CHIPS просто обязана быть их основным рабочим инструментом. Видимо, общие принципы организации работы не позволяют самостоятельно вмешиваться в указанные клиентом реквизиты, причем не только не позволяют изменить их на правильные, но даже просто проинформировать отправителя и придержать перевод до уточнений. Но если такие принципы в исполнении американских банков приходится принимать как данность, то нет никаких причин не внедрить соответствующий контроль в своем банке и либо корректировать неверные реквизиты самостоятельно, либо предупреждать отправителя об ошибке заранее, до отправки перевода. Первый принцип эффективнее и при грамотной реализации проблем не вызывает.

В рамках данной статьи не будем останавливаться на методах организации контроля реквизитов по базе CHIPS, отметим лишь, что он может проводиться как минимум вручную по данным официальной базы CHIPS на сайте www.chips.org, однако по-настоящему эффективно такой контроль может быть организован только в автоматическом режиме. База CHIPS в настоящее время доступна в Интернете для скачивания на сайте Deutsche Bank Trust Company Americas (http://rp1.tss.db.com/dbpsg/index.htm).

Как отмечалось в разд. 1.1, такой автоматический контроль позволяет практически полностью устранить неверный выбор посредника, хотя база CHIPS и не является абсолютно точным инструментом, следовательно, вероятность ошибок остается. Но на практике после внедрения этого инструмента собственные ошибки такого рода полностью исчезают, и основной задачей банка становится исправление подобных ошибок, допускаемых другими. Возможность вмешаться возникает в тех случаях, когда какой-либо банк, выполняющий перевод (чаще всего американский корреспондент банка отправителя), использует метод перевода с покрытием и присылает в банк получателя MT103, из содержимого полей 53 и 54 которого видно, что покрытие по данному MT103 отправлено на закрытый счет. В этом случае целесообразно немедленно отправить в банк, приславший такое MT103, краткое сообщение о том, что счет в выбранном для данного перевода корреспонденте закрыт, и сообщить правильные платежные инструкции. Приведем пример такого сообщения (табл. 5).

Таблица 5

     
   ——————————————————————————————————————————————————————————————————
   

MT196 в Deutsche Bank Trust Company Americas, New York

     
   ——————————————————————————————————————————————————————————————————
   

:20:MRPL051101753500

:21:C123456OCP110105

:76:OUR ACC. WITH BOFCUS33NYK IS CLOSED

PLS PAY THRU OWHBDEFF INSTEAD.

REGARDS, V.S.KOPALOV

:11R:103

051101

:20:C123456OCP110105

:23B:CRED

:32A:051101USD6453,00

:33B:USD6470,00

:50K:EUROPEAN TRADE COMPANY

ZURICH, SWITZERLAND

:52A:UBSWCHZH80A

:54A:BOFCUS33NYK

:59:40702840100000000001

RUSSIAN TRADE COMPANY

MOSCOW, RUSSIA

:70:/RFB/CONTRACT N 1

DATED:07-10-2005

:71A:BEN

:71F:USD17,00

:72:/BBI//REC/PLEASE PAY THROUGHBOFCUS3

//3NYK.

     
   ——————————————————————————————————————————————————————————————————
   

Разумеется, банк, получивший такую информацию, в большинстве случаев не успевает остановить перевод покрытия на закрытый счет. Однако исправление ошибки происходит обычно в течение одного-двух дней, то есть достаточно быстро. Если не предупредить, возврат будет инициирован бывшим корреспондентом обычно тоже в течение одного-двух дней, затем средства будут возвращены отправителю, ибо источником ошибки, как правило, являются его устаревшие инструкции. Далее следуют переговоры отправителя и бенефициара, уточнение новых реквизитов и т.д. В общей сложности перевод средств затягивается на неделю-две, не говоря уже о росте суммарных расходов. Конечно, банк бенефициара не обязан вмешиваться в процесс, ибо формально ошибка не его. Но вмешаться стоит как минимум ради улучшения общего качества расчетного обслуживания. Отметим, что все расходы ограничиваются расходами на одно сообщение MT196, никаких комиссий за его обработку никто не выставляет - банк всего лишь информирует о том, что кто-то другой допустил ошибку. Этот подробный анализ простейшей операции был затеян в самом начале статьи главным образом ради того, чтобы подчеркнуть два принципа, которые должны лежать в основе организации всей работы по расследованиям: 1) при расследованиях необходимо анализировать причины возникновения проблем и принимать организационные меры по их устранению или хотя бы минимизации; 2) расследование должно проводиться с максимально возможной оперативностью. Оперативность расследований существенно зависит от автоматизации этого процесса. Нетрудно заметить, что приведенное в последнем примере сообщение по сути крайне простое, несмотря на сравнительно большой объем. Немного найдется желающих сразу после получения MT103 с ошибкой тут же писать такой или даже более короткий ответ вручную - обычно есть более срочные дела. Но, если в системе обработки входящих сообщений предусмотреть кнопку, при нажатии которой генерируется стандартный ответ на некое MT103, вряд ли эта кнопка будет бездействовать. В начале данного раздела подчеркивалось, что проблемы, связанные с ошибочным указанием посредника, будут рассматриваться для переводов в долларах США. Вообще говоря, такие ошибки могут возникать и при переводах в любой другой валюте. Принципиальная разница заключается в отсутствии общедоступной централизованной информации о корреспондентских счетах банков в других валютах, которую можно было бы использовать в автоматическом режиме подобно базе CHIPS. Разумеется, есть разнообразные банковские справочники. Но, во-первых, эта информация платная, во-вторых, эффективность ручного контроля, в общем-то, рутинной информации невысока - нередко она просто не контролируется, особенно если банк-посредник явно указан клиентом. С другой стороны, реальная необходимость явного указания банка-посредника с точки зрения маршрутизации при переводах во всех валютах, кроме долларов США, невелика, да и вынужденно менять, то есть провоцировать проблему, приходится обычно именно корреспондентов по долларам США. Соответственно, при переводах в других валютах рассматриваемая проблема носит по существу теоретический характер. По крайней мере автору на практике сталкиваться с такими ошибками не приходилось. (Продолжение следует) В.С.Копалов Начальник отдела расчетов ОАО "Межтопэнергобанк" Подписано в печать 02.04.2007 ————