Month: August 2024

Автор: Артем Ляшанов

Между кликом Забронировать на сайте и финальной оплатой мини-бара при выезде, огромная серая зона.

Долгое время этот разрыв закрывали с помощью Merchant Initiated Transactions (MIT). Схема простая, сохраняем карту, а потом списываем средства без участия клиента (и без SCA). Отсутствие Strong Customer Authentication означает отсутствие переноса ответственности. Если гость оспорит транзакцию, банк встанет на его сторону, а мерчант останется с убытками.

На фоне роста фрода и ужесточения регуляций старый подход MIT становится токсичным активом. На смену ему приходят Merchant-Initiated Authentications (3RI).

Что такое 3RI

Если говорить просто, 3RI (3DS Requestor Initiated) – это технология, которая позволяет мерчанту проводить повторные платежи в отсутствие клиента, сохраняя при этом высший уровень безопасности.

В отличие от стандартного e-commerce, где покупатель каждый раз нажимает кнопку «Оплатить», 3RI создан для сценариев, где списание происходит автоматически, а именно подписки, рассрочки или доплаты. Когда гость впервые вводит данные карты, система запоминает не только номер пластика, но и уникальные адаптивные значения аутентификации. Это позволяет бизнесу использовать цифровой отпечаток первого подтвержденного платежа для всех последующих операций.

В чем отличие от обычных MIT?

Многие путают 3RI с классическими MIT. Разница между ними критическая, и она заключается в одном, ответственности.

1. Обычный MIT. Вы просто списываете деньги с сохраненной карты. Если клиент заявит о фроде (мошенничестве), банк-эмитент почти гарантированно вернет ему деньги;
2. 3RI транзакция остается аутентифицированной. Благодаря использованию данных первичной проверки 3DS, за платежом сохраняется так называемый перенос ответственности.

«Главная ценность 3RI не в удобстве списания, а в юридической броне. Используя аутентификационные данные первой транзакции, мерчант перекладывает риск мошенничества на банк-эмитент. В мире, где фрод становится профессиональной индустрией, это единственный способ защитить выручку отеля при дистанционных списаниях».

Артем Ляшанов

Как это работает на практике?

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

• При первой транзакции клиент проходит полную проверку (например, подтверждение в приложении банка);
• Система фиксирует токен аутентификации;
• Все последующие списания проходят через 3RI.

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

3RI vs. Традиционные MIT

Чтобы окончательно понять ценность 3RI, нужно сравнить его с классическими транзакциями по инициативе мерчанта (MIT). На первый взгляд они делают одно и то же, списывают деньги с карты гостя, когда его нет рядом. 

• Традиционные MIT (Card on File)

Это старый добрый метод карты в файле. Вы сохраняете токен карты и используете его для списаний. Это удобно, но у этого метода есть огромная брешь: отсутствие 3D Secure (3DS).

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

• 3RI (Merchant-Initiated Authentications)

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

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

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

Артем Ляшанов объясняет, чем Open Finance отличается от Open Banking

Open Banking в классическом понимании это возможность для клиента разрешить сторонним сервисам безопасный доступ к данным своего банковского счёта как транзакциям, балансам, платежам.

Open Finance, согласно материалам индустрии, расширяет эту логику за пределы банковского счёта на инвестиции, пенсионные накопления, страхование, кредитную историю и даже данные о занятости.

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

Ключевые отличия:

• Open Banking. Данные банковского счёта (транзакции, балансы, инициация платежей через защищённые API);
• Open Finance. Более широкий набор данных (инвестиции, пенсии, страхование, кредитная история, иногда данные о занятости и коммунальных платежах);
• Расширение этой логики связывают, в частности, с пакетом PSD3/PSR и отдельным регламентом о доступе к финансовым данным (FiDA), хотя окончательные сроки их вступления в силу, по имеющимся данным, ещё не зафиксированы.

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

В Австралии похожую роль играет режим Consumer Data Right, который, по имеющимся данным, изначально заработал в банковском секторе, а затем распространился на энергетику и небанковское кредитование. В США, судя по обзорам индустрии, ситуация развивается скорее рыночным путём, где финансовые институты и финтех-компании договариваются о подключении данных через партнёрства и конкуренцию, без единого федерального мандата, охватывающего всю эту сферу.

Почему исходящие данные тоже могут быть преимуществом

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

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

Цифры, которые приводят в отраслевых материалах

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

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

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

Артем Ляшанов об украинском контексте

Прямых регуляторных требований Open Banking по образцу PSD2/PSD3 в Украине пока что, насколько известно, нет в том же объёме, что в ЕС, хотя тема открытого банкинга обсуждается в контексте евроинтеграции финансового регулирования. Для украинских финтех-компаний, работающих с европейскими партнёрами или готовящихся к возможной гармонизации регулирования, эта тема, вероятно, актуальна скорее как ориентир на будущее, чем как текущее операционное требование.

Артем Ляшанов о рисках и открытых вопросах:

• Переход от Open Banking к Open Finance означает распространение принципов обмена данными на более чувствительные категории, что, вероятно, повышает и требования к защите приватности;
• Отсутствие единого стандарта API в разных юрисдикциях продолжает оставаться практической проблемой, даже если регуляторные намерения направлены на гармонизацию.

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

Артем Ляшанов – предприниматель, финтех-эксперт и инвестор, более 10 лет опыта в создании платёжных продуктов. Материал подготовлен на основе публичных источников и не является финансовой или инвестиционной консультацией.

Артем Ляшанов — бізнесмен, спеціаліст із фінансових технологій та інвестор із понад 10-річним досвідом створення платіжних продуктів. Сьогодні — приватний бізнес-радник великих брендів і фінтех-інвестор.

Український фінансовий ринок переходить у нову фазу. З 1 січня 2026 року банки та інші постачальники платіжних послуг зобов’язані працювати за новими правилами Open Banking. Для бізнесу, особливо фінтех-компаній, ритейлу, маркетплейсів і будь-кого, хто працює з платежами, це зміна правил гри.

Що таке Open Banking

Простими словами, Open Banking це механізм, який дозволяє стороннім сервісам (не банкам) отримувати доступ до інформації про рахунок клієнта або інціювати платіж з цього рахунку, але тільки за явною згодою самого клієнта. Раніше дані про ваш рахунок існували виключно всередині банку.

Тепер, якщо клієнт сам на це погодився, цими даними може скористатися інший сервіс, наприклад, застосунок для управління особистими фінансами, бухгалтерський сервіс або платіжний провайдер інтернет-магазину.

Юридично це впроваджено Постановою Правління НБУ № 80 «Про затвердження Положення про відкритий банкінг в Україні», яка набрала чинності 1 серпня 2025 року. Банкам дали п’ять місяців на технічну та організаційну підготовку, тобто привести свою роботу у відповідність до нових вимог потрібно було до 1 січня 2026 року.

Важливо розуміти контекст, що це не одноразова інша вимога регулятора, а логічне продовження довгого шляху. Ще у 2020 році Національний банк затвердив Стратегію розвитку фінтеху в Україні до 2025 року, у якій окремим напрямком було визначено побудову академічної бази для відкритого банкінгу та імплементацію європейської директиви PSD2. Тобто бізнес, який стежив за фінтех-ринком останні п’ять років, мав час підготуватися.

Як це працює

В основі Open Banking, поняття явної згоди користувача (consent), яка обов’язково підтверджується через надійну автентифікацію клієнта (SCA – Strong Customer Authentication). Без цього підтвердження банк не має права передавати жодну інформацію третій стороні.

Спрощено механізм виглядає так:

• Користувач у застосунку стороннього провайдера (наприклад, у сервісі обліку фінансів) натискає «підключити рахунок» або «оплатити через…»;
• Цей провайдер надсилає запит до банку через спеціальний API;
• Банк проводить автентифікацію клієнта та показує йому, кому, які саме дані (баланс, виписки за певний період) і на який термін (максимум 180 днів) буде надано доступ;
• Клієнт підтверджує згоду, і лише після цього дані чи платіж стають доступні третій стороні.

Відкликати згоду можна в будь-який момент, як через інтерфейс банку, так і через інтерфейс стороннього сервісу, причому без повторної суворої автентифікації. Усі учасники процесу зобов’язані фіксувати дату й час надання та відкликання згоди і зберігати ці записи щонайменше п’ять років.

Хто за що відповідає

Це ключове питання для будь-якого бізнесу, який планує інтегруватися з банками через Open Banking. Відповідальність розподілена так:

• Банк відповідає за коректне отримання й перевірку згоди клієнта, за збитки, спричинені порушенням вимог регулювання, і за неправомірне розкриття банківської чи комерційної таємниці третій стороні;
• Третя сторона (провайдер інформаційних послуг або провайдер послуг з ініціювання платежу) відповідає за коректність запиту на доступ і за перевірку чинності згоди перед кожним зверненням за даними чи платежем.

Іншими словами, банк це вартовий рахунку клієнта, а фінтех-компанія чи будь-який інший сторонній сервіс, той, хто повинен довести, що має на руках чинний дозвіл, і регулярно це підтверджувати.

Що це означає для бізнесу

Вбудовані фінансові сервіси. Будь-який бізнес тепер може законно і безпечно бачити рахунок клієнта (з його дозволу) і будувати на цьому продукт:

• Автоматичний підбір тарифу;
• Миттєву перевірку платоспроможності;
• Персоналізовані пропозиції.

Прямі платежі з рахунку замість карткових комісій. Можливість ініціювати платіж напряму з рахунку клієнта (PISP-модель) дозволяє бізнесу зменшити залежність від карткових платіжних систем і відповідно, частину комісій за еквайринг.

Точніший скоринг і нові продукти кредитування. Доступ до реальної транзакційної історії клієнта (за його згодою) дає фінансовим компаніям набагато якісніші дані для оцінки ризику, ніж застарілі моделі скорингу. Це безпосередньо впливає на те, хто на ринку мікрофінансування і кредитування зможе пропонувати кращі умови.

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

Що це означає для бізнесу

Компаніям, які планують виступати третьою стороною (TPP), варто заздалегідь подбати про кілька речей:

• Технічна готовність;
• Юридична готовність;
• Прозорість інтерфейсу;
• Кібербезпека.

Банки, зі свого боку, зобов’язані забезпечити базові API для прийому запитів на згоду, оновити внутрішні документи, провести автентифікацію клієнта на кожному кроці та миттєво припиняти доступ третьої сторони у разі відкликання згоди.

Артем Ляшанов регулярно аналізує зміни на фінтех-ринку України та світу для провідних бізнес-медіа. Більше колонок у блозі.