«Платежные и расчетные ПРС системы Международный опыт Выпуск 39 Платежи, совершаемые с использованием мобильного телефона Белая книга 2013 © Центральный банк Российской Федерации, 2007 107016, Москва, ул. Неглинная, 12 ...»

С точки зрения предприятия торговли этот сценарий очень похож на SCP 1.

Перед началом исполнения сценария потребитель должен активировать карту (карты) для совершения дистанционных платежей в меню конфигурации мобильного кошелька.

На рисунке 12 отражены следующие действия:

1. Зайдя в сеть Интернет с помощью своего мобильного телефона или с использованием специального приложения MRP, потребитель переходит в раздел расчетов на сайте предприятия торговли.

2. Сайт предприятия торговли выводит платежную информацию на дисплей мобильного телефона потребителя.

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

4. После авторизации платежа по карте SEPA он обрабатывается.

5. Предприятие передает потребителю товары или оказывает услуги.

Рисунок 12. Платеж по карте SEPA потребителя – предприятию: мобильный кошелек МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

Таблица 12. Кредитовый перевод по карте SEPA потребителя – предприятию (SCP 2):

мобильный кошелек Кредитовый перевод по карте SEPA потребителя – предприятию (SCP 2): мобильный кошелек Категория «Потребитель – предприятию» (C2B), также относится к B2B Платежное средство Карта SEPA – любой тип (SCF) Инициатор платежа Предприятие торговли (услуг) Необходимые условия • Предприятие торговли (услуг) принимает дистанционные платежи, совершаемые потребителем посредством платежной карты по данной карточной схеме Способ подтверждения платежа Как в случае любой другой дистанционной операции по карте SEPA Выгоды для торгового предприятия • Доступ к более широкой базе данных по держателям карт Выгоды для потребителя • Удобство, мобильность • Удобство для потребителя в выборе платежной карты с соответствующими удостоверительными данными с использованием мобильного кошелька. Снижается Проблемы •Отсутствуют особые проблемы в мобильном канале по сравнению с другими дистанционными платежами, совершенными потребителем в сети Интернет посредством платежной карты • Аутентификация пользователя: поскольку ему не разрешается сохранять защитный код карты, потребитель должен вводить этот код, чтобы совершить операцию, 5.2.1.3. Кредитовый перевод по карте SEPA потребителя – предприятию (SCP 3): надежная аутентификация держателя карты (С2В) Этот сценарий отличается от описанного выше сценария SCP 2 тем, что плательщик должен совершить дополнительные действия для аутентификации. Поскольку в дистанционных операциях по карте может использоваться карточная аутентификация, такая как CAP (Chip Authentication Program) или DPA (Dynamic Passcode Authentication), использование SE в мобильном телефоне с установленным специальным приложением аутентификации может быть очень удобным для потребителя. Это приложение аутентификации используется после ввода потребителем мобильного кода в мобильный телефон:

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

Кроме того, если в мобильном телефоне уже установлено приложение MCP в SE, это может быть финансово выгодным решением.

Эмитент карты (карт) должен установить специальное приложение аутентификации в SE в мобильном телефоне потребителя. Кроме того, потребитель должен включить это приложение аутентификации, например, в меню конфигурации мобильного кошелька.

В качестве альтернативы, если плательщик имеет мобильный телефон с NFC и бесконтактную карту, включая приложение аутентификации, такое как CAP или DPA, он может осуществить аутентификацию, вставив карту в считывающее устройство с технологией NFC в мобильном телефоне. Опять же, использование этого метода аутентификации осуществляется после ввода мобильного кода потребителем в мобильном телефоне.

На рисунке 13 отражены следующие действия:

1. Зайдя в сеть Интернет с помощью своего мобильного телефона или с использованием специального приложения MRP, потребитель переходит в раздел расчетов на сайте предприятия торговли (услуг).

2. Сайт предприятия торговли (услуг) выводит платежную информацию на дисплей мобильного телефона потребителя.

3. Реквизиты платежной карты потребителя передаются через мобильный кошелек, после чего инициируется операция SCP. Приложение аутентификации в платежной карте удостоверяет потребителя.

4. После успешной аутентификации платеж разрешается.

5. После авторизации платеж SCP обрабатывается.

6. Предприятие торговли (услуг) передает потребителю товар или оказывает услугу.

Рисунок 13. Платеж по карте SEPA потребителя – предприятию (SCP 3): надежная Таблица 13. Кредитовый перевод по карте SEPA потребителя – предприятию (SCP 3):

надежная аутентификация держателя карты Кредитовый перевод по карте SEPA потребителя – предприятию: надежная аутентификация держателя карты Категория «Потребитель – предприятию» (C2B), также относится к B2B Платежное средство Карта SEPA – любой тип (SCF) Инициатор платежа Предприятие торговли Необходимые условия • Предприятие торговли принимает дистанционные платежи, совершаемые потребителем посредством платежной карты по данной карточной схеме Способ подтверждения платежа Как в случае любой другой дистанционной операции по карте SEPA Выгоды для торгового предприятия • Доступ к более широкой базе держателей карт • Меньше случаев совершения несанкционированных операций с дистанционными платежами по картам Выгоды для потребителя • Удобство, мобильность Проблемы • Отсутствуют особые проблемы в мобильном канале связи по сравнению с 5.2.1.4. Кредитовый перевод по карте SEPA потребителя – потребителю (SCP 4) (C2C) На рисунке 14 показан возможный пример действий пользователя при совершении платежа в зоне SEPA «потребитель – потребителю», инициированного с мобильного телефона, когда потребитель (плательщик) желает произвести персональный платеж другому потребителю (получателю) с помощью своего мобильного телефона.

В данном примере главное отличие от обычного платежа в зоне SEPA в том, что операция инициирована плательщиком, а не получателем. Платеж обрабатывается в сетях карточной схемы, и сумма платежа обычным образом списывается со счета платежной карты плательщика. Получатель обычно (но не МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

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

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

Многие крупные карточные схемы уже предлагают некоторые проприетарные услуги C2C, но для их широкого распространения в SEPA нужно обеспечить операционную совместимость.

На рисунке ниже отражены следующие действия:

1. Плательщик определяет сумму, которую необходимо уплатить.

2. Плательщик выбирает свое приложение MRP.

3. Плательщик вводит сумму и уникальный идентификатор получателя, подтверждает номер карты, которая будет использоваться для платежа, и разрешает операцию.

4. PSP плательщика получает идентификационные данные получателя на основе уникального идентификатора.

5. PSP плательщика отправляет платеж в PSP получателя.

6.Затем PSP получателя зачисляет платеж на основной платежный счет получателя (возможно, с уведомлением).

Можно расширить этот пример использования, рассмотрев случаи, когда требуется «срочный» или «быстрый» платеж. «Быстрый» сервис C2C SCP подойдет для сценариев, при которых:

• получатель должен использовать денежные средства незамедлительно;

• получателю требуется уверенность в получении платежа, чтобы выполнить связанную с ним операцию, например сделку купли-продажи товаров или предоставления услуг между незнакомыми лицами.

Рисунок 14. Кредитовый перевод по карте SEPA потребителя – потребителю (SCP 4) Таблица 14. Кредитовый перевод по карте SEPA потребителя – потребителю (SCP 4) Категория Главным образом «потребитель – потребителю» (C2C), некоторые сценарии – «потребитель – предприятию» (например, малому) (C2B) Платежное средство Карта SEPA – любой тип (SCF) Инициатор платежа Плательщик Необходимые условия • Получатель идентифицируется по уникальному идентификатору, обычно, но не обязательно – по платежной карте • Плательщик имеет карту, отвечающую требованиям SCF, и подписан на услуги мобильной карточной платежной системы C2C у своего PSP (эмитент карт) Способ подтверждения платежа Определяется PSP (эмитент карт) Выгоды для потребителя • Скорость и легкость для обоих потребителей • Позволяет плательщику сохранить удостоверительные данные в тайне, а получателю не требуется раскрывать реквизиты счета Проблемы • Обеспечение операционной совместимости карточных схем • Неудобство для держателя карты в связи с необходимостью ввода своих удостоверительных данных в мобильный телефон (можно решить, например, путем использования мобильного кошелька) 5.2.2. дИСТАНЦИОННЫЕ КРЕдИТОВЫЕ ПЕРЕВОдЫ SEPA, СОВЕРШАЕМЫЕ

С ИСПОЛЬЗОВАНИЕМ МОБИЛЬНОГО ТЕЛЕФОНА

Следующие примеры использования основаны на SCT в качестве основного платежного средства SEPA.

Обратите внимание, что в соответствии с действующими правилами SCT максимальное время обработки операции между PSPs для SCT – один рабочий день (D+1), согласно PSD.

Независимо от действий по инициированию реальная операция SCT всегда основана на использовании IBAN и BIC13.

5.2.2.1. Кредитовый перевод SEPA потребителя потребителю (SCT 1) – C2C, SCT На рисунке 15 показан основной пример действий пользователя по платежу SCT, инициированному с использованием мобильного телефона, когда потребитель (плательщик) производит платеж с собственного платежного счета на платежный счет другого потребителя (получателя). Плательщик и получатель могут являться и часто действительно являются клиентами разных поставщиков платежных услуг (PSP) (четырехсторонняя модель14, см. разделы 5.4.3.2 и 5.4.3.3).

В этом сценарии не предполагается изначального доверия между плательщиком и получателем. Плательщик и получатель получают услуги одного уровня от своих PSPs, как и в случае других SCT.

Во многих обстоятельствах этот пример использования также относится к C2B, B2C и B2B (в частности, малые предприятия).

На рисунке ниже отражены следующие действия.

1. Получатель предоставляет всю необходимую информацию, включая IBAN и BIC, плательщику.

2. Плательщик предоставляет всю необходимую информацию, включая IBAN и BIC получателя, своему PSP по своему мобильному телефону. Эта информация может быть полностью введена плательщиком или может быть запрошена, если получатель заранее зарегистрирован. Обычно это делается с использованием специального приложения PSP в мобильном телефоне или через мобильный браузер.

3. Плательщик, аутентификация которого проведена его PSP, разрешает инструкцию SCT в соответствии с обычными требованиями безопасности, установленными этим PSP.

4. Затем PSP плательщика обрабатывает и передает SCT в PSP получателя, который, в свою очередь, зачисляет сумму на счет получателя.

В соответствии с Положением SEPA необходимость использования BIC потребителями исчезнет самое позднее к февралю 2016 года, а в большинстве случаев – к февралю 2014 года (по внутренним операциям).

Ссылка на четырехстороннюю модель не означает, что трехсторонние модели не могут быть улучшены на основе рассмотренных здесь примеров.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

Рисунок 15. Кредитовый перевод SEPA потребителя – потребителю (SCT 1) Таблица 15. Кредитовый перевод SEPA потребителя – потребителю Категория «Потребитель – потребителю» (C2C), также относится к C2B и B2B.

Платежное средство Кредитовый перевод SEPA Инициатор платежа Плательщик Необходимые условия Плательщик подписывается на услугу дистанционных платежей, совершаемых с Способ подтверждения платежа Определяется PSP Выгоды для потребителя • Мобильность для плательщика Проблемы • Неудобство в связи с необходимостью получения удостоверительных данных 5.2.2.2. Кредитовый перевод SEPA потребителя – потребителю (SCT 2): уникальный идентификатор (C2C, SCT) На рисунке 16 показан возможный пример действий пользователя по платежу SCT, инициированному с мобильного телефона, когда потребитель (плательщик) производит платеж с собственного платежного счета на платежный счет другого потребителя (получателя). Плательщик и получатель могут являться и часто действительно являются клиентами разных PSP (четырехсторонняя модель15, см. разделы 5.4.3. и 5.4.3.3).

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

Во многих обстоятельствах этот пример использования также относится к C2B, B2C и B2B (в частности, малые предприятия).

Ссылка на четырехстороннюю модель не означает, что трехсторонние модели не могут быть улучшены на основе рассмотренных здесь примеров.

Идентификационные данные получателя должны быть зарегистрированы вместе с его уникальным идентификатором.

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

PSP плательщика должен быть способен определить PSP получателя и реквизиты платежного счета на основе уникального идентификатора получателя через общую инфраструктуру (см. раздел 5.4.2.3).

На рисунке 16 отражены следующие действия:

1. Получатель предоставляет плательщику свои идентификационные данные с использованием псевдонима получателя для удобства и/или безопасности.

2. Плательщик передает необходимую информацию (сумма, псевдоним получателя и т.д.) своему PSP по мобильному телефону. Обычно это делается с использованием специального приложения MRP в телефоне или через мобильный браузер.

3. Плательщик, аутентификация которого проведена его PSP, разрешает инструкцию SCT в соответствии с обычными требованиями безопасности, установленными этим PSP.

4. PSP плательщика устанавливает идентификационные данные получателя и идентифицирует PSP получателя с использованием псевдонима получателя по общей инфраструктуре.

5. Затем PSP плательщика обрабатывает и передает SCT в PSP получателя, который, в свою очередь, зачисляет сумму на счет получателя.

Рисунок 16. Кредитовый перевод SEPA потребителя – потребителю: уникальный идентификатор Таблица 16. Кредитовый перевод SEPA потребителя – потребителю (SCT 2): уникальный идентификатор Кредитовый перевод SEPA потребителя – потребителю: уникальный идентификатор Категория «Потребитель – потребителю» (C2C), также относится к C2B и B2B Платежное средство Кредитовый перевод SEPA Инициатор платежа Плательщик Необходимые условия • Получатель или PSP получателя зарегистрировали свои идентификационные данные в общей инфраструктуре • PSP плательщика должен предлагать мобильную платежную услугу на основе использования псевдонима МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

Способ подтверждения платежа Определяется PSP Выгоды для потребителя • Удобство, мобильность Проблемы • Необходимость договоренности о формате псевдонима 5.2.2.3. Кредитовый перевод SEPA потребителя – предприятию (SCT 3A): подтверждение (C2B, C2C, B2B SCT) На рисунке 17 показан возможный пример действий пользователя по платежу SCT, инициированному с мобильного телефона, когда потребитель (плательщик) производит платеж с собственного платежного счета на платежный счет получателя. Плательщик и получатель могут являться и часто действительно являются клиентами разных PSPs (четырехсторонняя модель16, см. разделы 5.4.3.2 и 5.4.3.3).

В этом примере использования «подтверждение платежа», направляемое получателю, важно для того, чтобы SCT был приемлемой формой платежа (например, предприятию торговли требуется достаточная уверенность в проведении платежа перед передачей товаров или оказанием услуг). Обычно, но не всегда здесь реализуется сценарий «потребитель – предприятию» (предприятию торговли) C2B. Однако можно предусмотреть ситуации C2C (например, продажа автомобиля или иных ценных предметов) и B2B (например, сделки между коммерсантами).

Идеальным вариантом, хотя и не обязательным, стало бы использование универсального идентификатора согласно определению в предыдущем сценарии. Этот пример использования также относится к C2C, B2C и B2B (малые предприятия) с учетом регистрации в общей, совместно используемой службе «подтверждения платежа».

На рисунке 17 отражены следующие действия:

1. Плательщик и получатель договариваются о сумме, которая должна быть уплачена, и получатель передает плательщику свои идентификационные данные, при этом возможно использование уникального идентификатора для удобства и/или безопасности.

2. Плательщик передает необходимую информацию (сумма, псевдоним получателя и т.д.) своему PSP по своему мобильному телефону. Обычно это делается с использованием специального приложения MRP в телефоне или через мобильный браузер.

3. Плательщик, аутентификацию которого проводит его PSP, разрешает инструкцию SCT в соответствии с обычными требованиями безопасности, установленными этим PSP.

4. PSP плательщика устанавливает идентификационные данные получателя и идентифицирует PSP получателя (например, с использованием псевдонима получателя) по общей инфраструктуре.

5. PSP плательщика сообщает в службу «подтверждения платежа» о платеже SCT, в том числе идентификационные данные получателя и соответствующего PSP.

6. В качестве участника службы «подтверждения платежа» PSP получателя получает подтверждение, что SCT в безотзывном порядке произведен PSP плательщика.

7. PSP получателя передает ему подтверждение.

8. Затем PSP плательщика обрабатывает и передает SCT в PSP получателя, который, в свою очередь, зачисляет сумму на счет получателя.

Ссылка на четырехстороннюю модель не означает, что трехсторонние модели не могут быть улучшены на основе рассмотренных здесь примеров.

Рисунок 17. Кредитовый перевод SEPA потребителя – предприятию (SCT 3A): подтверждение Таблица 17. Кредитовый перевод SEPA потребителя – предприятию (SCT 3A): подтверждение Кредитовый перевод SEPA потребителя – предприятию: подтверждение Категория «Потребитель – предприятию» (C2B), также относится к B2B.

Платежное средство Кредитовый перевод SEPA Инициатор платежа Плательщик Необходимые условия • Создание службы «подтверждения платежа»

• Плательщик должен иметь возможность направить своему PSP инструкции относительно обращения в службу «подтверждения платежа».

Способ подтверждения платежа Определяется PSP Выгоды для потребителя • Удобство, мобильность, оперативность • Получателю приходит немедленное подтверждение окончательного характера «подтверждения платежа» направляет подтверждение немедленно, платеж не является (не обязательно является) таковым Проблемы •Создание и эксплуатация службы «подтверждения платежа»

5.2.2.4. Кредитовый перевод SEPA потребителя – предприятию (SCT 3B): подтверждение через службу электронных платежей (C2B, SCT) В этом сценарии как PSP плательщика, так и PSP получателя относятся к одной и той же службе электронных платежей на основе SCT, которая включает службу «подтверждения платежа». Кроме того, получатель является предприятием торговли (услуг), зарегистрированным в службе электронных платежей. Платеж проводится таким же образом, как и операция SCT, инициированная с компьютера или планшетного компьютера, но в данном случае он инициируется с мобильного телефона.

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

Так как реквизиты PSP (или платежного счета) получателя уже зарегистрированы в службе электронных платежей, нет необходимости использовать уникальный идентификатор. Кроме того, поскольку эта Должна работать служба передачи уведомлений между получателем (торговым предприятием) и его PSP для подтверждения последним проведения платежа до передачи товаров или услуг плательщику.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

служба передает подтверждение платежа зарегистрированным в ней предприятиям торговли, организовывать отдельный процесс «подтверждения платежа» для получателей не требуется.

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

На рисунке 18 показаны следующие действия:

1. Плательщик, делая покупку посредством мобильного устройства (мобильный браузер или приложение), выбирает на кассе опцию «электронный платеж».

2. Плательщику передается список участвующих PSP.

3. Он выбирает своего PSP из списка.

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

5. Плательщик, аутентификацию которого проводит его PSP, разрешает инструкцию SCT в соответствии с обычными требованиями безопасности, установленными этим PSP.

6. PSP плательщика сообщает в службу электронных платежей о платеже SCT, в том числе идентификационные данные получателя и соответствующего PSP. В качестве участника службы электронных платежей PSP получателя получает подтверждение, что SCT будет в безотзывном порядке произведен PSP плательщика.

7. PSP получателя передает ему подтверждение.

8. Затем PSP плательщика обрабатывает и передает SCT в PSP получателя, который, в свою очередь, зачисляет сумму на счет получателя.

Рисунок 18. Кредитовый перевод SEPA потребителя – предприятию (SCT 3B):

подтверждение через службу электронных платежей Таблица 18. Кредитовый перевод SEPA потребителя – предприятию (SCT 3B): подтверждение через службу электронных платежей Кредитовый перевод SEPA потребителя – предприятию: подтверждение через службу электронных платежей Платежное средство Кредитовый перевод SEPA Инициатор платежа Получатель (через службу электронных платежей) Необходимые условия • Наличие службы электронных платежей • Получатель (предприятие торговли) должен быть зарегистрирован в службе электронных платежей Способ подтверждения платежа Определяется службой электронных платежей Выгоды для потребителя • Удобство для плательщика Проблемы • Договоренность о подтверждении платежа со службой электронных платежей (не Примечание. В случае если PSPs зарегистрированы в разных службах электронных платежей, должна существовать структура, обеспечивающая операционную совместимость (см. также 5.4.3.3), которой отвечают обе службы электронных платежей. Кроме того, в данном случае эта структура также обеспечивает работу службы «подтверждения платежа».

5.2.2.5. Срочный кредитовый перевод SEPA потребителя – потребителю (C2C, uSCT) На рисунке 19 показан возможный пример действий пользователя по срочному платежу SCT, инициированному с использованием мобильного телефона, когда потребитель (плательщик) совершает быстрый платеж со своего собственного платежного счета на платежный счет другого потребителя (получателя).

Плательщик и получатель платежа могут являться и часто действительно являются клиентами разных PSPs. Этот сценарий может также относиться к операциям «потребитель – предприятию», поскольку «мгновенный» характер перевода позволяет получателю подтвердить получение денежных средств у своего PSP до передачи товаров или услуг.

Схема SCT SEPA в настоящее время не предлагает быстрого перевода платежей. Однако это не препятствует тому, чтобы в будущем «быструю» или «мгновенную» услугу предложили бы все или некоторые участники SCT.

По мере того, как все больше новых участников рынка предлагают более широкий выбор пользователям платежных услуг, весьма вероятен рост спроса на «мгновенное» выполнение всех операций, в том числе платежных. Ожидается, что PSPs должны будут разработать подобные решения, чтобы оставаться конкурентоспособными, в частности в области мобильных услуг.

Для целей данного сценария эта концепция именуется срочным кредитовым переводом SEPA (uSCT).

Во многих ситуациях этот пример использования также относится к C2B, B2C и B2B (в частности, для малых предприятий).

На рисунке ниже показаны следующие действия:

1. Получатель передает свои данные плательщику с использованием уникального идентификатора получателя для удобства и/или безопасности.

2. Плательщик передает необходимую информацию (сумма, уникальный идентификатор получателя и т.д.) своему PSP по мобильному телефону. Обычно это делается с использованием специального приложения MRP в телефоне или через мобильный браузер.

3. Плательщик, аутентификацию которого проводит его PSP, разрешает инструкцию SCT в соответствии с обычными требованиями безопасности, установленными этим PSP.

4. Затем PSP плательщика обрабатывает и передает uSCT в PSP получателя, который, в свою очередь, зачисляет сумму на счет получателя.

5. Получатель имеет возможность получить от своего PSP (почти мгновенно) подтверждение того, что платеж получен (например, мобильное уведомление), и получить доступ к денежным средствам.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

Рисунок 19. Срочный кредитовый перевод SEPA потребителя – потребителю Примечание. На этом рисунке не представлен механизм получения идентификационных данных получателя и его PSP по номеру мобильного телефона.

Таблица 19. Срочный кредитовый перевод SEPA потребителя – потребителю Категория «Потребитель – потребителю» (C2C), также относится к B2B, C2B и B2C Платежное средство Кредитовый перевод SEPA Необходимые условия Создание uSCT SEPA Способ подтверждения платежа Определяется PSP Выгоды для потребителя • Удобство, мобильность, оперативность Этот пример использования фактически совпадает с примером использования SCT 2, когда платеж совершается незамедлительно с использованием срочного кредитового перевода SEPA (uSCT).

5.3. ЭКОСИСТЕМА 5.3.1. ВВЕдЕНИЕ Одна из целей EPC – развитие платежных средств SEPA, поэтому в настоящей «Белой книге» рассмотрены только экосистемы, отвечающие требованиям SEPA18. Это касается как четырехсторонних, так и трехсторонних моделей (см. раздел 5.4.3), при условии, что в последних используются форматы, отвечающие требованиям SEPA. Это также означает, что для MRPs должны использоваться платежные счета.

Желательно использовать существующие инфраструктуру и бизнес-процессы платежных средств SEPA в максимально возможной степени. Это означает, что внимание должно быть сосредоточено на том, каким образом использовать мобильный телефон, чтобы инициировать операции SEPA и вписать их в существующие платежные инфраструктуры, позволив им затем обрабатывать платежи в соответствии с существующими платежными схемами SEPA.

5.3.2. ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ • Плательщик, имея платежный счет SEPA или карту, отвечающую требованиям SEPA, и мобильный телефон, должен иметь действующую подписку на услуги MNO. Хотя в настоящей «Белой книге» рассмаОбратите внимание, что примеры использования и модели обслуживания, представленные здесь, могут также действовать за пределами зоны SEPA.

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

• Получатель имеет платежный счет SEPA и, в соответствующих случаях, карту, отвечающую требованиям SEPA. Если получатель является частным потребителем / малым предприятием, возможны ситуации, когда получателю удобнее воспользоваться мобильным телефоном для получения дополнительных услуг, таких как уведомление о проведенном платеже.

• PSP предлагает платежные услуги SEPA, отвечающие нормативно-правовым требованиям / требованиям безопасности.

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

• Функции платежной системы обеспечиваются отвечающей требованиям SEPA платежной схемой и механизмом клиринга и расчетов (CSM).

• В случае если для MRP используется специальное приложение MRP в мобильном телефоне, эмитентом MRP является PSP, отвечающий за предоставление этого приложения плательщику. Обычно это приложение находится в SE в мобильном телефоне.

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

• Доверенный сервис-менеджер (TSM) является TTP, действующей от имени эмитентов SE и/или эмитентов приложения MRP для формирования открытой экосистемы в случае, если SE используется для размещения приложения (приложений) MRP. Могут существовать одновременно несколько TSMs, которые предлагают взаимно конкурирующие услуги.

5.3.3. МОдЕЛИ ОБСЛуЖИВАНИЯ 5.3.3.1. Платежная операция Дистанционные платежи по картам SEPA C2B не влияют на платежные операции по картам SEPA, на которых они основаны. Следовательно, для этих мобильных дистанционных платежей, совершаемых путем введения реквизитов платежной карты SEPA, модели обслуживания не меняются по сравнению с моделями платежных операций по картам SEPA.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

Для дистанционных платежей по картам SEPA C2C требуется новая TTP, управляющая общей платформой карточной схемы P2P для получения идентификационных данных получателя (см. раздел 5.2.1.4).

TTP не влияет на платежные операции по картам SEPA, на которых основываются дистанционные платежи, но может повлиять на модель обслуживания.

Основные мобильные дистанционные платежи SCT C2C, представленные в подразделе 5.2.2.1, не влияют на платежные операции SCT, на которых они основываются; следовательно, существующая модель обслуживания продолжает действовать.

Другие примеры использования, представленные в подразделах 5.2.2.2, 5.2.2.3 и 5.2.2.4, не меняют платежных операций SCT. Однако дополнительные особенности в этих примерах использования могут повлиять на существующие модели обслуживания SCT в связи с появлением новых TTP.

Заключительный пример использования C2C, представленный в подразделе 5.2.2.5, требует изменений в механизме проведения платежа SCT, на котором он основывается, в связи с незамедлительностью. Однако модель обслуживания SCT должна остаться неизменной.

5.3.3.2. Обеспечение и управление В зависимости от конкретного MRP платежная информация, хранящаяся в мобильном телефоне, может изменяться: от одних лишь платежных реквизитов до специального приложения MRP в SE. Очевидно, обеспечение и управление по этой платежной информации будут соответствующим образом отличаться. Некоторая дополнительная информация приведена в разделе 7.3.

5.4. АРхИТЕКТуРА ВЫСОКОГО уРОВНЯ 5.4.1. ВВЕдЕНИЕ Для дистанционных платежей архитектура высокого уровня может не зависеть от того, является ли платежное средство, на котором они основаны, картами в зоне SEPA или SCT.

Рисунок 21. Архитектура высокого уровня для дистанционных платежей, совершаемых с использованием мобильного телефона На рисунке 21 можно выделить три уровня:

• Уровень 1. Возможности подключения и пользовательский интерфейс, используемые для инициирования платежа Для инициирования дистанционного платежа посредством мобильного телефона могут использоваться различные способы, такие как мобильный браузер, SMS или специальное приложение MRP. Следовательно, возможности подключения и пользовательский интерфейс важны для обеспечения удобства действий пользователя на этом этапе, но они также относятся к конкурентному пространству.

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

• Уровень 2. Общая инфраструктура, используемая для ускорения платежей Компонент ускорения платежей помогает определить платежные средства, используемые двумя сторонами дистанционной платежной операции. Существуют различные модели. Обе стороны могут добровольно раскрыть друг другу реквизиты платежного средства (например, IBAN и BIC); они могут полагатьМЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

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

• Уровень 3. Платежное средство для денежных переводов и движения денежных средств Фактические денежные переводы и движение денежных средств осуществляются с использованием существующих платежных средств SEPA.

5.4.2. ВОЗВРАщЕНИЕ НА уРОВЕНЬ 5.4.2.1. Введение Главное назначение общей инфраструктуры – связать идентификатор / уникальный идентификатор с соответствующими платежными реквизитами получателя, чтобы обеспечить соответствующую маршрутизацию платежной операции (например, с платежным счетом получателя через IBAN/BIC по операции на основе SCT). В дальнейшем это может использоваться в качестве платформы для дополнительных услуг.

В зависимости от использования общей инфраструктуры (уровень 2) можно рассмотреть две основные модели для дистанционных платежей в зоне SEPA посредством мобильного телефона:

• первая модель основана на использовании существующей инфраструктуры и обеспечивает прямую операционную совместимость между плательщиками и получателями;

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

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

5.4.2.2. Модель прямой операционной совместимости Модель прямой операционной совместимости зависит от способности плательщиков/получателей передать все соответствующие платежные реквизиты (BIC, IBAN, наименование, адрес и т.д.) своему PSP или контрагенту. Единственное отличие между этим видом мобильных дистанционных платежей в зоне SEPA и традиционными платежами SEPA состоит в том, что платеж инициируется с помощью мобильного телефона вместо, например, ПК или бумажного документа.

Рисунок 22. Модель прямой операционной совместимости Преимущества модели прямой операционной совместимости заключаются в низкой стоимости ее реализации и эксплуатации, поскольку все операции производятся с использованием уже существующих каналов, а главный ее недостаток – неудобство для потребителей. Существует возможность расширить эту модель обслуживания за счет дополнительных услуг, например услуг по уведомлению клиентов.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

5.4.2.3. Модель операционной совместимости на основе централизованной общей инфраструктуры В этой модели операционная совместимость достигается за счет использования централизованной общей инфраструктуры19, которая может иметь различные формы и цели и может быть реализована на основе распределения. Главное назначение этой инфраструктуры – действовать в качестве службы каталога или коммутационного механизма для маршрутизации. Очевидно, централизованная общая инфраструктура может также предлагать различные дополнительные услуги, такие, как услуги по уведомлению и передаче данных, которые, однако, выходят за рамки настоящей «Белой книги».

Рисунок 23. Модель централизованной общей инфраструктуры 5.4.3. ВОЗВРАщЕНИЕ НА уРОВЕНЬ На основе этой архитектуры можно построить ряд различных моделей обслуживания в зависимости от того, относятся ли плательщик и получатель к одному и тому же PSP, и в зависимости от того, действуют ли соответствующие PSP в рамках одной или разных платежных схем. В следующих разделах рассматриваются следующие модели:

• трехсторонняя модель с участием одного-единственного PSP;

• четырехсторонняя модель с участием разных PSP в рамках одной платежной схемы;

• четырехсторонняя модель с участием разных PSP в рамках разных платежных схем.

5.4.3.1. Трехсторонняя модель В этой модели как плательщик, так и получатель являются клиентами одного PSP, действующего в рамках данной платежной схемы. Тот факт, что участвует только один PSP, позволяет упростить реализацию примеров использования, описанных в разделе 5.2, в отношении идентификации получателя (который известен PSP), подтверждения платежа и аспекта незамедлительности.

Обратите внимание, что общая инфраструктура может быть проприетарной (например, может управляться карточными схемами).

5.4.3.2. четырехсторонняя модель в рамках одной платежной схемы В этой модели плательщик и получатель являются клиентами разных PSP, но предполагается, что оба PSP действуют в рамках одной и той же платежной схемы (карточная схема или служба электронных платежей). Эта модель также позволяет упростить некоторые аспекты, описанные в примерах использования в разделе 5.2, такие как идентификация получателя по псевдониму, подтверждение платежа и его незамедлительность.

Рисунок 25. четырехсторонняя модель в рамках одной платежной схемы

PSP PSP

5.4.3.3. четырехсторонняя модель в рамках различных платежных схем В этой модели плательщик и получатель являются клиентами разных PSPs, которые действуют по разным платежным схемам. Очевидно, обе схемы должны иметь некоторую операционную совместимость (т.е. должно существовать соглашение между этими платежными схемами). Это наиболее общая модель, которая может существовать.

Рисунок 26. четырехсторонняя модель в рамках различных платежных схем

PSP PSP

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

6. БЕЗОПАСНАЯ ПОдПИСКА НА ПЛАТЕЖИ, СОВЕРШАЕМЫЕ

С ИСПОЛЬЗОВАНИЕМ МОБИЛЬНОГО ТЕЛЕФОНА

Примеры использования, описывающие безопасную подписку на услуги проведения платежей, совершаемых с использованием мобильного телефона, которые приведены в настоящем разделе, основаны не на платежных средствах SEPA и не стандартизируются EPC. Они представлены здесь только для того, чтобы продемонстрировать, каким образом можно легко и удобно организовать подписку на данный вид услуг, и являются исключительно иллюстративными.

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

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

См. [3], где даны конкретные рекомендации по реализации услуг по регистрации клиентов с выполнением требований PSD [19].

6.1. дИСТАНЦИОННАЯ ПОдПИСКА В этом сценарии, показанном на рисунке 27, клиент PSP (потребитель) подписывается на услуги, позволяющие оплачивать товары (услуги) посредством мобильного телефона через существующую платежную услугу с использованием сети Интернет. При этом потребитель уже аутентифицирован и работает в защищенной среде.

В этом сценарии сделаны следующие исходные предположения:

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

• у мобильного телефона есть необходимые технические возможности для использования желаемого вида услуг по проведению платежей посредством мобильного телефона.

Этот сценарий может выполняться следующим образом:

1. Сначала потребитель выполняет аутентификацию в PSP в рамках обычного открытия дистанционного сеанса работы.

2. Затем потребитель инициирует подписку на мобильные услуги, введя свой номер мобильного телефона и обозначив конкретную услугу, которую он намерен использовать.

3. После этого PSP проверяет технические возможности мобильного телефона (включая UICC или другой SE), напрямую или с использованием услуг, предоставляемых TSM.

4. Затем потребитель получает SMS об этом от PSP на свой мобильный телефон.

5. Он открывает SMS и подтверждает, что намерен подключить данную услугу, с мобильного телефона, на который поступило сообщение.

6. После того как потребитель отправил свое подтверждение, услуга подключается, и на дисплее мобильного телефона он видит подтверждение подключения.

Подключение услуги может быть связано с дополнительными особенностями, такими как несколько приложений, которые могут быть скачаны и установлены в SE (например, платежное приложение) и в самом мобильном телефоне (например, интерфейс конечного пользователя).

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

Рисунок 27. Пример дистанционной подписки на платежи, совершаемые Примечание. Операции, помеченные звездочкой, могут потребовать дополнительных действий потребителя.

6.2. ПОдПИСКА чЕРЕЗ уСТРОйСТВО САМООБСЛуЖИВАНИЯ В этом сценарии, представленном на рисунке 28, клиент PSP (потребитель) подписывается на услуги мобильных платежей через устройство самообслуживания (например, банкомат). При этом потребитель уже аутентифицирован и работает в защищенной среде.

В этом сценарии сделаны следующие исходные предположения:

• действующий договор между потребителем и PSP допускает подписку на новые дополнительные платежные услуги через устройство самообслуживания;

• у мобильного телефона есть необходимые технические возможности для использования желаемого вида услуг по проведению платежей посредством мобильного телефона.

Этот сценарий выполняется следующим образом:

1. Сначала потребитель выполняет аутентификацию в банкомате в рамках обычного открытия сеанса работы.

2. Затем потребитель инициирует подписку, введя свой номер мобильного телефона и обозначив услугу, которую он намерен использовать.

3. После этого PSP проверяет технические возможности мобильного телефона (включая UICC или другой SE), напрямую или с использованием услуг, предоставляемых TSM.

4. Затем потребитель получает SMS об этом от PSP на свой мобильный телефон.

5. Он открывает SMS и подтверждает, что намерен подключить услугу, с мобильного телефона, на который поступило сообщение.

6. После того как потребитель отправил свое подтверждение, услуга подключается, и на дисплее мобильного телефона потребитель видит подтверждение подключения.

Подключение услуги может быть связано с дополнительными особенностями, такими как несколько приложений, которые могут быть скачаны и установлены в SE (например, платежное приложение) и в самом мобильном телефоне (например, интерфейс конечного пользователя).

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

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

Рисунок 28. Пример подписки через банкомат на платежи, совершаемые Примечание. Операции, помеченные звездочкой, могут потребовать дополнительных действий потребителя.

6.3. ПОдПИСКА В ФИЛИАЛЕ PSP В этом сценарии, представленном на рисунке 29, подписка на услуги мобильных платежей оформляется, когда потребитель приходит в свой филиал PSP.

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

Этот сценарий выполняется следующим образом:

1. Потребитель сообщает сотруднику филиала о своем намерении подписаться на услугу по проведению платежей посредством мобильного телефона.

2. Затем потребитель сообщает номер мобильного телефона, который фиксируется в числе прочей регистрационной информации.

3. После этого PSP проверяет технические возможности мобильного телефона (включая UICC или другой SE), напрямую или с использованием услуг, предоставляемых TSM.

4. Новая функциональная возможность включается в мобильном телефоне дистанционно, и потребитель видит, что в его мобильном телефоне установлено новое платежное приложение.

Подключение услуги может быть связано с дополнительными особенностями, такими как несколько приложений, которые могут быть скачаны и установлены в SE (например, платежное приложение) и в самом мобильном телефоне (например, интерфейс конечного пользователя).

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

Рисунок 29. Пример подписки на персональные платежи, совершаемые с использованием Примечание. Операции, помеченные звездочкой, могут потребовать дополнительных действий потребителя.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

7. ИНФРАСТРуКТуРА 7.1. ОБщИЕ ПОЛОЖЕНИЯ В настоящем разделе рассматриваются различные инфраструктурные компоненты, которые используются для MCP и MRP.

7.1.1. МОБИЛЬНЫЕ ТЕЛЕФОНЫ В SEPA все используемые мобильные телефоны общего назначения работают в стандарте GSM или UMTS (также именуется 3G). Все мобильные телефоны UMTS обеспечивают мобильный широкополосный доступ, и практически все новые мобильные телефоны GSM, поступающие в продажу, также поддерживают GPRS или EDGE, которые также обеспечивают уверенный доступ в сеть Интернет, хотя и с невысокой скоростью передачи данных. Они поддерживают UICC (вместо SIM): устойчивое к постороннему вмешательству устройство идентификации, принадлежащее MNO, предоставляемое MNO и полностью стандартизированное ETSI. UICC управляет необходимыми конфиденциальными криптографическими данными в целях идентификации пользователя сети мобильной связи. Кроме того, в UICC также можно установить приложения MCP под контролем PSPs.

Мобильный телефон может использоваться как для MCPs, так и для MRPs, в зависимости от требований к телефону. Например, PSP, предоставляющий услугу MRP, может требовать только того, чтобы телефон поддерживал SMS, тогда как другой PSP может требовать загрузки своего платежного приложения в мобильный телефон со специальной платформой. Для MCP требования к мобильным телефонам выше:

должны присутствовать контроллер NFC, SE и интерфейсы для защищенных приложений MCP. В отсутствие SE (см. раздел 7.1.3) для MRP можно использовать средства безопасности мобильных телефонов, такие как SIMs и TEEs20. В настоящее время считается, что для MCP они недостаточно безопасны.

Мобильные телефоны постоянно совершенствуются и получают все более широкие функциональные возможности. Современные телефоны, так называемые «смартфоны», основаны на (открытых) компьютерных платформах общего назначения, которые могут выполнять очень сложные задачи, они поддерживают цветные дисплеи все большего размера и обеспечивают доступ в сеть Интернет, подобно ПК.

Существенно, что смартфоны – основная категория мобильных устройств, доля которых на рынке в настоящее время растет, причем быстрыми темпами [11].

Технология NFC, используемая для бесконтактных платежей, совершаемых посредством мобильного телефона, совместима с протоколами для бесконтактных карт21. Телефоны со встроенным модулем NFC могут работать со стандартными считывающими устройствами NFC (например, POI), а также с другими устройствами с NFC. Поэтому они могут использоваться в существующей инфраструктуре по бесконтактным платежным услугам на основе карт.

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

7.1.2. ИНТЕРФЕйС КОНЕчНОГО ПОЛЬЗОВАТЕЛЯ Управление платежами, совершаемыми посредством мобильного телефона, осуществляется с помощью пользовательского интерфейса на мобильном устройстве. Этот интерфейс включает, например, приложение SMS или USSD, браузер или скачиваемое клиентское приложение, предоставляемое PSP.

Мобильные кошельки (см. раздел 8) предусматривают такой интерфейс и могут управляться PSP, но их могут также предоставлять TTPs, и тогда PSPs могут участвовать посредством своих платежных приложений AAUIs.

Хотя самые современные смартфоны имеют очень большие цветные дисплеи и сенсорные интерфейсы, их использование все равно затрудняется неизбежно малым формфактором. Например, формфактор мобильного телефона действительно ограничивает объем информации, которая может выводиться на экран в данный момент времени, и способность пользователя ввести сложный текст. Поэтому важно предоставить простые в использовании интерфейсы мобильного телефона с последовательными действиями пользователя по всем поддерживаемым реализациям для мобильных телефонов.

TEE означает «безопасная среда выполнения». Это защищенная область в центральном процессоре телефона для хранения, обработки и защиты важных данных в безопасной среде.

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

7.1.3. ЭЛЕМЕНТЫ БЕЗОПАСНОСТИ Повышенная безопасность достигается с помощью так называемого элемента безопасности (SE) (сертифицированная устойчивая к постороннему вмешательству отдельная интегральная схема, т.е. «микрочип») для хранения личных данных потребителя и его платежных реквизитов. Опыт использования платежных карт при расчетах показывает, что технология микрочипов является эффективным и недорогим способом повышения безопасности. Кроме того, для SE может использоваться существующая инфраструктура практики оценки и сертификации микрочипов и карт.

Есть несколько альтернативных вариантов использования SEs (см. Приложение II. Элемент безопасности) в мобильном телефоне для поддержания платежей, совершаемых с использованием мобильного телефона. Основные факторы выбора SE в этом контексте следующие:

• контроль и управление SE;

• внутренние характеристики безопасности;

• возможность официальной сертификации по безопасности;

• интеграция в мобильном телефоне и соединение с внешними интерфейсами, такими как бесконтактные или дистанционные протоколы;

• доступность (сроки поставки и географический рынок);

• поддерживающая инфраструктура (средства персонализации);

• возможность использования в существующих коммерческих цепочках поставки по мобильным телефонам;

• экономическая эффективность и экономия за счет роста масштабов.

Выбор типа SE влияет на модель обслуживания по платежам, совершаемым с использованием мобильного телефона. Поэтому EPC сосредоточил внимание на трех типах SE: UICC, вложенный SE и съемный SE (такой как карта микро-SD) и подробно проанализировал различные аспекты модели обслуживания каждого из них (см. [5], раздел 4).

Дополнительная информация по этому вопросу приведена в специальном приложении (см. Приложение II. Элемент безопасности).

Как сказано в разделе 4, для важных операций в MCP требуется использование SE. По MRP плательщик напрямую аутентифицируется на платежном сервере в соответствии с выбранным его PSP методом аутентификации, и это не обязательно требует использования SE. Однако если SE уже имеется для поддержки MCPs, его можно использовать и для MRP, чтобы обеспечить большее удобство для потребителя. Кроме того, использование SE для MRP может повысить безопасность.

7.2. ИНФРАСТРуКТуРА дЛЯ MCP В настоящем разделе рассматриваются различные инфраструктурные компоненты, которые используются только для MCP.

7.2.1. ОПЕРАЦИОННАЯ ИНФРАСТРуКТуРА В инфраструктуре, необходимой для платежной операции MCP, полностью используется уже существующая инфраструктура для осуществления платежей посредством платежной карты. Инвестиции в инфраструктуру для принятия бесконтактных карт также могут использоваться для бесконтактных платежей в зоне SEPA, совершаемых с использованием мобильного телефона.

7.2.2. ОБЕСПЕчЕНИЕ И уПРАВЛЕНИЕ В SE должно быть установлено приложение для бесконтактных платежей в зоне SEPA, совершаемых с использованием мобильного телефона (см. раздел 7.1.3). Это означает, что следует определить специальные процессы для обеспечения и управления указанным платежным приложением, которые могут различаться в зависимости от выбранного SE. Ожидается, что для персонализации платежного приложения будут использоваться существующие системы персонализации карт. С этой целью могут быть привлечены TSMs. Дополнительные рекомендации по этому вопросу приведены в [5] и [6].

7.2.3. ПРИЛОЖЕНИЕ MCP Приложение MCP представляет собой программное обеспечение, установленное в SE, которое реализует функциональные возможности платежной карты в мобильном телефоне под контролем эмитента MCP в соответствии с карточной системой SEPA. Оно имеет прямой доступ к интерфейсу NFC и поэтоМЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

му связано непосредственно с POI. Приложения MCP персонализируются и управляются дистанционно эмитентом MCP или TSM от имени эмитента MCP (см. [5], раздел 5).

Эмитенты MCP могут конкурировать в предложении своих услуг путем настройки приложения MCP, пользовательских функций конфигурации и операций (дистанционного) управления.

Дополнительные рекомендации по приложению MCP приведены в разделе 6 в [5].

7.2.4. ПОЛЬЗОВАТЕЛЬСКИй ИНТЕРФЕйС ПРИЛОЖЕНИЯ MCP Приложение MCP может поддерживаться дополнительными приложениями, находящимися в «основной памяти» мобильного телефона, которые называются приложениями пользовательского интерфейса MCP (AAUI) и предназначены для взаимодействия с потребителем (см. [5], раздел 7.3, где приведены дополнительные соображения по этому вопросу). Эмитент MCP отвечает за это приложение, его характеристики безопасности и безопасную связь с приложением MCP.

7.2.5. ТОчКА ВЗАИМОдЕйСТВИЯ POI – это аппаратный и/или программный компонент оборудования торговой точки, который позволяет потребителю использовать карту для совершения покупки в магазине. Кассовый терминал может быть обслуживаемым или необслуживаемым. Новые поколения систем POI позволяют использовать для совершения платежей другие устройства, помимо карт (например, мобильные телефоны или карманные компьютеры).

Однако в основном инфраструктура POI еще не поддерживает NFC и потому требует обновления, которое должно включать потенциально необходимые требования, кроме уже определенных для бесконтактных платежей по картам SEPA, чтобы добиться максимальной эффективности инвестиций. Например, в то время как требования по аппаратным компонентам должны быть одинаковыми, встроенное программное обеспечение может потребовать обновления для поддержки, например правильной обработки мобильных кодов. EPC уже активно участвует в решении этого вопроса вместе со всеми соответствующими организациями по стандартизации и заинтересованными сторонами.

7.3. ИНФРАСТРуКТуРА дЛЯ MRP В настоящем разделе рассматриваются различные инфраструктурные компоненты, которые используются только для MRPs.

7.3.1. ОПЕРАЦИОННАЯ ИНФРАСТРуКТуРА В инфраструктурах, необходимых для дистанционных платежных операций, совершаемых с использованием мобильного телефона, может использоваться уже существующая инфраструктура для дистанционных платежей по картам или платежей SCT (например, торговые интернет-браузеры, 3D secure, дистанционные кошельки и т.д.). Однако, как сказано в главе 5.2, некоторые примеры использования связаны с реализацией общей инфраструктуры.

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

В зависимости от использования общей инфраструктуры (уровень 2) в разделе 5.4.2 показано, что для MRPs в SEPA могут быть рассмотрены две основные модели. Обе модели допускают предложение дополнительных услуг, поскольку пользователи платежей, совершаемых посредством мобильного телефона, ожидают быстрого и надежного обслуживания. Процесс предоставления уведомления считается особенно важным, поскольку, например, предприятиям торговли (услуг) нужно подтверждение платежа перед поставкой купленных товаров или предоставлением услуг.

В обеих моделях эмитенты MRP отвечают за регистрацию клиентов в различных платежных службах MRP.

Итак, главное назначение централизованной общей инфраструктуры – связать уникальный идентификатор с соответствующими платежными реквизитами получателя, чтобы обеспечить правильную маршрутизацию платежной операции. Как минимум, в общей инфраструктуре должны храниться уникальный идентификатор и наименование, IBAN и BIC получателя. Она может также использоваться в качестве платформы для дополнительных услуг.

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

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

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

- Уникальный идентификатор получателя указывает на URL PSP получателя. В этом случае сопоставлением псевдонима / уникального идентификатора и реквизитов получателя занимается PSP получателя.

- Уникальный идентификатор получателя непосредственно указывает на реквизиты получателя.

• В качестве центрального коммутатора, позволяющего PSP плательщика после получения уникального идентификатора получателя отправить эту информацию в центральный коммутатор. Центральный коммутатор связывает эту информацию с соответствующими реквизитами PSP получателя / счета карты (например, IBAN и/или BIC в случае SCT) и затем направляет платежную операцию в PSP получателя / на счет получателя.

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

7.3.2. уНИКАЛЬНЫй ИдЕНТИФИКАТОР Концепция псевдонима представлена в ряде примеров использования в разделах 4 и 5. Псевдоним позволяет однозначно идентифицировать платежный счет получателя. В случае SCT он позволяет связать наименование, BIC и IBAN получателя. В случае дистанционных платежей, совершаемых с использованием мобильного телефона посредством ввода реквизитов платежной карты, он обеспечивает однозначную идентификацию платежного счета получателя (например, с использованием номера мобильного телефона). Обратите внимание, что псевдоним может также служить идентификатором плательщика.

7.3.3. хРАНЕНИЕ дАННЫх MRP И ПРИЛОЖЕНИЕ В МОБИЛЬНОМ ТЕЛЕФОНЕ В нижеследующем разделе проводится различие между хранением данных / удостоверительных данных, относящихся к дистанционным платежам, и установкой приложения для дистанционных платежей в мобильном телефоне. Хранение данных, относящихся к дистанционным платежам, означает хранение данных в мобильном телефоне для удобства потребителя, чтобы не вводить их вручную при совершении операции. Приложение MRP, по аналогии с приложением MCP, является специальным пакетом программного обеспечения, динамически генерирующим операционные данные.

7.3.3.1. хранение данных / удостоверительных данных, относящихся к дистанционным платежам В мобильном телефоне можно хранить статические данные / удостоверительные данные для дистанционных платежей SCT и платежей SCP. Если для этих данных установлены требования по безопасности (безошибочность и/или конфиденциальность), они должны храниться в безопасной среде, например SE. Эти данные могут храниться плательщиком или его PSP. Если они хранятся в безопасной среде, обычно требуется некоторый контроль доступа, например некоторая форма аутентификации, такая как специальный код плательщика или функция управления приложением MRP в PSP.

7.3.3.2. установка приложения MRP Для некоторых вариантов реализации MRP может потребоваться установка специального приложения MRP в мобильном телефоне. Если это приложение имеет активные функции безопасности (например, криптографические функции), оно устанавливается в SE. Как и в случае MCP, это приложение MRP требует от PSP плательщика управления всем жизненным циклом, включая обеспечение, активацию, персонализацию и т.д. (см. [21]).

PSP плательщика может передать TSM некоторые из этих функций. Как и в случае MCP, действуют разные требования к ролям, исполняющим эти функции (см. [15] и [18].

7.3.3.3. Обеспечение и управление Дистанционный платеж SEPA посредством мобильного телефона может потребовать установки специального приложения в SE (см. раздел 7.1.3). Это означает, что необходимо определить специальные процессы по обеспечению и управлению указанным платежным приложением, которые могут различаться в зависимости от выбранного SE. Для этого могут быть привлечены TSM. Дополнительные рекомендации по этому вопросу будут приведены в готовящихся Методических рекомендациях по реализации операционной совместимости MRP.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

7.3.4. ПОЛЬЗОВАТЕЛЬСКИй ИНТЕРФЕйС ПРИЛОЖЕНИЯ MRP Хотя самые современные смартфоны имеют очень большие цветные дисплеи и сенсорные интерфейсы, их использование все равно затрудняется неизбежно малым формфактором. Например, формфактор мобильного телефона действительно ограничивает объем информации, которая может выводиться на экран в данный момент времени, и способность пользователя ввести сложный текст. Обратите внимание, что для инициирования дистанционных платежей, совершаемых с использованием мобильного телефона, могут применяться различные средства, такие как мобильный браузер, SMS или специальный AAUI.

EPC рассмотрит этот вопрос более подробно в готовящихся Методических рекомендациях по реализации операционной совместимости MRP.

7.3.5. ТОРГОВЫй ИНТЕРФЕйС В целом предприятия торговли (услуг) предлагают клиентам разные способы совершения покупок, именуемые в настоящем документе «контексты покупки». Например, предприятие торговли (услуг) может предложить использовать SMS, создать мобильный сайт в сети Интернет, предложить специальное мобильное приложение (например, для игр) или принять заранее зарегистрированный псевдоним (например, номер мобильного телефона), подобно традиционной среде POI.

Важное требование с точки зрения предприятия торговли (услуг) и потребителя состоит в том, что процессы покупки и оплаты должны быть удобными для пользователя. Для этого нужно обеспечить, чтобы сочетание платежного средства MRP и мобильного телефона подходило бы для конкретного контекста покупки.

PSP устанавливает некоторые требования к мобильному телефону потребителя исходя из реализации MRP. В простейших случаях достаточно, чтобы потребитель имел возможность использовать SMS или интернет-браузер мобильного телефона (мобильный браузер). В других случаях PSP может потребовать, чтобы потребители загрузили мобильное приложение, например для выбора платежного средства, аутентификации и других подобных целей.

7.3.6. РАСПРЕдЕЛЕНИЕ ПРИМЕРОВ ИСПОЛЬЗОВАНИЯ MRP В ИНФРАСТРуКТуРЕ В настоящем разделе примеры использования, указанные в разделе 5.2, распределяются по трехсторонней архитектуре, представленной в разделе 5.4.1. В зависимости от примеров использования платеж может быть инициирован на уровне 1 разными способами (см. раздел 5.4.1), такими как платеж посредством мобильного телефона через браузер или мобильные кошельки, в том числе с использованием надежной аутентификации.

По каждому примеру использования в нижеследующей таблице указаны компоненты, которые должны быть добавлены на уровне 2 (например, общая инфраструктура), и возможности предоставления новых услуг на уровне 3 (например, подтверждение платежа, незамедлительность платежа). Обратите внимание, что уровни 2 и 3 находятся в кооперативном пространстве, тогда как уровень 1 остается в конкурентном пространстве.

Таблица 20. Распределение примеров использования по трем уровням архитектуры MRP Три уровня Уровень 1: инициирование платежа Уровень 2: совершение использования SCP 3 С надежным механизмом аутентификации

8. МОБИЛЬНЫЕ КОШЕЛЬКИ

8.1. ОПРЕдЕЛЕНИЕ Как и обычный кошелек, «цифровой» кошелек, в сущности, содержит идентификационные данные владельца кошелька, данные о платежных средствах, доступных владельцу кошелька, и в некоторых случаях – личные данные его владельца (изображения, документы и т.д.). Это может включать информацию об удостоверениях личности, цифровые подписи и сертификаты, информацию для входа в систему, адреса для выставления счетов и передачи, а также информацию о платежных средствах, таких как продукты SCT и SDD и платежные карты (предварительно оплаченные, дебетовые, кредитные). Кроме того, он может также включать другие приложения, например бонусные баллы, билеты или проездные билеты.

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

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

«Цифровой» кошелек обычно реализуется в оборудовании, используемом владельцем кошелька. Таким образом, владелец непосредственно контролирует свой кошелек. Однако «цифровой» кошелек может также быть реализован в качестве дистанционного кошелька в схеме передачи «программное обеспечение в качестве услуги».

Помимо технических требований и требований безопасности, которые должны выполняться при использовании/предложении услуг, связанных с «цифровым» кошельком, следует решить вопрос права собственности в отношении «цифрового» кошелька, поскольку это будет зависеть от его реализации.

Следовательно, можно принять следующие определения.

«Цифровой кошелек – это услуга, позволяющая владельцу безопасно получать доступ к идентификационным данным и платежным средствам, управлять ими и использовать их для инициирования платежей22. Эта услуга может быть встроена в устройство, принадлежащее владельцу, например мобильный телефон или ПК, или может быть установлена на удаленном сервере, но в любом случае контролируется владельцем».

«Мобильный кошелек – это цифровой кошелек, находящийся в мобильном телефоне».

Дальнейшее развитие концепции и обсуждение основных вопросов, касающихся мобильного кошелька, можно найти в [17].

8.2. МОБИЛЬНЫЕ КОШЕЛЬКИ И ПЛАТЕЖИ, СОВЕРШАЕМЫЕ

С ИСПОЛЬЗОВАНИЕМ МОБИЛЬНОГО ТЕЛЕФОНА

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

При этом на начальном этапе рассмотрения платежей посредством мобильного телефона важно проанализировать различные ситуации: от более простых, когда в мобильном телефоне имеется одно платежное приложение, до сложных, когда в мобильном телефоне хранятся несколько платежных приложений разного характера (SE с данными карты по платежам NFC, данные карты по дистанционным платежам, виртуальный счет и т.д.).

8.3. ИСПОЛЬЗОВАНИЕ МОБИЛЬНЫх КОШЕЛЬКОВ дЛЯ БЕСКОНТАКТНЫх

И дИСТАНЦИОННЫх ПЛАТЕЖЕй, СОВЕРШАЕМЫх С ИСПОЛЬЗОВАНИЕМ

МОБИЛЬНОГО ТЕЛЕФОНА

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

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

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

Кошелек должен иметь как минимум следующие функциональные возможности:

• интерфейс для регистрации личных данных и данных по платежным средствам (в мобильном телефоне);

• архив данных для хранения этих данных (в мобильном телефоне);

• интерфейс, позволяющий пользователю выбрать платежное средство;

• интерфейс, позволяющий пользователю использовать платежное средство (один интерфейс, управляющий всеми платежными средствами, или несколько интерфейсов для разных платежных средств);

• интерфейс для управления сохраненными данными и их обновления (обновление, аннулирование и т.д.).

Как сказано выше, приложение для мобильного кошелька может быть очень простым – в случае если оно предназначено для хранения данных и управления ими по одному-единственному платежному средству, или более сложным – в случае нескольких разных платежных средств. Если в кошельке хранятся несколько разных платежных средств, кошелек должен, как минимум, позволять потребителю в любой момент выбрать платежное средство, которое он намерен использовать.

Кроме того, желательно, чтобы кошелек позволял определить платежное средство, используемое по умолчанию – одно для всех видов платежей или, что будет лучше, одно для каждого вида платежей (например, предварительно оплаченная карта X для бесконтактных платежей, кредитная карта Y для дистанционных платежей и т.д.).

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

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

Желательно, чтобы потребитель мог выбирать, каким образом он предпочитает создать и использовать свой кошелек; поставщики платежных услуг должны позволять потребителям управлять (регистрировать и использовать) своими платежными средствами в каждом кошельке23.

EPC планирует работать над различными аспектами мобильных кошельков.

При условии, что выполняются соответствующие требования (например, по безопасности).

9. СТАНдАРТИЗАЦИЯ И ОТРАСЛЕВЫЕ ОРГАНИЗАЦИИ

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

• iSo Международная организация по стандартизации (ISO) – крупнейший в мире разработчик международных стандартов. В ISO существуют различные комитеты, которые устанавливают технические стандарты, используемые при осуществлении платежей посредством мобильного телефона, такие как стандарты карт с интегральными схемами, протоколы обмена данными, технология NFC, механизмы безопасности. ISO также решает вопросы в рамках Рабочей группы по платежам, совершаемым с использованием мобильного телефона в ISO TC68 SC7 WG10 (http://www.iso.org).

• ETSi Европейский институт по стандартам в области телекоммуникаций (ETSI) разрабатывает действующие во всем мире стандарты по информационным и коммуникационным технологиям, включая технологии стационарной связи, мобильной связи, радиосвязи, объединенные технологии, технологии радиовещания и интернет-технологии. ETSI определяет протоколы обмена данными GSM, UMTS и UICC, включая все протоколы доступа (http://www.etsi.org).

• EMVCo EMVCo осуществляет деятельность по управлению, поддержке и расширению спецификаций карт с интегральными схемами (EMV® Integrated Circuit Card Specifications) для платежных карт на основе микрочипов и приемных устройств, включая терминалы в торговых точках (POS) и банкоматы. EMVCo также устанавливает процедуру испытаний и одобрения в рамках оценки соблюдения спецификаций EMV и управляет этой процедурой. EMVCo в настоящее время принадлежит компаниям «American Express», JCB, «MasterCard» и «Visa» (http://www.emvco.com).

• iETF Рабочая группа проектирования сети Интернет (IETF) – это крупное открытое международное объединение проектировщиков, операторов, поставщиков и исследователей сетей, занимающееся развитием интернет-архитектуры и обеспечением бесперебойной работы сети Интернет. IETF определяет основу всех интернет-протоколов (http://www.ietf.org).

• GlobalPlatform GlobalPlatform (GP) – это ведущая международная ассоциация, занимающаяся созданием и обслуживанием совместимой устойчивой инфраструктуры для использования микропроцессорных карт (смарткарты). Ее технологии поддерживают реализацию нескольких приложений, нескольких действующих субъектов и нескольких моделей обслуживания, что выгодно для эмитентов, поставщиков услуг и поставщиков технологий (http://www.globalplatform.org).

• GSMA GSMA представляет интересы мирового сектора мобильной связи. Охватывая более 200 стран, GSMA объединяет почти 800 мировых операторов мобильной связи, а также более 200 компаний в более широкой экосистеме мобильной связи, включая производителей телефонов, компании по разработке программного обеспечения, поставщиков оборудования, интернет-компании, средства массовой информации и компании по организации зрелищных мероприятий. Деятельность GSMA сосредоточена на инновациях, развитии и создании новых возможностей для ее членов с конечной целью стимулирования роста сектора мобильной связи (http://www.gsmworld.com).

• Mobey Forum Mobey Forum – это мировой форум финансового сектора, задачей которого является стимулирование предложения банками мобильных финансовых услуг за счет опыта реализации пилотных проектов, межотраслевого сотрудничества, анализа, обмена опытом, экспериментов, а также сотрудничества и связей с соответствующими внешними заинтересованными сторонами (http://www.mobeyforum.org).

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

• nFC Forum Near Field Communication Forum – это некоммерческая отраслевая ассоциация, ставящая своей целью расширение использования связи в ближней зоне NFC в потребительской электронике, мобильных устройствах и ПК (http://www.nfcfbrum.org).

• PCi Совет по стандартам безопасности PCI – это открытый всемирный форум, действующий с 2006 года, который отвечает за деятельность по разработке, управлению, образованию и информированию по стандартам безопасности PCI, включая стандарт защиты данных (PCI DSS), стандарт защиты данных в платежных приложениях (PA-DSS) и требования операционной безопасности PIN (PTS) (https://www.

pcisecuritystandards.org).

• W3C World Wide Web Consortium (W3C) – это международное сообщество, разрабатывающее стандарты сети Интернет и ставящее своей задачей полное использование ее возможностей (www.w3.org).

10. ЗАКЛючЕНИЕ Роль EPC Роль EPC заключается в участии в развитии единого рынка платежей в Европе путем помощи или содействия в разработке и внедрении стандартов, передовой практики и схем. В секторе мобильной телефонной связи достигнуты полное проникновение на рынок и высокий уровень обслуживания, что обеспечивает идеальный канал расширения использования платежных средств SEPA.

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

• бесконтактные платежи, совершаемые с использованием мобильного телефона;

• дистанционные платежи, совершаемые с использованием мобильного телефона.

Для инициирования платежей главным образом используется мобильный телефон, тогда как EPC использует существующие платежные средства SEPA для самого платежа.

Анализ и распределение приоритетов Проанализировав различные категории «бесконтактных» (в ближней зоне) и «дистанционных» мобильных платежей, EPC считает приоритетными в области платежей, совершаемых с использованием мобильного телефона, следующие виды платежей:

• бесконтактные платежи в зоне SEPA;

• дистанционные платежи в зоне SEPA;

• дистанционные кредитовые переводы SEPA.

Бесконтактные платежи, совершаемые с использованием мобильного телефона В бесконтактных платежах по картам SEPA, совершаемых с использованием мобильного телефона, выбор SE сильно влияет на модель обслуживания и роли различных заинтересованных сторон.

В помощь этим заинтересованным сторонам EPC опубликовал Методические рекомендации по реализации операционной совместимости MCP [5].

дистанционные платежи, совершаемые с использованием мобильного телефона Определены три основные цели:

• удобство инициирования трансакции и идентификации получателя по платежам, инициируемым плательщиком;

• определенность результата платежа для получателя;

• немедленные (или очень быстрые) платежи.

Последующие действия Хотя многие из указанных задач не являются специфичными для мобильного канала, их раннее определенное решение важно для того, чтобы платежные средства SEPA стали успешными в мобильном канале. В этом отношении EPC намерен сосредоточить усилия на разработке Методических рекомендаций по операционной совместимости мобильных дистанционных платежей.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

Платежные средства, развиваемые EPC:

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

Свод правил схемы SCT [SCT] и прилагаемые Методические рекомендации по реализации являются окончательными источниками информации о правилах и обязательствах в этой схеме. Кроме того, имеется документ «Быстрый доступ к схемам кредитового перевода в зоне SEPA» («Shortcut to the SEPA Credit Transfer Scheme»), в котором представлена основная информация о характеристиках и преимуществах схемы SCT.

• Безакцептное списание SEPA (Sdd) Основная схема SDD – подобно любой другой схеме безакцептного списания – основана на следующей концепции: «Мне требуется денежный перевод от другого лица с его предварительного согласия, и я зачисляю сумму перевода на свой счет».

Основная схема SDD [SDD] распространяется на операции в евро. Дебитор и кредитор должны иметь счета в кредитной организации, находящейся в зоне SEPA. Кредитные организации, совершающие операцию безакцептного списания, должны быть участниками схемы, т.е. обе организации должны официально выполнять требования схемы SDD. Эта схема может использоваться для однократного (единовременного) или периодического безакцептного списания; ограничения на суммы отсутствуют.

• Карточная система SEPA (SCF) SCF [SCF], разработанная EPC, – документ, определяющий политику в отношении того, каким образом участники рынка платежных карт (такие как карточные схемы, эмитенты карт, предприятия торговли (услуг), принимающие платежные карты, и другие поставщики услуг) должны адаптировать свою текущую деятельность для приведения ее в соответствие с концепцией SEPA по платежам в евро, совершаемым с использованием банковских карт. Хотя участник рынка сам определяет, приводить ли ему свои системы в соответствие с требованиями SCF, члены EPC обязуются выполнять условия SCF в качестве эмитентов и эквайреров.

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

Особые ограничения, связанные с формфактором мобильных телефонов Независимо от окончательного типа используемых SE и в противоположность физическим платежным картам следует предусмотреть особые условия в связи с тем, что в большинстве случаев PSPs, предоставляющие приложение для платежей, совершаемых с использованием мобильного телефона, не отвечают за распространение мобильных телефонов и SE. Основные причины этого следующие.

• В мобильном телефоне в любой определенный момент времени может быть установлено только ограниченное количество SE. Замена SE пользователем в мобильном телефоне часто очень неудобна.

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

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

Элементы безопасности для платежей, совершаемых с использованием мобильного телефона EPC участвовал в подготовке документа Mobey Forum «Альтернативы для банков при предоставлении услуг по безопасным платежам, совершаемым посредством мобильного телефона», в котором представлен обзор существующих предложений для SE [16]. В нем рассматриваются следующие типы устройств:

• Стикеры Бесконтактные карты, изготавливаемые в виде стикера, которые могут быть персонализированы и могут обрабатываться с помощью существующей платежной инфраструктуры. Потребители могут разместить стикер в своем мобильном телефоне для платежей с использованием технологии NFC.

• Карта Secure Micro SD Карты памяти с встроенным микрочипом, которые могут использоваться в качестве SE (устанавливаются в мобильном телефоне или отдельно). Эти карты Secure Micro SD могут также иметь антенну NFC.

• Universal Integrated Circuit Card (UICC) Универсальный стандартизированный SE, принадлежащий MNO и предоставляемый MNO.

• Встроенный SE SE, встроенный в мобильный телефон при его изготовлении.

• Trusted Mobile Base Защищенный изолированный раздел центрального процессора мобильных телефонов, в котором могут храниться защищенные приложения.

EPC дополнительно проанализировал эти различные типы SE и установил в своей последующей работе (см. [5]) такие приоритетные формфакторы SE:

• UICC;

• встроенный SE;

• съемный SE, такой как карта Secure Micro SD.

МЕЖДУНАРОДНЫЙ ОПЫТ — Выпуск 39. 2013 г.

[1] Little, Arthur D. «Global M-Payment Report Update, 2009»: http://www.adlittle.com/reports.

html?view= [2] EMVCo: http://www.emvco.com/ [3] Европейский платежный совет. «EPC397-08 Customer-to-Bank Security Good Practices Guide»:

http://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id= [4] Европейский платежный совет. «EPC 020-08 SEPA Cards Standardisation (SCS) Volume – Book of Requirements»: http://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_ [5] Европейский платежный совет. «EPC 178-10 Mobile Contactless SEPA Card Payments Interoperability Implementation Guidelines»: http://www.europeanpaymentscouncil.eu/knowledge_ bank_detail.cfm?documents_id= [6] Европейский платежный совет – Ассоциация GSM. «EPC 220-08 Mobile Contactless Payments Service Management Roles – Requirements and Specifications»: http://www.

europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id= [7] Европейский институт по стандартам в области телекоммуникаций: http://www.etsi.org [8] Европейский институт по стандартам в области телекоммуникаций TS 102 221, TS 102 223, TS [9] Global Platform: http://www.globalplatform.org [10] Ассоциация GSM: http://www.gsmworld.com [11] Пресс-релиз IDC от 30 июля 2009 года «Smartphone Growth Encouraging, Yet the Worldwide Mobile Phone Market Still Expected To Shrink in 2009»: http://www.idc.com/about/viewpressrelease.jsp?con tainerId=prUS21950309§ionId=null&elementId=null&pageType=SYNOPSIS [12] Международная организация по стандартизации: http://www.iso.org [13] Рабочая группа проектирования Интернета: http://www.ietf.org [14] Международный союз электросвязи. «World Telecommunication/ICT Indicators Database (15th Edition)»: http://www.itu.int/ITU-D/ict/publications/world/world.html [15] Mobey Forum: http://www.mobeyforum.org [16] Mobey Forum. «Alternatives for Banks to offer Secure Mobile Payments (version 1.0)»: http://www.

mobeyforum.org/Press-Documents/Press-Releases/Alternatives-for-Banks-to-offer-Secure-MobilePayments [17] Mobey Forum. «Mobile wallet – Definition and vision – Part 1»: http://www.mobeyforum.org/PressDocuments/Press-Releases/Mobey-Forum-White-Paper-Provides-a-New-Perspective-on-MarketDevelopment [18] NFC Forum: http://www.nfc-forum.org/home [19] Директива по платежным услугам: Директива 2007/64/EC Европейского парламента и Совета от 13 ноября 2007 года по платежным услугам на внутреннем рынке [20] Ассоциация производителей карт SD: https://www.sdcard.org/developers

ДЛЯ ЗАМЕТОК