Модель «минимальной жизнеспособности» и трёх линий защиты для стартапа в сфере электронных платежей.
Зачем это вообще нужно
EMI живёт в мире, где ошибки стоят дорого: AML, фрод, карточные риски, жалобы клиентов, санкции, инциденты, утечки, сбои, safeguarding.
Три линии защиты нужны не “для красоты”, а чтобы:
- было ясно, кто владелец риска, кто контролирует, кто проверяет;
- контроль не зависел от “одного умного человека”;
- любые решения можно было объяснить и доказать (а не “мы так чувствовали”).
“Minimum viable” версия означает: минимум ролей, минимум документов, максимум ясности.
Концепция за 20 секунд
- 1-я линия: бизнес и операции. Они создают риск и управляют им каждый день.
- 2-я линия: комплаенс и риск. Они задают правила, следят за соблюдением, дают методологию.
- 3-я линия: внутренний аудит (или его эквивалент). Они независимо проверяют, что система реально работает.
Минимальная модель 3LoD для EMI-стартапа
1-я линия защиты: “Мы делаем продукт и не ломаем закон”
Кто это в стартапе: продукт, операции, support, payments ops, onboarding, финансы, иногда engineering (если они управляют изменениями и доступами).
Их ответственность (без отговорок):
- KYC/онбординг клиентов по правилам (не “по настроению sales”)
- лимиты/правила по транзакциям
- обработка алертов (фрод/AML) по инструкции
- safeguarding/движение средств и сверки (если применимо)
- выполнение процедур по инцидентам и жалобам
- корректное ведение данных (почему приняли клиента, почему отклонили, почему заблокировали)
Минимальные артефакты 1-й линии (должны существовать):
- 5–10 SOP/инструкций “как делаем”:
- onboarding & KYC steps
- handling alerts (AML/fraud)
- high-risk customers escalation
- chargeback/disputes (если карты)
- complaints handling
- incident first response
- RACI на 1 страницу (кто делает, кто утверждает, кто консультирует, кого информируем)
- 3–5 ключевых метрик (KPI/KRI) с владельцем:
- доля ручных проверок
- время реакции на алерты
- backlog алертов
- доля отказов/закрытий по причинам риска
- инциденты/жалобы
Главный принцип: 1-я линия не может говорить “это комплаенс должен был”. Это не комплаенс делает ваш бизнес.
2-я линия защиты: “Мы задаём правила и контролируем, что их соблюдают”
Кто это в стартапе: Head of Compliance / MLRO (часто совмещает), Risk Officer (иногда тот же человек на старте), DPO/InfoSec может быть частично здесь по функциям.
Их работа:
- политика и стандарты: AML/CTF, риск-аппетит, санкции, PEP, EDD, фрод, жалобы
- методология risk assessment (продукт/клиенты/география/каналы)
- мониторинг соответствия: выборочные проверки, отчётность руководству
- обучение сотрудников (да, даже если вас 7 человек)
- контроль аутсорса: что отдали на сторону, как контролируем, какие SLA, что делаем при сбое
Minimum viable набор 2-й линии:
- Risk Appetite Statement: что мы точно не делаем, где лимиты
- Risk Assessment (таблица): продуктовые риски, клиенты, географии, каналы, mitigations
- AML/CTF Policy + короткие процедуры (CDD/EDD/SAR/санкции)
- Compliance Monitoring Plan (на квартал): что проверяем, как часто, по каким выборкам
- Outsourcing register + базовый vendor due diligence (даже если это “просто SaaS”)
- Monthly compliance/risk report на 1 страницу для CEO/Board:
- алерты, блокировки, SAR (если есть), жалобы, инциденты, проблемные вендоры, ключевые изменения
Главный принцип: 2-я линия не должна “управлять вместо бизнеса”. Она должна делать правила простыми и проверяемыми.
3-я линия защиты: “Независимая проверка: это реально работает?”
Кто это в стартапе: полноценного internal audit часто нет. И это нормально, если вы не изображаете из себя банк на 2000 человек.
Минимально жизнеспособная замена внутреннему аудиту:
- аутсорс внутреннего аудита (1–2 проверки в год)
- Board-level review + независимая проверка (например, внешний консультант) по плану
Что 3-я линия проверяет в первую очередь (MVP-пакет):
- AML/KYC: качество кейсов и обоснований, наличие evidence
- транзакционный мониторинг: настройки, эскалации, закрытие алертов
- safeguarding/сверки (если применимо)
- доступы/изменения в системе: кто может менять правила/лимиты/чёрные списки
- аутсорс: контроль вендоров и план выхода (exit plan)
- жалобы и инциденты: есть ли следы и корректные действия
Артефакты 3-й линии:
- Audit plan (на год) из 6–10 тем
- Отчёт по проверке (что не так, риск, приоритет, владелец исправления, срок)
- Follow-up: проверка закрытия критичных пунктов
Главный принцип: 3-я линия должна быть независимой. Не “сам себя проверил и поставил себе 5”.
Как это собрать в команде из 6–20 человек
Минимальные роли (без лишнего цирка)
- CEO/COO: владелец операционных рисков (1-я линия)
- Head of Compliance / MLRO: 2-я линия (можно совмещать на старте)
- Risk owner’ы по направлениям (part-time): onboarding, payments ops, cards, support
- External audit/review: 3-я линия (2 раза в год достаточно для начала)
Самый практичный документ: одна таблица 3LoD
| Процесс | 1-я линия делает (бизнес/операции) | 2-я линия задаёт/контролит (compliance/risk) | 3-я линия проверяет (аудит/независимая проверка) |
| Onboarding (KYC/CDD/EDD) | ведёт чеклист, принимает решения, собирает evidence (скрины/логи/документы), эскалирует high-risk | задаёт политику/правила, критерии риска, проводит выборочные проверки качества кейсов, обучает | берёт выборку кейсов, проверяет качество решений и доказательств, ищет системные ошибки |
| Alerts (AML/Fraud/санкции) | обрабатывает алерты, делает эскалации, закрывает кейсы с обоснованием, ведёт backlog | задаёт правила/пороговые значения/сценарии, следит за backlog и SLA, проверяет корректность закрытий | проверяет качество закрытия (reason codes, evidence), адекватность эскалаций, полноту журналов |
| Vendors / Outsourcing | исполняет SLA, ведёт коммуникации с вендорами, фиксирует инциденты/сбои, инициирует изменения/замены | проводит due diligence, ведёт реестр аутсорса, оценку рисков, требования к контролю, exit plan | аудит критичных вендоров/контрактов, проверка контроля аутсорса и работоспособности exit plan |
| Incidents (ИТ/операц./безопасность) | реагирует, локализует, восстанавливает, фиксирует таймлайн, делает первичный отчёт | задаёт процесс, классификацию, требования к уведомлениям/эскалациям, обучает, контролит выполнение | review пост-мортемов, проверка соблюдения процедуры и качества корректирующих действий |
| Complaints (жалобы клиентов) | принимает/обрабатывает жалобы, отвечает в срок, фиксирует исход и причину, корректирует процесс | задаёт правила и сроки, контролит тренды/повторы причин, инициирует улучшения | проверяет соблюдение сроков, полноту регистрации, корректность классификации и ответов |
Топ-5 ошибок, из-за которых “3 линии” превращаются в фарс
- Комплаенс “владеет” риском вместо бизнеса.
- Нет evidence: решения принимаются, но следов нет.
- Аутсорс без контроля: “это же известный провайдер”.
- Нет метрик: никто не видит, где система течёт.
- “Внутренний аудит” = тот же человек, что писал политику.
Мини-чеклист: “мы готовы к минимальному 3LoD”
- Есть владельцы процессов (onboarding, monitoring, complaints, incidents)
- Есть 5–10 коротких SOP, по которым реально работают
- Есть risk assessment и risk appetite (не на 80 страниц)
- Есть мониторинг-план (что проверяем каждый месяц)
- Есть независимая проверка хотя бы 1–2 раза в год
- Любое решение по клиенту/транзакции можно подтвердить доказательствами
Вывод
Minimum viable 3LoD для EMI-стартапа это не “корпоративная религия”. Это минимальный набор ролей и правил, который позволяет вам:
- масштабировать операции,
- не утонуть в алертах и хаосе,
- пройти вопросы регулятора/партнёров/аудита без истерики.
Если хочешь “совсем по-простому”:
1-я линия делает. 2-я линия объясняет как правильно и проверяет. 3-я линия проверяет проверяющих.
ПОЛУЧИТЕ ČNB-READY GAP-CHECK И ЧЁТКИЙ СПИСОК ПРАВОК
ЗАПУСТИТЬ EMI PRE-CHECK
FAQ: “минимальная” модель 3 линий защиты (3LoD) для EMI-стартапа
3LoD обязательно делать “как в банке”, с отдельными департаментами?
Нет. В стартапе 3LoD это не про количество людей, а про разделение ролей:
- 1-я линия выполняет операции и принимает решения,
- 2-я задаёт правила и контролит соблюдение,
3-я независимо проверяет.
В маленькой команде 2-я линия часто совмещается (Compliance + Risk), а 3-ю можно закрывать внешней проверкой 1–2 раза в год.
Кто должен “владеть риском”: комплаенс или бизнес?
Бизнес (1-я линия). Комплаенс не может управлять вашим продуктом вместо вас. Он задаёт рамки и следит за соблюдением. Если 1-я линия говорит “это комплаенс виноват”, значит у вас не 3 линии, а театр.
Что самое важное “на старте”, если времени мало?
Три вещи, которые реально спасают:
- RACI на 1 страницу (кто делает/кто утверждает/кого эскалируем),
- 5–10 коротких SOP (онбординг, алерты, жалобы, инциденты, вендоры),
- evidence: логи, решения, причины, “почему так”.
Регулятору и аудитору нужны не красивые слова, а следы действий.
Внутреннего аудита нет. Это критично?
Не критично, если вы честно закрыли 3-ю линию альтернативой:
- внешний аудит/независимый review (по плану),
- или независимая проверка на уровне совета/инвесторов с формальным отчётом и follow-up.
Критично другое: когда “аудит” делает тот же человек, кто писал политику и потом сам себя похвалил.
Как часто нужна 3-я линия в минимальной версии?
Для большинства EMI-стартапов на ранней стадии достаточно:
- 1–2 тематических проверки в год (AML/KYC, алерты/мониторинг, аутсорс, инциденты),
- плюс follow-up по критичным пунктам.
Лучше мало, но регулярно, чем “раз в три года, зато на 80 страниц”.
Какие метрики (KRIs) самые полезные, чтобы 3LoD не был формальностью?
Минимальный набор:
- backlog алертов (сколько висит и сколько просрочено),
- среднее время реакции на алерт/инцидент,
- доля high-risk клиентов и сколько из них прошло EDD,
- тренды по жалобам (топ-3 причины),
- инциденты у критичных вендоров и выполнение SLA.
Что обычно ломает “агентскую/партнёрскую” модель с точки зрения 3LoD?
Иллюзия, что “партнёр всё сделает”. Нет.
Партнёр действительно держит лицензию, но вам всё равно нужно:
- исполнять процессы (1-я линия),
- иметь контроль и отчётность (2-я линия),
- проходить независимые проверки (3-я линия),
иначе партнёр просто закроет вам доступ или задушит ограничениями.
Какие процессы проверяют первыми почти всегда?
Четыре вечные темы:
- onboarding (KYC/EDD) и качество решений,
- transaction monitoring / alerts (как закрываете кейсы),
- outsourcing/vendor oversight (кто критичный и как контролите),
- incidents & complaints (как реагируете и какие выводы делаете).
