Матеріал носить інформаційний характер і не є юридичною консультацією. Для оцінки конкретної ситуації — зверніться до юриста.

Фінтех IT-компанія виходить на закордонні ринки без ліцензії: правила гри, моделі та регуляторні пастки

TL;DR

IT-компанія у фінтех може виходити на закордонні ринки без банківської або платіжної ліцензії — якщо вона постачає технологію, а не надає фінансові послуги кінцевому клієнту. Ключова умова: регульований партнер (банк, EMI, платіжна установа) бере на себе всі фінансові зобов'язання. Але «технологічний щит» не захищає від DORA, GDPR, AML/KYC-обов'язків і відповідальності за якість продукту. Модель працює — але потребує чіткої структури, правильно укладених контрактів і юридичного супроводу з першого дня.

Для кого ця стаття

• Засновники та C-level українських фінтех-компаній, що розглядають вихід на ринки ЄС, Великої Британії або США
• Юристи та compliance-офіцери, що структурують партнерства з іноземними банками
• Інвестори, що оцінюють регуляторні ризики фінтех-активів
• IT-компанії, що розробляють продукти для regulated ринків

Чому фінтех-компанії не завжди потребують ліцензії

Коротка відповідь

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

Пояснення

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

«Хто фактично зберігає, переміщує або розпоряджається грошима клієнта?»

Якщо відповідь — ліцензований банк або платіжна установа, а IT-компанія лише надає їм програмне забезпечення, інтерфейс або аналітику — ліцензія IT-компанії не вимагається. Це відоме в галузі як модель "технологічного провайдера" або BaaS (Banking-as-a-Service) з позиції вендора.

Приклад: Monobank / Fintech-IT Group

Найвідоміший кейс в Україні — Fintech Band (нині Fintech-IT Group), розробник додатку monobank. З самого початку, у 2017 році, компанія позиціонувала себе як IT-компанію, що розробляє банківський продукт для Universal Bank. Банківська ліцензія — у Universal Bank. Фінансова відповідальність, KYC/AML, зберігання коштів — у Universal Bank. Fintech-IT Group надає технологію, UX і операційну модель.

Результат: станом на жовтень 2025 року Fintech-IT Group оцінена понад $1 млрд (перший фінтех-юнікорн України) — як IT-компанія, а не банк. Близько 90% виручки холдингу формує FintechBand — технологічний оператор monobank.

Водночас спроба самостійного виходу на ринок Великої Британії (проєкт Koto) зіткнулася з необхідністю отримати фінансову ліцензію FCA — і проєкт був призупинений.

Висновок: модель «IT-компанія + регульований партнер» дозволяє масштабуватися без власної ліцензії. Але самостійна операція на regulated ринку без партнера = ліцензування обов'язкове.

Три основні моделі виходу фінтеху на міжнародні ринки без власної ліцензії

Модель 1: White-label / IT-вендор для банку

Суть: IT-компанія розробляє або постачає готове рішення (мобільний банк, платіжний модуль, скоринг, KYC-систему) — банк або EMI використовує його під власним брендом.

Юридична позиція IT-компанії: постачальник програмного забезпечення (SaaS або Source Code License). Договір — IT-сервісний або ліцензійний. Фінансова відповідальність перед клієнтами — виключно у партнера.

Приклади глобальні: SDK.finance, DashDevs Fintech Core, Solaris (діє як «банківська технологічна компанія з ліцензією» для партнерів, що не мають власної). Перед отриманням власної ліцензії, N26 використовував white-label інфраструктуру Wirecard Bank.

Плюси:

• Жодних регуляторних вимог щодо отримання фінансової ліцензії
• Швидкий вихід на ринок (тижні, а не роки)
• Масштабування через кількох партнерів одночасно

Ризики:

• Залежність від партнерської ліцензії: якщо партнер втрачає ліцензію — бізнес зупиняється
• DORA (ЄС): IT-компанія стає ICT third-party provider з додатковими зобов'язаннями
• Регулятор може перекласифікувати IT-компанію як фактичного надавача послуг (якщо реальний контроль — у вендора)

Модель 2: BaaS (Banking-as-a-Service) — партнерство з liсензованою платформою

Суть: фінтех-компанія підключається до BaaS-платформи (Solaris, Clearbank, Stripe Treasury, Unit тощо), яка має ліцензію і надає API-доступ до банківської інфраструктури. IT-компанія будує споживчий продукт поверх.

Юридична позиція: дистрибутор або агент ліцензованої установи. Кінцевий продукт — «powered by [BaaS partner]».

Практично: такі компанії, як Solaris (Берлін, банківська ліцензія), дозволяють партнерам розробляти і продавати банківські продукти клієнтам — без отримання власної ліцензії партнером.

Плюси:

• Регуляторний «парасоль» ліцензованого партнера
• Швидкий запуск MVP (тижні, не місяці)
• KYC/AML — на стороні BaaS-провайдера

Ризики:

• Регулятори, зокрема у США, посилюють нагляд: понад 45 enforcement actions щодо BaaS-партнерств у 2023–2024 рр. (банки несуть відповідальність за дії фінтех-партнерів)
• Вендорний lock-in: зміна BaaS-партнера може паралізувати продукт
• Колапс проміжного гравця ризикований для всього ланцюжка (кейс Synapse у США, 2024)
• AML-обов'язки частково переходять до IT-компанії через договір

Модель 3: B2B SaaS для regulated entities (чиста IT-модель)

Суть: IT-компанія продає технологічний продукт (скоринг, fraud detection, KYC/AML-система, core banking software, регуляторна звітність) безпосередньо банкам, страховим компаніям, платіжним установам.

Юридична позиція: чистий технологічний постачальник (ICT third-party service provider). Фінансові послуги не надаються взагалі — ні прямо, ні опосередковано кінцевому клієнту.

Приклади: RegTech-компанії (ComplyAdvantage, Fenergo), core banking постачальники, AI-аналітика для банків.

Плюси:

• Найчистіша регуляторна позиція
• Немає споживчих ризиків
• Можна входити в ЄС без ліцензії

Ризики:

• DORA: IT-компанія, що постачає послуги EU financial entities, потрапляє в ICT third-party oversight framework
• Потрібні DORA-compliant контракти (SLA, audit rights, exit strategy, incident notification)
• Якщо визнана «критичним ICT-постачальником» — прямий нагляд з боку ESA (EBA/ESMA/EIOPA) і зобов'язання присутності в ЄС

Коли ліцензія обов'язкова: червоні лінії

Незалежно від обраної моделі, власна фінансова ліцензія потрібна, якщо IT-компанія:

Функція

Ліцензія

Зберігає кошти клієнтів

Банківська або EMI

Здійснює платіжні операції від свого імені

Payment Institution (PI) або EMI

Видає електронні гроші

EMI license

Надає інвестиційні послуги

MiFID II authorization

Обмінює або зберігає крипто

CASP / VASP (MiCA, з 2025 р.)

Кредитує кінцевих клієнтів

Consumer credit license

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

DORA: нова реальність для IT-компаній у фінтех

Що відбулося з 17 січня 2025 року

З набуттям чинності DORA (EU Regulation 2022/2554) будь-яка IT-компанія, що постачає ICT-послуги фінансовим установам ЄС, потрапляє під регуляторний периметр — навіть якщо сама не є банком чи фінтехом.

DORA охоплює: хмарні провайдери, розробники ПЗ, SaaS-платформи, аналітичні сервіси, IT-консалтинг — якщо вони обслуговують banks, insurance companies, payment institutions, crypto-asset service providers у ЄС.

Що це означає для Ukrainian IT-компанії

Якщо ваш клієнт — банк або платіжна установа в ЄС, ваш контракт має включати:

• SLA з чіткими показниками доступності та часу відновлення
• Audit rights — право клієнта (банку) та регулятора перевіряти вашу інфраструктуру
• Exit strategy — план переходу клієнта до альтернативного постачальника
• Incident notification — процедури та дедлайни повідомлення про ICT-інциденти
• Subcontracting clauses — прозорість ланцюжка субпідрядників

Якщо ESAs (EBA/ESMA/EIOPA) визнають вас «critical ICT third-party provider» (CTPP) — ви зобов'язані встановити присутність в ЄС протягом 12 місяців і підпорядкуватися прямому нагляду з боку ESA.

Станом на листопад 2025 р. перший список CTPP включає 19 провайдерів (AWS, Microsoft Azure, Google Cloud та ін.). Українські IT-компанії масштабу Fintech-IT Group поки не в списку, але ризик зростає разом з обсягом контрактів.

Регуляторна карта ЄС: що потрібно знати до виходу

Регуляція

Кого стосується

Ключова вимога для IT-вендора

DORA (2025)

ICT-провайдери EU financial entities

Contacutally compliant contracts, incident reporting, audit readiness

GDPR

Будь-яка обробка персональних даних EU residents

DPA з клієнтом, Data Processing Agreement, transfer mechanisms

PSD2 / PSD3

Payment services

Не стосується чистого IT-вендора, але стосується агентів PI/EMI

MiCA (2025)

Crypto-asset services

CASP license для крипто-послуг; IT-вендори — DORA scope

AMLD (6th)

Фінансові установи та агенти

AML policy може поширюватися на IT-компанії в ролі агентів

AI Act (2025)

Системи AI у фінансових рішеннях

High-risk classification для credit scoring AI; transparency obligations

Покроковий алгоритм виходу на закордонний ринок без ліцензії

Крок 1: Визначте модель і позицію компанії

• Чи буде компанія мати прямий контакт з кінцевими клієнтами фінансових послуг?
• Чи будуть на рахунках компанії кошти клієнтів?
• Чи визначає компанія умови надання фінансових послуг кінцевим користувачам?

Якщо відповідь «ні» — рухайтесь далі. Якщо «так» хоч на одне — стоп: потрібна ліцензія або реструктуризація.

Крок 2: Юрисдикційна перевірка цільового ринку

Визначте:

• Яка регуляторна класифікація вашого продукту в конкретній країні?
• Чи існує в цій юрисдикції концепція «технологічного вендора» без ліцензії?
• Які вимоги до AML/KYC для IT-вендорів у цій країні?

Пріоритети для українських компаній:

• ЄС (особливо Литва, Естонія, Польща): розвинений фінтех-регулятор, пасспортинг у межах ЄС — але DORA з дня один
• Велика Британія (FCA): окрема юрисдикція після Brexit, FCA sandbox для тестування
• Німеччина: BaFin — суворий, але передбачуваний
• США: федерально-штатний лабіринт, залежить від типу послуги та штату

Крок 3: Обрати та структурувати партнерство

• Обрати партнерський банк або BaaS-платформу з активною ліцензією у цільовому ринку
• Узгодити розподіл відповідальності: хто несе KYC/AML, хто виконує compliance, хто відповідає перед регулятором
• Укласти договір із DORA-compliant клаузулами (якщо це ЄС)
• Підписати DPA (Data Processing Agreement) під GDPR

Крок 4: Структурувати корпоративну оболонку

• Визначити юридичну особу для роботи в цільовій юрисдикції (subsidiary, branch, contract entity)
• Оцінити податкові наслідки: transfer pricing при реалізації IP, royalty structures
• Кіпрська холдингова структура (як у Fintech-IT Group) — поширена модель для українських компаній для акумуляції іноземних доходів

Крок 5: Compliance readiness

• Побудувати внутрішню AML/KYC-програму (навіть якщо не є фінансовою установою — регульований партнер вимагатиме аудиту)
• Впровадити GDPR-compliant data governance
• Підготувати incident management policy (DORA)
• Призначити відповідального за compliance у цільовій юрисдикції

Крок 6: Sandbox / Regulatory dialogue

• У Великій Британії, Литві, Сингапурі та ін. — використати regulatory sandbox (тест продукту без повного ліцензування)
• Проактивна комунікація з регулятором знижує ризик enforcement action

Ключові ризики та сценарії

Ризик 1: Перекласифікація IT-компанії у фінансову установу

Сценарій А: регулятор встановлює, що IT-компанія фактично контролює продукт, призначає тарифи, управляє лімітами. Банк-партнер — номінальний. Результат: enforcement action, зупинення діяльності, штрафи.

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

Ризик 2: Колапс партнера

Сценарій Б: банк-партнер втрачає ліцензію або банкрутує (кейс Synapse у США, 2024 — тисячі клієнтів залишилися без доступу до коштів). IT-компанія зупиняє роботу одночасно.

Контроль: exit strategy у контракті, мультипартнерська модель, contractual protections.

Ризик 3: DORA non-compliance

Сценарій В: EU financial entity включає IT-компанію в Register of ICT third-party providers і виявляє відсутність audit rights, exit strategy або incident notification в контракті. Банк зобов'язаний розірвати договір.

Контроль: DORA-compliant contract від початку, не після enforcement.

Ризик 4: IP та конфіденційність

Сценарій Г: банк-партнер або регулятор вимагають доступу до вихідного коду або алгоритмів. IT-компанія не захистила IP завчасно.

Контроль: source code escrow, IP licensing (не передача), confidentiality carve-outs у контракті.

Ризик 5: AML-відповідальність через «знання»

Сценарій Д: IT-компанія є middleware-провайдером, обробляє дані транзакцій. Регулятор стверджує, що компанія «знала або мала знати» про підозрілу діяльність і не повідомила.

Контроль: чіткий contractual disclaimer щодо AML-відповідальності, SAR (Suspicious Activity Report) obligations — лише на стороні регульованого партнера.

Типові помилки

❌ Помилка 1: «Ми технологічна компанія, нас це не стосується»
Стосується — якщо ваш клієнт є EU financial entity. DORA застосовується незалежно від того, де базується IT-провайдер.

❌ Помилка 2: Копіювати локальний IT-договір для іноземного ринку
Стандартний IT-контракт не містить DORA-клаузул, GDPR DPA, exit strategy, audit rights. Його не приймуть серйозні партнери в ЄС або Великій Британії.

❌ Помилка 3: Недооцінити вимоги банку-партнера
Банки-партнери (особливо у США) після 2023–2024 рр. вимагають від IT-партнерів дотримання суворіших AML/KYC-стандартів, ніж це юридично обов'язково для нефінансових компаній.

❌ Помилка 4: Запустити — потім регулювати
Стратегія «launch first, comply later» більше не працює. Регулятори у ЄС та США активно використовують enforcement на etапі продукту, а не після скарг клієнтів.

❌ Помилка 5: Ігнорувати корпоративну структуру
Відсутність правильної holding structure для акумуляції іноземних доходів від royalties/SaaS → нееффективне оподаткування і потенційні трансфертні ризики.

❌ Помилка 6: Один партнер = безпека
Якщо бізнес-модель повністю залежить від однієї ліцензії одного партнера — це концентраційний ризик, що може обнулити всю компанію.

Коли звертатися до юриста

• До підписання будь-якого партнерського договору з іноземним банком або BaaS-платформою
• До реєстрації юридичної особи в цільовій юрисдикції
• При першому контакті з регулятором або отриманні запиту від нього
• При масштабуванні продукту з одного ринку на кілька (кожна нова юрисдикція = окремий аналіз)
• При зміні бізнес-моделі (наприклад, перехід від B2B до B2C — може активувати ліцензійні вимоги)
• При залученні інвестицій від іноземних фондів (due diligence включає регуляторну оцінку)
• При первинних ознаках перекласифікації або запитах від регулятора щодо характеру діяльності

FAQ

1. Чи може українська IT-компанія постачати BaaS-продукт в ЄС без ліцензії?
Так, якщо компанія є технологічним вендором, а не надавачем фінансових послуг. Кінцева відповідальність перед регулятором — у ліцензованого партнера. Але контракт має відповідати вимогам DORA, а компанія — готуватися до ICT third-party audits.

2. Що таке BaaS і чому він дозволяє обійтися без ліцензії?
BaaS (Banking-as-a-Service) — модель, де ліцензована установа надає API-доступ до своєї банківської інфраструктури. Партнер (IT-компанія) будує продукт поверх, але кошти клієнтів тримає ліцензований банк. IT-компанія не зберігає і не переміщує кошти — ліцензія не потрібна.

3. Чи стосується DORA Ukrainian IT-компаній?
Так — якщо вони постачають ICT-послуги фінансовим установам в ЄС, незалежно від місця реєстрації постачальника. DORA має екстериторіальне застосування щодо ICT-провайдерів, що обслуговують EU financial entities.

4. Як Mono (Fintech-IT Group) працює без банківської ліцензії?
Fintech-IT Group — розробник технологічної платформи. Банківська ліцензія — у Universal Bank, партнера по контракту. Fintech-IT Group отримує дохід як постачальник IT-сервісів, а не як банк. При виході на ринок Великої Британії (Koto) — власна ліцензія FCA вже була необхідна.

5. Яка мінімальна структура потрібна для B2B SaaS у ЄС?
Щонайменше: DORA-compliant контракт, GDPR Data Processing Agreement, AML-policy (на вимогу клієнта), incident notification procedure. Бажано: legal entity в ЄС для спрощення договірних відносин і local compliance representation.

6. Де найлегше отримати EMI-ліцензію в ЄС, якщо вона таки потрібна?
Литва (Bank of Lithuania), Естонія, Ірландія — традиційно найбільш відкриті юрисдикції для фінтех-ліцензування. Литовська EMI-ліцензія дає пасспортинг на всі країни ЄС. Термін — від 6 до 12 місяців.

7. Чи є ризик, що регулятор перекваліфікує IT-компанію у платіжну установу?
Так. Якщо IT-компанія фактично контролює умови фінансового продукту для кінцевих користувачів, визначає ліміти, тарифи або управляє клієнтськими рахунками — регулятор може застосувати substance over form і визнати її де-факто платіжною установою.

8. Чи може Ukrainian IT-компанія отримати DORA-статус критичного провайдера?
Теоретично — так, якщо масштаб послуг для EU financial entities стає системно значущим. Перший список CTPP (листопад 2025) включає 19 глобальних провайдерів. Для mid-size Ukrainian компаній цей ризик поки низький, але зростає з масштабом.

Висновок

Вихід фінтех IT-компанії на закордонний regulated ринок без власної ліцензії — цілком легальна і доведена стратегія, реалізована такими гравцями, як Fintech-IT Group (Monobank), Solaris, SDK.finance та десятками інших. Ключові умови:

1. Чітке розмежування між «технологічним провайдером» і «надавачем фінансових послуг»
2. Правильно структурований партнерський договір з ліцензованою установою
3. DORA-ready контракт для будь-якого продукту в ЄС (з 2025 р.)
4. Корпоративна структура, що захищає IP і оптимізує оподаткування доходів
5. Готовність до compliance-аудитів з боку банків-партнерів та регуляторів

Модель «IT-компанія + регульований партнер» — це не уникнення регуляції. Це правильний розподіл регуляторних ролей між учасниками ринку. І він потребує такого ж серйозного юридичного супроводу, як і пряме ліцензування.

Потрібна структура для виходу на зовнішній ринок?

Juscutum супроводжує фінтех-компанії у:

• Структуруванні партнерств з іноземними банками та BaaS-платформами
• Аналізі регуляторної позиції продукту в ЄС, Великій Британії, США
• Підготовці DORA-compliant контрактів
• Побудові холдингових структур для акумуляції іноземних доходів
• EMI/PI-ліцензуванні в юрисдикціях ЄС

→ Отримати консультацію фінтех-юриста Juscutum

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

‍