Начинаем серию статей о безопасности в платежных технологиях. Тема большая, эта статья будет первой, вводной. О безопасности мы решили поговорить с Игорем Голдовским, главным архитектором и директором департамента, человеком, знающим все о платежных системах и их защите.
Вопросы безопасности в карточных платежных технологиях играют ключевую роль. Сама по себе банковская карта — средство, обеспечивающее удаленную аутентификацию ее держателя при совершении операции безналичной покупки или получения наличных. От надежности используемых методов аутентификации держателя карты в существенной степени зависит безопасность карточных операций в целом, а, следовательно, и доверие пользователей к картам как средству платежей.
С другой стороны, платежные технологии слепо не следуют за лозунгом «Безопасности много не бывает». Технологии, обеспечивающие высокий уровень безопасности, но при этом неудобные для использования и/или требующие значительных расходов/усилий на внедрение, оказываются на практике невостребованными.
В платежных технологиях всегда ищется баланс между уровнем обеспечиваемой безопасности, удобством пользователя и стоимостью внедрения
Одним из примеров, иллюстрирующих этот тезис, является неудачная попытка внедрения протокола Secure Electronic Transaction (SET), практически безупречного с точки зрения обеспечиваемой им безопасности обработки операций электронной коммерции. Стандарт появился в 1998 г. и начал использоваться банками, но уже к 2001 г. стало понятно, что его массовое быстрое внедрение невозможно из-за высокой стоимости предлагаемых на рынке решений, а также из-за проблем на стороне держателей карт, связанных с необходимостью удаленной установки и настройки клиентского ПО на их персональных компьютерах. В результате, платежные системы постепенно отказались от использования SET и начали внедрять значительно более простой в использовании и дешевый для банков/магазинов протокол 3-D Secure.
Ранее на рынке реализовывалась модель «брони и снаряда» — в ответ на очередной снаряд, полученный от мошенников, устанавливается броня нужной для этого снаряда толщины. Но карточные платежи – коммерческий бизнес, в котором меры противодействия должны быть достаточными с точки зрения безопасности, а также максимально необременительными и удобными для банков и пользователей.
Приведу один пример такого соревнования брони и снаряда. К концу 90-х ведущие платежные системы пришли к выводу о том, несмотря на все предпринятые ими усилия, для эффективной борьбы с поддельными картами необходимо переходить на совершенно новую технологию микропроцессорных карт. Микропроцессорные карты позволили радикальным образом повысить безопасность так называемых Card Present- транзакций, в которых карта находится в точке совершения операции, за счет обеспечения 2-х факторной динамической аутентификации держателя карты ее эмитентом. С их внедрением уровень мошенничества по поддельным картам снизился практически до нуля, но начал расти уровень мошенничества для CNP (Card Not Present)-операций, то есть тех, где в точке выполнения операции карты нет. В первую очередь речь об операциях электронной коммерции, рекуррентных платежах, Card-on-File операциях и пр. В настоящее время появились технологии, позволяющие обеспечить уровень безопасности CNP-операций, соизмеримый с операциями по микропроцессорным картам. Это и новая версия протокола 3-D Secure 2.0, и in-app платежи в телефонах, и токенизация карт, и операции удаленных платежей с использованием систем Secure Remote Commerce.
Поговорим о Secure Remote Commerce
Используемый вот уже два десятилетия платежными системами (ПС) протокол безопасной электронной коммерции 3D-Secure (v.1.0 и v.2.0) обеспечивает эмитенту возможность аутентификации держателя его карты в самом начале процедуры оплаты онлайновой покупки, до начала авторизации платежа эмитентом в платежной системе. Внедрение первой версии протокола позволило существенно повысить безопасность покупок в онлайновых магазинах. Новая версия протокола 3-D- Secure v.2.0 расширила возможности первой версии, позволяя совершать покупки из мобильного приложения магазина на смартфоне покупателя, а также обеспечивая выполнение операции без непосредственной аутентификации клиента его банком (в т.н. моде frictionless mode). В последнем случае платформа 3-D Secure v.2.0 производит оценку рисков для выполняемой операции и от лица эмитента принимает решение о возможности выполнить авторизацию транзакции без непосредственной аутентификации покупателя его банком. При принятии решения учитываются параметры покупки, а также информация об устройстве, с которого совершается операция, и о покупателе.
В то же время протокол 3-D Secure оставляет за скобками процедуры удобного для покупателя выбора платежного инструмента и оформления покупки, а также организации (при необходимости) процедуры аутентификации покупателя его банком. Определенные попытки заполнить пробел ранее предпринимались ведущими ПС, создавшими свои кошельки для выполнения удаленных платежей. Но сегодня уже можно признать — эти попытки оказались недостаточно удачными для того, чтобы завоевать сердца держателей карт. Протокол Secure Remote Commerce (SRC) — это новая попытка решить проблему создания удобного и безопасного для покупателя кошелька, предназначенного для удаленных платежей.
SRC представляет собой универсальный для держателей карт и торгово-сервисных предприятий (ТСП) механизм оплаты операций электронной коммерции.
Механизм оформлен в виде стандарта ассоциации EMVCo и оперативно взят на вооружение ведущими ПС. Некоторые международные платежные системы уже создали свои платформы SRC и в конце прошлого года запустили их в пилотном проекте на территории США. Механизм SRC реализуется на базе технической платформы, обеспечивающей для пользователя оформление оплаты покупки по принципу «нажатия одной кнопки» (one-click checkout). Кроме того, SRC повышает безопасность онлайновых операций за счет отсутствия необходимости ввода реквизитов карты (точнее, минимального использования этой процедуры) и токенизации инструментов оплаты.
SRC позволяет держателю карты при выполнении операции ЭК использовать на сайте ТСП «единую кнопку» для совершения платежа с помощью любого его платежного инструмента, зарегистрированного на платформе. Для этого SRC сама идентифицирует пользователя, отбирает платёжные инструменты пользователя, подходящие для оплаты покупки в данном ТСП, и дает возможность покупателю выбрать один из них. После регистрации в SRC при выполнении операции пользователю не нужно вводить информацию о себе, платежном инструменте и адресе доставки товаров. Все эти данные вводятся один раз при регистрации и потом хранятся на платформе SRC.
Ниже в очень упрощенном виде описана процедура выполнения покупки через систему SRC.
- ТСП (торговая площадка, поставщик платежного сервиса) после выбора покупателем кнопки SRC Triger отправляет в систему SRC данные о покупателе (например, биометрические данные покупателя, идентификатор мобильного приложения, из которого выполняется платеж), его устройстве (например, MAC-адрес устройства, версия ОС, идентификатор ОС и другие параметры, в общем случае до нескольких десятков характеристик) и самом ТСП (например, имя ТСП, код категории ТСП и т.п.). Следует заметить, что каждая платежная система имеет собственную систему SRC. Поэтому ТСП отправляет запросы во все системы SRC, принадлежащие ПС, карты которых принимает ТСП.
- Все SRC, получившие запрос ТСП, осуществляют распознавание (идентификацию) держателя карты и определяют его идентификатор. Если однозначную идентификацию выполнить не получается, покупателю будут заданы дополнительные вопросы для его окончательной идентификации (например, покупателя попросят ввести адрес его электронной почты)
- SRC выполняет поиск участников платформы, которые хранят сведения о всех зарегистрированных в SRC платежных инструментах (картах) идентифицированного покупателя. Такие участники SRC называются DCF (Digital Card Facilitator). В состав сведений о платежном инструменте входит информация об алиасе платежного инструмента, области его действия (в каких магазинах он может использоваться), а также инструкциях по выполнению процедуры аутентификации покупателя. Сегодня роль DCF выполняют сами платежные системы.
- ТСП получает из системы SRC список всех доступных покупателю для оплаты в данном ТСП платежных инструментов, отображает этот список покупателю, который выбирает один из них
- ТСП отправляет в систему SRC запрос, содержащий данные платежа и выбранного покупателем платежного инструмента
- Система SRC отправляет запрос DCF, представляющему выбранный пользователем платежный инструмент
- DCF отображает пользователю цифровую карту для выбранного платежного инструмента и в соответствии с инструкциями эмитента организует аутентификацию покупателя
- DCF отвечает системе SRC сообщением с результатом аутентификации покупателя, и система готовит данные для авторизационного запроса. Эти данные могут включать динамические данные транзакции, вычисленные с использованием криптографических алгоритмов
- Система SRC сообщает ТСП данные, необходимые для формирования авторизационного запроса, и ТСП инициирует процедуру авторизацию транзакции
- После получения ТСП ответа по результату авторизации, ТСП этот результат возвращает системе SRC, и система далее использует его в процедурах управления рисками при обработке будущих операций покупателя.
Очевидны преимущества внедрения системы SRC для покупателя:
- реализуется так желаемая им модель выполнения покупки «нажатием одной кнопки» (One click purchase): покупатель идентифицируется системой SRC по своему устройству и/или платежному приложению, ему дают возможность выбора карты, не нужно вводить реквизиты платежного инструмента и адреса доставки
- некоторые транзакции выполняются без аутентификации покупателя его банком с использованием процедур управления рисками, поддерживаемыми SRC
- обеспечивается универсальный способ совершения покупки и его аутентификации (одни и те же знакомые экраны, одни и те же действия)
- широкий выбор платежных инструментов (в будущем не только карты).
Для ТСП плюс от внедрения SRC в том, что за них комплексно и универсально решаются вопросы организации безопасных безналичных платежей. От магазина требуется всего лишь интегрировать в свой софт некоторое клиентское ПО системы SRC, обеспечивающее его интеграцию с SRC. Как пример, решения проблем магазина- использование токенизированных Card-on-File платежей, предлагаемых магазину платформой SRC. Также на стороне ТСП ожидается сокращение количества отказов покупателей от онлайновых покупок (abandonment rates) из-за недоверия покупателя к предлагаемому ему способу оплаты.
Очевидны преимущества SRC и для эмитентов карт. К ним относятся повышение безопасности операций (все операции токенизированы и выполняются на уровне безопасности EMV Chip, реквизиты карты вводятся на стороне ТСП только однажды при регистрации платежного инструмента), а также снижение abandonment rates.
Одним словом, платежные системы и их участники возлагают на внедрение SRC большие надежды, справедливо предполагая, что этот новый механизм удаленных платежей окажется максимально удобным для покупателя.