Управление платежной системой в МФЦА (AIFC): Payment System Operation
Payment System Operation — это управление правилами и инфраструктурой, через которую проходит перевод денежных средств между участниками системы. Регуляторно “платежная система” — это не только IT: это правила участия, settlement, управление рисками (операционный, кредитный/ликвидный, кибер, fraud) и доказуемая устойчивость. Для AFSA критично показать: как устроены правила системы, кто участники, как проходят расчеты, и какие контроли применяются при сбоях/инцидентах.
- Ядро: rulebook платежной системы, membership, порядок расчетов, финальность расчетов и журналирование.
- Риски: операционная устойчивость, кибер, отказоустойчивость, инциденты, управление изменениями.
- Governance: роли оператора, комитеты/функции контроля, аутсорсинг и надзор за поставщиками.
Критерии допуска/исключения, роли (payer/receiver/PSP/bank), ответственность и дисциплина.
Где и когда происходят расчеты: неттинг/брутто, циклы, финальность, возвраты и спорные операции.
BCP/DR, RTO/RPO, тестирование, реагирование на инциденты и коммуникации с участниками.
Частая ошибка: описать “платформу переводов”, но не описать платежную систему как набор правил + governance + settlement.
Что означает управление платежной системой: практический периметр
Управление платежной системой обычно включает разработку и поддержание правил системы, управление доступом участников, обеспечение расчётов/settlement и доказуемую операционную устойчивость. Ниже — элементы, которые чаще всего требуют “разворачивания”.
Membership, обязанности участников, лимиты, дисциплина, порядок разрешения споров и санкции за нарушения правил системы.
Модель расчетов (нетто/брутто), циклы, финальность, возвраты, обработка сбоев и резервные сценарии.
BCP/DR, кибербезопасность, мониторинг, инцидент-менеджмент, контроль изменений и тестирование.
Важно различать “платежный сервис” и “платежную систему”: система — это, как правило, правила + инфраструктура + settlement, а не только интерфейс и процессинг.
Границы модели: где чаще всего возникает переквалификация и вопросы
Вопросы обычно возникают, когда (1) неясно, кто держит средства и где settlement; (2) правила участия “плавающие”; (3) ключевые функции переданы подрядчикам без управляемости; (4) отсутствует доказательная база по рискам и инцидентам.
Признаки, которые чаще всего требуют структурированного описания.
- формальные правила системы: membership, обязанности, дисциплина, процедуры
- описанный settlement: циклы, финальность, возвраты, резервные сценарии
- управление рисками: операционный/кибер/ликвидность (если применимо), fraud
- governance: роли, комитеты/контроли, эскалация
- доказуемость: журналы операций/событий, отчеты по инцидентам, тестирование
Если это “не прописано”, вопросы почти неизбежны.
- кто участники и по каким критериям допускаются/исключаются
- flow of funds: где деньги, кто контролирует settlement и возвраты
- процедуры disputes/chargebacks (если применимо)
- аутсорсинг: процессинг/cloud/support — SLA, контроль, аудит, exit-plan
- BCP/DR: RTO/RPO, тесты, роли, коммуникации при инцидентах
Матрица: платежный сервис vs платежная система
Как отличать “интерфейс” от “правил + settlement + governance”
| Фактор | Payment services (сервис) | Payment system operation (система) |
|---|---|---|
| Фокус | Платежные операции для клиентов/мерчантов | Правила и инфраструктура взаимодействия участников + settlement |
| Участники | Клиенты/мерчанты/пользователи | Участники системы с формальным membership и обязанностями |
| Settlement | Может быть “через партнеров” и не управляться оператором | Описан и управляется правилами системы (циклы, финальность, fallback) |
| Governance | Операционная функция провайдера | Функции управления системой, рисками и дисциплиной участников |
| Устойчивость | Важно, но может быть в рамках продукта | Критически важно: BCP/DR, incident response, мониторинг и доказуемость |
Квалификация зависит от фактов. Если у вас есть “membership” участников, собственный rulebook и управляемый settlement-контур — это уже ближе к платежной системе, чем к отдельному платежному сервису.
Что обычно ожидают от оператора платежной системы
Регуляторный смысл — доказать управляемость: правила, риски, инциденты и непрерывность. Ниже — практические блоки, которые обычно “раскрывают” в описании модели и пакете политик.
Роли оператора, механика принятия изменений в правилах, комитеты/контрольные функции и эскалация.
Мониторинг, обработка исключений, порядок остановки/восстановления, поддержка участников и инциденты.
Контроль доступа, журналирование, управление уязвимостями, change management и тестирование релизов.
RTO/RPO, сценарии отказа, резервные контуры, регулярные тесты и коммуникации при сбоях.
Процессинг/cloud/support: due diligence, SLA, контроль и право аудита, exit plan и подменные провайдеры.
Логи, отчеты, инциденты, метрики, результаты тестов и внутренние обзоры рисков.
Практический принцип: “правила = процессы = IT”. Если в реальности settlement/операции идут иначе, чем написано в rulebook — риск повышается.
Типовой путь подготовки оператора платежной системы к лицензированию
Последовательность, которая снижает риск “дыр” в rulebook и ускоряет сбор пакета и согласование.
Фиксируем membership, права/обязанности, правила операций, дисциплину и управление изменениями.
Описываем flow of funds, циклы расчетов, финальность, возвраты и исключения.
Безопасность, логи, change management, BCP/DR, провайдеры, SLA и exit-plan.
Готовим описание модели, политики и сопровождаем вопросы/доработки по запросам AFSA.
Практически полезно заранее подготовить: схему участников, flow of funds, карту аутсорсинга и матрицу инцидентов/реакций.
Набор правил системы: membership, процедуры операций, расчеты, ответственность, инциденты и изменения правил.
Расчеты между участниками: нетто/брутто, циклы, финальность, возвраты и резервные сценарии при сбоях.
Способность системы работать при сбоях: BCP/DR, мониторинг, инциденты, тестирование и управление изменениями.
Передача функций провайдерам: процессинг/cloud/support — с SLA, контролем, аудитом и exit-plan.
Чем платежная система отличается от платежного сервиса?+
Что важнее для AFSA: IT или документы?+
Можно ли ключевые функции отдать процессингу/провайдерам?+
Какие “доказательства” обычно нужны по устойчивости?+
Если мы не держим средства клиентов, это упрощает регулирование?+
Нужно ли делать отдельную политику по инцидентам?+
Материал подготовлен для общего информирования и не является юридической консультацией или заключением. Квалификация деятельности требует анализа фактической модели, rulebook, settlement и IT/outsourcing контуров.
Как WCR Consulting сопровождает запуск оператора платежной системы в МФЦА
Мы помогаем зафиксировать периметр payment system, подготовить rulebook и описание settlement, выстроить governance, операционные и IT-контуры (BCP/DR, security, outsourcing), а также сопровождать вопросы и доработки по запросам AFSA.
WCR Consulting анализирует модель системы и settlement, помогает оформить rulebook и governance, выстроить resilience/security/outsourcing и подготовить доказуемые контроли и пакет документов для диалога с AFSA.
Материал подготовлен для общего информирования и не является юридической консультацией или заключением. Квалификация деятельности требует анализа фактической модели, rulebook, settlement и IT/outsourcing контуров.