Чи потрібна банківська ліцензія, щоб запустити фінтех-застосунок?

«Чи потрібна банківська ліцензія, щоб запустити фінтех-застосунок?» — це насправді три питання в одному пальті. Чи ви тримаєте гроші клієнтів? Чи ви їх переміщуєте? І чий регуляторний дозвіл покриває це переміщення — ваш чи чийсь інший? Дайте відповідь на них, і питання ліцензування здебільшого розв'язується саме. Коротка версія, яка дивує більшість команд: більшість фінтех-застосунків ніколи не мають банківської ліцензії, бо вони ніколи не роблять того єдиного, для чого банківська ліцензія потрібна. Нижче — карта спектра, а не юридична порада: мета — знати, які питання ставити, перш ніж хтось назве вам строки чи ціну.

Для чого насправді потрібна банківська ліцензія

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

Спектр дозволів: від найважчого до найлегшого

Фінансові дозволи бувають кількох рівнів. На вершині — кредитна установа, тобто банк: він може приймати депозити та видавати кредити. Нижче — установа електронних грошей (EMI): вона може випускати електронні гроші, зберігати кошти клієнтів і розміщувати їх на картках чи в гаманцях, але залишок (float) мусить бути захищений: відокремлений, недоторканний і ніколи не виданий у кредит. Ще нижче — платіжна установа (PI): вона може виконувати платежі — ініціювати перекази, приймати кошти, здійснювати грошові перекази, еквайрити карткові операції, — але не призначена для зберігання коштів у часі: гроші проходять крізь неї, а не лежать на рахунку. І насамкінець агент або дистриб'ютор: власної ліцензії він не має взагалі, а працює на підставі дозволу ліцензованої компанії, яка його зареєструвала.

Закономірність проста: з кожним щаблем униз зникає одна можливість, а разом з нею — частина капіталу та зобов'язань. Приймати депозити — найважче, що можна дозволити; бути агентом того, хто це може, — найлегше. Більшість споживчих фінтех-застосунків — гаманці, картки, перекази, платіжні посилання — працюють у діапазоні EMI та платіжних установ або будуються поверх партнера, який має один із цих дозволів. Бути банком потрібно дуже рідко, і якщо зрозуміти це на початку, можна заощадити чимало зусиль, спрямованих не туди.

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

Оренда дозволу: партнерські моделі

Мати дозвіл самому, щоб будувати на ньому продукт, необов'язково. Звичайний шлях — орендувати його. У моделі sponsor bank або Banking-as-a-Service ліцензований банк чи EMI тримає рахунки, випускає IBAN і картки та захищає float, а ви створюєте застосунок на їхньому API і запускаєте сервіс. У агентській моделі ви реєструєтеся як агент платіжної установи або як дистриб'ютор емітента електронних грошей: їхня ліцензія покриває вашу діяльність, а регулятор знає про вас через них. Контракти різні, а суть та сама: десь у стеку хтось має дозвіл. Питання лише в тому, чи це ви, чи партнер.

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

Оренда ліцензії не знімає відповідальності. Перед регулятором відповідає ліцензована компанія — за захист коштів клієнтів, за моніторинг у сфері протидії відмиванню грошей, за поведінку всієї програми. Але ці зобов'язання за договором передаються вниз. Працюючи на ліцензії партнера, ви все одно проводите KYC та онбординг, все одно стежите за транзакціями з погляду AML і дотримуєтеся лімітів та звітності, якими зв'язаний партнер. Відповідальність не так передається назовні, як розподіляється: партнер відповідає за неї перед регулятором, а вас тримає договором, який значну частину щоденних обов'язків повертає на ваш бік. Читайте цей договір так само уважно, як читали б ліцензію, яку вирішили не отримувати.

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

Програмне забезпечення й ліцензія — окремі закупівлі

Саме це розуміння перебудовує весь проєкт. Платіжний застосунок здається клієнтові єдиним цілим, але насправді це два злиті елементи: регульований дозвіл тримати чи переміщувати гроші та програмне забезпечення, яке керує переказом, веде реєстр, зводить надходження й показує баланс на екрані. Постачаються вони окремо. Можна мати власну ліцензію й купити софт; мати ліцензію й створити софт власними силами; орендувати дозвіл через партнера й купити софт поверх нього; або взяти обидва в одного постачальника, який їх об'єднав. Усі чотири варіанти нормальні. Ненормально — і тихо відбирає місяці в проєктів — плутати їх: шукати «банківську ліцензію», коли насправді потрібен BaaS-партнер і застосунок, або шукати застосунок, припускаючи, що дозвіл іде до нього в комплекті.

Розуміння, що це окремі закупівлі, проясняє картину: їхню вартість і терміни можна планувати незалежно. Софт оцінюють за суттю — чи працює онбординг, чи коректний реєстр, чи можуть оператори справді керувати системою, — а дозвіл оцінюють за юрисдикцією, захистом коштів і умовами. Protocore Pay (/products/pay) — приклад програмного шару окремо: whitelabel-платформа застосунків і консоль оператора, що працює поверх будь-яких регульованих рейок, які ви до неї підключите. Це не ліцензія, і жодне програмне забезпечення нею не є — тому ліцензія й залишається окремим рядком у плані.

Що запитати в будь-якого постачальника платформи

Хто б не пропонував вам платформу «запусти свій фінтех», кілька однакових запитань прибирають більшу частину невизначеності. Чи містить ваш продукт регульований дозвіл, чи я приношу свій? Якщо містить — чия це ліцензія, в яких країнах, і чи я прямий клієнт цієї установи, чи її агент? Хто захищає кошти клієнтів і де вони зберігаються? Хто названий регулятору відповідальним за протидію відмиванню грошей — ви, партнер чи я? Які обов'язки лягають на мене за договором, хоча ліцензія не моя? І що станеться з грошима моїх клієнтів та їхніми даними, якщо партнерство припиниться? Відповіді швидко розподіляють постачальників на тих, хто продає софт, тих, хто перепродає дозвіл партнера, і тих, хто справді поєднав обидва, — і показують, з ким із трьох ви насправді розмовляєте.

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