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

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

ПРИМЕР

Представим, что в нашем портфеле целых 5 карт, и вчера по ним были следующие авторизации (неважно, успешные или нет) (табл. 1).

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

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

Тогда, если построить запрос на выборку с учетом данных из табл. 1 и 2, на выходе получим запрос 1 (табл. 3).

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

Например, в табл. 2 число 200 находится в 3 строке (максимум) и в 4 (минимум).

В зависимости от выбранной модели присваивания веса, карта наберет либо

10 баллов, либо 15 (как в нашем примере).

Другой пример — теперь уже из области целых чисел. Будем анализировать количество авторизационных запросов по картам за период времени.

ПРИМЕР

Предположим, с нашими картами вчера происходили следующие события (табл. 4).

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

Тогда при реализации запроса, в котором число операций по карте из табл. 4 сопоставляется с наперед заданными значениями (параметрами) табл. 5, на выходе получим запрос 2 (табл. 6).

Обратите внимание, что в табл. 6 содержатся целые числа (тип integer или long), и поэтому они не повторяются в столбцах минимума и максимума; поэтому при построении запроса необходимо будет использовать нестрогие равенства с обеих сторон.