Применение численных методов для оценки риска при мониторинге
К оглавлению1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1617 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
68 69 70 71 72 73 74 75 76 77 78
Мониторинг, несомненно, является весьма эффективным способом контроля мошенничества и снижения потенциальных убытков банков. Согласно требованиям международных платежных систем (МПС) эмитенты и эквайеры обязаны ежедневно генерировать и периодически анализировать данные по мониторингу.
В частности, 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 полученных значений для каждой карты, наибольшие суммы наберут карты, наиболее «неблагоприятные», требующие внимания и анализа.
ПРИМЕР
Другой пример — теперь уже из области целых чисел. Будем анализировать количество авторизационных запросов по картам за период времени.
ПРИМЕР
В результате прохождения соответствующих запросов им будут присвоены следующие веса (табл. 10 и 11).
Наглядный пример (по результатам запросов 1–5) (табл. 12).
ПРИМЕР
Как реализовать эту методику
Рекомендуется использовать для работы среду 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. Вообще говоря, вопрос параметризации и нормализации базовых весов сам по себе является очень важной и интересной темой для исследования.
Заключение
Численный метод оценки риска позволяет осуществлять мониторинг в строгом соответствии с требованиями МПС, предлагая дополнительные удобства и возможности, существенно расширяя и диапазон процедур обработки подозрительных операций по картам.
Мониторинг, несомненно, является весьма эффективным способом контроля мошенничества и снижения потенциальных убытков банков. Согласно требованиям международных платежных систем (МПС) эмитенты и эквайеры обязаны ежедневно генерировать и периодически анализировать данные по мониторингу.
В частности, 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 полученных значений для каждой карты, наибольшие суммы наберут карты, наиболее «неблагоприятные», требующие внимания и анализа.
ПРИМЕР
Другой пример — теперь уже из области целых чисел. Будем анализировать количество авторизационных запросов по картам за период времени.
ПРИМЕР
В результате прохождения соответствующих запросов им будут присвоены следующие веса (табл. 10 и 11).
Наглядный пример (по результатам запросов 1–5) (табл. 12).
ПРИМЕР
Как реализовать эту методику
Рекомендуется использовать для работы среду 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. Вообще говоря, вопрос параметризации и нормализации базовых весов сам по себе является очень важной и интересной темой для исследования.
Заключение
Численный метод оценки риска позволяет осуществлять мониторинг в строгом соответствии с требованиями МПС, предлагая дополнительные удобства и возможности, существенно расширяя и диапазон процедур обработки подозрительных операций по картам.