Предположим, с нашими картами вчера происходили следующие события (табл. 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.
