Мониторинг авторизационных запросов по банковским картам: эмиссия

Полная версия статьи размещена в печатной версии журнала

Цели и методы

Под мониторингом в карточном бизнесе обычно подразумевают набор процедур и мероприятий, направленных на выявление необычных (подозрительных) событий, связанных с операциями по пластиковым картам, с целью предотвращения (минимизации) возможных финансовых потерь. Соответственно принято разделять мониторинг авторизационных запросов и финансовых операций (транзакций). В свою очередь, авторизации и транзакции наблюдают как по эмиссии, так и по эквайрингу. Таким образом, существует четыре относительно независимых направления мониторинга. В эмиссии все события привязываются к номеру карты (primary account number, PAN), в эквайринге - к номеру терминала (Terminal ID). Грамотно настроенная система мониторинга позволяет:

1) привлечь внимание к картам/терминалам с аномальной (повышенной) активностью;

2) своевременно обнаружить и выявить подозрительные и мошеннические операции;

3) минимизировать сумму потенциальных (последующих возможных) потерь.

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

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

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

Существует и такая классификация решений по мониторингу:

- основанные на правилах;

- системы искусственного интеллекта;

- их комбинации.

В статье содержится подробное описание механизмов реализации самого востребованного вида мониторинга - авторизационных запросов по эмиссии банковских карт, а также рекомендации по реализации самописных решений для каждого из них с применением инструментариев MS Access. Почему рекомендуется именно MS Access? Ниже следует перечень аргументов «за»:

1) много справочной литературы;

2) хорошая поддержка, много комментариев в сети Интернет;

3) не требуется глубокого знания SQL;

4) можно освоить и начать эффективно использовать в очень короткие сроки;

5) понятный дружественный интерфейс;

6) можно использовать самые разнообразные шрифты для генерации отчетов, в том числе разные шрифты и цвета для разных полей отчетов и форм;

7) отчеты можно быстро, легко и удобно экспортировать в файлы формата .snp - snapshot, которые потом архивировать и хранить для целей аудита, или в .pdf.

Следует особо отметить, что в ходе проверок (on-site review) инспекторы МПС Visa уделяют повышенное внимание именно аспектам соответствия банков требованиям в части мониторинга. Несоблюдение этих требований приводит к довольно тяжким последствиям вплоть до наложения штрафов.

Международные платежные системы (здесь и далее речь идет о Visa и MasterCard) налагают на банки - участники расчетов с пластиковыми картами довольно жесткие требования в части базовых методов мониторинга. Наиболее детальное описание требований содержится в документе, именуемом CEMEA VIOR (в настоящее время он уже не актуален, но вполне может и должен быть использован как справочное пособие). В соответствии с требованиями МПС банки - участники расчетов обязаны ежедневно генерировать и анализировать отчеты по следующим видам мониторинга:

- эмиссия - авторизационные запросы;

- эквайринг - авторизационные запросы и финансовые операции (транзакции).

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

Основные термины и определения

Мы будем использовать термины и определения, несколько отличающиеся от соответствующих им в Положении ЦБ РФ от 24.12.2004 № 266П «Об эмиссии банковских карт и об операциях, с использованием платежных карт», но не противоречащие им по своей сути - исключительно для облегчения понимания сути изложенного материала.

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

1) маршрутизация информационных сообщений по картам/в устройствах банка;

2) обслуживание авторизационных запросов по картам/в устройствах банка;

3) предоставление расчетной информации (клиринг) по картам и операциям в устройствах банка.

Событие - авторизационный запрос (любой, в т.ч. неуспешный) или финансовая операция (транзакция, в т.ч. подлимитная, т.е. совершенная без предшествующего авторизационного запроса).

Успешный авторизационный запрос - авторизационный запрос, на который был получен код авторизации (authorization code, approval code).

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

Бэк-офис - СПО, отвечающее за финансовые операции начисления/списания денежных средств (ДС) на/с картсчет/картсчета.

Запрос SQL - оператор SELECT SQL, результатом которого является выборка из (совокупности) таблиц набора нужных полей или вычисленных значений (см. MS Access 2007 queries).

Отчет - представление в наглядной и удобной для работы форме данных запроса SQL (см. MS Access reports).

Устройство - любой терминал (банкомат, POS, виртуальный POS, импринтер) банка, зарегистрированный в сети МПС для приема и обслуживания карт МПС.

Карта - PAN, по которому проводятся операции (в т.ч. по реквизитам карты через Интернет).

Методы реализации

Как правило, фронтальное СПО и бэк-офис реализованы с использованием систем управления базами данных (СУБД Oracle). Для построения системы мониторинга необходимо иметь доступ к определенным полям таблиц Oracle - как фронтального СПО, так и бэк-офиса. Многие разработчики предоставляют описание соответствующих таблиц Oracle. При отсутствии описаний грамотному специалисту, как правило, не составляет труда найти нужную таблицу и поля, необходимые для работы и анализа.

В статье акцент будет сделан на реализации системы мониторинга в среде MS Access как наиболее доступной и легкой в использовании.

Обычно доступ к таблицам Oracle СПО в среде MS Access наиболее легко реализуется посредством использования ODBC (open database connectivity). Возможно, администраторам Oracle (database administrator, DBA) придется разработать и использовать так называемый view - запрос, на выходе имеющий ограниченный набор полей из соответствующей таблицы.

Совершенно очевидно, что доступ к таблицам Oracle должен быть ограничен режимом «только чтение» во избежание случайного повреждения данных. Хорошей идеей является использование отдельного сервера, хранящего полные копии производственных баз данных Oracle, что легко реализуется на обычном, не серверном, «железе», например под управлением OS Linux и MySQL Server. В задачи системных администраторов будет входить только решение вопроса своевременного ежесуточного копирования необходимых полей таблиц Oracle с производственных серверов на выделенный сервер мониторинга.

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

- доступ только к необходимым полям таблиц Oracle;

- гарантия сохранности производственных таблиц Oracle и их данных;

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

Реализация накопления данных БД-мониторинга на выделенном сервере под управлением MySQL (или иного другого поставщика ПО, например Oracle, PostGres или MS SQL Server) имеет еще одно важное преимущество: данные можно накапливать практически бесконечно (размер БД-мониторинга будет зависеть только от емкости физического жесткого диска). При импорте данных в таблицы MS Access следует принимать в расчет, что размер файла с данными в этих БД не может превышать 2 Гб.

Для работы и построения СУБД-мониторинга авторизационных запросов по эмиссии, как правило, необходимо иметь доступ к нижеследующим полям авторизационного запроса:

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

2) срок действия;

3) дата запроса;

4) время запроса;

5) страна;

6) город;

7) адрес ТСП;

8) название ТСП;

9) идентификатор банка-эквайера (Acquirer ID);

10) МСС;

11) номер терминала;

12) POS Entry Mode;

13) Service Code;

14) сумма и валюта запроса в местной валюте;

15) сумма и валюта запроса в валюте счета;

16) сумма и валюта запроса в единой валюте (вычисляемое значение, см. ниже);

17) Response Code (RC);

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

19) признак отмены (Reversal);

20) тип операции;

21) прочие поля, в зависимости от фронтального СПО.

Для целей унификации всех видов запроса и вычисления некоторых показателей необходимо будет привести все запросы к единой валюте. Обычно счета клиентов - держателей карт банка открываются и ведутся в одной из трех валют - рублях, долларах США и евро. Соответственно нужно при помощи средств SQL уметь вычислять сумму каждого запроса в некой единой валюте - как правило, в долларах США (сумма запроса в валюте счета клиента делится или умножается на соответствующее значение, задаваемое при работе с БД-мониторингом в начале каждой сессии).

В среде MS Access это реализуется путем создания и запуска формы при открытии БД (startup form) - в ней предлагается сразу ввести курс рубля к евро и доллару на дату вычислений. Пересчет в единую валюту в среде MS Access легко реализуется посредством оператора IIf (Immediate If). В данном случае точность курса валюты не имеет особого значения и служит лишь для приведения к единому общему знаменателю (курсу в валюте вычислений) сумм всех авторизационных запросов вне зависимости от валюты операций. Неважно, что позже финансовая операция будет рассчитана совсем по другому курсу, - важно в момент анализа авторизационного запроса, поступившего на хост эмитента из любой точки планеты, иметь представление, какая сумма была запрошена (в рублях, долларах или евро - на выбор разработчика) в некой единой валюте.

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

Мониторинг авторизационных запросов (эмиссия)

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

1. Общее количество запросов по карте.

2. Общее количество запросов по карте с разбивкой по МСС высокого риска.

3. Общее количество запросов по карте в одном и том же терминале (ТСП).

4. Общее количество запросов по карте с разбивкой по странам высокого риска.

5. Общее количество попыток ввода неверного пин по карте.

6. Общее количество авторизационных запросов по карте с POS Entry Mode, PEM = ‘02’ (совет: анализировать PEM, отличный от ‘90’).

7. Общая сумма запросов по карте.

8. Общая сумма запросов по карте с разбивкой по МСС высокого риска.

9. Общая сумма запросов по карте с разбивкой по странам высокого риска.

10. Сумма отдельного запроса по карте превышает заданное наперед значение в единой валюте.

11. Сумма отдельного запроса по карте превышает заданное наперед значение с разбивкой по МСС высокого риска.

12. Сумма отдельного запроса по карте превышает заданное наперед значение с разбивкой по странам высокого риска.

13. Анализ cross-border авторизаций по карте (запросы из разных стран в течение некоего наперед заданного промежутка времени, например в одни сутки).

14. Анализ авторизационных запросов по карте в режиме ручного ввода номера карты (key entry mode).

15. Анализ запросов по картам с высоким объемом авторизационных запросов, предваряющихся отказами (в процентном отношении к наперед заданным значениям).

16. Анализ процентного отношения фактически потраченных средств в розничной сети и полученных наличными (сравнение поведения клиента с имеющимся шаблоном).

Легко заметить, что запросы делятся на группы, а именно:

1) общее количество (6 запросов);

2) общая сумма (3 запроса);

3) сумма отдельного запроса (в единой валюте, 3 запроса);

4) сравнительный анализ (4 запроса).

Ниже рассмотрим подробно все 16 обязательных SQL-запросов, которые эмитенты должны ежедневно исполнять и анализировать.

На данном этапе следует задуматься о начислении баллов по результатам исполнения каждого из SQL-запросов. Например, если по карте была 1 операция (внимание: здесь и далее до оговорки везде под термином «операция» подразумевается авторизационный запрос, успешный или нет), присвоим этой карте 1 балл (или 10), если 2 - то 2 (или 20, 25, 50), если 3 - то 3 (или 30, 50, 100). Основная идея: чем больше операций - тем больше баллов. Чем больше сумма операции - тем больше баллов. Чем больше отказов - тем больше баллов. Ключевая мысль: чем «опаснее/рисковее» событие - тем больше баллов! Зависимость вовсе не должна быть линейной, но обязана быть прямой (с ростом числа/сумм авторизационных запросов растет сумма «штрафных» баллов, набираемых картой).

Таким образом, в результате работы каждого из 16 SQL-запросов («выборка») на выходе получаем таблицу из двух столбцов:

1. Общее количество запросов по карте.

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

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

Например, у нас в портфеле банка 10 карт. Номера карт в примере соответственно от 0 до 9. Если по всем картам за определенную дату (день, предшествующий дате исполнения запроса) не было событий (авторизационных запросов), а по картам 2, 5 и 9 были соответственно 5, 2 и 6 запросов, на выходе в результате работы SQL-запроса (1 — Общее количество запросов по карте) будем иметь следующий результат:

Видно, что наибольшее число баллов (60) набрала карта № 9, так как именно по этой карте зафиксировано наибольшее число событий (авторизационных запросов, любых, не обязательно успешных в контексте данного запроса), что потенциально несет в себе больший риск (возможных финансовых потерь клиента или банка, если клиент — мошенник), чем по картам, не имевшим запросов или имевшим меньшее их число. Данное утверждение относится именно только к числу запросов, а не к общей их сумме или прочим аспектам (МСС, страна и пр.).

2. Общее количество запросов по карте с разбивкой по МСС высокого риска.

Существует устойчивое понятие «МСС повышенного риска» (МСС — merchant category code). К ним традиционно относят такие коды, как 5944, 7995, в последнее время — 6012, 8999 и пр. (на выбор разработчика БД-мониторинга). Официально МПС рассылают участникам ежеквартальные бюллетени, содержащие в том числе и списки МСС повышенного риска. Аналогично предыдущему SQL-запросу в данном анализируется количество событий, МСС которых совпадает с кодами повышенного риска. Точно так же следует начислять «штрафные» баллы по схеме, полностью совпадающей с изложенной выше, — чем больше запросов, тем больше баллов (можно составить таблицу значений начисляемых баллов даже для каждого МСС).

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

Разработчикам СУБД следует иметь таблицу МСС с эмпирически заданными наперед значениями «штрафных» баллов, например для каждого запроса (успешного/неуспешного) из ТСП с МСС 5944 начислять карте 20 баллов, при запросе из ТСП с МСС 7995 — 100 баллов и т.д.

3. Общее количество запросов по карте в одном и том же терминале (ТСП).

В этом SQL-запросе анализируется количество запросов по карте, сделанных из одного и того же терминала (поле Terminal ID). Чем больше запросов, тем больше число баллов (подозрительно, когда одна и та же карта «гуляет» в одном и том же терминале, очень похоже на «прозвон» доступного остатка или потенциальное мошенничество). Обычно по одной и той же карте совершается 1–2 операции в одном терминале в день, как то предписано в Правилах и Требованиях МПС (оформить все покупки одной транзакцией). Для более жесткого соблюдения условий уникальности терминала можно анализировать еще и поле Acquirer ID, что гарантирует факт соблюдения формального требования МПС (предполагается, что у одного и того же эквайера не может быть терминалов с одинаковыми номерами).