Применение численных методов для оценки риска при мониторинге

Применение численных методов для оценки риска при мониторинге

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

В частности, Visa CEMEA предписывает эмитентам генерировать 16 запросов только по авторизациям и 23 запроса — эквайерам по авторизациям (9) и транзакциям (14).

Если строго формально и непредвзято исполнять требования МПС, то даже при относительно небольшом количестве карт (ТСП) количество запросов и отчетов будет составлять несколько десятков в день, что неизбежно приведет к чудовищному росту ненужных бумаг и персонала.

Практически все известные на данный момент программные решения для карточного бизнеса в той или иной мере реализуют требования Visa CEMEA в части обязательного мониторинга, предлагая клиентам генерировать 39 и даже более отчетов, которые действительно соответствуют всем параметрам, но ужасно неудобны в работе!

В данном разделе предлагается ознакомиться с оригинальным методом использования балльных оценок (скоринга) для одновременного успешного решения нескольких задач:

1) формального удовлетворения требований МПС;

2) минимизации трудозатрат и документооборота;

3) построения системы мониторинга и отчетности, которая действительно работает и позволяет своевременно выявлять подозрительные операции.

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

Итак, в чем же проблема? Согласно требованиям МПС банкам, работающим с картами, необходимо ежедневно генерировать и анализировать несколько десятков отчетов, что является само по себе непростой задачей, особенно в части анализа. Представьте себе, даже при небольшом портфеле (2–3 тысячи активных карт), какой хорошей памятью нужно обладать сотруднику, анализирующему отчеты, чтобы заметить, что карта с одним и тем же номером попала, предположим, в отчеты под номерами 1, 5 и 12? А если активных карт сотни тысяч? Как быть?

Решение — довольно простое, но работающее, проверенное и доказавшее свою эффективность и удобство.

Напомним, что эмитенты должны «пропускать» каждую карту через 16 запросов — общая сумма операций, общее число операций, анализ response code (ISO)[210], МСС[211], рисковых стран, количество отказов, операций в одном ТСП, анализ POS Entry Mode (PEM)[212], cross-border[213] и проч.

Давайте попробуем по результатам прохождения карты через каждый запрос присваивать ей определенное количество баллов. Логика — понятна и проста: предположим, если по карте была 1 операция[214], присвоим этой карте 1 балл (или 10 — как больше нравится), если 2 — то 2 (или 20, 25, 50), если 3 — то 3 (или 30, 50, 100 — сколько угодно).

Основная идея: чем больше операций — тем больше баллов. Чем больше сумма операции — тем больше баллов. Чем больше отказов — тем больше баллов. Зависимость вовсе не должна быть линейной, но обязана быть прямой (с ростом числа (сумм) авторизационных запросов (отказов) растет сумма баллов, набираемых картой).

По эквайрингу — полная аналогия, но только вместо номеров карт будут выступать номера терминальных устройств (банкоматов, электронных терминалов, импринтеров).

Таким образом, если мы пропустим карты через все 16 обязательных запросов и присвоим каждой карте по результатам работы каждого запроса некоторое количество баллов, исходя из принципа «чем хуже, тем больше баллов», а потом просуммируем все 16 полученных значений для каждой карты, наибольшие суммы наберут карты, наиболее «неблагоприятные», требующие внимания и анализа.

ПРИМЕР

Представим, что в нашем портфеле целых 5 карт, и вчера по ним были следующие авторизации (неважно, успешные или нет) (табл. 1).

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

Если сумма (эквивалент в долларах) авторизационного запроса по карте приходится между минимумом и максимумом какой-то строки, такой операции присваивается вес, находящийся в этой же строчке таблицы!

Тогда, если построить запрос на выборку с учетом данных из табл. 1 и 2, на выходе получим запрос 1 (табл. 3).

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

Например, в табл. 2 число 200 находится в 3 строке (максимум) и в 4 (минимум).

В зависимости от выбранной модели присваивания веса, карта наберет либо

10 баллов, либо 15 (как в нашем примере).

Другой пример — теперь уже из области целых чисел. Будем анализировать количество авторизационных запросов по картам за период времени.

ПРИМЕР

Предположим, с нашими картами вчера происходили следующие события (табл. 4).

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

Тогда при реализации запроса, в котором число операций по карте из табл. 4 сопоставляется с наперед заданными значениями (параметрами) табл. 5, на выходе получим запрос 2 (табл. 6).

Обратите внимание, что в табл. 6 содержатся целые числа (тип integer или long), и поэтому они не повторяются в столбцах минимума и максимума; поэтому при построении запроса необходимо будет использовать нестрогие равенства с обеих сторон.

Точно таким же образом строятся все остальные обязательные запросы, связанные с анализом сумм авторизационных запросов и их количества. Рекомендуется использовать для анализа сумм авторизаций эквивалент в единой валюте, для чего следует подобрать соответствующее поле из авторизационного сообщения, хранимого в таблице фронтальной программы. Как показывает опыт, для мониторинга эмиссии лучше использовать эквивалент суммы авторизационного запроса в долларах США (поскольку карты одного банка могут побывать практически в любой точке планеты), для мониторинга эквайринга — российский рубль (поскольку все ТСП на территории Российской Федерации ведут расчеты в рублях).

Совершенно аналогично назначаются веса для таких запросов, как анализирующих количество отказов и суммы операций по карте в терминалах, POS Entry Mode которых отличается от «90» (формально это некоторое отступление в сторону расширения от требования к запросам МПС, в которых говорится, что следует выявлять лишь операции, совершенные с POS entry mode = «02» или «01» в процентном отношении).

Как же быть с реализацией запросов, в которых требуется анализировать активность карт в странах и ТСП с МСС повышенного риска? Решить эту проблему предлагается следующим образом. Необходимо завести соответствующие таблицы — например, tblMCC и tbiCountries, примерная структура которых приводится ниже (табл. 7, 8).

Само собой разумеется, что значения МСС и кодов ISO стран в соответствующих таблицах должны быть уникальными (не допускаются повторения).

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

Предположим, если наши «учебные» карты побывали, предположим, вчера, в нижеследующих ТСП и странах (табл. 9).

В результате прохождения соответствующих запросов им будут присвоены следующие веса (табл. 10 и 11).

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

На базе этих базовых запросов, каждый из которых содержит на выходе два столбца с одинаковыми названиями (например, CardNo и Weight) формируется один-единственный итоговый запрос, на выходе которого также два столбца — номера карт и суммы баллов, набранных в первичных запросах! Столбцы сортируются по убыванию сумм баллов, набранных картами при прохождении первичных запросов.

Наглядный пример (по результатам запросов 1–5) (табл. 12).

ПРИМЕР

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

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

Как реализовать эту методику

Рекомендуется использовать для работы среду MS Access как наилучшим образом отвечающую потребностям данной задачи. По опыту, следует использовать подключение к авторизационной БД или ее суточной копии на резервном сервере через ODBC.

Для работы и вывода в отчет нам потребуются следующие поля базы данных авторизаций:

1) дата авторизации;

2) время авторизации;

3) номер карты;

4) сумма авторизации;

5) оригинальная валюта совершаемой операции;

6) тип операции (прямая или reversal);

7) эквивалент суммы авторизационного запроса в долл. США;

8) код авторизации (если был);

9) response code (ISO);

10) МСС;

11) POS Entry Mode (PEM);

12) BIN эквайера;

13) номер терминального устройства;

14) наименование ТСП;

15) город ТСП;

16) страна ТСП.

Это — необходимый минимум. Именно эти данные следует включать в итоговый отчет — они позволяют наглядно представлять картину операций по карте. По желанию и при наличии возможностей перечень может быть дополнен — например, такие поля, как STAN[215], RRN[216], Expiry Date[217], валюта СКС, момент времени по UTC также могут оказаться весьма полезными при детальном анализе событий.

При мониторинге эмиссии в качестве объектов анализа выступают номера карт банка; при мониторинге эквайринга таковыми являются номера терминальных устройств. Следовательно, при построении базовых запросов и итогового запроса при реализации данного метода в мониторинге эквайринга в левом столбце всегда будут номера терминалов (вне зависимости от типа устройства — банкомат, POS или импринтер).

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

Помимо стандартных (формально обязательных) отчетов МПС совершенно нелишне разработать свои. Например, во многих банках успешно используется в качестве одного из базовых запрос, анализирующий код ответа (RC) — при мониторинге эквайринговой активности частые RC, отличные от «00», служат верным признаком проблем в ТСП: либо неисправно оборудование, либо мошенники облюбовали его для проверок ворованных карт или даже для совершения покупок по ним.

MS Access позволяет генерировать самые разнообразные отчеты с использованием всего спектра шрифтов, установленных в системе. Неплохой идеей является использование шрифтов типа Arial Narrow для экономии пространства.

Также полезным является размещение отчета в альбомной (Landscape) ориентации на странице, причем в два столбца. Хорошей практикой является использование пониженного расхода тонера (economy mode) при печати на лазерном принтере и вывод на печать с обеих сторон листа — при значительных объемах эмиссии (эквайринга) даже отчеты в два столбца могут занимать несколько десятков страниц.

В MS Access предусмотрена возможность экспорта отчетов в файлы особого формата — snapshot (.snp): такие файлы невозможно редактировать, но можно просматривать с различным увеличением (вплоть до 200 %) и выводить на печать. Кроме того, они прекрасно архивируются.

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

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

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

Конечно же, табл. 13 приведена только для примера, и число строк в ней может и должно быть расширено — по усмотрению банка.

При работе с отчетами следует анализировать поведение держателя, обращая внимание на время, место, сумму и количество операций, режим ввода номера карты (POS entry mode), коды ответа (RC), географическое расположение ТСП, МСС. Можно также оформить документально некоторое решение, регулирующее обязательность анализа всех транзакций по картам, набравшим определенную сумму баллов — предположим, обязать сотрудника, отвечающего за данное направление, связываться с законным держателем карты и запрашивать у него подтверждения совершения этих операций.

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

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

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

Заключение

Численный метод оценки риска позволяет осуществлять мониторинг в строгом соответствии с требованиями МПС, предлагая дополнительные удобства и возможности, существенно расширяя и диапазон процедур обработки подозрительных операций по картам.