Сбербанк запустил сервис быстрого возврата денег, поступающих на карту от злоумышленников. Речь идёт о ситуациях, когда человека используют как дропа — легального держателя карты, через которого прогоняют украденные средства. Технически это означает, что банк научился в реальном времени распознавать подозрительные входящие переводы по СБП и автоматически их откатывать. Для студента ИТ-специальности это не просто новость из ленты, а готовый каркас для практической части диплома. Ниже покажу, как превратить антифрод-контур в полноценную ВКР: от обоснования актуальности до метрик эффективности и защиты.
Кейс закрывает сразу три боли, которые мучают студентов на защите: «а что я разработал», «на чём основано проектирование» и «как измерить результат». Не нужно выдумывать космические технологии — достаточно взять реальную бизнес-задачу, которую уже решил Сбер, и предложить свою реализацию, пусть даже упрощённую.
Статья даёт отличный материал для первой главы: там есть и угроза (дроп-переводы), и объект автоматизации (процесс возврата средств), и требование к системе — оперативно отличать криминальный перевод от ошибочного легального. Это ложится в обоснование актуальности и в постановку задачи.
Для второй главы проектируете антифрод-модуль. Не нужно строить систему уровня Сбера — достаточно спроектировать контур, который анализирует входящие переводы по СБП и присваивает им риск-скоринг. В третьей главе проводите тестирование на синтетических данных и считаете метрики качества. Именно такой формат работы — анализ → проект → эксперимент — считается самым защищаемым.
| Раздел | Что берём из кейса | Как оформляем |
|---|---|---|
| Глава 1. Анализ | Описание дроп-схем, требования к антифрод-системам, классификация методов возврата | Схема угроз, сравнительная таблица аналогов, обоснование выбора архитектуры |
| Глава 2. Проектирование | Модуль скоринга переводов, интеграция с СБП, сценарий отката | UML-диаграммы: sequence, activity, компонентная схема C4 |
| Глава 3. Тестирование | Датасет с легальными и подозрительными переводами, оценка точности и полноты | Confusion matrix, Precision/Recall, ROC-кривая, выводы об эффективности |
Суть инженерной задачи — отличить «плохой» перевод от случайного. Случайный перевод — это когда родственник ошибся номером или сумма ушла на незнакомый счёт. Криминальный — когда злоумышленник специально кладёт деньги на карту дропа, чтобы потом снять их или перевести дальше. Разница часто лишь в паттерне поведения.
Постройте диаграмму последовательности для двух сценариев. В первом — перевод от обычного отправителя, во втором — от того, кто уже вносил похожие кредиты другим дропам. Ключевой элемент — очередь событий, куда поступают данные о переводе: сумма, время, частота операций по счёту, атрибуты отправителя. Дальше событие уходит в риск-скоринг.
// Псевдокод риск-скоринга входящего перевода по СБП
score = 0
if transfer.amount > threshold:
score += 30
if sender.history.risk_events > 0:
score += 40
if recipient.is_new_drop_candidate():
score += 20
if transfer.frequency > 5 per hour:
score += 10
if score > 60:
approve_refund()
else:
notify_user_with_delay()Код не должен быть продакшен-уровня, но обязан показывать логику. В пояснительной записке укажите: используется скоринг с весами, пороговое значение подбирается эмпирически. Достаточно, — это уже демонстрация системного подхода, а не «игрушечного» скрипта.
Для защиты достаточно трёх видов диаграмм:
Если в вузе не требуют строгих нотаций, можно ограничиться BPMN для бизнес-процесса и обычной схемой архитектуры для ИТ-составляющей. Главное — не рисовать «сферического коня в вакууме», а привязать каждый блок к реальной функции из текста статьи.
Формулировка темы должна звучать академично, но с инженерным акцентом. Например: «Разработка модуля автоматизированного возврата денежных переводов по СБП на основе скоринга рисков». Это практико-ориентированная тема, которая читается как полноценная НИР, а не как реферат.
Цель — разработать модуль, который минимизирует время возврата и снижает долю ложных срабатываний. Задачи: анализ предметной области, проектирование архитектуры, разработка алгоритма скоринга, практическое тестирование. Цель и задачи должны зеркалить структуру глав — это важный момент при проверке на нормоконтроль.
Актуальность легко обосновать ссылкой на статью: банки уже решают проблему, значит, задача не надуманная, а востребованная. Рекомендую процитировать новость в первой главе и указать, что сервис Сбера — это индустриальный пример, а ваша работа — попытка воспроизвести и проанализировать подобный механизм в учебном контуре.
Классическая ошибка — считать только точность (Accuracy). На антифроде это даёт ложное чувство успеха: если мошеннические переводы занимают 2% выборки, модель, которая всегда говорит «здесь всё чисто», покажет точность 98%, но будет бесполезна. Поэтому используйте более честные метрики.
Для диплома достаточно трёх показателей:
Если делаете упор на временные характеристики, добавьте метрику MTTR (Mean Time To Refund) — среднее время между поступлением перевода и инициацией возврата. Это сблизит вашу работу с требованиями ISO/IEC 25010 в части производительности и надёжности.
Никто и не ждёт реальных данных. Генерируете синтетический датасет: N записей с признаками «сумма», «количество переводов за час», «флаг подозрительного отправителя», «результат проверки». Так и напишите в работе: данные синтетические, потому что реальная банковская информация относится к коммерческой тайне. Это плюс, а не минус — вы показываете понимание ограничений.
Для модели — Python (pandas, scikit-learn). Для симуляции API — FastAPI или Flask. Для хранения — SQLite или PostgreSQL. Никакого хайпа. Комиссия оценит, когда вы уверенно владеете базовыми инструментами, а не перечислили десять модных фреймворков.
Если в вузе действует ГОСТ по информационной безопасности — укажите его. Универсально подойдут ГОСТ 34.601-90 (стадии создания автоматизированных систем) и ГОСТ Р ИСО/МЭК 12207 (жизненный цикл ПО). Не нужно слепо копировать перечень — читайте, что реально относимо к вашей задаче.
Достаточно одного аккуратного файла с реализацией скоринга и тестами. Код в пояснительной записке не должен копировать приложение целиком — выносите в приложения листинги ключевых функций. Объём кода не является метрикой качества, качество — это работающие сценарии и метрики.
Ошибка 1. Путаница между анализом и проектированием. Студенты пишут «я проанализировал» там, где обычный обзор литературы. В вашем кейсе анализ — это разбор сегмента дроп-переводов и выявление атрибутов, по которым перевод можно счесть криминальным. Проектирование — это уже архитектура и нотации.
Ошибка 2. Игнорирование ложных срабатываний. Если сервис будет возвращать каждый подозрительный перевод, он заблокирует и легальные транзакции. Обязательно включите в работу сценарий, когда система ошибается, и механизм ручной верификации.
Ошибка 3. Слишком большой объём теоретической главы. На фоне статьи про Сбер легко уйти в описания всех видов мошенничества. Но комиссия ждёт практику: одна глава теории максимум, остальное — инженерия.
Источник: Злоумышленников щелкнули по носу. Заработал новый сервис защиты россиян от криминальных входящих переводов (опубликовано 2026-03-18)