BRD — бизнес-требования
This content is not available in your language yet.
BRD (Business Requirements Document) — документ бизнес-требований. Описывает, что система должна делать с точки зрения бизнеса: цели, заинтересованных сторон, бизнес-процессы AS-IS / TO-BE, функциональные (FR) и нефункциональные (NFR) требования, бизнес-правила, ограничения и границы проекта. Это контракт между заказчиком и командой разработки; как это реализовано — описывает LLD.
Проект: Система интеллектуального мониторинга мерчантов — сервис мониторинга контента сайтов мерчантов (мониторинг контента сайтов мерчантов) Версия: 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. Функциональные требования»Приоритет (MoSCoW): Must — обязательно · Should — желательно · Could — возможно.
| ID | Категория | Наименование требования | Описание (Система должна [действие] при условии [условие]) | Приоритет |
|---|---|---|---|---|
| FR-01 | Аутентификация | Вход подписчика | Система должна аутентифицировать пользователей подписчика по email+паролю с приглашениями и опциональным 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 + Андеррайтинг (по образцу Web Shield)
Заголовок раздела «Расширение продукта: Onboarding + Андеррайтинг (по образцу Web Shield)»Блок требований для модулей Onboarding (приём заявок) и Андеррайтинг (андеррайтинг мерчанта при подключении и ежегодно). Дополняет контент-мониторинг до полного жизненного цикла мерчанта: заявка → мерчант (+структура) → кейс с 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 | Андеррайтинг | Кейс Андеррайтинг | Система должна заводить кейс андеррайтинга на мерчанта (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 |
| FR-52 | Биллинг | Учёт объёмов и тарификация | Система должна вести автоматический помесячный учёт количества проверок по трём видам услуг (контент = сайт ОТС со сканом за месяц; TL = цикл TL-анализа мерчанта; due diligence = кейс андеррайтинга) нарастающим итогом, тарифицировать по модели базовый пакет/мес + overage сверх квоты (база и ставки редактируются супер-админом, пер-тенант override) и формировать биллинг-артефакты: Акт сверки объёмов, месячный отчёт по объёмам с разбивкой по ОТС, Акт об оказании услуг (PDF/Excel). (проект договора, тендер МТБанк) | Must |
Модуль ФИШИНГ-ДЕТЕКТОР (Digital Risk Protection)
Заголовок раздела «Модуль ФИШИНГ-ДЕТЕКТОР (Digital Risk Protection)»Комплексная защита бренда заказчика от внешних цифровых угроз: фишинговых сайтов, поддельных мобильных приложений и мошеннических аккаунтов в соцсетях. Полный цикл: регистрация защищаемых активов → снятие цифрового отпечатка → непрерывный мониторинг → реагирование и блокировка.
Подмодуль: Защищаемые активы (Protected Assets)
Заголовок раздела «Подмодуль: Защищаемые активы (Protected Assets)»| ID | Категория | Наименование требования | Описание | Приоритет |
|---|---|---|---|---|
| FR-60 | Защищаемые активы | Реестр защищаемых активов | Система должна позволять офицеру регистрировать официальные активы заказчика, подлежащие защите: веб-сайты, мобильные приложения, аккаунты в соцсетях/мессенджерах — с метаданными (домен/package name/handle, тип, статус активен/пауза). | Must |
| FR-61 | Защищаемые активы | Цифровой отпечаток веб-актива | Система должна автоматически сканировать зарегистрированный веб-актив и извлекать цифровой отпечаток: favicon → perceptual hash, DOM-структура → структурная сигнатура, цветовая палитра, визуальный embedding, брендовые ключевые слова, паттерны форм ввода. Отпечаток обновляется по расписанию (официальный сайт меняется). | Must |
| FR-62 | Защищаемые активы | Цифровой отпечаток мобильного приложения | Система должна формировать отпечаток официального мобильного приложения: package name (Android) / bundle ID (iOS), SHA-256 сертификата подписи APK, иконка → perceptual hash, официальные Store URL (Google Play, App Store, AppGallery). Метаданные вводятся офицером и/или извлекаются из Store API. | Must |
Подмодуль: Обнаружение и мониторинг (DRP)
Заголовок раздела «Подмодуль: Обнаружение и мониторинг (DRP)»| ID | Категория | Наименование требования | Описание | Приоритет |
|---|---|---|---|---|
| FR-63 | Мониторинг | Мониторинг доменов и DNS | Система должна вести непрерывный поиск новых доменов, содержащих брендовые слова заказчика (из FR-61), с учётом омоглифов, транслитерации и тайпосквоттинга (опечатки, перестановки, добавления). Источники: Certificate Transparency logs, пассивный DNS, WHOIS-потоки. | Must |
| FR-64 | Мониторинг | Мониторинг веб-страниц | Система должна сканировать обнаруженные подозрительные страницы на структурную схожесть с эталоном (FR-61): сравнение favicon hash, DOM-сигнатуры, брендинговых элементов, наличие форм ввода паролей/платёжных данных. | Must |
| FR-65 | Мониторинг | Embedding-детекция фишинга | Система должна применять векторное сравнение (embedding) визуального и структурного отпечатка страницы с эталоном (FR-61) для выявления фишинга, визуально изменённого относительно оригинала (иной цвет, перетасованные блоки). | Should |
| FR-66 | Мониторинг | Мониторинг мобильных приложений | Система должна выполнять поиск приложений с брендом заказчика в официальных (Google Play, App Store, AppGallery) и неофициальных сторах/APK-агрегаторах; сравнивать package name, сертификат подписи и иконку с отпечатком FR-62; расхождение → тикет. | Must |
| FR-67 | Мониторинг | Мониторинг соцсетей и мессенджеров | Система должна выявлять мошеннические аккаунты и фейковые страницы в Telegram, X (Twitter), Instagram, Viber и других платформах, нелегитимно использующих бренд заказчика (название, логотип, официальный handle). | Should |
| FR-68 | Мониторинг | Ручное создание тикета | Система должна позволять офицеру вручную зарегистрировать угрозу (URL / аккаунт / APK), минуя автодетект, с указанием типа и описания. | Must |
Подмодуль: Реагирование и блокировка (Response)
Заголовок раздела «Подмодуль: Реагирование и блокировка (Response)»| ID | Категория | Наименование требования | Описание | Приоритет |
|---|---|---|---|---|
| FR-69 | Реагирование | Жизненный цикл тикета | Система должна вести тикет угрозы со статусами: на мониторинге (обнаружен, ожидает обработки офицером) → в работе (жалоба направлена, ожидает блокировки) → заблокирован. Из открытых статусов офицер может закрыть тикет как ложное срабатывание (терминальный статус): повторное обнаружение того же URL фиксируется в счётчике обнаружений, но не возвращает тикет в очередь офицера (whitelist). | Must |
| FR-70 | Реагирование | Доказательная база для блокировки | Система должна автоматически формировать пакет доказательств для короткоживущих фишинговых страниц: скриншот, HTML-снимок, временная метка, источник обнаружения, факт гео-клоакинга (если выявлен). Доказательства хранятся append-only (immutable). | Must |
| FR-71 | Реагирование | Отправка жалобы на блокировку (takedown) | Система реализует трёхуровневый автоматизированный механизм takedown: Уровень 1 (API-блоклисты) — автоматическая подача URL в публичные антифишинговые реестры (Google Safe Browsing Reporting API, PhishTank Submit, Netcraft, APWG eCrime Exchange); Уровень 2 (email-abuse) — автоматическая отправка структурированной жалобы от abuse@shield.by регистратору домена и хостинг-провайдеру (ICANN-контакт abuse@, определяется по WHOIS), с идентификацией Shield.by как «уполномоченного представителя» банка-клиента; тенанту свой SMTP не нужен. Уровень 3 (ассистированный ручной) — для платформ со сложными формами и CAPTCHA система выводит офицеру пошаговую инструкцию. Канал, внешний ref, дата и полученный ответ фиксируются в takedown_requests. | Should |
Организационные предусловия FR-71 (выполнить до запуска Уровня 1–2 в production):
1. Email-инфраструктура
abuse@shield.byНастроить SPF + DKIM + DMARC для доменаshield.byи «прогреть» домен постепенной отправкой. Без этого письма Уровня 2 попадают в спам вне зависимости от содержания.2. Регистрация в PhishTank Создать организационный аккаунт на phishtank.org (бесплатно, без ревью). Позволяет подавать URL через API и формирует публичный reputation-след репортёра — ускоряет обработку.
3. Вступление в APWG eCrime Exchange APWG — американская некоммерческая организация; членство открыто для международных организаций, в т.ч. белорусских частных компаний. ООО «АртКлауд» как private tech-company без госаффилиации под санкционные ограничения не подпадает.
Что требуется для подачи заявки (apwg.org/membership, форма Associate Member):
- Юридические реквизиты компании (название, адрес, контактное лицо)
- Описание деятельности в контексте борьбы с фишингом: «DRP-платформа для банков-эквайеров, автоматически обнаруживает фишинговые клоны брендов мерчантов и инициирует takedown»
- Техническое описание (1 стр.): как Shield.by собирает, верифицирует и структурирует URL перед репортингом — ключевой вопрос при рассмотрении
- Подписание Data Use Agreement (условия совместного использования threat intel, запрет публичного раскрытия без согласования)
- OFAC self-attestation — стандартная форма для US-организаций; подтверждает, что компания не входит в SDN-список OFAC. Для частной tech-компании без госаффилиации — формальность, не барьер. Рекомендация действующего члена APWG ускоряет рассмотрение, но не обязательна.
Что даёт членство: приоритетная обработка репортов платформами (Google, Meta, Cloudflare), доступ к агрегированным фидам угроз eCrime Exchange, институциональный статус в коммуникациях с регистраторами.
Контакт для уточнения текущих требований: apwg@apwg.org
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 + Андеррайтинг, по образцу 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).
-
Модуль ФИШИНГ-ДЕТЕКТОР (FR-60–FR-71):
- Реестр защищаемых активов и цифровые отпечатки: веб (FR-60–FR-61) и мобильные приложения (FR-62).
- Мониторинг: домены/DNS (FR-63), веб-страницы (FR-64), embedding-детекция (FR-65), APK (FR-66), соцсети (FR-67), ручной тикет (FR-68).
- Реагирование: жизненный цикл тикета (FR-69), доказательная база (FR-70), takedown-жалобы (FR-71).
- Фаза 2 (бэклог): CT-стриминг (certstream) + NRD-фиды — расширение FR-63: поиск бренд-слов активов во всех выпускаемых TLS-сертификатах (стриминг Certificate Transparency) и в ежедневных списках новых регистраций доменов (закрывает HTTP-кейс: домен ловится при регистрации, до сертификата и сайта). Снимает ограничение «видим фишинг только на доменах, похожих на бренд». План —
scanner/PHASE2.md, M6. - Реализовано (M7, admin v1.3.0): канарейка на официальном сайте — расширение FR-64: JS-сниппет на сайте актива (beacon при открытии копии страницы на чужом домене). Детерминированно ловит активный клон на любом домене и чистом HTTP в момент первого открытия; дедуп по URL, суточный анти-флуд-потолок на актив. Referer-анализ хотлинка ассетов — бэклог.
- Фаза 2 (бэклог): поиск по favicon-хэшу (urlscan.io) — расширение FR-64: периодический поиск favicon’а актива среди просканированных в мире страниц, кандидаты — в общий пайплайн. План —
scanner/PHASE2.md, M8.
8. Уровни подписки (тарифы)
Заголовок раздела «8. Уровни подписки (тарифы)»Принцип разделения тарифов: всё, что не использует ИИ и не требует тяжёлых ресурсов (детерминированный контент-скан, морфология ru/be/en, анти-обфускация, стоп-листы, Onboarding, Андеррайтинг, детерминированный Transaction Laundering, evidence-HTML, отчёты) входит в Простую (Basic). Премиум добавляет всё ИИ- и тяжёлое поверх: LLM-классификация, семантический поиск, полный headless-рендеринг SPA и скриншоты страниц.
Таким образом базовая подписка уже включает все три модуля жизненного цикла мерчанта — Onboarding, Андеррайтинг, Monitoring (см. «Модули продукта» ниже); это единый продукт, а не отдельные платные опции. Verdict-API при оплате (фаза 3) — отдельный модуль, продаётся доп. опцией к любому тарифу после интеграции с PSP-шлюзом.
Модель ценообразования (базовый пакет + overage). Базовый пакет/мес (абонплата) покрывает гарантированные квоты по трём услугам; сверх квоты тарифицируется только overage по ставке за единицу. Итог = базовый_пакет + Σ overage. Базовый пакет: дефолт платформы — стартовый от 5 000 BYN/мес (на лендинге), МТБанк — 15 000 BYN/мес (тендер, покрывает квоты 3000/3000/1). Тариф (Basic/Premium) определяет глубину анализа (детерминированный слой vs + AI-слой). Учёт объёмов и тарификацию ведёт биллинг-модуль (FR-52); базовый пакет, ставки и квоты редактирует супер-админ, возможен пер-тенант override. Публичный калькулятор на лендинге даёт предварительную оценку (база + overage по объёму). Совпадает с формулировкой тендера — «абонентская плата/мес».
| Возможность | Простая (Basic) | Премиум (Premium) |
|---|---|---|
| Поиск по стоп-листу: точное совпадение | ✓ | ✓ |
| Морфология ru/be/en (все словоформы) | ✓ | ✓ |
| Анти-обфускация (разрядка, гомоглифы, транслит) | ✓ | ✓ |
| Onboarding — приём заявок (ручной/CSV/API/форма) → кейс | ✓ | ✓ |
| Андеррайтинг — кейс, индикаторы, 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), Андеррайтинг (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 / Андеррайтинг / Onboarding). Все три модуля входят в базовую подписку:
- Onboarding (FR-30–FR-34) — приём заявки на подключение (ручной ввод / CSV / API / публичная форма) и конвертация в мерчанта + кейс андеррайтинга. Аккаунт пользователя при этом не создаётся.
- Андеррайтинг (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) и входят в базовый объём (детерминированные, без ИИ), а не в премиум-слой.