Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

Новые механизмы управления рисками для карт стандарта CPA

(Нет голосов)

11.09.2006 Количество просмотров 1865 просмотров
В одном из ранее опубликованных материалов Игоря Голдовского (см. статью “Что день грядущий нам готовит? Часть II”, “ПЛАС” № 3/2006) автором уже было уделено внимание таким значимым событиям индустрии платежных карт, как появление в конце 2005 г. спецификаций Common Payment Application (CPA), разработка EMVCo единой процедуры тестирования приложения карты (EMVCo Type Approval Process for Card Application ) и единых процедур оценки безопасности карт стандарта EMV – EMV Security Evaluation Process. Продолжая данную тему, в этот раз мы предлагаем вниманию читателей анализ новых механизмов управления рисками, реализованных в рамках стандарта CPA.

Как уже неоднократно отмечалось экспертами и озвучивалось в зарубежных и российских профессиональных СМИ, появление спецификаций Common Payment Application (CPA) имеет большое значение для всех участников рынка платежных карт и сегодня находится в центре внимания банковских специалистов и менеджеров, курирующих карточный бизнес. Возможность внедрения единых процедур персонализации EMV-карт, управления рисками и обработки транзакций на хостах банков-участников крупнейших мировых платежных систем является, безусловно, важным шагом в процессе распространения микропроцессорных карт. В то же время у некоторых участников рынка может сложиться впечатление, что появление универсального стандарта является результатом технологического компромисса между спецификациями VIS 1.4 и M/Chip4, а потому, как это часто бывает в подобных случаях, новый стандарт не поддерживает полной функциональности карт указанных спецификаций. Иными словами, речь идет о возможном заблуждении относительно того, что внедрение CPA неизбежно влечет за собой потерю некоторой функциональности карт VIS 1.4 и M/Chip4.

Однако в реальности все обстоит совершенно иначе. Для того чтобы сформировать для себя четкое представление о возможностях CPA, в рамках настоящей статьи мы рассмотрим очень важную компоненту алгоритма работы микропроцессорной карты – процедуры управления рисками (Card Risk Management, или CRM) и принятия решения о способе завершения транзакции (Card Action Analysis, CAA). Процедуры CRM включают в себя выполнение картой проверок ряда параметров текущей и предыдущих транзакций и формирование по результатам этих проверок объекта данных (Application Decisional Results, ADR). Процедура CAA состоит в выполнении картой анализа результатов ADR с целью принятия решения о том, каким образом следует продолжить обработку операции – должна ли транзакция быть одобрена/отклонена в офлайновом режиме или ее следует отправить на авторизацию эмитенту. При принятии решения учитываются результаты процедур управления рисками, выполненные терминалом.

Таким образом, процедуры CRM&CAA – это делегированные эмитентом карте полномочия по принятию решения о результате завершения транзакции. На примере этих процедур мы докажем, что стандарт CPA является, несомненно, новым шагом в направлении повышения гибкости и функциональности процедур управления рисками. Этот факт к настоящему времени уже осознан многими банками. В частности, банки Германии приняли решение о миграции своих микропроцессорных карт на стандарт CPA начиная с 1 января 2007 г. Следует отметить, что компания EMVCo, разработчик и держатель стандарта CPA, обещает до конца нынешнего 2006г. утвердить процедуры тестирования и сертификации карт на совместимость с CPA (последние уже разработаны и находятся на стадии обсуждения участниками карточного рынка), а также единые процедуры оценки безопасности карт стандарта CCD/CPA – CCD/CPA Security Evaluation Process. Несмотря на то, что подробно рассказать о процедурах управления рисками, используемых на картах CPA, не вдаваясь в технические детали, достаточно проблематично, в настоящей статье автор попытается разъяснить новые возможности процедур CRM&CAA карты CPA в самом общем виде, минимизировав по возможности использование специализированной терминологии.

Процедуры CRM&CAA в стандарте CPA задаются профилем карты, который идентифицируется идентификатором Profile ID и определяется в начале выполнения операции по значениям параметров транзакции, карты и терминала с помощью специальной таблицы (в терминологии спецификаций – Profile Selection Table). На карте может быть определено несколько профилей, задающих различные процедуры управления рисками.

Профиль карты определяется по значениям параметров обрабатываемой транзакции, терминала и карты. Набор параметров, по которым определяется профиль карты, изначально задается эмитентом и записывается на карту в процессе ее персонализации (в таблице Profile Selection Table). Например, он может включать в себя тип транзакции, сумму транзакции и код валюты (параметры транзакции), код страны терминала, тип терминала, возможности терминала по обработке транзакции (параметры терминала), код страны эмитента, прикладную валюту эмитента (параметры карты). Профиль карты, используемый для обработки текущей транзакции, определяется в самом начале обработки транзакции (до первой процедуры CRM&CAA).

Для этого карта получает параметры транзакции и терминала из данных команды Get Processing Options. Набор данных, содержащихся в этой команде, задается эмитентом карты в опциональном параметре FCI Template файла ADF, соответствующем конкретному приложению, выбранному картой для обработки транзакции. Таким образом, для поддержания картой процедуры выбора профиля от эмитента требуется в FCI Template (Tag ‘6F’) приложения в обязательном составном объекте данных FCI Proprietary Template (Tag ‘A5’) определить перечень данных PDOL (Tag ‘9F38’), ожидаемых картой от терминала. Каким же образом по выбранным данным транзакции, терминала и карты осуществляется выбор профиля карты? Выбор производится с помощью таблицы Profile Selection Table, состоящей из отдельных последовательных записей Profile Selection Table Entry (при этом важен и сам порядок, в котором записи присутствуют в таблице Profile Selection Table ). Каждая запись определяет набор параметров, используемых для выбора профиля карты, правило принятия решения и собственно решение – т.е. либо выбор определенного профиля, либо переход к анализу другой записи Profile Selection Table Entry. Фактически таблица Profile Selection Table представляет собой компьютерную программу (набор инструкций), а каждая запись таблицы – Profile Selection Table Entry – является оператором условного перехода вида “если выполняется X, то Y, иначе Z”. При этом выполнение условия X определяется по значениям определенных в Profile Selection Table Entry параметров транзакции, терминала и карты, а решения Y и Z, как уже отмечалось выше, представляют собой либо значение идентификатора выбранного профиля карты Profile ID, либо указание на следующую запись таблицы (в нашей интерпретации – указание на следующий оператор, который должен быть исполнен в программе), к обработке которой следует перейти. Вид записи Profile Selection Table Entry показан на рис. 1.
 Как показывает рис. 1, каждая запись таблицы определяет:
• номер первого байта (Position) в данных команды Get Processing Options, используемого для выбора профиля карты (обозначим этот номер через Х);
• количество байтов поля данных команды Get Processing Options, используемых для выбора профиля карты (Comparison Block Length); обозначим это количество байтов через L; таким образом, для выбора профиля используются байты X,…,X + L – 1 поля данных команды Get Processing Options;
• маску (Bit Mask), представляющую собой последовательность из логических 0 и 1 длиной L байтов; с помощью маски путем по-битового логического умножения ее битов с соответствующими (с теми же последовательными номерами) битами байтов X,…,X+L–1 поля данных команды Get Processing Options получается маскированная последовательность Z. Элемент Check Type определяет тип сравнения данных Comparison Value 1, …, Comparison Value (n – 1) записи Profile Selection Table Entry с маскированной последовательностью Z.Если тип сравнения – “=”, то количество блоков Comparison Value может быть любым натуральным числом. Если тип сравнения – “>” или “<”, то используется единственный блок Comparison Value 1. Если тип сравнения – “=”, то считается, что проверка завершилась успешно в случае, если маскированная последовательность Z совпадает с какимлибо из блоков Comparison Value 1, …, Comparison Value (n – 1).

Элементы Positive Action и Negative Action записи Profile Selection Table Entry определяют дальнейшие действия карты по выбору своего профиля. Описанный выше алгоритм показан на рис. 2. В рамках этой статьи мы не будем подробно рассматривать процедуру выбора профиля карты. Отметим только, что данная процедура позволяет задать профиль карты по практически любому набору параметров операции, терминала и карты, состав которого (набора) выбран эмитентом карты. Теперь поговорим о том, что определяет выбранный профиль карты при обработке транзакции (см. рис. 3). Профиль карты определяет: • набор данных, которые должны быть прочитаны терминалом для обработки транзакции (Application File Locator, или AFL), а также возможности карты, связанные с обработкой текущей транзакции (Application Interchange Profile, или AIP), – поддержка методов аутентификации приложения и процедур верификации держателя карты, способ аутентификации эмитента; • объекты данных – триплеты Card Issuer Action Code (CIAC), с помощью которых после получения картой результатов выполнения процедур управления рисками (объекта ADR) она принимает решение (с учетом решения, принятого терминалом) о способе продолжения транзакции: завершить операцию одобрением или отклонением в офлайновом режиме или отправить операцию на обработку эмитенту карты; при этом триплеты CIAC в CPA стали развитием объектов данных спецификации M/Chip4 и представляют собой альтернативу объекту Application Default Actions, используемому в спецификациях VIS 1.4; • объект Issuer Options, о котором будет рассказано ниже;
• два кумулятивных счетчика Accumulator 1 и Accumulator 2, позволяющих вводить ограничения на использование средств по карте при выполнении операции в офлайновом режиме;
• два циклических кумулятивных счетчика Cyclic Accumulator 1 и Cyclic Accumulator 2, позволяющих вводить ограничения на использование средств по карте при выполнении операции в офлайновом режиме;
• три счетчика транзакций Counter 1, Counter 2, Counter 3, позволяющих вводить ограничения на количество операций, выполняемых по карте в офлайновом режиме;
• значение кумулятивного счетчика VLP (VISA Low Value Payment), используемого в продуктах Visa International для реализации офлайновых операций на небольшие суммы;
• максимальное значение суммы операции по карте Maximum Transaction Amount, с помощью которого можно устанавливать максимальный размер операции, при котором она еще может быть выполнена в офлайновом режиме.

Остановимся на наиболее важных параметрах, задаваемых профилем карты. В первую очередь отметим, что выбор профиля задает объекты AIP/AFL, фактически определяющие способ обработки транзакции. Например, для транзакций на небольшие суммы с помощью AIP можно заявить о том, что карта не поддерживает верификацию ее держателя или даже не поддерживает процедуру динамической аутентификации. Такой подход ускоряет обработку транзакции и в то же время является допустимым для безопасности операции с точки зрения эмитента карты. Объекту AIP должен соответствовать и другой объект данных – AFL, определяющий линейные файлы/записи, которые должны быть прочитаны терминалом до начала обработки транзакции. Например, в предыдущем примере AFL не должен указывать на записи, содержащие объект CVM List, описывающий способы верификации держателя карты, поддерживаемые картой, а также на реквизиты карты, используемые при проведении процедуры динамической аутентификации.

Триплеты CIAC, определяющие правила принятия решения по результатам выполнения процедур управления рисками (объекту ADR), также могут задаваться профилем карты. Например, можно определить профиль высокорискованных транзакций (например, по коду страны обслуживающего банка и/или типу торгового предприятия), для которого все операции должны обслуживаться только в онлайновом режиме. Такой режим обслуживания транзакции можно установить с помощью соответствующего триплета CIAC. Можно также выставить условие, чтобы операции покупки при выборе профиля высокорискованных транзакций обрабатывались с использованием метода верификации держателя карты PIN Offline. Если проверка ПИН-кода не производилась, то операция должна быть картой отклонена. Очень важным объектом данных является объект Issuer Options. Этот объект определяет:
• необходимость логирования транзакций на карте;
• необходимость выполнения двух дополнительных проверок в рамках процедуры управления рисками карты (CRM);
• необходимость использования в рамках CRM счетчика максимального количества дней, прошедших с момента выполнения последней онлайновой операции (Max Days Offline Counter); • необходимость шифрования значений счетчиков карты при их передаче эмитенту в рамках объекта данных Issuer Application Data;
• необходимость установки картой начального значения Max Days Offline Counter после обработки онлайновой транзакции;
• возможность обойти решение CIAC-Default для торговых терминалов, способных функционировать только в офлайновом режиме;
• ряд других параметров карты. На рис. 4 показаны определяемые Issuer Options объекты данных.

В свою очередь, наиболее интересным элементом объекта Issuer Options являются две дополнительные проверки, определенные для платежного приложения карты независимо от выбранного профиля – профиль карты в данном случае лишь определяет необходимость выполнения каждой из проверок. Дополнительные проверки выполняются для данных, полученных картой в командах Generate AC. Если некоторые полученные данные равны одному из определенных заранее эмитентом значений, то проверки считаются завершенными с положительным результатом (соответствие найдено). Результаты проверок определяют соответствующие биты ADR и таким образом влияют на результат обработки транзакции (на результат выполнения процедуры CAA).

Блок-схема алгоритма выполнения дополнительной проверки показана на рис. 5. Как уже ранее отмечалось, для CPAприложения карты могут быть определены три счетчика операций, выполняемых по карте. Независимо от профиля карты каждый счетчик определяется условиями, заданными эмитентом при персонализации карты, при которых его текущее значение должно увеличиваться на единицу. Эти условия включают в себя определение необходимости учета:
• ARQC-операций (операций, при выполнении которых вычислялась криптограмма ARQC);
• офлайновых транзакций, завершившихся отказом;
• офлайновых успешно завершенных операций;
• только международных транзакций;
• только внутренних (domestic) транзакций;
• только транзакций, не изменяющих значение какого-либо кумулятивного счетчика. При этом профиль карты для каждого счетчика определяет:
• необходимость использования данного конкретного счетчика;
• значения верхнего и нижнего лимитов, определяющих необходимость обработки транзакции в онлайновом режиме в случае применения, соответственно, только офлайнового (Offline Only) терминала и терминала, способного выполнять операции в онлайновом режиме;
• необходимость переустановки счетчика после выполнения онлайновой операции;
• необходимость передачи значения счетчика эмитенту в рамках объекта Issuer Application Data (IAD).

На карте определены два кумулятивных счетчика, Accumulator 1 и Accumulator 2, позволяющие вводить ограничения на использование средств в операциях, выполняемых по карте в офлайновом режиме. Для каждого счетчика независимо от выбранного профиля карты заданы два набора значений верхнего и нижнего лимитов, позволяющие вводить ограничения на использование средств в офлайновых операциях. Превышение верхнего и нижнего лимитов требует обработки транзакции в онлайновом режиме в случае применения, соответственно, только офлайнового (Offline Only) терминала и терминала, способного выполнять операции в онлайновом режиме. Профиль карты для каждого счетчика определяет один из двух наборов значений верхнего и нижнего лимитов, а также:
• необходимость использования счетчика при выполнении текущей операции;
• необходимость переустановки кумулятивного счетчика после выполнения онлайновой операции,
• необходимость передачи значения счетчика эмитенту в рамках объекта Issuer Application Data (IAD);
• возможность конверсии суммы транзакции в валюту лимитов;
• таблицу конверсии валюты.

На карте также заданы два циклических кумулятивных счетчика, Cyclic Accumulator 1 и Cyclic Accumulator 2, позволяющие вводить ограничения на использование средств в офлайновых операциях, выполненных по карте в течение заданного периода времени (день, неделя, месяц). Для каждого счетчика независимо от выбранного профиля определены тип счетчика (дневной, недельный, месячный), валюта счетчика и необходимость включать в него успешно завершенные онлайновые операции. Профиль карты для каждого счетчика определяет необходимость использования данного счетчика при выполнении текущей операции, значение лимита, превышение которого означает необходимость выполнения операции в онлайновом режиме, а также таблицу конверсии валюты транзакции в валюту счетчика. Значения циклических кумулятивных счетчиков эмитенту не отправляются. Помимо перечисленных счетчиков каждый эмитент карты CPA имеет возможность использовать дополнительные счетчики и дополнительные проверки в рамках процедуры управления рисками.

В спецификациях M/Chip4 на карте используются следующие счетчики: • VCC (velocity checking count) – количество последовательных офлайновых операций, выполненных картой после выполнения онлайновой операции. Очевидно, что VCC = ATC – LATC (LATC – Last Online Application Transaction Counter, Tag ‘9F13’ – номер последней онлайновой транзакции). • COTA (cumulative offline transaction amount) – сумма денежных средств, выраженная в валюте Application Currency Code и потраченная по карте в последовательных успешных офлайновых транзакциях. Для перечисленных счетчиков в спецификациях M/Chip4 эмитент может установить следующие лимиты:
• Lower Consecutive Offline Limit (LCOL, Tag ’9F14’, 1 байт) – определяет максимальное количество последовательных офлайновых операций, которые карта может выполнить на терминале, способном обработать транзакцию в онлайновом режиме;
• Upper Consecutive Offline Limit (UCOL, Tag ’9F23’, 1 байт) – определяет максимальное количество последовательных офлайновых операций, которые карта может выполнить на терминале, не способном обработать транзакцию в онлайновом режиме;
• Lower Cumulative Off-line Transaction Amount (LCOTA) – определяет максимальную величину денежных средств, выраженную в валюте Application Currency Code (Tag ‘9F42’), которую эмитент разрешает потратить по карте в рамках последовательных офлайновых операций на терминале, способном обработать транзакцию в онлайновом режиме;
• Upper Cumulative Off-line Transaction Amount (UCOTA) – определяет максимальную величину денежных средств, выраженную в валюте Application Currency Code (Tag ‘9F42’), которую эмитент разрешает потратить по карте в рамках последовательных офлайновых операций на терминале, не способном обработать транзакцию в онлайновом режиме. Все операции в M/Chip4 делятся на локальные (domestic) и остальные – трансграничные (non-domestic) транзакции. Транзакция считается локальной, если:
• Terminal Country Code = Issuer Country Code;
• Transaction Currency Code = Application Currency Code. Проверки параметра VCC производятся с помощью анализа неравенств ATC – LATC > LCOL/NDCF и ATC – LATC > UCOL/NDCF, где коэффициент NDCF (Non-Domestic Control Factor) равен 1 для локальных транзакций и NDCF1 для трансграничных транзакций.

Каждый эмитент карты CPA имеет возможность использовать дополнительные счетчики и дополнительные проверки в рамках процедуры управления рисками При проверках параметра COTA может случиться так, что код валюты транзакции (Transaction Currency Code) не равен коду валюты приложения (Application Currency Code). В этом случае стандарт EMV предусматривает возможность конверсии суммы транзакции АА в валюту приложения (Application Currency). Для этого карта должна поддерживать для валюты транзакции курс обмена Reference Currency to Application Currency Conversion Rate. Курс обмена умножается на сумму транзакции в валюте транзакции для того, чтобы получить сумму транзакции АА1 в валюте приложения. Далее проверки параметра COTA производятся с помощью анализа неравенств LCOTA – COTA < AA1 и UCOTA – COTA < AA1.

В спецификациях VIS 1.4 эмитенты карт используют лимиты на количество офлайновых транзакций и объем потраченных по ним средств, отличные от применяемых в M/Chip4. К этим лимитам относятся:
• Consecutive Transaction Limit (International, Currency) – максимально допустимое количество последовательных офлайновых операций, в которых код валюты транзакции отличается от кода валюты карты (Application Currency Code);
• Consecutive Transaction Limit (International, Country) – максимально допустимое количество последовательных офлайновых операций, в которых код страны эмитента (Issuer Country Code) отличается от кода страны терминала (Terminal Country Code);
• Cumulative Total Transaction Amount Limit – максимальный размер средств, которые можно потратить по карте в рамках последовательных офлайновых транзакций, сумма которых выражена в валюте Application Currency Code;
• Cumulative Total Transaction Amount Limit (Dual Currency) – максимальный размер средств, которые можно потратить в рамках последовательных офлайновых транзакций, сумма которых выражена в валюте Application Currency Code или какой-либо иной валюте, выбранной эмитентом. Очевидно, для каждого из перечисленных лимитов на карте поддерживаются соответствующие счетчики. Заметим, что в спецификациях VIS 1.4 лимиты на количество последовательных офлайновых операций определены только для международных транзакций (отдельно по валюте и коду страны терминала). Таким образом, локальный трафик офлайновых операций в VIS 1.4 регулируется только размером средств, потраченных в рамках офлайновых операций. Очевидно, что параметры управления рисками в спецификациях CPA позволяют описать схемы счетчиков, принятые в протоколах M/Chip4 и VIS 1.4, и более того, дают возможность описать и многие другие ограничения, позволяющие эмитенту формировать разнообразные правила обработки транзакции в офлайновом режиме.

Следует отметить, что процедуры управления рисками не специфицируются в стандарте EMV. EMVCo всегда считала разработку этих процедур прерогативой платежных систем и банков-эмитентов. В рамках спецификаций CPA на основе опыта использования уже используемых процедур на картах VIS 1.4 и M/Chip4 компания EMVCo впервые определила процедуру управления рисками карты. При этом спецификации CPA приняты Visa International и MasterCard Worldwide в качестве альтернативного стандарта для своих микропроцессорных карт.

Совершенно очевидно, что возможности карты CPA в части управления рисками гораздо выше в сравнении с возможностями карт стандартов VIS 1.4 и M/Chip4. Основные преимущества CPA состоят в следующем:
1. Формализована и внедрена процедура выбора способа обработки транзакции в зависимости от ее параметров (выбор профиля).
2. Расширен набор параметров управления рисками карты (большее количество различным образом настраиваемых счетчиков).
3. Эмитенту предоставлены широкие возможности для создания собственных правил принятия решения по способу обработки транзакции (Issuer Options). Следует отметить, что процедура выбора способа обработки транзакции (см. пункт 1) была доступна и в рамках других (не CPA) микропроцессорных карт. Однако стандартный механизм ее реализации был впервые формализован именно в спецификациях CPA.

Отметим, что EMVCo, идя навстречу банкам крупнейших международных платежных систем, к настоящему моменту определила два профиля карты – профиль для реализации процедур аутентификации держателя карты (CAP/TBA – Chip Authentication Program/Token Based Authentication) и профиль для операций на небольшие суммы (low value transactions). Известно, что платежные системы изначально рекомендовали банкам для реализации схем аутентификации держателя карты использовать отдельное (не платежное) EMV-приложение. Это требуется для того, чтобы не оказывать влияния на значения счетчиков платежного EMV-приложения функциональностью операций аутентификации. Для реализации функции CAP/TBA в соответствующем профиле платежного приложения, задаваемого CNP-транзакцией, необходимо определить объект AIP, в соответствии с которым карта не поддерживает ни один из методов динамической или статической аутентификации приложения, а объект CVM List состоит из единственного элемента – Plaintext PIN verification by ICC.Кроме того, в данном профиле не должны использоваться счетчики карты (все они дезактивированы), а объект CIAC-Decline должен указывать на необходимость отклонения транзакции в офлайновом режиме (например, установив бит Offline PIN Verification Performed равным 1).

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

Текст статьи читайте в журнале ПЛАС № 8-9 за 2006 год


Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


Читайте в этом номере:
обновить

а вы знаете, что...

… предоплаченные платежные карты возникли как платежный инструмент в середине 1990-х гг., и первыми из них были карты Electronic Benefits Transfer (EBT) в США, на которые заменили ранее выдаваемые нуждающимся бумажные продовольственные сертификаты?