Опубликован: 24.10.2016 | Доступ: свободный | Студентов: 1352 / 467 | Длительность: 21:30:00
Лекция 12:

Модели объединения платежных систем

< Лекция 11 || Лекция 12 || Лекция 13 >

В настоящее время существует огромное множество электронных платежных систем, различающихся протоколами обмена и криптографической защиты передаваемых данных, числом и номиналом поддерживаемых валют, минимальным и максимальным порогом проведения микроплатежей, а также многими другими характеристиками платежных транзакций. Производители и продавцы могут ограничивать перечень платежных агентов, при помощи которых можно оплачивать производимые ими товары или услуги. Потребители в свою очередь могут быть приверженцами одной единственной платежной системы или банка, которые осуществляют оплату проводимых клиентом финансовых операций. Все вышеперечисленные факты приводят к необходимости создания объединенных платформ, обеспечивающих поддержку сервисов различных платежных систем. В данной главе дается описание нескольких таких платформ: европейской системы SEMPER, российской системы СБЕРКАРТ и российской Объединенной системы моментальных платежей.

12.1. SEMPER

SEMPER (Secure Electronic Technologics and Services)

Созданию платформы предшествовало появление системы CAFE (Conditional Access for Europe), в которой была предприняты попытка создания многофункциональной смарт-карты, поддерживающей значительное число платежных сервисов. Предполагалось, что данная смарт-карта станет единым средством оплаты товаров и услуг, заменив собой множество карт эмитентов, находящихся в обращении на территории Европы. Однако цель не была достигнута, и итогом кампании стало создание очередной, пусть и многофункциональной, платежной смарт-карты.

Неудачный опыт CAFE был учтен при разработке нового проекта. Любая защищенная электронная платежная транзакция требует участия третьей стороны или посредника, выполняющего определенные функции:

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

На рис. 12.1 представлена схема традиционного взаимодействия покупателя и продавца с участием посредника.

Взаимодействие участников защищенной платежной транзакции

Рис. 12.1. Взаимодействие участников защищенной платежной транзакции

Если и продавец, и покупатель входят в состав одной и той же платежной системы, то такое взаимодействие достаточно просто организовать. В противном случае возникает множество проблем, связанных с согласованием используемых протоколов, определением правил перевода средств между различными банковскими системами, а также размеров комиссий за осуществление платежных транзакций, введением дополнительного посредника между посредником покупателя и посредником продавца и т.д. SEMPER устраняет указанные проблемы путем возложения всех посреднических функций на прикладное программное обеспечение API SEMPER, что демонстрирует схема на рис. 12.2.

Взаимодействие участников защищенной платежной транзакции при помощи SEMPER

Рис. 12.2. Взаимодействие участников защищенной платежной транзакции при помощи SEMPER

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

Возможности API SEMPER

увеличить изображение
Рис. 12.3. Возможности API SEMPER

Архитектура SEMPER представляет собой четыре уровня ( рис. 12.4).

Архитектура SEMPER

Рис. 12.4. Архитектура SEMPER

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

Уровень приложений обмена данными обеспечивает "честный" обмен сообщениями. Под "честным" подразумевается обмен, гарантирующий покупателю доставку оплаченного товара или услуги и соответственно оплату продавцу предоставленных товара или услуги. Платежный документ, передаваемый на данном уровне, носит название контейнер (container) и может содержать в себе следующие сущности:

  • подписанный документ;
  • информация;
  • электронные деньги.

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

Уровень приложений передачи данных включает в себя четыре сущности, приведенные на рис. 12.5.

Структура уровня приложений передачи данных

увеличить изображение
Рис. 12.5. Структура уровня приложений передачи данных
  • Менеджер передачи данных (Transfer manager). Отвечает за синтаксический анализ, объединение и разделение контейнеров, а также формирование их заголовков и передачу выше- и нижележащим уровням.
  • Блок проведения платежей (Payment Service Block). Данный блок реализует концепцию "единой валюты", схематично представленной на рис. 12.6 (она позволяет обслуживать клиентов различных платежных систем).
Концепция «единой валюты» SEMPER

увеличить изображение
Рис. 12.6. Концепция «единой валюты» SEMPER

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

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

увеличить изображение
Рис. 12.7. Пример взаимодействия блока проведения платежей с платежными системами

Далее пользователь может свободно распоряжаться своими средствами, оперируя суммой, введенной в систему. Вывод денег из системы происходит в обратном порядке. С внутреннего кошелька пользователя деньги переводятся на счет или электронный кошелек платежной системы пользователя. Таким образом, пользователь любой платежной системы может осуществлять в рамках системы SEMPER привычные ему операции.

  • Блок проверки подлинности (Statement Service Block). Данный блок осуществляет проверку целостности и аутентичности сообщений, а кроме того, согласует при проведении транзакций обмена следующие параметры:
    • алгоритм формирования MAC,
    • алгоритм цифровой подписи,
    • алгоритм проверки цифровой подписи,
    • алгоритм симметричного шифрования,
    • алгоритм шифрования с открытым ключом,
    • хеш-функция,
    • алгоритм обмена ключами.
  • Блок сертификации (Certificate Service Block). Данный блок осуществляет проверку и аутентификацию параметров пользователя или платежной системы. Фактически данный блок преобразует все присланные пользователем при регистрации сертификаты и атрибуты в единый сертификат, имеющий хождение внутри системы SEMPER. На рис. 12.8 дана схема блока сертификации. В состав блока входят три сущности:
    • модуль регистрации (Registration Authority) - осуществляет прием данных пользователя при регистрации в системе,
    • модуль сертификации (Certification Authority) - формирует внутренний сертификат SEMPER (в соответствии с Х509.3) на основе данных, полученных от модуля регистрации,
    • модуль хранения сертификатов (Directory Authority) - хранит информацию о всех зарегистрированных в системе сертификатах и предоставляет их криптомодулям в случае необходимости.
Структура блока сертификации

увеличить изображение
Рис. 12.8. Структура блока сертификации

Уровень служб поддержки (Supporting Services Layer) включает в себя определенные блоки, представленные на рис. 12.9.

Структура уровня служб поддержки

увеличить изображение
Рис. 12.9. Структура уровня служб поддержки
  • Блок соединения (communication block) - осуществляет передачу данных между двумя пользователями SEMPER.
  • Криптомодуль (crypro block). Реализует защищенный канал взаимодействия пользователей SEMPER. Логика работы данного блока схожа с организацией защищенного соединения протоколом SSL. На начальном этапе блоки проверки подлинности согласуют параметры взаимодействия (по аналогии с протоколом Handshake в SSL), затем криптомодуль обеспечивает безопасную передачу данных (по аналогии с протоколом Record в SSL), как показано в схеме на рис. 12.10.
  • Блок свойств (Preference Block). Определяет характерные особенности текущего соединения.
  • Блок контроля доступа (Access Control Block). По сути, сторожевой процессор, обеспечивающий корректное функционирование всех остальных блоков и регламентирующий политику безопасности.
  • Архивный блок (Archive Block). Предназначен для архивации и хранения локальных данных.
  • Блок интерфейса (TINGUIN - Trusted Interactive Graphical User Interface).
Безопасная передача данных в SEMPER

увеличить изображение
Рис. 12.10. Безопасная передача данных в SEMPER

12.2. СБЕРКАРТ

Идеи создания национальной платежной системы России появились давно, но воплощаться в жизнь они начали лишь в 2005 г. после опубликования исследований Федеральной антимонопольной службы, показавших, что 50% безналичных платежей в России контролируются компаниями Visa International и MasterCard. Кроме того, на долю данных компаний приходилось 60% эмитированных карт и свыше 70% пунктов выдачи наличных и банкоматов. Такая ситуация перестала устраивать национальных игроков, и в этом же году Сбербанк Российской Федерации принял решение о создании национальной платежной системы, которая получила название СБЕРКАРТ.

Подход Сбербанка в точности копирует идеологию CAFE - создать единую смарт-карту осуществления платежей. Несмотря на то что CAFE потерпела неудачу, существует ряд факторов, позволяющих с оптимизмом смотреть на будущее системы СБЕРКАРТ. Во-первых, Сбербанк является одним из крупнейших банков на территории России. Во-вторых, большая часть коммунальных и налоговых платежей, которые в скором времени планируется сделать электронными, проходит именно через Сбербанк. Кроме того, данный проект поддерживается Правительством Российской Федерации.

На рис. 12.11 показана схема взаимодействия участников состемы СБЕРКАРТ.

Структура системы СБЕРКАРТ: 1 - корреспондентский счет и обеспечительный депозит; 2 - реестр сообщений; 3 - сведения о счетах Принципиальных Членов Системы; 4 - расчетные отношения; 5 - процессинг операций эквайринга

увеличить изображение
Рис. 12.11. Структура системы СБЕРКАРТ: 1 - корреспондентский счет и обеспечительный депозит; 2 - реестр сообщений; 3 - сведения о счетах Принципиальных Членов Системы; 4 - расчетные отношения; 5 - процессинг операций эквайринга

В состав системы СБЕРКАРТ входят следующие участники.

  • Оператор системы. Юридическое лицо, выполняющее функции координации и обеспечения деятельности Системы в целом. Функции оператора выполняет ЗАО "СБЕРКАРТА".
  • Расчетный банк. Кредитная организация, уполномоченная Оператором Системы осуществлять клиринговые расчеты. Расчетным банком системы СБЕРКАРТ является Сбербанк Российской Федерации.
  • Члены системы. Кредитные организации, установившие договорные отношения с Оператором системы и осуществляющие на этом основании платежные операции. Члены системы могут быть:
    • принципиальными - осуществляющими взаимодействие с Расчетным банком напрямую;
    • ассоциированными - осуществляющими взаимодействие с Расчетным банком через Принципиального Члена системы.
  • Провайдер. Юридическое лицо (процессинговый центр), уполномоченное Оператором Системы на предоставление Принципиальным и связанным с ними Ассоциированным Членам системы процессинговых услуг исключительно по операциям эквайринга.

Взаимодействие с пользователем осуществляется при помощи автоматизированной системы расчетов DUET, использующей для работы многофункциональные карты DUET MF-card (Multifunctional card) стандарта EMV. Карта позволяет открывать несколько финансовых и нефинансовых приложений. Менять функциональные возможности карты можно удаленно, а также при помощи устройств самообслуживания Сбербанка. Карта поддерживает бесконтактные технологии, что позволяет ее использовать в качестве "социальной карты". Безопасность карты обеспечивается использованием алгоритма 3DES с длиной ключа 112 бит и PIN-кодом. Кроме того терминальные устройства для работы с картами СБЕРКАРТ планируется оснастить устройством идентификации клиента при помощи биометрических данных.

По состоянию на 1 августа 2009 г. участниками системы являются 24 банка, среди которых можно выделить Сбербанк, ВнешПромБанк, АКБ "Первый Инвестиционный" и АКБ "1-й Процессинговый". Некоторые дополнительные данные о системе СБЕРКАРТ приведены в табл. 12.1.

Таблица 12.1. Сведения о системе СБЕРКАРТ
Выпущено карт Число пунктов выдачи наличных Число банкоматов Число платежных терминалов Число информационно-платежных терминалов
> 3 100 000 17 900 18 500 58 000 5 600

12.3. Объединенная система моментальных платежей

В июле 2009 г. о своем слиянии объявили два крупнейших российских игрока в сфере приема электронных платежей - Объединенная система моментальных платежей (бренд QIWI) и e-port. Процесс объединения операторов производится гораздо проще, нежели создание межбанковской системы. В последнем случае требуется принципиальное согласие самого банка, наличие процессинговых центров, согласование множества протоколов передачи данных. В случае же объединения операторов достаточно введение системы межоператорного перевода средств. При этом операция по переводу средств на кошелек другого оператора практически не отличается от перевода средств внутри системы. Схема слияния представлена на рис. 12.12.

Модель объединения операторов платежных терминалов

увеличить изображение
Рис. 12.12. Модель объединения операторов платежных терминалов
< Лекция 11 || Лекция 12 || Лекция 13 >