Артем Ляшанов про невидиму безпеку: Як технологія 3RI усуває архітектурні бар'єри у фінтеху

«Більшість фінтех-команд досі сприймають автентифікацію як необхідне зло, бар'єр між користувачем та платежем. SMS-коди, підтвердження у додатку, кинуті кошики. Роздратування з обох боків. Конверсія у мінусі. Підтримка завалена тикетами.

Але поки одні команди оптимізують цей бар'єр, інші його позбавляються. І інструмент для цього вже існує. Мова про 3RI. І ось чому це важливіше, ніж здається», – зазначає Артем Ляшанов.

Використання 3RI дозволяє ініціювати запити на аутентифікацію поза прямою взаємодією з користувачем (інтерфейсом оплати).

Трансформація UX у фінтеху

Класична логіка 3D Secure будувалася навколо постулату: «безпека прямо пропорційна активній участі платника».

Кожна транзакція – це введення OTP-коду, перехід у додаток, біометрична верифікація. На зорі електронної комерції це виглядало розумним компромісом, але в 2026 році, в умовах економіки підписок, така модель перетворилася на архітектурний глухий кут. Докладніше про те, як працювати з такими моделями оплати, Артем Ляшанов розповідав у матеріалі.

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

Коли у користувача сфокусовано п'ять-десять регулярних зобов'язань, він стикається з платіжною втомою.

• Ігнорування повідомлень;
• Таймінг-конфлікти;
• Обрив транзакційного ланцюжка.

В результаті бізнес стикається з необґрунтованим відтоком, а служба підтримки перевантажується тикетами, які не пов'язані з відсутністю коштів на рахунку, а спричинені виключно дефектом архітектури підтвердження.

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

Що таке 3RI і як він вирішує цю проблему

3RI (Requestor-Initiated) – це компонент протоколу 3-D Secure, який дозволяє мерчанту або PSP ініціювати автентифікацію транзакції без участі клієнта. Технічно це називається off-session автентифікація.

Механіка виглядає так:

При першому платежі клієнт проходить стандартну автентифікацію, вводить код, підтверджує у додатку один раз. Цей момент фіксується у системі як база для майбутніх запитів. Усі наступні транзакції ініціюються мерчантом безпосередньо через банк-емітент за протоколом 3RI. Система передає контекст попередньої аутентифікації, сигнали ризику, патерн поведінки клієнта. Банк аналізує дані у реальному часі та приймає рішення без участі користувача.

Результат: платіж або проходить у фоні, або банк запитує додаткове підтвердження тільки у разі реального ризику, але не як правило, а як виняток.

«Суть 3RI – невидимий, але надійний платіж. Коли клієнт не витрачає час, бізнес не втрачає гроші. Це вже не просто технологія, а новий стандарт зручності».

Артем Ляшанов, фінтех-підприємець

Де це вже працює і чому саме там

3RI не є універсальним рішенням для будь-якого платежу. Це точковий інструмент, який закриває конкретні сценарії, де присутність клієнта в момент транзакції надмірна чи неможлива.

Підписки та рекурентні платежі. Стрімінгові послуги, SaaS-продукти, цифрові видання, фітнес-додатки. Клієнт якось дав згоду, далі система працює сама. Без щомісячних SMS, без ризику втратити передплатника через те, що він був зайнятий у момент списання.

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

MOTO транзакції. Платежі по телефону та поштою – окремий болісний сегмент. Карта фізично немає, клієнт не може натиснути кнопку в додатку. Класична SCA тут або неможлива, або створює такий складний флоу, що конверсія падає до нуля. 3RI дає легальний та технічно коректний шлях для таких транзакцій.

Комунальні та регулярні платежі. Сценарій, де клієнт очікує на повну автоматизацію. Будь-яке тертя тут сприймається як збій сервісу, а не міра безпеки.

Регуляторний контекст

Тут важливо розвіяти поширену оману. Деякі команди сприймають аутентифікацію off-session як спробу обійти вимоги Strong Customer Authentication. Це принципово неправильне трактування.

PSD2 ввів SCA як обов'язкову вимогу, але одночасно передбачив винятки для транзакцій із низьким рівнем ризику за наявності достатнього контексту. PSD3 йде далі, він не просто зберігає ці винятки, але посилює акцент на ненав'язливу аутентифікацію як пріоритетну модель для рекурентних платежів.

«Ми вже бачимо, як міжнародні платіжні системи підтримують 3RI. Це технологія, яка логічно розвиває ідеї PSD2 і повністю відповідає новим стандартам PSD3, де акцент на безпечній, але ненав'язливій аутентифікації стає ще сильнішим». 

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

Що змінюється у метриках

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

Розберемо за кожним виміром.

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

Емітент отримує не анонімний запит, а повний контекст, історія аутентифікації, паттерн транзакцій, поведінкові сигнали. Це змінює логіку прийняття рішення за банку. Хибні відмови за підозрою у шахрайстві скорочуються не тому, що знизилася пильність, а тому, що з'явилася інформація для обґрунтованого рішення.

Кожен неуспішний платіж – це потенційне звернення на підтримку, ручне оброблення, комунікація з клієнтом. У рекурентних моделях з великим обсягом транзакцій це множиться на тисячі кейсів на місяць. 3RI прибирає цілий клас операційних проблем лише на рівні архітектури.