Federated Learning в iGaming

1) Навіщо FL саме в iGaming

Федеративне навчання (FL) дозволяє кільком учасникам (брендам, регіонам, провайдерам, PSP) навчати загальну модель без обміну сирими даними. Це критично там, де є PII/фінанси, транскордонні обмеження і широкий партнерський периметр.

• Поліпшення якості моделей за рахунок «загального інтелекту» холдингу/партнерів.
• Зниження юридичних ризиків і витрат на анонімізацію/обмін.
• Швидкий вихід в нові регіони без міграції історій даних.

Типові завдання: Responsible Gaming (RG) скоринг, антифрод/чарджбеки, AML-патерни, KYC-верифікація (thin-file), персоналізація/CRM, детекція бот-трафіку/бустингу.

2) Архітектури FL

Cross-silo (між організаціями/брендами/регіонами): трохи «розумних» учасниками, стабільний зв'язок, довгі сесії. Підходить для холдингів/PSP/провайдерів.
Cross-device (безліч пристроїв гравців): мільйони «тонких» клієнтів, непостійний зв'язок. Для iGaming застосовується рідше (чати/клієнти додатків), але можливо для on-device сигналів.

• Централізований координатор (server-aggregator) - базовий варіант.
• Ієрархічний (регіональні агрегатори → центральний) - знижує трафік/латентність.
• Peer-to-peer/secure aggregation mesh - складніше, але вище «zero-trust» властивості.

3) Захист приватності та безпеки

Secure Aggregation: сервер бачить лише суму/середнє градієнтів, а не оновлення конкретного учасника.
Диференціальна приватність (DP): шум на стороні клієнта та/або в агрегації; ведемо облік ε -бюджету.
Конфіденційні обчислення (TEE): агрегація та/або інференс в ізольованих енклейвах.
MPC/PSI: безпечні перетини/обчислення при ко-інференсі з PSP/провайдерами.
Політики доступу та логування: заборона на серіалізацію сирих фіч/градієнтів; тільки агрегати і метадані.

4) Технічні виклики FL і як їх вирішувати

Non-IID і дисбаланс: дані доменів відрізняються (країни, методи оплати, лендери).
→ Використовуйте персоналізацію поверх глобальної моделі (fine-tuning/adapter-шари), стратифіковані батчі, зважену агрегацію (за якістю/розміром).

Heterogeneous hardware/мережа: учасники з різною потужністю і доступністю.
→ часткова участь (partial participation), асинхронна агрегація, адаптивні розміри оновлень.

Компресія і трафік: великі ваги/градієнти.
→ Квантування, sparsification, sketch-кодування; рідше - передачу «дельт» замість повних ваг.

Отруєння/бекдори (poisoning): зловмисний учасник псує модель.
→ Робастні агрегатори (median/Krum/trimmed mean), детектори аномалій в оновленнях, «honeypot» завдання і тест-сети, репутаційні ваги.

Дрейф і регрес: зміни поведінки/регуляторики.
→ Безперервне навчання, періодичний re-init, champion-challenger, ML-observability за сегментами.

5) Патерни для ключових кейсів

5. 1 RG-скоринг (відповідальна гра)

Мета: Equal Opportunity (не пропускати ризикових гравців в будь-якій країні/сегменті).
Підхід: cross-silo FL між брендами/регіональними командами; Secure Agg + DP; локальне калібрування порогів.
Overrides: прапори самовиключення/лімітів домінують над моделлю.

5. 2 Антифрод/виплати/chargeback

Мета: Equalized Odds (контроль FPR), стійкість до нового фроду.
Підхід: спільне FL між операторами холдингу і PSP; TEE-агрегатор; MPC для ко-інференса при платежі.
Захист: робастна агрегація + детект аномальних оновлень.

5. 3 AML/KYC

Мета: зниження false-reject для thin-file без втрати чутливості.
Підхід: FL на ознаках документів/патернах платежів; PSI для списків санкцій/РЕР; DP на агрегатах.

5. 4 Персоналізація/CRM

Мета: зростання LTV/утримання без порушення етики і RG.
Підхід: глобальна модель переваг в FL + локальна адаптація шарів; виключення high-risk з «агресивних» офферів; explainability для саппорту.

6) Архітектурна схема (референс)

1. Клієнтські силоси: локальні фічепайплайни (PII відокремлена), тренування локального кроку (E epochs).
2. Захист: DP-кліпінг/шум, шифрування каналів, Secure Agg ключі.
3. Агрегатор: TEE-вузол з робастним агрегатором, трекінг вкладів, контроль аномалій.
4. Регістри: Model Registry (версії, ε/ δ, пороги), Feature Registry (політика ознак).
5. CI/CD ML: fairness-/privacy-гейти, тести на poisoning, калібрування і shadow-прогони.
6. Інференс: централізований або co-inference з партнерами (MPC/TEE), журнали без PII.

7) MLOps для FL

Policy-as-Code: білі/сірі/чорні списки фіч, заборона проксі-атрибутів; перевірка на етапі PR.
Pipeline hooks: тест на дрейф груп/калібрування, EO/EOp по сегментах, вилов аномалій оновлень.
Версіонування: модель/дані/код + ε -облік; «картки моделей» з розділами Fairness & Privacy.
Каталог і лінійдж: зв'язку «сайло → агрегатор → версія моделі», «хто і коли навчав», SLO свіжості.
Observability: latency FL-раундів, частка учасників, розмір/помилка агрегації, Attack- AUC≈random.

8) Метрики та SLO

Якість: AUC/PR, калібрування (Brier), uplift (для CRM).
Справедливість: EO/EOp-дельти по країнах/каналах/пристроях.
Приватність: ε -usage, ймовірність re-id, Attack-AUC (membership/inversion) ≈ 0. 5.
Надійність: участь N учасників ≥ цільового порогу, частка успішних раундів, час раунду.
Безпека: частка відхилених аномальних оновлень, інциденти poisoning = 0.
Бізнес: зниження chargeback/фроду, поліпшення RG-результатів, зростання утримання без зростання диспаритетів.

9) Шаблони (готово до використання)

9. 1 Картка FL-проекту

Завдання/домен: (RG/AML/виплати/CRM)

Топологія: cross-silo/cross-device, ієрархія агрегаторів

Захист: Secure Agg, DP (ε/ δ), TEE/MPC, політика логів

Учасники: список силосів, власники, довірена зона

Метрики: якість, fairness, приватність, надійність, бізнес-KPI

Ризики/мітигації: poisoning, non-IID, дрейф, юрисдикції

Режим релізів: shadow → canary → rollout, частота раундів

9. 2 FL-чек-лист перед запуском

• Контракти даних і політика фіч узгоджені
• Secure Aggregation і шифрування каналів налаштовані
• DP-параметри та облік ε задокументовані
• Робастна агрегація і детект аномалій включені
• Fairness-пороги/ЕОр/ЕО і калібрування по групах задані
• Shadow-прогін пройдений, Attack-AUC ≈ random
• План інцидентів (poisoning/privacy) і rollback готовий

9. 3 Політика участі силосу (фрагмент)

Мінімальний обсяг і якість даних для участі в раунді

Обов'язкові локальні перевірки (DQ, калібрування) до відправки оновлень

Санкції за отруєння: виключення/зниження ваги/аудит

Рев'ю прав і логів: періодичність і відповідальні

10) Дорожня карта впровадження

0-30 днів (MVP)

1. Вибрати 1 пріоритетну задачу (напр., RG або антифрод).
2. Визначити 3-5 силосів, підписати політику фіч і участь.
3. Розгорнути агрегатор (TEE), включити Secure Agg і базову DP.
4. Налаштувати CI-гейти: fairness, privacy, poisoning-тести.
5. Запустити 5-10 раундів FL в shadow-режимі, порівняти з централізованою базою.

30-90 днів

1. Робастні агрегатори + детект аномалій, персоналізація локальними шарами.
2. Знизити трафік (квантування/дельти), ввести часткову участь.
3. Канарка в проді на 5-10% трафіку, звіти по SLO/ ε -usage.
4. Документи: картка FL-проекту, регламент інцидентів, навчання команд.

3-6 місяців

1. Розширення на нові силоси/регіони, ієрархічна агрегація.
2. PSI/MPC для ко-інференса з PSP/вендорами, приватний інференс виплат.
3. Єдиний дашборд FL-observability, регулярні аудити fairness/privacy.
4. Масовий rollout, SLO і повне покриття high-impact завдань.

11) Анти-патерни

FL без Secure Aggregation/DP - «витоку через градієнти».
Ігнорування non-IID: один поріг/політика для всіх доменів.
Відсутність робастної агрегації та моніторингу poisoning.
Логи з PII/фіч-дампами на стороні агрегатора.
«Разово навчили і забули»: без shadow/champion-challenger і рев'ю.

12) Зв'язок з сусідніми практиками

Data Governance, Етика даних, Конфіденційне ML, Походження і шлях даних, Зниження упередженості, Моніторинг моделей, DSAR/Privacy - забезпечують правила фіч, прозорість, метрики і керовані релізи.

Підсумок

Federated Learning дає iGaming-екосистемам спільний інтелект без обміну сирими даними. З правильною архітектурою (Secure Agg + DP + TEE/MPC), стійкістю до non-IID і poisoning, а також дисципліною MLOps ви отримаєте моделі, які масштабуються по ринках і партнерам, витримують аудит і приносять стабільну бізнес Цінність.