UX і регуляторні вимоги: як зберегти зручність продукту без порушення норм

13 хвилин читання

Як поєднати зручність UX із фінтех-регуляцією без втрат для бізнесу? У цій статті MLRO компанії SENDS ділиться реальними кейсами, як побудувати комплаєнс, орієнтований на продукт, зберегти довіру користувачів і водночас повністю відповідати вимогам FCA та AML.

Photo: pexels.com

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

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

Читайте також: У глобальних компаніях публічність майже завжди належить CEO. Проте справжня архітектура бізнесу часто створюється іншими — тими, хто формує технологічне ядро і масштабування. Про еволюцію ролі співзасновника Revolut Влада Яценка детально пише Grokipedia, а Forbes Ukraine розкриває український контекст і бізнес-наслідки його переходу. Йдеться не просто про зміну посади, а про приклад того, як «друге обличчя» визначає траєкторію компанії з оцінкою $75 млрд.

Це постійне балансування, коли йдеться про фінтех-продукт. І я була залучена до нього як з боку UX, так і з боку регулювання.

Я відповідальна за фінансовий моніторинг (MLRO) у SENDS, британській фінтех-компанії, що регулюється Управлінням з фінансового нагляду Великої Британії (FCA). Моя робота полягає в тому, щоб забезпечити дотримання всіх нормативних вимог – боротьби з відмиванням грошей (AML), верифікація клієнтів (KYC), виявлення шахрайства, моніторинг транзакцій. Крім того, мені йдеться про те, щоб люди не покидали застосунок, ще до того, як побачать дашборд.

Це нелегке завдання. Тож ми повинні перестати ставитися до регулювання та UX як до протилежностей. Бо щойно відповідність вимогам порушує роботу продукту, ви вже втратили свого користувача.

Як комплаєнс руйнує користувацький досвід

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

У 2022 році видання Finextra повідомило, що понад 68% користувачів фінтех-застосунків відмовилися від процесу реєстрації через поганий досвід KYC. Це дві третини вашого маркетингового бюджету, витраченого ще до того, як користувач підтвердить свій обліковий запис. Для стартапів це смертельно небезпечно. Для регуляторів це втрачена можливість зміцнити довіру завдяки продуманому дизайну.

Чому це відбувається?

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

У SENDS я бачила, що відбувається, коли ви ставитеся до регулювання як формальної галочки. До мого призначення на нинішню посаду, процес онбордингу в застосунку займав у середньому 8 хвилин. 39% користувачів відпадали вже на третьому кроці: перевірці документів. І щогірше – користувачі, які зазнали невдачі один раз, часто не пробували знову.

Але комплаєнс не обов'язково означає складність. Коли це зроблено добре, це непомітно. Інтуїтивно зрозуміло. Зміцнює довіру.

Ось чому питання не в тому, чи дотримуємося ми вимог, а в тому, як ми це робимо, не вбиваючи досвід користувача.

Основи комплаєнс-стратегії, орієнтованої на продукт

У SENDS нам довелося зробити вибір: дозволити комплаєнсу визначати продукт, або дозволити продукту формувати комплаєнс. Ми обрали друге. І це змінило все.

Ми називаємо це комплаєнсом, орієнтованим на продукт. Замість того, щоб починати з регулювання та пізніше вигадувати, як його «впровадити», ми з першого дня тісно співпрацювали з командами розробників продуктів та UX. Це означало сидіти за одним столом, зіставляти шляхи користувачів з нормативними вимогами та переробляти обидва, коли вони суперечили один одному.

Одним з наших найефективніших кроків було впровадження багаторівневої моделі KYC. Натхненні ризикоорієнтованим підходом FATF, ми згрупували користувачів за категоріями на основі розміру транзакції та географічного ризику. Користувачі з нижчим рівнем ризику — хтось, хто надсилає 50 фунтів другу у Великій Британії — отримали легкий та безперешкодний процес реєстрації. Для користувачів з вищим ризиком автоматично запускалися більш глибокі перевірки.

Результат?

Підписуйтеся на наші соцмережі

  • Ми скоротили час онбордингу в середньому на 50%.
  • Відтік користувачів на етапі перевірки документів знизився з 39% до 20%.
  • Середня кількість звернень у службу підтримки, пов'язаних з верифікацією, зменшилася на 70% протягом трьох місяців після впровадження.

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

Ключові принципи поєднання UX та регулювання

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

1. Знайте регулювання краще, ніж ваш регулятор

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

Коли ми переробляли процес онбордингу у SENDS, я особисто переглядала не лише правила FCA Великої Британії, але й рекомендації FATF, директиви ЄС щодо боротьби з відмиванням грошей та навіть ключові санкційні рішення. Чому? Бо чим краще ми розуміли суть правил, тим більше свободи мали для інновацій.

Показовий приклад: закон не вимагав від користувачів завантажувати документи з першого дня. Він вимагав від нас перевірки особи перед певними діями. Тож ми реструктуризували процес — користувачі могли досліджувати додаток і запускали перевірку лише тоді, коли намагалися здійснити транзакцію. Ця зміна сама по собі збільшила утримання користувачів протягом першого тижня на 25%.

2. Дизайн з урахуванням ризику, а не бюрократії

Не всі користувачі становлять однаковий ризик і не всіх потрібно перевіряти однаково. Багаторівнева модель комплаєнсу дозволяє вам бути одночасно суворими та шанобливими до користувача.

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

Результат? Ми забезпечили повну відповідність вимогам AML і зменшили кількість хибних спрацювань на 40%, що дозволило співробітникам з комплаєнсу зосередитися на реальних загрозах.

3. Зробіть помилки зрозумілими

Занадто багато фінтех-компаній досі видають сповіщення на кшталт «IDV_FAIL_404» або вимагають повторного завантаження без жодних інструкцій. Це не комплаєнс — це лінощі.

Ми переписали кожне повідомлення про помилку в нашому процесі людською мовою. Замість «документ не прийнято» ми використали: «Ми не змогли прочитати ваше посвідчення особи. Спробуйте ще раз за кращого освітлення або зробіть чіткіше фото». Наш рівень успішності повторної перевірки зріс з 44% до 72%.

4. UX, продукт і юридичний відділ: об’єднуйте зусилля ще до старту розробки

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

У SENDS фахівці з комплаєнсу беруть участь у перших зустрічах з планування продукту. Наші вайрфрейми проходять оцінку ризиків, перш ніж потрапити у Figma. Спочатку це повільно, але швидше в довгостроковій перспективі.

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

Як безперешкодний комплаєнс впливає на прибуток

Якісний UX — це не просто “приємний бонус” у сфері комплаєнсу, це стратегічний актив. У SENDS, щойно ми відмовилися від універсального підходу до онбордингу та переробили наші процеси комплаєнсу з урахуванням потреб користувача, вплив був негайним та вимірюваним.

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

  • Час онбордингу користувачів скоротився на 43%. З 30 хвилин для корпоративних клієнтів до менш ніж 15 — без скасування жодного кроку комплаєнсу.
  • Коефіцієнт відмов під час перевірки особи знизився з 39% до 20%. Чіткіші інструкції, розумніша автоматизація та дизайн, орієнтований на мобільні пристрої, зробили свою справу.
  • Кількість хибнопозитивних AML-сповіщень зменшилась на 40%. Завдяки сегментації на основі ризиків та кращим навчальним даним.
  • Кількість звернень до підтримки, пов’язаних із KYC, знизилась на 70%. Ми надали користувачам інструменти для самостійного вирішення більшості проблем без ескалації.

Але цифри розповідають лише частину історії.

Ми почали отримувати спонтанні відгуки від користувачів, які писали, що процес «відчувався прозорим» або що він «підвищив довіру до додатка».  Це трапляється рідко. І цінно. Тому що довіра – це валюта у фінтех-сфері, а прозорість комплаєнсу – це новий брендинг.

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

Ми також почали підключати продакт-рішення до нашої системи оцінки ризиків. Коли користувач відмовляється від реєстрації на етапі завантаження документа, ми не просто реєструємо це – ми запитуємо чому. А іноді ми повністю змінюємо весь процес.

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

Чому індустрії потрібні комплаєнс-лідери з продуктовим мисленням

Фінтех-інновації переживають бум у всьому світі — у Лондоні, Берліні, Амстердамі, Нью-Йорку, Вільнюсі та інших містах. Лише у 2023 році європейські стартапи залучили понад 15 мільярдів євро фінансування, тоді як у США — понад 24 мільярди доларів. Від необанків до вбудованих фінансових платформ, цей простір є динамічним, швидкозмінним і дедалі складнішим.

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

Ми бачимо це всюди:

  • У Великій Британії Закон про фінансові послуги та ринки 2023 року запровадив кардинальні зміни щодо споживчих зборів, змушуючи компанії переглянути логіку онбордингу, розкриття інформації та доступності.
  • У США тиск з боку SEC та CFPB підштовхує фінтех-компанії до перегляду моделей ризику, особливо щодо кредитування та криптовалют.
  • У ЄС дія Регламенту про цифрову операційну стійкість (DORA) та нові вимоги щодо боротьби з відмиванням коштів перевіряють здатність компаній адаптуватися швидко — без шкоди для користувацького досвіду.

Результат? Багато зайвих дій. Повільніший онбординг. Порушені потоки. Команди з комплаєнсу, які намагаються перетворити юридичні вимоги в елегантний інтерфейс. А в найгірших випадках – недовіра та відтік користувачів.

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

Саме тут я знайшла свою перевагу.

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

Фінтех-екосистеми, які процвітатимуть — чи то в Лондоні, Нью-Йорку чи Варшаві — будуть ставитися до комплаєнсу не як до рішення в останню хвилину, а як до принципу дизайну продукту.