Нужна ли банковская лицензия, чтобы запустить финтех-приложение?

Вопрос «Нужна ли банковская лицензия, чтобы запустить финтех-приложение?» на самом деле состоит из трёх вопросов в одном пальто. Вы храните деньги клиентов? Вы их перемещаете? И чьё регуляторное разрешение покрывает это перемещение — ваше или чужое? Ответьте на них, и вопрос о лицензии в основном решится сам. Короткая версия, которая удивляет большинство команд: большинство финтех-приложений никогда не получают банковскую лицензию, потому что большинство финтех-приложений не занимаются тем единственным, ради чего банковская лицензия нужна. Дальше — карта спектра, а не юридическая консультация: цель в том, чтобы знать, какие вопросы задать, прежде чем вам назовут сроки или цену.

Для чего на самом деле нужна банковская лицензия

Полная банковская лицензия — по терминологии ЕС, разрешение кредитной организации — допускает один конкретный, строго охраняемый вид деятельности: привлечение депозитов от населения и выдачу этих денег в кредит. Именно этот разрыв по срокам, когда долгие кредиты финансируются остатками, которые клиенты могут забрать в любой момент, и есть причина жёстких требований к капиталу, обязательств по гарантированию вкладов и надзорного органа, читающего баланс банка построчно. Если ваше приложение не принимает депозиты и не кредитует за их счёт, речь почти наверняка не о банковской лицензии. Речь о чём-то более лёгком, находящемся дальше по спектру, а спектр — это и есть вся история.

Спектр разрешений: от самых тяжёлых к самым лёгким

Финансовые разрешения делятся на уровни. На вершине стоит кредитная организация — банк, — которая может принимать депозиты и выдавать кредиты. Ниже находится учреждение электронных денег (EMI): оно вправе выпускать электронные деньги, то есть хранить средства клиентов и размещать их на картах или в кошельках. Но удерживаемый им float подлежит защите: он хранится отдельно, неприкосновенен и не может быть выдан в кредит. Ещё ниже — платёжная организация (PI): она может проводить платежи — инициировать переводы, принимать и отправлять деньги, заниматься эквайрингом карточных операций, — но не предназначена для хранения средств: деньги проходят через неё, а не лежат на счетах. А на самой нижней ступени агент или дистрибьютор вообще не имеет собственной лицензии и работает по полномочиям лицензированной компании, которая его зарегистрировала.

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

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

Аренда разрешения: партнёрские модели

Чтобы строить на разрешении, держать его самому не обязательно. Обычный путь — арендовать. По схеме sponsor bank или Banking-as-a-Service лицензированный банк или EMI ведёт счета, выпускает IBAN и карты и обеспечивает защиту float; вы пишете приложение поверх их API и выводите продукт на рынок. По агентской модели вы регистрируетесь как агент платёжной организации или как дистрибьютор эмитента электронных денег: их лицензия покрывает вашу деятельность, а регулятор знает о вас через них. Договоры разные, а суть одна: где-то в стеке кто-то держит разрешение. Вопрос лишь в том, вы это или партнёр.

Кто за что отвечает

Аренда лицензии не передаёт ответственность. Перед регулятором отвечает лицензированная компания — за защиту средств клиентов, за мониторинг в рамках AML, за поведение всей программы в целом. Но эти обязательства по договору спускаются вниз по цепочке. Работая под лицензией партнёра, вы всё равно проводите KYC и онбординг, следите за транзакциями в рамках AML, соблюдаете лимиты и отчётность, которыми связан партнёр. Ответственность не столько передаётся, сколько распределяется: партнёр отвечает за неё перед регулятором, а вы отвечаете перед ним по договору, который возлагает значительную часть повседневных обязанностей на вашу сторону. Читайте этот договор так же внимательно, как читали бы лицензию, которую решили не получать.

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

ПО и лицензия — это отдельные покупки

Именно это меняет порядок работы над всем проектом. Клиенту платёжное приложение кажется единым целым, но на деле это две сросшиеся вещи: регулируемое разрешение хранить или переводить деньги и программное обеспечение, которое отдаёт команды на перевод, ведёт ledger, сверяет зачисления и показывает баланс на экране. Источники у них разные. Можно получить собственную лицензию и купить ПО; получить лицензию и написать ПО самим; арендовать разрешение через партнёра и купить ПО поверх него; или взять и то, и другое у одного вендора, который их объединил. Все четыре варианта нормальны. Ненормально — и незаметно съедает у проектов месяцы — путать их: искать «банковскую лицензию», когда на самом деле нужен BaaS-партнёр и приложение, или искать приложение в расчёте на то, что разрешение идёт к нему в комплекте.

Взгляд на них как на отдельные покупки проясняет картину: их можно оценивать и планировать независимо. ПО оценивается по существу — работает ли онбординг, верен ли ledger, может ли операторская команда реально управлять системой, — а разрешение оценивается по юрисдикции, защите средств и условиям. Protocore Pay (/products/pay) — пример программного слоя в чистом виде: whitelabel-платформа приложений и операторская консоль, которая работает поверх любой регулируемой инфраструктуры, которую вы к ней подключите. Это не лицензия, и никакое ПО ею не является — именно поэтому лицензия остаётся в плане отдельной строкой.

Вопросы, которые стоит задать любому вендору платформы

Что бы вам ни предлагали под лозунгом «запусти свой финтех», один и тот же короткий список вопросов снимает большую часть неопределённости. Включено ли в ваш продукт регулируемое разрешение, или мне нужно принести своё? Если включено, чья это лицензия, в каких странах и являюсь ли я прямым клиентом этой компании или её агентом? Кто обеспечивает защиту средств клиентов и где они хранятся? Кто назван регулятору ответственным за противодействие отмыванию денег — вы, партнёр или я? Какие обязательства ложатся на меня по договору, хотя лицензия не моя? И что будет с деньгами и данными моих клиентов, если партнёрство закончится? Ответы быстро разделяют вендоров на тех, кто продаёт ПО, тех, кто перепродаёт разрешение партнёра, и тех, кто действительно объединил и то, и другое, — и показывают, с кем из них вы на самом деле разговариваете.

Хорошая новость в том, что большинство приложений стартуют как ПО плюс разрешение партнёра и переходят на собственную лицензию, только когда объём, маржа или стратегия оправдывают капитал и штат комплаенса. Понять, какая ступень вам действительно нужна, и что ПО и разрешение покупаются отдельными строками, — это большая часть дела. Остальное — задать вопросы выше и внимательно прочитать ответы. Всё сказанное не является юридической консультацией, а пороговые значения и названия категорий различаются в зависимости от юрисдикции; относитесь к этому тексту как к карте, с которой вы идёте на разговор с регулятором или консультантом, а не как к замене такого разговора.