Мониторинг

[Aleksa_81]

Мне интересен такой вопрос - очень часто возникает ситуация, когда появляется необходимость произвести оплату за третее лицо согласно письму твоего контрагента или за твою организацию также платят. При этом в платежном поручении указывают - оплата по счету за ООО "Того-то". Но мне многие бухгалтера говорят, что этого нельзя делать и отказываются так платить или принимать такие платежи, говорят, что вообще-то мониторинг никто не отменял. И в некоторых банках службы безопасности не пропускают такие платежи. Так можно так платить или нельзя? И какие в данном случае возникают нарушения?

[Nadia]

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

[Aleksa_81]

Сообщение от Nadia

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

А я ни разу этого не делала? И меня банк ни разу ен просил. Что с этим делать? И разве для налоговой важно, заполнил ты эту анкету или нет?

[Nadia]

"Управление в кредитной организации", 2006, N 6

ЗАДАЧИ ПО АВТОМАТИЗАЦИИ ЗАКОНОДАТЕЛЬНЫХ ТРЕБОВАНИЙ В СФЕРЕ
ПРОТИВОДЕЙСТВИЯ ЛЕГАЛИЗАЦИИ ПРЕСТУПНЫХ ДОХОДОВ:
ПРАКТИЧЕСКИЙ ВЗГЛЯД

Данная публикация содержит тезисы выступления начальника службы финансового мониторинга Европейского трастового банка и члена Комитета Ассоциации российских банков по противодействию легализации доходов, полученных преступным путем, и финансированию терроризма на XII Международном форуме разработчиков интегрированных банковских систем.

В настоящее время мы наблюдаем большие изменения в подходах банков к теме противодействия легализации преступных доходов. Сегодня важно не только формально исполнять требования законодательных и нормативных документов, чтобы не навлечь замечания и претензии со стороны надзорных органов. Более или менее полно эта задача уже решена. Задача сегодняшнего дня - минимизировать банковские риски, исключить вовлечение банка в сомнительные операции. Не допустить ситуации, когда банк, сам того не желая и не ведая, станет звеном какой-либо "серой" схемы. Это очень важно для минимизации правового риска, риска потери деловой репутации.
Во многих банках пришли к пониманию того, что если уж тратить время, средства на ведение внутреннего контроля в целях противодействия легализации преступных доходов, то лучше все организовать таким образом, чтобы результаты можно было использовать уже непосредственно в интересах самого банка, чтобы получать аналитические данные, оптимизировать операции.
И здесь уже формальный подход невозможен, надо творчески и внимательно разрабатывать внутрибанковские критерии и признаки сомнительных, необычных операций.
И, конечно же, при решении таких общих глобальных задач не обойтись без гибкого умного программного обеспечения.
Задачи реализации требований по противодействию легализации преступных доходов становятся существенно шире, требуют больших трудозатрат, и, естественно, банки сейчас очень заинтересованы в новых программных решениях.
Нам бы хотелось вкратце затронуть основные направления работы. На наш взгляд, их пять:
1) идентификация клиентов, установление и идентификация выгодоприобретателей;
2) выявление операций, подлежащих обязательному контролю;
3 выявление необычных, сомнительных операций;
4) контроль отчетов, направляемых банками в Росфинмониторинг;
5) проверка качества транзитных платежей относительно требований законодательства зарубежных стран.
Пятая тема актуальна для банков, проводящих валютные платежи своих "лоро"-респондентов через "ностро"-счета, открытые в американских и европейских банках. Это проверка качества транзитных платежей относительно требований законодательства зарубежных стран.

Идентификация банком своих клиентов, установление
и идентификация выгодоприобретателей

Исполнить данное нормативное требование можно несколькими путями. Первый путь (может быть, самый простой на первый взгляд) - предложить клиентам заполнить анкеты, собрать эти анкеты в папки в хронологическом порядке и обновлять с определенной периодичностью. Но в итоге мы получим пыльные тома сведений, обработать которые невозможно. Второй путь - вводить данные в банковские информационные системы, причем вводить строго по правилам. Такая унификация данных позволяет проводить их автоматизированную обработку.
Например, сведения о собственниках клиентов. При автоматизированной обработке можно выявить клиентов, имеющих одинаковых собственников, проверить клиентов и их собственников на принадлежность к лицам, указанным в списках массовых заявителей, адресах массовой регистрации, составленных 46-й налоговой инспекцией.
На сегодняшний день в банковских информационных системах предусмотрены поля для ввода всей информации, но в основном это текстовые неструктурированные поля, и добиться унифицированного ввода можно только за счет обязательного ввода различных разделителей, знаков препинания. Это, естественно, увеличивает срок ввода. Было бы лучше все-таки изменить структуру полей, ввести дополнительные проверки размерности числовых полей. И еще: надо, чтобы ввод данных был простым и удобным. Как правило, большая часть информации вводится в дополнительные реквизиты документа, которых очень много, при вводе анкеты клиента приходится этот список много раз перелистывать. Было бы намного удобнее, если бы поля были по какому-либо признаку сгруппированы.
Следующая проблема, с которой мы сталкиваемся, - оценка риска легализации клиентом преступных доходов. При всей внешней простоте это большая проблема. Можно, конечно, ввести текстовое поле с соответствующим названием и заставить сотрудников вручную его заполнять. Но нет гарантии, что результат такой оценки учтет все необходимое: и виды операций клиента, и состав контрагентов. А можно процесс хотя бы частично автоматизировать. Причем критериев установления клиентам повышенного риска легализации достаточно много, у нас в банке их 16. Интересно было бы иметь информацию о том, по какому же конкретно критерию повышен риск, и предусмотреть возможность формирования различных сводных таблиц, отчетов в разрезе отдельных критериев. Например, осуществлять дополнительную проверку операций по различным признакам в зависимости от критериев, по которым риск установлен. Это позволило бы проводить оперативный комплексный контроль.
Вопрос выгодоприобретателей, наверное, одна из самых проблемных тем. Согласно требованиям законодательных и нормативных документов банк обязан выявить операции с участием третьих лиц, направить клиенту запрос по предоставлению сведений о третьем лице, предоставить документы. Но, поскольку операций много, нужно продумать систему учета направленных и полученных ответов, исключить случаи повтора. Многие банки, с которыми мы обсуждали этот вопрос, начинали вести учет с использованием подручных средств - Excel, Word. Но, к сожалению, это привело к путанице. Хорошо бы такую, я подчеркиваю, систему выявления и контроля выгодоприобретателей реализовать в банковской информационной системе.
Для реализации этой и других задач мы решили использовать такой инструмент, как связанные субъекты. Для каждого типа запросов, которые адресованы клиентам, мы создаем отдельный класс связанных субъектов. При таком подходе алгоритм по выявлению и идентификации выгодоприобретателей выглядит следующим образом:
1) формируем отдельный класс связанных субъектов под наименованием "выгодоприобретатели";
2) вводим названия известных нам выгодоприобретателей, относительно каждого выгодоприобретателя - номера и даты установленных договоров между ним и клиентом;
3) в последующем в случае выявления этого же выгодоприобретателя, но в другом написании вводим сведения в поле "Другие наименования выгодоприобретателя";
4) фиксируем, был ли направлен клиенту запрос относительно данного выгодоприобретателя, способ отправки запроса, фиксируем факт получения ответа и состав полученной информации: переданы ли банку анкета выгодоприобретателя, копия договора;
5) с определенной периодичностью запускаем фильтр, который выявляет все платежи в адрес третьих лиц, проверяет, были ли платежи относительно уже установленных выгодоприобретателей, предлагает ввести новых. Далее проводится анализ всей имеющейся информации о выгодоприобретателе. В случае если какая-то информация отсутствует, клиенту автоматически формируется соответствующий запрос.

Выявление операций, подлежащих обязательному контролю

Операции, подлежащие обязательному контролю в явном виде, перечислены в Законе N 115-ФЗ. Специальные фильтры по выявлению таких операций настроены, наверное, во всех банковских системах. Однако проблемы, к сожалению, есть и здесь.
Часть операций, подлежащих обязательному контролю, сориентирована непосредственно на сумму платежа. Например, валютообменные операции. Поменял человек 20 000 евро (сумма превышает 600 000 руб.) - мы отправляем сообщение в Росфинмониторинг. Все просто и понятно.
Но часть операций предполагает контроль не суммы платежа, а суммы сделки, то есть суммы договора по операции с недвижимостью, суммы акта приема-передачи по лизинговым операциям. Платежи по данным договорам могут производиться траншами, поэтому возникает необходимость вести некие реестры учета платежей в разрезе отдельных договоров, суммировать платежи, дожидаясь того момента, когда накопившаяся сумма превысит контрольную. Следовательно, надо построить систему учета отдельных операций нарастающим итогом.
Сейчас практически у всех банков алгоритм действий таков: запускается фильтр, по ключевым словам выявляющий отдельные операции. Сотрудник банка загружает полученную в банковской информационной системе информацию в Excel, а далее уже средствами Excel сортирует платежи по клиентам, по наименованию, выделяет номера договоров, суммирует вручную. В результате такой ручной обработки, естественно, появляются неточности, ошибки.
Хорошо бы было хотя бы частично автоматизировать данный процесс. Например, ввести поля, в которые автоматически подтягивалась бы сумма платежа, а сотрудник вручную привязывал к сумме номер и дату договора при первом платеже. Далее при появлении следующего платежа данного клиента, который был бы отобран фильтром как "тоже платеж за недвижимость", программа по контекстному поиску проверяла бы, не производится ли платеж по уже установленному ранее договору. Если "да", накапливаемая сумма увеличивалась бы на сумму текущего платежа, если "нет", предлагалось бы ввести новый договор.
То же самое и с лизингом, займами. При этом платеж, проведение которого привело к превышению контрольной суммы, маркировался бы как подлежащий непосредственно отправке в Росфинмониторинг, указывалась бы общая накопленная сумма. Представляется, что реализовать такой алгоритм не так уж и сложно, а качество анализа операций в этом случае может существенно улучшиться.
Еще один вопрос - что делать с платежами "лоро"-респондентов, как их анализировать? В основном это транзитные платежи, в банковскую информационную систему они загружаются, как правило, как списание либо зачисление средств. Для того чтобы их проанализировать, необходимы специальные средства, подтягивающие тексты SWIFT-сообщений и телексных сообщений в общий отчет. В противном случае приходится заходить вручную в каждое поручение, что занимает много времени.

Необычные операции

Каждый банк должен решить сам, какие операции считать необычными, сомнительными. Было время, когда банки, не задумываясь, переписывали себе в правила внутреннего контроля критерии и признаки необычных операций, сформулированные в рекомендациях Банка России, редактировали эти признаки и критерии таким образом, чтобы они становились чисто формальными, и не реализовывали их на практике. Сейчас, как мы уже говорили, все изменилось. Строже стали требования надзорных органов по контролю необычных операций, появилась заинтересованность в этом у самих банков. А вот программное обеспечение по контролю практически не разработано.
Разумеется, полная автоматизация контроля необычных операций невозможна. Но ведь можно автоматизировать хотя бы часть. Например, практически во всех банках необычным является дробление клиентом денежных переводов, то есть отправка одному и тому же контрагенту средств по одному и тому же договору. Либо, наоборот, получение средств по такой схеме и в дальнейшем перевод общей суммы уже собственных средств в другой банк. Либо внесение физическим лицом наличных средств на счет до востребования с дальнейшей безналичной конвертацией. Наверное, автоматизировать эти признаки было бы не так уж сложно.
Конечно, есть и другие признаки, сложнее. Согласно последним рекомендациям Банка России к операциям, требующим проведения дополнительного контроля, нужно относить отдельные платежи резидентов по внешнеэкономическим контрактам, особенно в случаях, когда аккредитация нерезидента-получателя не совпадает с аккредитацией его банка.
В некоторых банках к необычным операциям, также требующим дополнительного контроля, относят платежи по внешнеэкономическим контрактам, не предусматривающим пересечение товаром таможенной границы Российской Федерации. Вручную проводить такой анализ очень сложно, поскольку операций много и очень часто речь идет об авансовых платежах. Соответственно, следует при выявлении платежа запрашивать дату поставки, а позже - документы, подтверждающие исполнение обязательств. Этот контроль необходим, чтобы пресечь бесконтрольный вывоз денежных средств за рубеж по фиктивным контрактам.
Говорить о необычных, сомнительных операциях можно сколь угодно долго. Позволю себе обратить внимание еще только на одну проблему - различные системы денежных переводов.
С точки зрения автоматизации контроля за легализацией преступных доходов сделано очень мало, если сделано вообще. А ведь речь идет об огромных суммах, которые перекачиваются в зарубежные страны, в том числе неблагоприятные. И вручную организовать контроль невозможно. Опять-таки возникает тема возможного дробления сумм, регулярных, иногда ежедневных, переводов.

Проверка правильности формирования отчетности,
отправляемой в Росфинмониторинг

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

Проверка качества транзитных платежей относительно
требований законодательства зарубежных стран

Пятое направление касается в основном расчетных банков, банков, которые обслуживают платежи своих "лоро"-респондентов в иностранной валюте. Кредитные организации открывают в каком-либо банке "лоро"-счета и проводят через этот банк платежи своих клиентов в иностранной валюте. Расчетный банк проводит эти платежи транзитом через свой "ностро"-счет, открытый, причем с большим трудом, в каком-либо иностранном, например американском, банке. Иностранный банк дополнительно контролирует все платежи в соответствии с законодательством своей страны, причем контроль этот очень серьезный. Платежи, сомнительные с точки зрения иностранного банка, блокируются или задерживаются, этот банк составляет различные уточняющие запросы. Мало того что проведение таких некорректных с точки зрения иностранных банков платежей может навредить самому расчетному банку, в отдельных случаях, как мы поняли, банк может быть внесен в черный список, причем совершенно незаслуженно, поскольку он-то всего лишь передаточное звено, здесь еще и существенный политический вопрос - формирование негативного имиджа российских банков. Поэтому необходимо разработать автоматизированную систему предварительной проверки платежей. Критерии проверки должен опять-таки установить сам банк. Но совершенно точно, что как минимум должно быть реализовано следующее:
- проверка всех лиц, упомянутых в платежном документе, на принадлежность к спискам, составленным OFAC - американской службой, аналогичной нашему Росфинмониторингу;
- проверка всех упомянутых в платежном документе банков на принадлежность к так называемым банкам-оболочкам. Списков таких банков нет, однако точно можно сказать, что к "банкам-оболочкам" не относятся банки, упомянутые в Bankers Almanac, в справочниках SWIFT. Все остальные банки необходимо проверять отдельно;
- проверка всех лиц на аккредитацию в государствах, указанных в списке FATF, а также государствах повышенного риска легализации доходов, к которым согласно мировой практике применяются требования углубленного анализа (Куба, Ирак и др.);
- платежи, когда аккредитация получателя средств не совпадает с аккредитацией его банка, особенно если участник расчетов аккредитован в офшорной зоне.
На самом деле этот перечень может быть продолжен. Еще раз отмечу: критерии могут меняться, следовательно, программное обеспечение должно быть легконастраиваемым.

* * *

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

Н.И.Захарова
Европейский трастовый банк
Подписано в печать
07.11.2006