BRD — бизнес-требования
BRD (Business Requirements Document) — документ бизнес-требований. Описывает, что система должна делать с точки зрения бизнеса: цели, стейкхолдеров, бизнес-процессы AS-IS / TO-BE, функциональные (FR) и нефункциональные (NFR) требования, бизнес-правила, ограничения и границы проекта. Это контракт между заказчиком и командой разработки; как это реализовано — описывает LLD.
Проект: Web Shield AI — сервис мониторинга контента сайтов мерчантов (Merchant Content Monitoring Service) Версия: 1.1 Статус: Черновик Ответственный: А. Зубик (архитектор / бизнес-аналитик)
1. Общие сведения
Заголовок раздела «1. Общие сведения»- Цель документа: Описание функциональности SaaS-сервиса, который по подписке периодически сканирует сайты мерчантов, подключённых к интернет-эквайрингу банка, и выявляет на них слова и фразы из стоп-листа (товары и услуги, запрещённые к продаже либо нарушающие правила платёжных систем).
- Бизнес-цель: Снизить регуляторные и репутационные риски банка-эквайера, связанные с продажей мерчантами запрещённых товаров, и автоматизировать ручной комплаенс-мониторинг портфеля мерчантов (по аналогии с Mastercard BRAM / Merchant Monitoring Program). Целевой эффект — сокращение трудозатрат комплаенс-отдела и снижение числа пропущенных нарушений.
- Стейкхолдеры:
- Банк-эквайер / PSP (заказчик и подписчик);
- Комплаенс-офицер / риск-аналитик банка (основной пользователь);
- Платёжный шлюз / процессинг (потребитель verdict-API на этапе оплаты);
- Мерчант (объект мониторинга, не пользователь системы);
- Администратор сервиса (провайдер).
2. Описание бизнес-процессов (AS-IS / TO-BE)
Заголовок раздела «2. Описание бизнес-процессов (AS-IS / TO-BE)»AS-IS (как есть): Комплаенс-отдел вручную или выборочно проверяет сайты мерчантов на наличие запрещённых товаров. Процесс несистемный, не покрывает весь портфель, реагирует постфактум, доказательная база собирается вручную (скриншоты).
TO-BE (как должно стать): Подписчик загружает список сайтов и стоп-листы. Сервис автоматически и по расписанию обходит все страницы сайтов, ищет стоп-слова с учётом морфологии, классифицирует срабатывания, сохраняет доказательства и формирует отчёт о комплаенс-статусе. На этапе оплаты платёжный шлюз получает по API кэшированный вердикт по сайту/странице и при необходимости показывает предупреждение или блокирует операцию.
Роли пользователей:
- Администратор сервиса — управление тарифами, тенантами, глобальными настройками краулинга.
- Комплаенс-офицер (пользователь подписчика) — управление сайтами и стоп-листами, просмотр отчётов, разметка срабатываний.
- Интеграционная система (M2M) — платёжный шлюз, запрашивающий вердикт при оплате.
3. Функциональные требования
Заголовок раздела «3. Функциональные требования»| ID | Категория | Наименование требования | Описание (Система должна [действие] при условии [условие]) | Приоритет |
|---|---|---|---|---|
| FR-01 | Аутентификация | Вход подписчика | Система должна аутентифицировать пользователей подписчика по email+паролю с приглашениями (invite-flow) и опциональным 2FA (email-OTP), изолировать данные между тенантами и разграничивать доступ по ролям (super_admin/admin/officer/auditor-read-only); администратор может отключать пользователей. Корпоративный SSO (OAuth/Keycloak) — по решению заказчика не делаем. | Must |
| FR-02 | Подписка | Тарифные лимиты | Система должна ограничивать доступные методы анализа, число сайтов, глубину обхода и частоту рекраула в соответствии с уровнем подписки (см. раздел 8). | Must |
| FR-03 | Управление сайтами | Загрузка списка сайтов | Система должна позволять подписчику добавлять сайты мерчантов вручную и пакетно (CSV / API). | Must |
| FR-04 | Стоп-листы | Управление стоп-листами | Система должна позволять создавать и редактировать стоп-слова и фразы с привязкой к категориям нарушений. | Must |
| FR-05 | Краулинг | Обход страниц сайта | Система должна обходить все доступные внутренние страницы каждого сайта при условии соблюдения robots.txt и ограничения нагрузки на домен. | Must |
| FR-06 | Краулинг | Догрузка JS-контента | Система должна догружать страницу через headless-браузер при условии, что статический обход вернул недостаточно текста. | Should |
| FR-07 | Извлечение | Извлечение текста | Система должна извлекать значимый текст страницы, отсекая навигацию, меню и футеры. | Must |
| FR-08 | Матчинг | Морфологический поиск | Система должна находить вхождения стоп-слов с учётом словоформ для русского, белорусского и английского (язык — по сайту). Диспетчер по языку реализован (ru — pymorphy3, be — UDPipe belarusian-hse, en — identity); be обязателен по тендеру. | Must |
| FR-09 | Матчинг | Анти-обфускация | Система должна выявлять замаскированные написания (разрядка букв, гомоглифы, транслитерация). | Should |
| FR-10 | Верификация | AI-классификация | Система должна классифицировать срабатывание как реальную продажу запрещённого товара или ложное упоминание с помощью LLM. | Should |
| FR-11 | Верификация | Распознавание изображений | Система должна распознавать текст на изображениях товаров (OCR / vision-модель). | Could |
| FR-12 | Доказательства | Снимок страницы | Система должна сохранять HTML и скриншот страницы на момент срабатывания. | Must |
| FR-13 | Расписание | Автоматический рекраул | Система должна повторно обходить сайты с периодичностью согласно тарифу подписчика. | Must |
| FR-14 | Отчётность | Отчёт по сайту | Система должна формировать отчёт по сайту: комплаенс-статус, число срабатываний, перечень страниц и найденных фраз. | Must |
| FR-15 | Verdict API | Вердикт по запросу | Система должна по запросу платёжного потока возвращать кэшированный вердикт комплаенса по домену/URL. | Must |
| FR-16 | Verdict API | Предупреждение при оплате | Система должна возвращать признак «обнаружен потенциально запрещённый товар» для показа предупреждения покупателю либо блокировки оплаты. | Must |
| FR-17 | Алертинг | Уведомления | Система должна уведомлять комплаенс-офицера о новых срабатываниях (e-mail / webhook). | Should |
| FR-18 | Ревью | Разметка срабатываний | Система должна позволять помечать срабатывание как подтверждённое или ложное. | Should |
| FR-19 | Отчётность | Экспорт в PDF | Система должна экспортировать отчёт-доказательство в PDF для предоставления регулятору / платёжной системе. | Should |
| FR-20 | История | Журнал сканирований | Система должна хранить историю сканирований для отслеживания изменений контента сайта во времени. | Should |
| FR-21 | Матчинг | Семантический поиск нарушений | Система должна выявлять признаки продажи запрещённых товаров без точного совпадения со стоп-словом — по смыслу (эмбеддинги / LLM) — при условии подписки уровня Премиум. | Should |
Расширение продукта: Onboarding + InvestiGate (по образцу Web Shield)
Заголовок раздела «Расширение продукта: Onboarding + InvestiGate (по образцу Web Shield)»Блок требований для модулей Onboarding (приём заявок) и InvestiGate (андеррайтинг мерчанта при подключении и ежегодно). Дополняет контент-мониторинг до полного жизненного цикла мерчанта: заявка → мерчант (+структура) → кейс с risk-индикаторами и score → решение Accept/Decline.
| ID | Категория | Наименование требования | Описание | Приоритет |
|---|---|---|---|---|
| FR-30 | Онбординг | Приём заявки | Система должна принимать заявку на подключение мерчанта (ручной ввод / CSV / API / форма) и конвертировать её в мерчанта и кейс андеррайтинга. | Should |
| FR-31 | Онбординг | Публичная форма intake | Система должна предоставлять token-based форму для самостоятельного заполнения мерчантом (без создания учётной записи пользователя). | Could |
| FR-32 | Онбординг | Пакетный импорт мерчантов | Система должна импортировать мерчантов из CSV с дедупликацией по УНП. | Should |
| FR-33 | Сущности | Домен Merchant / Entity | Система должна вести мерчанта как сущность с реквизитами (УНП/ОКПО/MCC/страна), директорами/UBO, адресами, документами и сайтами. | Should |
| FR-34 | Сущности | Документы мерчанта | Система должна хранить документы мерчанта (устав, регистрация, балансы, лицензии) append-only. | Could |
| FR-40 | Андеррайтинг | Кейс InvestiGate | Система должна заводить кейс андеррайтинга на мерчанта (onboarding / ежегодный рескан) с жизненным циклом open→approved/declined/terminated. | Should |
| FR-41 | Андеррайтинг | Каталог индикаторов | Система должна вести каталог риск-индикаторов по 4 группам (Reputation / Content / Money Laundering / Transaction Laundering) с traffic-light статусами. | Should |
| FR-42 | Андеррайтинг | Контент-индикаторы из сканера | Система должна авто-выводить контент-индикаторы кейса (Content Violation, Business Classification) из данных сканера и MCC, не затирая ручную разметку. | Should |
| FR-43 | Андеррайтинг | Ручная разметка индикаторов | Система должна позволять офицеру вручную выставлять статус/вердикт индикатора. | Should |
| FR-44 | Андеррайтинг | Dynamic risk score | Система должна считать единый risk score (вычитательная модель: старт 100%, пол 1%), на кейс и на сайт, с уровнем LOW/MEDIUM/HIGH. | Should |
| FR-44a | Андеррайтинг | CREM — кредитная экспозиция | Система должна рассчитывать кредитную экспозицию (FEaD, EtPR, сценарии, рекомендуемые залоги). | Should |
| FR-44b | Андеррайтинг | MCC Knowledge Base | Система должна показывать регуляторную справку по MCC (требования регистрации MRP/VIRP, страновые правила, рекомендации). | Should |
| FR-45 | Андеррайтинг | Решение Accept/Decline | Система должна фиксировать решение по кейсу (Accept/Decline/Terminate) и проецировать его на жизненный цикл мерчанта. | Should |
| FR-46 | Мониторинг | Связка кейс ↔ мониторинг | Система должна перезапускать underwriting-проверки по расписанию (ежегодно для high-risk) и обновлять score. | Should |
| FR-47 | Отчётность | PDF-отчёт по кейсу | Система должна формировать многосекционный PDF-отчёт (индикаторы, данные мерчанта, CREM, сводка, MCC, recommendation checklist, дисклеймер). | Should |
| FR-50 | Transaction Laundering | Контроль TL | Система должна выявлять transaction laundering: редиректы/перекрёстные ссылки, входные слова-идентификаторы (ФИО/УНП/счёт/моб) на найденных ресурсах, whois + reverse-IP, гео-клоакинг, метод тестовых платежей. (тендер МТБанк) | Should |
4. Нефункциональные требования
Заголовок раздела «4. Нефункциональные требования»- Производительность: Verdict-API отвечает за ≤ 200 мс (p95) на закэшированный вердикт. Полный рекраул портфеля (десятки–сотни сайтов, до сотен тысяч страниц) укладывается в окно рекраула тарифа (например, 24 часа).
- Масштабируемость: Горизонтальное масштабирование воркеров краулинга без простоя control-plane.
- Безопасность: Мультитенантная изоляция данных подписчиков; данные о мерчантах конфиденциальны; персональные данные обрабатываются согласно Закону РБ от 07.05.2021 № 99-З «О защите персональных данных» (и GDPR при работе с ЕС); хранение чувствительных данных в зашифрованном виде; журнал аудита действий пользователей.
- Доступность: ≥ 99.5% для control-plane и verdict-API. Деградация краулинга не должна влиять на доступность verdict-API.
- Локализация: Интерфейс — русский и английский. Контент-анализ — русский, белорусский, английский.
- Аудируемость: Все вердикты и доказательства неизменяемы и привязаны к моменту сканирования.
5. Бизнес-правила
Заголовок раздела «5. Бизнес-правила»- Сайт считается некомплаентным, если по нему есть хотя бы одно подтверждённое срабатывание категории «запрещено».
- Вердикт при оплате = «предупреждение», если по запрашиваемому URL/домену на момент последнего сканирования есть неразрешённое срабатывание; иначе «чисто».
- Срабатывание, помеченное комплаенс-офицером как ложное, не влияет на итоговый вердикт.
- Частота рекраула, число сайтов и глубина обхода определяются исключительно тарифом подписки.
- Если сайт недоступен дольше заданного порога, ему присваивается статус «требует внимания» (а не «чисто»).
- Стоп-листы являются данными подписчика; интерпретирует и применяет их только движок сканирования, не интерфейс.
- Набор активных слоёв анализа определяется уровнем подписки: Простая — только точное совпадение и морфология; Премиум — дополнительно семантический анализ, AI-классификация срабатываний и анализ изображений.
- Вердикт уровня Премиум сопровождается оценкой уверенности (confidence) от AI-слоя; вердикт уровня Простая — бинарный («чисто» / «предупреждение»).
6. Ограничения и допущения
Заголовок раздела «6. Ограничения и допущения»- Ограничения:
- Анализируются только публично доступные страницы; зоны за авторизацией (member-only) вне охвата MVP.
- Динамический клоакинг (разный контент для краулера и человека) может снижать полноту обнаружения.
- Verdict при оплате опирается на данные последнего сканирования, а не на состояние страницы «прямо сейчас».
- Допущения:
- Подписчик имеет законное право мониторить указанные сайты (это его мерчанты).
- Платёжный шлюз способен вызывать verdict-API в платёжном потоке.
- Стоп-листы предоставляет и согласует подписчик; категории нарушений определены заранее.
7. Границы проекта
Заголовок раздела «7. Границы проекта»Дорожная карта разбита на три фазы. Verdict-API при оплате намеренно вынесен в фазу 3 — это синхронный hot path под чужим SLA, включаться в платёжный поток до того, как качество детекции подтверждено на сухом проходе (краул → ревью комплаенс-офицером → PDF-доказательства), преждевременно. Банк получает ценность и без него: автоматизированный комплаенс-мониторинг портфеля вместо ручного.
- Фаза 1 (MVP):
- Обход server-rendered сайтов и извлечение текста (FR-05, FR-07).
- Морфологический матчинг по стоп-листу для ru/be/en (FR-08, диспетчер по языку) + анти-обфускация: разрядка, гомоглифы, транслит (FR-09).
- Управление сайтами, стоп-листами, подписками (FR-03, FR-04, FR-02).
- Сохранение доказательств и расписание рекраула (FR-12, FR-13).
- Ревью и разметка срабатываний комплаенс-офицером (FR-18), базовый отчёт (FR-14).
- Админка (control-plane), email-аутентификация + приглашения + 2FA (FR-01).
- Фаза 2 (Premium AI-слой):
- LLM-классификация срабатываний (FR-10).
- Семантический поиск нарушений без точного совпадения (FR-21).
- Полный JS/SPA-рендеринг (FR-06).
- Webhook-алертинг (FR-17), PDF-доказательства, история, экспорт (FR-19, FR-20).
- Расширение продукта (Onboarding + InvestiGate, по образцу Web Shield):
- Домен Merchant/Entity, приём заявок и конвертация (FR-30–FR-34).
- Кейс андеррайтинга: каталог индикаторов, dynamic risk score, CREM, MCC-KB, решение, PDF (FR-40–FR-47); контент-индикаторы переиспользуют сканер (FR-42).
- Transaction Laundering (FR-50) и белорусская морфология — обязательны по тендеру МТБанк (ОК 26/12); ранее значились «вне фаз»/«позже», подняты в обязательный объём.
Вне области (по решению заказчика): распознавание изображений (OCR / vision, FR-11) и Verdict-API при оплате (фаза 3, FR-15, FR-16) в работу не берём. Требования остаются в этом документе для трассируемости, но не реализуются. См. RTM.
-
Кэш-слой (Redis) и инвалидация при изменении вердикта.
-
Интеграционное соглашение с банком-эквайером / PSP, проработка SLA.
-
Что НЕ входит ни в одну фазу (на горизонте этого проекта):
- Мониторинг member-зон за авторизацией.
- Мобильное приложение.
Примечание: transaction laundering ранее значился здесь как вне фаз — по тендеру МТБанк перенесён в обязательный объём (FR-50).
8. Уровни подписки (тарифы)
Заголовок раздела «8. Уровни подписки (тарифы)»Принцип разделения тарифов: всё, что не использует ИИ и не требует тяжёлых ресурсов (детерминированный контент-скан, морфология ru/be/en, анти-обфускация, стоп-листы, Onboarding, InvestiGate, детерминированный Transaction Laundering, evidence-HTML, отчёты) входит в Простую (Basic). Премиум добавляет всё ИИ- и тяжёлое поверх: LLM-классификация, семантический поиск, полный headless-рендеринг SPA и скриншоты страниц.
Таким образом базовая подписка уже включает все три модуля жизненного цикла мерчанта — Onboarding, InvestiGate, Monitoring (см. «Модули продукта» ниже); это единый продукт, а не отдельные платные опции. Verdict-API при оплате (фаза 3) — отдельный модуль, продаётся доп. опцией к любому тарифу после интеграции с PSP-шлюзом.
| Возможность | Простая (Basic) | Премиум (Premium) |
|---|---|---|
| Поиск по стоп-листу: точное совпадение | ✓ | ✓ |
| Морфология ru/be/en (все словоформы) | ✓ | ✓ |
| Анти-обфускация (разрядка, гомоглифы, транслит) | ✓ | ✓ |
| Onboarding — приём заявок (ручной/CSV/API/форма) → кейс | ✓ | ✓ |
| InvestiGate — кейс, индикаторы, risk score, CREM, MCC-KB, PDF-отчёт | ✓ | ✓ |
| Transaction Laundering (детерминированный: whois, reverse-IP, портфель, SiteReveal, тест-карты) | ✓ | ✓ |
| Evidence — immutable HTML-снимок | ✓ | ✓ |
| Семантический анализ — нарушение без точного слова (FR-21) | — | ✓ |
| AI-классификация срабатываний, отсев ложных (FR-10) | — | ✓ |
| Скриншоты страниц в evidence (headless-браузер) | — | ✓ |
| JS-рендеринг SPA-сайтов (FR-06) | детекция SPA | + полный рендер (headless) |
| Частота рекраула | реже (напр. 1 раз/нед.) | чаще (ежедневно) + по запросу |
| Лимит сайтов в портфеле | до N | до M / индивидуально |
| Глубина обхода | ограниченная | полная |
| Алертинг (FR-17) | e-mail + webhook (near-real-time) | |
| Отчётность | базовый отчёт (FR-14) | + PDF-доказательства, история, экспорт по API (FR-19, FR-20) |
| Поддержка / SLA | стандарт | приоритет |
Состав по требованиям (правило: не-ИИ и не-тяжёлое → Простая):
- Простая (Basic): весь детерминированный контур — FR-01–05, FR-07, FR-08 (ru/be/en), FR-09, FR-12 (HTML-снимок), FR-13, FR-14, FR-18; модули Onboarding (FR-30–FR-34), InvestiGate (FR-40–FR-47) и детерминированный Transaction Laundering (FR-50: whois/reverse-IP/портфель/SiteReveal/тест-карты).
- Премиум (Premium): всё из «Простой» + ИИ и тяжёлое: FR-10 (LLM-классификация), FR-21 (семантика), FR-06 (полный headless-рендер SPA), FR-12 (скриншоты через headless-браузер), FR-17 (webhook), FR-19/FR-20 и повышенные лимиты по FR-02/FR-13. AI-ассист текстов MCC-KB (Mistral) — премиум-опция.
- Вне области: FR-11 (OCR/vision) и FR-15, FR-16 (Verdict-API) — по решению заказчика не реализуем.
Примечание по архитектуре: оба уровня используют один и тот же дешёвый keyword-проход (Aho-Corasick + морфология) как первый слой. Для Премиума его результат становится входом для дорогого AI-слоя — LLM-классификация и семантика через эмбеддинги (провайдер Mistral, vector DB Qdrant). Это позволяет не гонять тяжёлые модели по всем страницам и держать себестоимость Премиума управляемой.
Модули продукта
Заголовок раздела «Модули продукта»Единый продукт покрывает весь жизненный цикл мерчанта (по образцу Web Shield: Monitor / InvestiGate / Onboarding). Все три модуля входят в базовую подписку:
- Onboarding (FR-30–FR-34) — приём заявки на подключение (ручной ввод / CSV / API / публичная форма) и конвертация в мерчанта + кейс андеррайтинга. Аккаунт пользователя при этом не создаётся.
- InvestiGate (FR-40–FR-47) — углублённая проверка мерчанта при подключении и ежегодно для high-risk: кейс, каталог риск-индикаторов (4 группы, traffic-light), dynamic risk score, CREM (кредитная экспозиция), MCC-справка, recommendation checklist и PDF-отчёт. Детерминированный — входит в Basic.
- Monitoring (FR-03–FR-21) — постоянный контент-мониторинг сайтов на нарушения BRAM/GBPP по расписанию; основной объём по тендеру. Детерминированный слой — Basic, AI-слой (FR-10/FR-21) — Premium.
Transaction Laundering (FR-50) и мультиязычная морфология ru/be/en (FR-08) — обязательны по тендеру МТБанк (ОК 26/12) и входят в базовый объём (детерминированные, без ИИ), а не в премиум-слой.