Платежные карты: Бизнес-энциклопедия

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

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

214

Здесь и далее везде под термином «операция» подразумевается авторизационный запрос, успешный или нет.

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

Таким образом, если мы пропустим карты через все 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 также могут оказаться весьма полезными при детальном анализе событий.

215

STAN (System Trace Audit Number) — уникальное число, однозначно идентифицирующее авторизацию

216

RRN (Retrieval Reference Number) — аналог STAN.

217

Expiry Date — дата окончания срока действия карты.