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

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

Тогда, если построить запрос на выборку с учетом данных из табл. 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 формально необходимых, чем одновременно или поочередно с шестнадцатью!