Правила антифрода в JSON с контролем ложных срабатываний

Соблюдай все обязательные требования ниже. Верни только итоговый результат в требуемом формате. Не добавляй вступления, комментарии о процессе, предупреждения, альтернативные версии или просьбы что-либо уточнить. Если часть входных данных отсутствует и исходный промпт допускает рабочие предположения, явно фиксируй их только там, где это прямо требуется. Сохраняй placeholders, JSON, YAML, SQL, код, формулы, названия метрик, пороги, порядок разделов и другие обязательные технические элементы без искажений.

Ниже приведён исходный замысел и обязательные ограничения. Сохрани смысл, полноту и прикладную ценность, но сделай ответ максимально однозначным, компактным и готовым к использованию с первой попытки.

Вы — специалист по выявлению мошенничества, разрабатывающий систему мониторинга транзакций для {industry}. Проанализируйте предоставленные {data_type} за {time_period} и создайте детализированную систему обнаружения, которая выявляет подозрительные закономерности при сохранении уровня ложноположительных срабатываний, указанного в {threshold_level}. Выдайте готовый к внедрению набор правил и порогов в формате JSON (см. требуемую структуру ниже). Не добавляйте пояснений вне требуемого формата.

Общие требования и допущения:
- Если {threshold_level} указано числом, используйте его как максимально допустимый процент ложноположительных срабатываний (FPR). Если указано качественно ("низкий"/"средний"/"высокий"), интерпретируйте как соответствие: "низкий" = FPR ≤ 0.5% (0.005), "средний" = FPR ≤ 1% (0.01), "высокий" = FPR ≤ 5% (0.05).
- Под {anomaly_type} понимаются тип/категория аномалий, которые нужно помечать (например, "двойные списания", "смещение геолокации", "необычная частота транзакций" и т.д.). Для каждого правила явно укажите какие варианты {anomaly_type} оно покрывает.
- Учтите сезонность и поведенческие базовые линии: указывайте базовый период для расчёта норм (например, 28/30/90 дней) и метод сглаживания/коррекции (скользящая средняя, EWMA, медиана по часам дня и дням недели и т.п.).
- Формат вывода — строго JSON-массив объектов-правил. Каждый объект должен содержать поля, описанные ниже. Никаких дополнительных полей, метаданных или пояснений вне JSON.

Требуемая структура каждого правила (обязательные поля):
- id: строка, уникальный идентификатор правила.
- name: краткое название правила.
- anomaly_type: одно или несколько значений {anomaly_type}, которые правило обнаруживает.
- description: одно-двухстрочное бизнес-описание, зачем правило нужно и какие риски покрывает.
- data_fields: список полей из {data_type}, необходимых для правила (названия полей и типы — string/number/timestamp/geo/ip и т.п.).
- baseline_period: период (например, "last_90_days") и метод расчёта базовой линии (median, mean, EWMA, пользов. percentiles).
- lookback_window: окно для реального времени (например, 1h, 24h, 7d).
- aggregation_granularity: гранулярность агрегирования (per-transaction, per-user-per-hour, per-card-per-day и т.п.).
- detection_logic: формальная логика с четкими условиями (булевы выражения, пороговые значения, статистические тесты). Приводите выражения вида: fieldA > X AND count(fieldB, window) >= Y, z-score > Z, p-value < 0.01 и т.п.
- numerical_thresholds: конкретные числовые пороги с единицами и объяснением, как они получены (например, "threshold = baseline_mean + 4 * baseline_std" или "95th percentile of last_30_days").
- statistical_basis: краткая нотация, какой статистический метод использован (z-score, Poisson test, binomial test, EWMA, isolation forest и т.д.) и параметры (alpha, lambda, contamination).
- expected_fp_rate: оценка ожидаемой ложноположительной частоты для этого правила с пояснением соответствия общему {threshold_level} (в процентах).
- estimated_detection_rate: примерная оценка охвата/чувствительности (TPR) или диапазон, и при каких сценариях он достигается.
- real_time_trigger: конкретный событийный триггер для немедленного срабатывания (например, "при поступлении транзакции, удовлетворяющей detection_logic — генерировать ALERT_HIGH") и минимальная задержка (latency).
- score_and_priority: схема присвоения риска (числовой риск 0-100 и мэппинг на приоритеты: LOW/MEDIUM/HIGH/CRITICAL) и правило объединения с другими сигналами.
- examples: 1–2 конкретных тестовых примера транзакций/сценариев (в виде JSON объектов входных данных) которые вызовут срабатывание, с пояснением.
- mitigation_action: рекомендуемое оперативное действие при срабатывании (например, "немедленная блокировка и ручная проверка", "заморозить на 24 часа и отправить оповещение аналитикам").
- monitoring_metrics: какие метрики наблюдать после внедрения для данного правила (alert_rate, fp_rate_estimate, avg_time_to_investigate, %escalated), и частота отчётов.
- recalibration_frequency: рекомендованная периодичность пересмотра порогов (например, weekly/monthly/quarterly) и условия автопересчёта (drift > X%).
- deployment_notes: минимальные предпосылки/ограничения для корректной работы (например, требуемая полнота полей, часы синхронизации, минимальный объём данных в базе).
- confidence: краткая оценка уверенности в этом правиле (low/medium/high) и основания для оценки.

Требования к набору правил в целом:
- Покрыть все значимые классы аномалий, релевантные для {industry} и {anomaly_type}, и объяснить какие из них приоритизируются для немедленного расследования.
- Обеспечить совокупную ожидаемую FPR ≤ {threshold_level} (с учётом интерпретации качественных меток, указанной выше). Для этого укажите метод агрегации FPR (например, независимые правила, коррекция Бонферрони, комбинированный скоринг).
- Укажите, какие правила должны генерировать немедленные (block/hold) реакции, а какие — только alerts для аналитиков.
- Сформируйте не менее 6 и не более 12 правил (если объём данных/сценариев ограничен, сформируйте максимально информативные 4–6 правила).
- Для каждого правила укажите, можно ли реализовать его как простое детерминированное правило (SQL/boolean) или требуется ML-модель, и какие признаки/модели предпочтительны.

Формат вывода — строго JSON:
- Выведите JSON-массив правил. Пример структуры (строго соблюдать поля): [{id, name, anomaly_type, description, data_fields, baseline_period, lookback_window, aggregation_granularity, detection_logic, numerical_thresholds, statistical_basis, expected_fp_rate, estimated_detection_rate, real_time_trigger, score_and_priority, examples, mitigation_action, monitoring_metrics, recalibration_frequency, deployment_notes, confidence}, ...]
- Ничего кроме валидного JSON не выводите.