План внедрения ИТ-инфраструктуры EMI

Внедрение ИТ в EMI: основной реестр, KYC, мониторинг транзакций, управление обращениями, отчетность, обработка карточных платежей.

В 2026 году технологический стек EMI оценивают меньше по “красивым фичам” и больше по тому, умеет ли он выдавать аудит-готовые доказательства: корректные балансы, трассируемые потоки, контролируемый аутсорсинг, устойчивые операции и воспроизводимую отчётность. Доверенный стек должен уметь в любой момент доказать: что произошло, почему это произошло, кто это одобрил и как это сходится с safeguarding (защитой/сегрегацией средств клиентов) и бухгалтерией.

Две регуляторные реальности формируют blueprint:

• DORA действует с 17 января 2025 и подняла базовые ожидания по управлению ICT-рисками, обработке инцидентов, тестированию устойчивости и контролю ICT-третьих сторон. К 2026 многие надзоры считают “DORA-style” ICT governance минимальной планкой.
• Ожидания EBA по ICT и security risk management продолжают влиять на оценку безопасности PSP/EMI: контроль доступа, change management, клиентские практики безопасности, теперь уже в DORA-контексте. Также рекомендации PSD2 по major incident reporting были отменены, потому что DORA ввела гармонизированную отчётность по инцидентам, поэтому готовность к инцидентам нужно проектировать в платформу с первого дня.

Ниже практическая референс-архитектура, которую можно использовать, чтобы проектировать (или объяснять) стек EMI регулятору, банкам-партнёрам и инвесторам.

Референс-архитектура (что к чему подключается)

Каналы

• Web / Mobile приложения
• Админ-back office
• Партнёрские порталы / API

Основной уровень обработки

• Core ledger (system of record, “источник истины”)
• Оркестрация платежей (SEPA/Instant/SWIFT, локальные rails)
• FX engine (курсы, спреды, букинг)
• Интеграция card processing (issuer processor / programme manager)

Уровень финансового контроля

• Reconciliation engine (выписки по rails, settlement-файлы по картам, safeguarding-счета)
• Мониторинг safeguarding и сегрегации
• Мост в GL / бухгалтерию (general ledger / accounting bridge)

Уровень рисков и комплаенс

• KYC/KYB + screening (санкции/PEP/adverse media)
• Transaction monitoring (правила + сценарии + risk scoring)
• Case management + SAR workflow
• Audit logging + evidence vault (хранилище доказательств)

Уровень отчетности

• Регуляторная отчётность (пруденциальная, инциденты, AML-метрики по необходимости)
• Управленческая отчётность (MI): KRI, fraud, disputes, операционные KPI

Уровень платформы

• IAM (роли, MFA), secrets, шифрование, key management
• Observability (logs/metrics/traces), SIEM
• Реестр вендоров/аутсорсинга + контроллинг (критичные сервисы)
• BCP/DR + тестирование устойчивости (ожидания DORA)

Лицензионный фокус CZ/EU: надзор (включая ČNB) обычно хочет увидеть:
(1) понятный single source of truth для балансов и safeguarding;
(2) governance аутсорсинга, совпадающий с реальностью (кто что делает, под какими контролями и как вы выходите/мигрируете).
Если диаграмма архитектуры и список вендоров “рассказывают разные истории”, это запускает лишние круги Q&A.

Основной бухгалтерский реестр: «единый источник достоверной информации»

Ledger это не “база данных”. Это авторитетный двигатель, который должен в любой момент отвечать:

• Какой баланс клиента прямо сейчас?
• Какой баланс компании прямо сейчас?
• Что safeguarded, что ждёт settlement, что отменено, в споре или заблокировано?

Непереговорные характеристики гроссбух

• Двойная запись (double-entry) или эквивалентная модель контролей
• Неизменяемый журнал (append-only; корректировки через reversals)
• Идемпотентность (повторные запросы не должны дублировать ценность)
• Ясная модель состояний: available / pending / reserved / blocked / chargeback / reversal
• Сильный audit trail, связанный с действиями пользователей и событиями системы (кто что сделал, когда и под какой авторизацией)

Типовые интеграции

• Пополнения/выводы, авторизации/клиринг по картам, FX-конвертации, комиссии, chargeback’и/refund’ы
• Выходы reconciliations в бухгалтерию/GL и в мониторинг safeguarding

Практика CZ: описание ledger должно совпадать с money-flow диаграммами, методом safeguarding и частотой reconciliations. В пакете приложений для ČNB ledger это “движок правды”, к которому должны сходиться все остальные заявления.

KYC/KYB стек: онбординг, скрининг и обновления по жизненному циклу

Рассматривайте KYC как жизненный цикл, а не разовую “калитку”:

• Захват личности (документ + liveness, где используется)
• Screening санкций/PEP
• Risk scoring (тип клиента, страна, продукт, канал)
• Постоянный мониторинг и refresh (периодические review, trigger-события)
• Offboarding (закрытия, redemption, retention)

Важные дизайн решения

• Владение данными: храните ключевые атрибуты идентичности у себя; ответы вендора храните как доказательства
• Управление workflow: risk-based маршруты (standard vs EDD), approvals, разделение обязанностей
• Evidence vault: что храните, сроки, доступы, защита от подмены (увязка с ожиданиями по outsourcing и ICT-контролям)

EU/ČNB реализм: надзор обычно не любит “KYC живёт целиком в портале вендора”. Им нужно доказательство, что вы владеете workflow, логикой решений и доказательствами, особенно если онбординг и скрининг на аутсорсе.

Мониторинг транзакций: детекция это не просто “алерты”

Зрелый мониторинг имеет три слоя:

1. Правила/сценарии: пороги, velocity, structuring, необычные коридоры
2. Модель рисков сущности: customer risk + product risk + geo risk
3. Behavioural baselining: опционально, но мощно на масштабе

Что подключить в мониторинг (минимум)

• События ledger (кредиты/дебеты, внутренние переводы)
• События payout rails (отправлено/возвращено/отклонено)
• События по картам (auth, reversals, clearing, chargebacks)
• FX события (конвертация, refunds)
• KYC события (изменение риска, EDD флаги)

Требования к выходу

• Объяснимая логика алерта (почему сработало, какие точки данных)
• Decision trail (расследование → закрыть/эскалировать; кто одобрил)
• Привязываемые доказательства (снимки, immutable references, вложения)

Это поддерживает ожидание “auditability” в governance и ICT/security: мониторинг должен быть контролируемым, объяснимым и воспроизводимым, а не “чёрным ящиком”.

Ведение дел: “пульт управления” AML, fraud и disputes

Избегайте классической поломки: алерты в одной системе, расследования в Excel, SAR-черновики в email. Под надзором это защищать больно.

Зрелый case-инструмент поддерживает:

• Очереди + SLA (по риску/серьёзности)
• Notes + вложения + “заморозку” доказательств
• Taxonomy решений (false positive / closed / filed / exited)
• SAR workflow и approvals
• Reporting (конверсия alert→case, цикл-тайм, backlog)

В DORA-контексте case-платформа должна быть устойчивой и восстановимой: backup, audit logs, governance доступа и контролируемые процессы восстановления.

CZ-фокус: описывая AML/fraud/dispute операции для ČNB, показывайте воспроизводимые контрольные процессы, а не “у нас есть тул”. Это значит SLA, tamper-evident логи, role-based access и чёткое разделение обязанностей в back office.

Отчетность: “regulatory + MI” из одного источника истины

Два класса отчётности

• Регуляторная: пруденциальная и иные обязательные отчёты по объёму деятельности и юрисдикции
• Управленческая (MI):
  
  • балансы и статус safeguarding
  • KPI по fraud/disputes
  • AML KPI (alerts, cases, SAR решения)
  • инциденты и метрики доступности

Отчётность по инцидентам: проектируйте это в платформу

Поскольку DORA ввела гармонизированную отчётность по инцидентам с 17 января 2025 и guidance PSD2 по major incident reporting отменён, платформа должна уметь классифицировать, доказывать и репортить инциденты единообразно. Это не “только политика”: нужны логи, таймлайны, доказательства влияния и повторяемые workflow для отчётности.

Практика CZ/EU: даже если вы не подаёте все отчёты в день 1, платформа должна доказать, что вы можете производить требуемые выходы из контролируемых данных, с audit trail и доказательствами-вложениями.

Процессинг банковских карт: держите карточный домен “чистым”

Карточные программы создают несколько “систем истины”:

• Поток авторизаций (почти real-time)
• Clearing & settlement файлы (batch)
• Chargebacks/disputes (долгий хвост)

Blueprint-совет: трактуйте карты как источник событий, который отражается в ledger через контролируемое маппирование:

• auth → резервирование средств (pending)
• clearing → финальное списание/зачисление
• reversal → снятие резерва
• chargeback → dispute-состояние и бухгалтерские проводки

Также обеспечьте reconciliations:

• processor statements ↔ ledger ↔ safeguarding accounts ↔ GL

CZ/EU реальность: карточные программы богаты исключениями (chargebacks, partial reversals, offline clearing). Надзор волнует меньше “скорость карт” и больше то, умеете ли вы reconciliate, доказывать решения и предотвращать balance drift на edge-кейcах.

Паттерны интеграции, снижающие операционные риски

Рекомендуемые паттерны

• Event bus для posting и monitoring (ledger, cards, payouts)
• Outbox pattern для консистентной публикации событий из ledger
• Сильный API gateway + IAM и rate limits
• Централизованное логирование + SIEM (ретенция “уровня расследований”)
• Версионируемые конфиги monitoring-правил (change control)

Контроль аутсорсинга это часть архитектуры

Ожидания EBA по аутсорсингу требуют оценивать “critical or important” услуги и управлять ими (реестры, надзор, audit rights, exit). На практике каждый ключевой вендор (KYC, мониторинг, processor, cloud) должен быть описан через:

• критичность
• RTO/RPO
• audit rights
• субподрядчиков
• exit plan

Build vs buy: что покупать, а что владеть

Обычно покупают

• KYC-проверку документов (но workflow и evidence-модель должны быть вашими)
• screening санкций/PEP
• card processing стек (processor/programme manager)
• case management (если не огромный масштаб)

Обычно владеют

• логикой ledger (даже с vendor core вы владеете posting-правилами и контролями)
• решениями в risk model и governance мониторинга
• reconciliations и safeguarding-контрольной логикой (ответственность ваша)

Дорожная карта внедрения (практический порядок)

1. Ledger + money flows (кошелёк, комиссии, правила проводок)
2. Оркестрация rails + reconciliations (чтобы закрывать “книги” и доказывать safeguarding)
3. KYC + screening + risk scoring
4. Transaction monitoring + case management
5. Cards (auth/clearing/chargebacks + reconciliations)
6. Reporting + incident readiness (DORA-aligned зрелость операций)

Быстрый чеклист: что делает EMI стек “доверенным” в 2026

• Ledger неизменяемый, double-entry и audit-ready
• Все внешние rails reconciliate ежедневно (с обработкой исключений)
• Мониторинг подключён к реальным ledger + rail + card событиям
• Cases end-to-end (alerts → решения → доказательства)
• Reporting использует одну контролируемую модель данных
• Реестр аутсорсинга существует и совпадает с реальностью
• Захват и отчётность по инцидентам встроены (DORA era)

Мы помогаем EMI с IT-архитектурой

Если вы готовите заявку на лицензию EMI в Чехии (ČNB), AMS может помочь построить regulator-ready IT-архитектуру и “stack narrative”, который соответствует чешскому подходу с приложениями (annex-driven submission). Мы закрываем: core ledger и money flows, safeguarding/reconciliations, реестр аутсорсинга и критичность вендоров, governance доступов и DORA-готовность по инцидентам.

Также поддерживаем финансовые планы и 3-летние финансовые модели для чешских EMI заявок, чтобы балансы, логика own funds, допущения по ликвидности, safeguarding операции и описания IT/аутсорсинга были согласованы. Это делает подачу защищаемой в Q&A с ČNB.

ПОЛУЧИТЕ ČNB-READY GAP-CHECK И ЧЁТКИЙ СПИСОК ПРАВОК

ЗАПУСТИТЬ EMI PRE-CHECK

ЗАКАЗАТЬ

FAQ: ПЛАН ВНЕДРЕНИЯ ИТ-ИНФРАСТРУКТУРЫ EMI

Какие документы ČNB обычно ожидает для подтверждения IT stack EMI при лицензировании?

Помимо архитектурных диаграмм надзор обычно хочет “доказательные артефакты”, что стек реально управляем. Полезные документы: пакет vendor due diligence (роли, SLA, субподрядчики), матрица прав доступа back office, примеры reconciliation-отчётов, incident response runbooks и доказательства планов тестирования DR/BCP. Это демонстрирует операционную готовность к лицензии EMI в Чехии.

Как EMI снизить лицензионный риск при использовании облака и сторонних fintech-вендоров в Европе?

Самый эффективный способ: встроить vendor governance в дизайн системы, а не добавлять юридически “потом”. Это значит определить критичность, audit rights, мониторинг, цели RTO/RPO, прозрачность субподрядчиков и реалистичный exit plan. Для EU EMI, особенно при подаче к ČNB, структурированный контроль третьих сторон заметно снижает дополнительные вопросы по аутсорсингу и ICT-рискам.

Какой самый частый “скрытый фейл” в EMI системах приводит к спорам по балансам и поломкам согласование?

 Частая причина: несогласованное маппирование событий между внешними системами (карт-процессоры, payment rails, FX-провайдеры) и внутренней posting-логикой EMI. Мелкие edge cases (partial reversals, задержанные settlement-файлы, поздние chargebacks, FX-разницы при refunds) накапливаются в “balance drift”. Надёжная платформа предотвращает это через строгие правила проводок, идемпотентность и exception handling, плюс ежедневную reconciliations с трассируемыми доказательствами.

Как выбрать case management для AML и fraud, не превращая это в overbuild?

 Начните с workflow и требований к доказательствам, а не с “фич”. Система должна поддерживать audit-grade заметки, вложения, approvals, настраиваемые outcomes и отчётность, показывающую, как alert превращается в case и решение. Для EMI лицензирования в Европе важно, чтобы инструмент мог экспортировать полный evidence-bundle для аудита и запросов надзора без Excel и ручных email-цепочек.

Как EMI показать DORA-готовый incident management в IT stack (и почему это важно для лицензирования)?

Надзор всё чаще ожидает, что готовность к инцидентам встроена в платформу, а не обслуживается вручную. На практике это: единая классификация, сбор доказательств (логи, таймлайн, затронутые сервисы, impact на пользователей), понятные владельцы и эскалации и повторяемые отчётные выходы. Хороший подход: связать observability (logs/metrics/traces) и SIEM с incident workflow, который хранит неизменяемые доказательства и по запросу производит audit-ready отчёты. Так проще защищать операционную устойчивость при лицензировании и дальнейшей супервизии.