FinTech Lab в МФЦА: authorisation (sandbox licence) — правовой статус, рамка теста и выход из sandbox
Authorisation в FinTech Lab — это ограниченная «sandbox licence», которая позволяет тестировать FinTech-активности в контролируемой среде и строго в параметрах, согласованных с AFSA (scope, лимиты, меры защиты клиентов, отчётность и exit plan).
- Sandbox authorisation — это режим тестирования, а не «облегчённая постоянная лицензия».
- Право действует только в пределах согласованной рамки; выход за perimeter — ключевой регуляторный риск.
- Итог теста — exit-сценарий: лицензирование, изменение модели, либо прекращение теста с закрытием обязательств.
Чем точнее описаны операции, клиентский путь и контрольные меры, тем меньше риск «переоткрытия» периметра в ходе теста.
Из чего состоит sandbox authorisation
Ниже — ключевые «узлы», которые обычно определяют судьбу заявки: квалификация модели, пакет документов, надзорный режим и логика перехода к постоянной деятельности (если она предполагается).
Что именно вы тестируете, почему это FinTech Lab и где проходят границы «разрешённого».
- роль компании в цепочке операций
- клиенты, география, каналы, лимиты
- риски и обоснование пропорциональности
Какие блоки «доказывают» управляемость модели и готовность к тесту под надзором.
- описание продукта и процессные схемы
- контроли: AML/KYC, жалобы, инциденты
- outsourcing, доступы, данные, BCP
Как живёт проект в sandbox: отчётность, мониторинг, изменения рамки, управление рисками.
- периодические отчёты и метрики теста
- контроль изменений и эскалации
- коммуникация и «case management»
Что должно быть готово заранее, чтобы выход из sandbox не превратился в «тормоз» проекта.
- сценарии: licence / change / stop
- закрытие обязательств перед клиентами
- данные, доступы, подрядчики, SLA
Как работает authorisation на практике
ЧТО ВАЖНО ПОНИМАТЬ: sandbox licence — это «контролируемый допуск». AFSA оценивает не «идею», а управляемость: понятную рамку теста, измеримые критерии, защиту клиентов и управляемый exit.
В FinTech Lab могут применяться пропорциональные послабления к отдельным требованиям — но только если это компенсируется рамкой теста и контрольными мерами.
- ограниченный масштаб операций (объёмы/суммы/кол-во клиентов)
- ограниченная функциональность продукта (только «ядро» теста)
- условия по IT/outsourcing (доступы, мониторинг, инциденты)
- условия по раскрытиям клиенту и жалобам
Критические ошибки возникают, когда фактическая деятельность начинает выходить за согласованный perimeter или когда «контроли на бумаге» не стыкуются с client journey и процессами.
- неопределённая роль компании (broker/dealer/custody vs IT-провайдер)
- непрописанные лимиты и критерии успеха теста
- нет управляемых процедур инцидентов/жалоб/эскалаций
- неуправляемые подрядчики и доступ к данным
Sandbox authorisation: краткая матрица смысла
Для быстрой проверки ожиданий по статусу и ограничениям
| Элемент | Что это | Практический смысл |
|---|---|---|
| Licence (authorisation) | Ограниченное разрешение на тестирование FinTech-активности | Даёт право тестировать только в рамках рамки (scope/limits/controls), а не «вести бизнес как обычно» |
| Условия и ограничения | Формальные условия по операциям, клиентам, функциям, отчётности | Это «страховка» пропорциональности: чем выше риск — тем жёстче perimeter и safeguards |
| Срок теста | Ограниченный по времени статус (как правило, до нескольких лет) | Срок связан с целями теста; продление/изменение рамки обычно требует отдельной регуляторной оценки |
| Мониторинг и отчётность | Регулярная отчётность по метрикам теста и событиям | Отчётность — это часть допуска; отсутствие данных/логов/процедур = риск пересмотра условий |
| Exit plan | Сценарий после теста | Выход обязателен: переход в лицензирование, изменение модели или прекращение теста с закрытием обязательств |
Материал носит общий характер и не является юридическим заключением.
Виды деятельности, которые обычно тестируют в FinTech Lab
Ниже — навигация по страницам продуктов/моделей. Каждый сценарий требует своей рамки: perimeter, лимитов, клиентских защит и контроля рисков.
Тестирование торговли цифровыми активами и связанных функций.
- модель допуска клиентов и лимиты
- market conduct и раскрытия
- операционный контроль и инциденты
Денежные услуги и цифровые платежи в тестовом контуре.
- потоки средств и сегрегация
- комплаенс и AML-триггеры
- жалобы, chargebacks, disputes
Брокерские решения: допуск, исполнение, раскрытия и конфликты.
- client onboarding и suitability
- конфликты интересов
- контроль исполнения и отчёты
Дилерские операции и риск-профиль модели.
- риски позиции и лимиты
- pricing / spreads / disclosure
- операционный контроль
Краудфандинг: инвесторские допуски, лимиты и раскрытия.
- инвесторские ограничения
- документы эмитента/проекта
- операционный и IT-контур
Тестирование STO-модели и цепочки размещения.
- периметр токена и права
- маркетинг и disclosure
- custody / settlement / KYC
Деривативы: маржинальные риски и client safeguards.
- risk limits и ликвидации
- расчёт P&L и прозрачность
- инциденты и стресс-сценарии
Стейкинг: custody-контур, риски протокола и раскрытия.
- делегирование/валидаторы
- риски slashing и downtime
- раскрытия и consent
NFT-торговля и сервисы вокруг маркетплейса.
- правовой perimeter контента
- consumer disclosures
- модерация и disputes
Кредитование в цифровых активах: залоги, ликвидации, disclosure.
- LTV и маржин-механики
- оценка и хранение залога
- порядок взыскания
Yield-модели: риски протокола, раскрытия и ограничения.
- риски смарт-контрактов
- loss/impermanent loss
- модель комиссий и disclosure
Перечень сценариев дан для навигации по разделу и не заменяет квалификацию конкретной модели.
Путь проекта: от идеи до выхода из sandbox
Типовая логика: сначала фиксируем perimeter и риски, затем проектируем рамку теста, проходим authorisation и управляем тестом до exit-сценария.
Определяем фактическую деятельность, роль компании, потоки средств/активов, клиентский путь и регуляторные «триггеры».
Формируем scope/limits/safeguards, критерии успеха, отчётность, план инцидентов и требования к подрядчикам/IT.
Получаем sandbox licence и запускаем тест строго в согласованных параметрах, с мониторингом и контролем изменений.
Реализуем сценарий: переход к лицензированию, изменение модели или завершение проекта с закрытием обязательств и данных.
Глоссарий
Термины, которые чаще всего встречаются в коммуникации с регулятором по sandbox authorisation.
Ограниченная лицензия (разрешение) на тестирование FinTech-активности в рамках согласованных условий.
Граница деятельности: что именно делает компания и где заканчивается разрешённый контур теста.
Меры защиты клиентов и рынка: раскрытия, жалобы, инциденты, сегрегация, контроль доступа, мониторинг.
Изменение параметров authorisation: лимитов, функций, клиентов или условий — обычно требует регуляторной оценки.
FAQ
Короткие ответы на вопросы, которые чаще всего возникают по sandbox authorisation.
Sandbox licence — это «облегчённая лицензия» на постоянную деятельность?+
Можно ли масштабировать продукт во время теста?+
Что является «ядром» сильной заявки на authorisation?+
Что происходит, если проект выходит за рамки теста?+
Материал подготовлен для общего информирования и не является юридической консультацией или заключением.
Сопровождение обычно строится вокруг периметра и управляемости: чтобы рамка теста соответствовала фактическим процессам и рискам.
- квалификация модели (perimeter) и карта регулируемых функций
- дизайн scope/limits/safeguards, критериев теста и отчётности
- правка/сбор пакета документов под рамку и процессы
- контуры outsourcing, IT-контролей, инцидентов, жалоб и exit
Чтобы быстро оценить пригодность FinTech Lab и формат authorisation, обычно достаточно короткого описания модели и схемы операций.
- что за продукт и кто клиент
- есть ли потоки средств/цифровых активов
- какие функции делаете сами, какие — через подрядчиков
- какой «выход» планируется после теста