Через ЮScan уже проверили более 550 тысяч заявок, а пропускная способность краулера доходит до 1000 сайтов в час. Для рынка, где ручная модерация давно проиграла и по скорости, и по цене ошибки, это не просто ещё один внутренний инструмент, а вполне показательный кейс про автоматизированный аудит сайтов в платёжной инфраструктуре.
О том, как устроен сервис, сообщает Habr / Новости со ссылкой на новую статью команды ЮMoney. ЮScan используют для предварительной проверки сайтов банков и платёжных организаций: система должна понять, чем ресурс занимается на практике, а не только по главной странице или анкете клиента. Логика здесь прикладная: если сайт скрывает рискованную или запрещённую деятельность в глубине каталога, ошибка на этапе подключения может обернуться проблемами уже для эквайера, compliance-команды и антифрод-контуров.
Главная техническая проблема в таких задачах давно известна: сайт редко укладывается в наивную схему «скачали HTML, пробежались по тексту, вынесли вердикт». У крупного интернет-магазина, маркетплейса или витрины услуг могут быть тысячи страниц, часть контента подгружается на клиенте, часть раскрывается только после действий пользователя, а критичные данные прячутся в карточках товаров, пользовательских отзывах или малозаметных разделах. Поэтому в ЮMoney сделали рекурсивный обход сайта и добавили работу с динамическим контентом через браузерное окружение. В статье отдельно упомянуты Scrapy и Playwright: выбор вполне логичный для связки «быстрый краулер плюс управление живой страницей», где нужно не только собирать ссылки, но и корректно прожимать интерфейс, дожидаться рендера и извлекать то, что не лежит в исходном коде страницы.
Дальше начинается самая интересная часть. ЮScan не ограничивается поиском подозрительных слов по словарю, потому что такой подход быстро упрётся в лавину ложных срабатываний. Сервис анализирует сразу несколько слоёв данных: тексты, изображения, отзывы, внешние ссылки и регистрационные сведения. После этого в ход идут ML-модели, embeddings и LLM, которые помогают оценить найденный контент и отделять реальный риск от шумовых совпадений. Для читателя из IT это, пожалуй, главный практический вывод: в 2026 году автоматизированный аудит сайтов уже плохо работает как чисто rule-based система. Если задача стоит не «что-то поймать любой ценой», а держать вменяемый баланс между покрытием и false positive, без многоступенчатой оценки контекста обойтись сложно.
При этом кейс ЮScan интересен не только финансовому сектору. В тексте прямо названы сценарии, знакомые куда более широкому кругу команд: эквайринг, маркетплейсы, KYC/AML-проверки и вообще ситуации, где нужно анализировать тысячи страниц в сутки. По сути, речь идёт о типовой корпоративной боли: бизнес хочет масштабировать онбординг клиентов и продавцов, юристы и безопасность требуют не пропустить серую схему, а разработка должна собрать систему, которая не утонет ни в динамическом фронтенде, ни в очередях задач, ни в потоке спорных кейсов. На этом фоне заявленная производительность в 1000 сайтов в час выглядит не маркетинговой деталью, а ключевым аргументом. Если объёмы действительно такие, ручной просмотр становится резервным инструментом для эскалации, а не основным способом принятия решения.
Есть и более широкий отраслевой контекст. За последние годы сайты перестали быть просто «визиткой бизнеса»: у одного и того же домена могут сосуществовать обычная витрина, пользовательский контент, лендинги под рекламу, скрытые разделы, партнёрские переходы и быстро меняющийся каталог. Для антифрода и compliance это неприятная среда, потому что предмет проверки всё время шевелится. Поэтому рынок естественным образом движется к гибридным системам: краулер собирает максимум материала, браузерный слой добирается до динамики, классификаторы и языковые модели пытаются понять смысл, а финальное решение при необходимости уходит человеку. ЮMoney здесь описывает не экзотику, а довольно зрелую архитектуру, просто применённую к конкретной боли платёжного бизнеса.
Для разработчиков эта история тоже полезна безотносительно финтеха. Во-первых, она напоминает, что «обходить сайт» в продакшене почти всегда значит строить распределённую систему с очередями, ограничениями по ресурсам, защитой от дублей и аккуратной работой с динамическими страницами. Во-вторых, она показывает, что LLM в корпоративных контурах чаще приживаются не как самостоятельный оракул, а как один из слоёв принятия решения рядом с эмбеддингами, признаковыми моделями и внешними источниками данных. И, в-третьих, кейс хорошо иллюстрирует зрелую постановку задачи: не просто находить плохое, а снижать число ложных тревог. Для бизнеса именно это обычно и решает судьбу проекта. Система, которая блокирует слишком много добросовестных клиентов, быстро превращается из средства защиты в источник внутренних конфликтов и потерь выручки.
Наиболее важный вопрос здесь даже не в том, насколько быстро ЮScan умеет обходить сайты, а в том, где проходит граница между автоматическим скорингом и человеческой ответственностью. Чем активнее банки, платёжные сервисы и маркетплейсы переводят проверки в автоматизированный режим, тем выше цена ошибки классификации. Значит, конкурировать будут не те, кто громче заявит про ML и LLM, а те, кто сумеет доказать качество решений на сложных и неоднозначных кейсах.