Закрытые букмекерские платформы — особая категория. Они не работают "на массу", редко светятся в инфополе и, как правило, ориентированы на опытных игроков и крупные суммы. Именно таким проектом стала bookedsports.com — зарубежная БК с ограниченным доступом и британской лицензией, в которой мне довелось реализовывать модуль KYC/AML + платёжную маршрутизацию.

В этом посте расскажу, как мы выстраивали архитектуру системы, ориентируясь на надежность, масштабируемость и безопасность, при этом не жертвуя удобством для конечного пользователя.

? Архитектура: микросервисы, оркестрация, отказоустойчивость

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

• Изоляция зон риска. Отдельные процессы (например, KYC и финансы) не зависели друг от друга напрямую.

• Упрощённая замена провайдеров. Можно было быстро переключить KYC или платёжного поставщика без каскадных изменений.

• Отказоустойчивость. Каждый сервис имел fallback-логику и внутренние очереди обработки при потере внешней доступности.

В основе архитектуры:

• Основной API и обработка бизнес-логики — через Node.js с NestJS.

• Отдельные сервисы логирования и событий — на Python (FastAPI).

• Базы данных: PostgreSQL (транзакционные данные), MongoDB (аудит и мониторинг), Redis (кеш и временные статусы).

• Асинхронная коммуникация — через Kafka.

? KYC/AML: гибкость без дыр в безопасности

Основной вызов — интегрировать строгую верификацию без "банковской" душности. Платформа закрытая, но это не значит, что можно игнорировать AML-риски. Поэтому:

• Мы подключили несколько KYC-провайдеров с возможностью fallback’а. Например, если основной API недоступен или дал отказ, пользователь незаметно переключался на резервного.

• Создали мультистадийную систему верификации. Базовый уровень — по паспорту и селфи, расширенный — при аномалиях в поведении, платежах, IP.

• Все статусы и документы проходят внутренний скан на потенциальные фрод-риски. Например, при совпадении имени и даты рождения с другим аккаунтом — срабатывает триггер и включается ручной комплаенс.

• Реализовали real-time аналитику: время между действиями, частота повторных верификаций, повторяющиеся платежные шаблоны.

Важно, что архитектура KYC-модуля строилась как оркестратор: она не зависела от одного провайдера и могла адаптироваться под юрисдикцию, локацию пользователя и валюту.

? Платежи: маршрутизация, контроль, антифрод

Платёжный модуль — вторая по критичности часть системы. Мы строили его с учётом high-risk-специфики:

• Гибкая маршрутизация по валюте, гео и типу юзера. Один пользователь видит только стабильные fiat-методы, другой — криптовалюту через проверенного процессора.

• Внутри реализован белый список провайдеров, каждый из которых проходит аудит и тестирование на поведение в нестабильных ситуациях (зависания, отмены, скачки курсов).

• Поддержка multi-wallet логики — с отслеживанием подозрительных совпадений (IP, устройство, способ ввода средств).

• Вся маршрутизация и логика рисков — через внутренний rules engine: например, если три неуспешные попытки пополнения подряд — происходит soft freeze и отправляется алерт в модуль мониторинга.

При этом пользователю не показывается "сложность" системы — он просто выбирает способ оплаты, а всё остальное решается в фоне. Это и есть грамотная оркестрация.

? Безопасность: слоистая защита и наблюдаемость

Безопасность в нашей платформе — это не только защита от внешних атак, но и способность реагировать на внутренние аномалии, а также учитывать поведение пользователей с течением времени. В беттинге, где высокие ставки, и вероятность мошенничества крайне велика, важно не только обеспечить защиту данных, но и уметь эффективно обнаруживать фроды, анализировать поведение и в реальном времени принимать решения.

Bookedsports.com — это закрытая букмекерская платформа, ориентированная на опытных игроков и крупные ставки. В таких системах, где каждый пользователь может делать большие финансовые операции, важно построить не только высококачественный UX и надёжную верификацию, но и систему безопасности, которая будет защищать не только данные, но и саму платформу от злоумышленников.

1. Многоуровневая защита

Для того чтобы платформа была защищена от всех видов атак и нежелательных вмешательств, мы внедрили несколько уровней защиты, которые обеспечивают слоистую защиту на разных этапах взаимодействия пользователя с системой:

• API Rate Limits и Троттлинг

Мы ограничили количество запросов, которые могут быть выполнены за определённый промежуток времени. Это позволяет предотвратить атаки типа brute force или DDoS, где злоумышленник может попытаться получить доступ к системе с помощью автоматических скриптов.

Например, для регистрации нового пользователя, при попытке слишком частых запросов (например, с одним и тем же IP-адресом), система будет блокировать дальнейшие попытки на время, а также информировать администраторов о потенциальной атаке.

• Web Application Firewall (WAF)

WAF стал важной частью нашей инфраструктуры для защиты веб-приложений от известных уязвимостей, таких как SQL инъекции, XSS атаки и других видов атак на уровне веб-приложения. Мы использовали решения, которые интегрируются с API и фильтруют все входящие HTTP-запросы, обеспечивая автоматическое блокирование вредоносных попыток.

• Token-based Авторизация + Device Fingerprinting

Использование токенов (например, JWT) для авторизации было обязательно, чтобы гарантировать, что только авторизованные пользователи могут получить доступ к платёжным системам или личным данным.

Дополнительно, мы внедрили device fingerprinting — метод, который позволяет идентифицировать устройство пользователя по ряду факторов (например, экран, браузер, операционная система). Это позволяет предотвратить попытки мошенничества с использованием поддельных аккаунтов или устройств, которые ранее не использовались.

2. Внутренняя телеметрия и поведение

Мы не ограничились просто базовой защитой. Платформа активно мониторит все действия пользователей в реальном времени и анализирует их поведение с течением времени:

• Внутренняя Телеметрия Событий (Event Logging)

Каждое действие пользователя (регистрация, депозиты, ставки, изменение настроек аккаунта) фиксируется в нашей системе мониторинга, что позволяет отслеживать и анализировать весь путь пользователя в системе.

Для обработки событий и анализа поведения мы использовали Kafka как систему сообщений, которая быстро и эффективно передаёт события в реальном времени, и PostHog для анализа аномалий в поведении. Все эти данные затем анализируются с использованием машинного обучения, чтобы выявить паттерны мошенничества или подозрительных действий.

• Поведенческий Анализ

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

Эти механизмы позволяют не только реагировать на текущие события, но и предсказывать возможные риски. Например, если система видит, что пользователь слишком часто делает ставку в короткий промежуток времени или ставит на редкие события, это может быть индикатором фрода.

3. Роль пользователей и доступ к данным через ACL

Контроль доступа к данным и функциям системы также имеет несколько слоёв защиты. Модуль ACL (Access Control List) позволяет определить, какие пользователи могут получить доступ к каким данным:

• Роль и Права Доступа

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

• Интеграция с внешними сервисами

Для дополнительной защиты мы также интегрировались с внешними сервисами по проверке фрода (например, блокировка мошеннических карт, проверка адресов на соответствие данным из базы данных). Если такие данные приходят из внешних систем, они сразу обрабатываются и используются для анализа.

4. Аудит-логи всех действий

Для того чтобы обеспечить прозрачность и контроль за любыми действиями, платформа ведет полный аудит всех операций:

• Логирование Всех Действий

Включая все действия пользователя — от входа в систему до изменения настроек аккаунта и совершения платежей. Каждое событие, вплоть до открытия модального окна с уведомлением, записывается в лог. Эти данные сохраняются в MongoDB и могут быть использованы для расследования фродовых действий или внутреннего аудита.

• Интеграция с внешними аналитическими системами

Мы интегрировали логи с системой PostHog, что позволяет не только хранить данные, но и визуализировать их для анализа, обнаружения паттернов и аномалий. Это помогает оперативно реагировать на появление фрода и улучшать защиту в реальном времени.

5. Обучение и улучшение

Вся система не только реагирует на текущие угрозы, но и обучается на поведении пользователей. Например, если система видит схожие паттерны действий у мошенников (например, постоянное использование одного устройства с разных IP), она помечает подобные действия у новых пользователей как подозрительные и автоматически запускает дополнительные проверки.

Это делает платформу не просто реактивной, а проактивной: она предсказывает, что может случиться, и начинает принимать меры заранее.

? UX: на грани жёсткости и понятности

Технически мы старались минимизировать "трение", но пока не всё идеально:

• Интерфейс верификации — слишком сухой. Нет инструкций, подсказок, визуального прогресса.

• Ошибки отображаются не всегда понятно (например, отказ верификации не объясняет причину).

• Отсутствует полноценный onboarding — пользователь попадает сразу в процесс, и если он не в теме, может растеряться.

Это уже не к бэкенду вопрос, но как практика показывает — в таких платформах именно мелкие UX-детали снижают нагрузку на поддержку и повышают доверие.

✅ Что в итоге

✔ Архитектура — масштабируемая и устойчивая к сбоям

✔ Верификация и платежи — гибкие, безопасные, модульные

✔ Все действия — логируются и анализируются

✘ Интерфейс KYC — требует улучшений в части прозрачности и объяснений

Этот проект стал отличным примером того, как можно выстроить гибкую и защищённую оркестрацию процессов в закрытой беттинг-системе с high-risk-профилем. Да, не без шероховатостей, но результат — платформа bookedsports, способная выдержать нагрузку, атаки и запросы на масштабирование.

Если ты тоже работаешь над финтех/геймтех-инфраструктурой — welcome в комменты, готов обсудить архитектурные решения, модули, риски.

#финтех #геймтех #kyc #aml #разработка #архитектура #безопасность #bookedsports #беттинг #devlog