T-Bank ML System Design: контрольные вопросы и phishing warnings

Ранжировать вопросы по expected utility: безопасность/разделяющая сила минус friction, с учетом клиента, канала, риска операции и доступности фактов.

Сначала нужно определить цель: снизить fraud/account takeover, сохранить call completion и не ухудшить UX. Кандидаты вопросов имеют признаки сложности, uniqueness, freshness, sensitivity, вероятность ответа владельцем и вероятность угадывания мошенником. Контекст: клиент, операция, риск-сигналы, история коммуникаций, канал, регуляторные ограничения.

Модель может быть LTR/scorecard: выбрать вопрос или последовательность вопросов. Нужны hard rules для запрещенных вопросов, fallback на ручную верификацию и мониторинг ошибок.

Нужны answer success, fraud outcomes and friction labels, но из-за logging policy требуется exploration, propensity logging или conservative offline evaluation.

Лейблы: правильно/неправильно ответил, время ответа, transfer/escalation, повторный звонок, confirmed fraud, false reject, complaint, manual review outcome. Проблема: историческая политика уже выбирала вопросы, поэтому unknown counterfactual для непоказанных вопросов.

Чтобы снизить bias, нужно логировать propensity/position, делать controlled exploration на безопасных сегментах, использовать IPS/DR evaluation или начинать с rules+human review. Для fraud labels важны задержки и post-fact confirmation.

Выкатывать staged rollout с жесткими guardrails, shadow mode, manual review для high-risk и monitoring delayed fraud outcomes.

До A/B нужен shadow scoring: модель предлагает вопрос, но не влияет на оператора. Затем small traffic на low/medium-risk сегментах. Primary метрики: fraud prevention, false reject/false accept, call completion, AHT, escalation, complaints. Guardrails: spike fraud, complaints, regulatory incidents, manual review overload.

High-risk операции лучше оставлять под stricter policy или human review до доказанного качества. Из-за delayed fraud labels нужны interim proxy metrics и последующий backtest.

Сделать multi-signal risk scoring URL/domain/page content, быстрый lookup на critical path, async enrichment и policy для warning/blocking thresholds.

Пайплайн включает URL/domain reputation, lexical features, DNS/TLS/hosting signals, redirects, page screenshot/content, brand impersonation, user reports and threat feeds. На online path у ISP должен быть быстрый cache/lookup score, а тяжелый crawling/enrichment идет асинхронно.

Решение не только модельное: нужны thresholds для warn/block/allow, feedback от пользователей, appeals, allowlist, monitoring false positives and incident response.

Комбинировать threat feeds, user reports, analyst labels, takedown/brand data and sandbox verdicts; логировать exposure warnings, чтобы не смешать behavior change с истинной безопасностью.

Лейблы приходят из внешних feeds, ручной аналитики, жалоб пользователей, brand protection, sandbox/crawler verdicts, allowlists and confirmed incidents. Они шумные, задержанные и biased toward known campaigns. После запуска предупреждений пользователи меньше переходят на опасные страницы, поэтому простое снижение инцидентов может быть эффектом показа, а не лучшей модели.

Нужно хранить policy exposure, model score, user action after warning, delayed confirmations and sampled manual audit.

Выбирать threshold по стоимости false positive/false negative, делать разные policy bands и мониторить precision, recall proxies, complaints, bypasses and incident rate.

Вместо одного порога лучше иметь зоны: allow, warn, strong warn/block, manual/async review. Threshold зависит от confidence, бренда, user segment, freshness threat intel и стоимости ошибки. Для банковского phishing false negative может быть очень дорогим, но массовые false positives ломают доверие и бизнес клиентов.

Monitoring: alert volume, warning CTR/bypass, confirmed phishing, false positive appeals, latency, cache hit rate, drift по доменам/хостингам, attack campaigns.