Astana Financial Services Authority

Комитет по регулированию финансовых услуг МФЦА (AFSA): лицензирование, надзор и правовые рамки

AFSA — регулятор финансовых услуг и связанных видов деятельности в контуре МФЦА (AIFC). На практике именно AFSA определяет, является ли модель регулируемой, какой режим и какой пакет требований применим, а также сопровождает жизненный цикл компании: от авторизации до постоянного надзора и изменений.

  • Лицензирование зависит от фактической модели: роли компании, потоков средств/активов и клиентского контура.
  • Надзор и отчётность строятся по risk-based подходу и системе внутреннего контроля.
  • Ключевая база — AIFC Regulations и Rulebooks (GEN, AML, COB, PRU и др.).
Куда смотреть на старте
Perimeter (применимость) Authorisation (лицензия) Supervision (надзор) Legal framework

Главная ошибка старта — «назвать продукт» и считать, что лицензия очевидна. В AFSA решает не название, а роль, риски и фактическая архитектура операций.

Ключевые разделы AFSA

Ниже — практические «точки входа» в регуляторную логику AFSA: от проверки применимости до постоянного надзора.

AU
Лицензирование (Authorisation)

Как AFSA рассматривает заявки и какие блоки обычно проверяет в первую очередь.

  • Квалификация модели и Regulated Activities
  • Controlled / Designated functions
  • Программа комплаенс и внутренние политики
Подробнее
SV
Надзор (Supervision)

Что означает «быть под надзором» после лицензирования и какие ожидания по контролю.

  • Risk-based supervision и взаимодействие
  • Отчётность и уведомления о изменениях
  • Роль governance, систем и контролей
Подробнее
LF
Правовые рамки (Rulebooks)

Какие модули правил обычно «поднимаются» в заявке и в текущей деятельности.

  • GEN: базовые принципы и функции
  • AML: риск-ориентированный контур
  • COB/PRU: conduct & prudential (где применимо)
Подробнее
EN
Применение мер (Enforcement)

Как AFSA реагирует на нарушения и почему важна дисциплина по изменениям модели и отчётности.

  • Обязательные уведомления и события
  • Проверки и запросы регулятора
  • Санкции и корректирующие меры
Подробнее

Роль AFSA в контуре МФЦА

ЧТО ВАЖНО ПОНИМАТЬ: AFSA не «выдаёт бумагу», а формирует регуляторный контур: авторизация, требования к управлению, надзор и контроль изменений.

Периметр и применимость
Ключевой вопрос — подпадает ли модель под Regulated Activities и какие модули правил применяются к компании и её должностным лицам.
Авторизация и условия
Лицензирование включает оценку governance, компетенций, meaning of control, внутреннего контроля и операционной устойчивости.
Постоянный надзор
После выдачи лицензии сохраняются обязанности по отчётности, уведомлениям о событиях и корректности фактической модели.

Карта функций AFSA (упрощённо)

Что обычно «проверяет» регулятор и что ожидает увидеть в документах

ЧТО ВАЖНО ПОНИМАТЬ
Блок О чём Что важно понимать
Perimeter Квалификация деятельности и применимость Regulated Activities Решает фактика: роль компании, контроль над активами/средствами, onboarding, маршруты платежей и custody (если есть)
Authorisation Лицензирование и оценка готовности к запуску Смотрят governance, компетенции, системные контроли, внутренние политики и реалистичность операционной модели
Systems & Controls Внутренний контроль, риск-менеджмент, комплаенс, BCP Документы должны соответствовать реальным процессам: «политика без процесса» быстро проявляется на Q&A и в надзоре
Supervision Надзор, отчётность, проверки, запросы После лицензирования важны изменения модели, уведомления о событиях и дисциплина по регулярным обязанностям
Enforcement Меры воздействия при нарушениях Риски часто возникают не из «злого умысла», а из неуправляемых изменений, просроченных уведомлений и слабого governance

Путь проекта через AFSA

Типовая логика: от первичной квалификации до авторизации и выхода на «режим» постоянного надзора.

1
Квалификация периметра

Фиксация фактической роли компании, потоков средств/активов, клиентского периметра и применимых Regulated Activities.

2
Архитектура модели

Governance, распределение ответственности, инфраструктура (custody/PSP/ИТ), целевая операционная модель и контроль рисков.

3
Документы и функции

Политики, процедуры, role descriptions, внутренний контроль, комплаенс и готовность к Q&A регулятора.

4
Надзор и изменения

Поддержание режима: отчётность, уведомления, контроль изменений в продукте и операциях, регулярные проверки/запросы.

Когда возникает регулирование AFSA

Вопрос «нужна ли лицензия» в AFSA решается не по маркетинговому описанию продукта, а по фактической роли компании и рискам для целей регулятора.

Факторы, которые обычно имеют значение

Для первичной квалификации важны роль компании, степень контроля, движение средств/активов и характер отношений с клиентом.

  • Есть ли приём/передача денег или активов клиентов (включая custody, settlement)
  • Кто инициирует сделки и кто несёт ответственность перед клиентом
  • Доступ к ключевым функциям: onboarding, KYC, распоряжения, лимиты
  • Клиентский сегмент, география и cross-border периметр
Что обычно требуется при регулируемой модели

Даже «маленькая» модель требует контроля: governance, систем и процедур, а также роли контрольных функций.

  • Controlled/Designated functions и разграничение ролей
  • AML/KYC: риск-ориентированная модель и onboarding
  • Risk management, conflicts, complaints (где применимо)
  • BCP/outsourcing/IT controls (по профилю деятельности)
Практические материалы

Мы собираем практические пояснения по применимости требований, структуре функций и типовым документам в разделе Ресурсы.

Что AFSA обычно ожидает увидеть в «зрелой» модели

Это не перечень «для галочки», а практические элементы, по которым чаще всего задаются вопросы на лицензировании и в надзоре.

1 Реалистичный governance

Понятные роли, ответственность и контроль: кто принимает решения, кто контролирует риски и комплаенс.

2 Риск-ориентированный комплаенс

AML/KYC не как «документ», а как процесс: оценка рисков, мониторинг, отчётность, обучение.

3 Контроль изменений

Изменения продукта, каналов, клиентов, потоков — отдельный контур управления и уведомлений.

4 Outsourcing & resilience

Управление подрядчиками, критичными функциями, BCP и IT-контролями на уровне реальной зависимости бизнеса.

5 Прозрачная архитектура операций

Понятно «кто где держит» активы/деньги, как идут платежи, где возникают риски и кто за них отвечает.

6 Документы = процессы

Политики соответствуют реальным операционным шагам; иначе несоответствие проявляется в Q&A и на надзоре.

Глоссарий

Краткие определения терминов, которые чаще всего встречаются при взаимодействии с AFSA.

Regulated Activity

Деятельность, подпадающая под регулирование AFSA; определяется фактической ролью компании и моделью оказания услуг.

Authorised Firm

Компания, получившая авторизацию AFSA на осуществление регулируемой деятельности в МФЦА.

GEN

Общие правила: базовые принципы, функции, системные требования и рамка для авторизации и надзора.

AML

Модуль правил по AML/CFT и санкциям: риск-ориентированный подход, CDD, мониторинг и отчётность.

COB

Правила поведения (conduct): стандарты взаимодействия с клиентами, раскрытия, конфликты интересов (где применимо).

PRU

Пруденциальные требования (где применимо): капитал/ликвидность, отчётность, аудит и финансовая устойчивость.

FAQ

Короткие ответы на вопросы, которые чаще всего возникают при «входе» в AFSA-контур.

Можно ли понять необходимость лицензии без общения с AFSA?+
Предварительно — да, через квалификацию модели и сопоставление с Regulated Activities и применимыми модулями Rulebooks. Но «пограничные» случаи требуют аккуратной фиксации фактов и корректной позиции.
Почему одинаковые продукты иногда получают разные требования?+
Потому что отличаются фактические роли и риски: кто контролирует операции, где хранятся активы, какие клиенты, какие каналы, и кто несёт ответственность по цепочке.
Какие документы чаще всего «ломают» заявки?+
Обычно — несоответствие политик реальным процессам (AML/Onboarding/Outsourcing/BCP), слабое governance, а также нефиксированные зависимости от подрядчиков и инфраструктуры.
Лицензия — это конец истории?+
Нет. После авторизации начинается режим надзора: отчётность, уведомления о событиях, контроль изменений и подтверждение, что фактическая модель соответствует заявленной.