Привет, Хабр!
Типичная картина ИТ-хакатона: команды тратят время не на продукт, а на борьбу с инфраструктурой. Документация есть, API есть – а собрать реальный сценарий нельзя: балансы не сходятся, переводы не оставляют следов, ответы статичные или ошибочные.
На пятом юбилейном API-хакатоне мы решили сделать иначе – собрать песочницу, которая ведёт себя как настоящий банк. Даже не один, а содружество трёх банков с клиентами, продуктами и межбанковскими сценариями. В результате появились реальные мультибанковские прототипы и ~1.5 млн вызовов API за месяц.
Меня зовут Александр Галкин, я занимаюсь открытым банкингом и открытыми API. В статье расскажу, как за несколько выходных собрать такую инфраструктуру, какие компромиссы неизбежны, почему на стенд обрушились массовые атаки, и как ИИ-ассистенты меняют сами хакатоны.
Благодарности
Перед погружением в историю, отдельно хочется отметить команду организаторов хакатона: сильную рекламную кампанию, понятный онбординг для команд, слаженную работу организаторов и выстроенные коммуникации на всех этапах. Площадка для экспертной оценки позволила глубоко и предметно разбирать решения команд, а финал стал логичным и достойным завершением всей этой работы.
Далее в статье я буду говорить исключительно о своём треке и выводах, сделанных на его примере.
Проблема хакатонов: доступ к реальной инфраструктуре
Участникам почти всегда нужна не документация и не витрина методов, а возможность собрать цепочку сценариев: авторизация → получение счетов → работа с транзакциями → перевод → повторная проверка баланса → обработка ошибок.
Но дать «тестовую» банковскую инфраструктуру извне почти всегда сложно: безопасность, сети, юридические ограничения. Поэтому на хакатонах появляются компромиссы:
статичные заглушки вместо данных, которые меняются от действий пользователя;
«песочница», которая не держит финансовую логику (можно «создать деньги», переводы не оставляют следов, баланс не сходится);
валидация и ответы расходятся со спецификацией – команды тратят время на угадайку и костыли;
в итоге сценарии превращаются в «фронт рисует, бэк выдумывает».
И в какой-то момент становится ясно: участники соревнуются не в продукте, а в умении обойти ограничения стенда.
Как всё начиналось (2020): «идея на хакатон» внезапно становится проектом
Моя история с хакатонами началась в 2020 году. В банке собирали идеи для хакатона MORE.Tech, и одна из моих идей оказалась слишком «живой»: мобильное приложение, которое по камере распознаёт автомобиль, показывает карточку авто, подбирает предложения и помогает подать заявку на кредит. Оказалось, что предлагать идеи бывает рискованно: иногда их действительно просят реализовать.
Деваться некуда – вовлекаю стажёра и архитектора, брейнштормим. В итоге развернули инфраструктуру в облаке, подняли API‑шлюз, который на тот момент парсил запросы к найденным API у интернет‑банка, и сделали модель распознавания автомобилей. Датасет собирал буквально «на ходу»: ездил на моноколесе и фотографировал машины с разных углов по кругу.
Собрали предметников из автокредитования, дизайнеров, бизнес‑кураторов, поддерживали команды. Мы тогда выложились на максимум — и с первого подхода получилось взять высокую планку. Стажёра, кстати, по итогам года отдельно отметил CDTO.
2021–2024: заглушки, «витрины API» и возвращение к реальности
В последующие годы хакатон выделился в отдельный «API‑бренд» с ежегодным треком «создание продуктов на основе API». Но повторилась типичная история: каждый год перед сезоном внезапно становилось понятно, что «хакатону быть», а на подготовку – считанные недели. Команда и инфраструктура менялись, контекста не накапливалось. При этом набор API со временем расширялся, но за ними оказывались не сервисы с бизнес‑логикой, а статические заглушки. Выглядит богато, а сценарий всё равно не собирается.
Формально участникам показывали, какие методы существуют, но:
по статике нельзя продемонстрировать вариативные сценарии;
часть ответов не проходила жёсткую валидацию на шлюзе;
реальные пользовательские цепочки распадались.
Как следствие, команды часто переставали вызывать API и писали свои заглушки под интерфейс.
В 2024 году я попробовал это исправить «малой кровью»: сделал динамические заглушки (вариативные ответы в рамках диапазонов) и настроил автодеплой через GitHub Actions. Участники видели репозиторий, могли предлагать правки через pull request, а изменения выкатывались по кнопке подтверждения от админа.
В идеале хотелось, чтобы участники могли приносить в песочницу свои API/сервисы и тем самым постепенно обогащать её новыми финансовыми сценариями.
И примерно в то же время случилось важное: мы показали реальный пилот мультибанка на Финополисе – когда клиент видит счета и транзакции из другого банка в одном интерфейсе.
Контекст: зачем банкам «открытость»
Кажется парадоксом: банк делится данными (с согласия клиента) с другими банками – ведь данные ценны, и клиент может уйти.
При этом движение в сторону открытых API становится неизбежным: требования регулятора, стандарты, расширение круга участников и сценариев. Конкуренция смещается из «у кого больше данных» в «кто лучше превращает данные в сервис».
На картинке ниже — схематично пересечение клиентских баз трёх банков. Конкуренция в первую очередь за «пересечение», но и за то, кто станет для клиента основным финансовым интерфейсом.
Это конкуренция за счёт:
продуктов (где выгоднее и полезнее – там и откроют);
интерфейса (где удобнее – туда и вернутся);
«цифрового советника», который проанализирует данные и подскажет лучший вариант под цели клиента.
2025: юбилейный год и ставка на реализм
Летом 2025 года мы довольно рано начали обсуждать концепцию и треки. В этот период я ненадолго выпал из рабочего ритма, находясь в долгожданном отпуске.
В один из дней мне написали с вопросом, не осталось ли у меня идей или материалов о том, как сделать трек интереснее. Немного отдохнув, я набросал концепцию, в которой участники строят мультибанковские приложения поверх нескольких эмуляторов банков, максимально приближённых к реальности: с тестовыми клиентами, продуктами, транзакциями и межбанковскими сценариями, где согласия — это не формальная «галочка», а полноценная часть процесса.
Плюс – возможность для команд при желании развернуть свой банк на основе шаблона, кастомизировать его, а также предоставить свои API/сервисы и подключить их к экосистеме (как в настоящем открытом банкинге). В идеале – на финале сделать симуляцию «нескольких лет рынка»: за 5 минут ИИ‑агенты в роли «клиентов» прогоняют набор сценариев и операций, чтобы сравнить, чей сервис/банк по итогу окажется реально лучше.
На следующий день пришёл короткий ответ: концепцию поддержали. Это дало зелёный свет идее - и одновременно обозначило следующий шаг: понять, как превратить эту схему в работающую инфраструктуру после возвращения из отпуска.
Как собрать «космолёт» за пару выходных
До хакатона оставался месяц. При интенсивной загрузке по основным рабочим задачам и подготовке к очередному Финополису время и ресурсы фактически сводились к нескольким вечерам и паре выходных.
При этом у меня был определённый багаж: опыт пет-проектов с VibeCoding, курс архитектора ПО и понимание того, как большие модели работают в реальных задачах. Это позволило решиться на реализацию песочницы для мультибанковских приложений в крайне сжатые сроки - по сути, в одиночку.
Решение было идти итерационно, версия за версией наращивать функционал. Не пытаться выкатить всё сразу (большой контекст легко теряет нить), а строить минимум, запускать, доращивать.
Роль ИИ‑ассистентов
Очень вовремя Anthropic расширила контекстное окно Claude Sonnet 4 до одного миллиона токенов – это позволило держать большую часть проекта в контексте модели: код, схемы БД, документацию, историю решений. У меня уже был опыт работы с Opus 4.1 в пет‑проектах, я знал цену (в прямом смысле) и понимал, на что иду.
Да, получилось недёшево, но если сравнивать с тем, сколько стоит работа senior full stack разработчика на фрилансе – выхлоп оказался в несколько раз дешевле и быстрее. ИИ здесь работал как «напарник»: ускорял рутину, помогал держать контекст, но финальные решения, архитектура и ответственность – всё на мне.
Архитектура как компромисс: между реализмом и скоростью старта
Я начинал рисунки С4 с «идеальной картины» открытого банкинга: оператор среды, JWKS, PKI, TLS‑proxy, сложный OIDC‑зоопарк, инфраструктурные прокси – всё, что правильно по учебнику. Помогло, что АФТ (Ассоциация ФинТех) публикует спецификации открытого банкинга в открытом доступе – их можно было «скормить» модели, и она хорошо держала контекст стандартов.
Но быстро стало ясно, что на хакатоне это убьёт первые несколько дней: участники будут настраивать окружение, разбираться с сертификатами и OAuth‑флоу, а не строить продукт.
Поэтому пошли развилки и компромиссы. Очень хотелось, чтобы участники познакомились с техническими аспектами открытого банкинга, но так, чтобы это не усложняло работу и не съедало время на отладку. В итоге я оставил ключевые идеи, но упростил «обвязку».
Самыми важными решениями стали:
Федерация из нескольких банков. Один шаблон кода банка, но отдельные контуры и данные – чтобы мультибанк был про интеграцию нескольких независимых участников, а не про разные ответы одного сервиса.
Реестр (Directory Service). Информация о зарегистрированных банках, их метаданных, а также возможность зарегистрировать новый банк в экосистему.
Согласия только там, где они реально нужны. Межбанковские вызовы – да; внутри банка – обычная работа клиента.
Финансовая целостность. Балансы сходятся, операции оставляют транзакции, проверки средств происходят «в моменте» – без этого любая демонстрация выглядит фальшиво.
Готовый фронт «из коробки». У каждого банка есть простой UI для быстрого знакомства с функционалом: счета, транзакции, подтверждение согласий. При желании его можно кастомизировать под свои сценарии.
Быстрый старт (bank-in-a-box). Банк можно развернуть четырьмя командами Docker и сразу подключить к экосистеме.
Понятное API + интерактивная документация. Одинаковая логика валидации, понятные коды ошибок и OpenAPI/Swagger «живьём» – чтобы быстро разобраться в методах и не тратить время на отладку.
Упрощённая аутентификация. Вместо полного OIDC – практичная схема для хакатона: быстрый вход, JWT‑токены и минимум шагов.
Конкретные упрощения по сравнению с production OpenBanking:
Компонент | Стандарт OpenBanking | Реализовано в песочнице |
|---|---|---|
MTLS | Обязателен | Не требуется |
ЭЦП | ГОСТ криптография | RSA-2048 |
OAuth2 | Authorization Code Flow | Упрощённый (username/password → JWT) |
Эти и другие компромиссы позволили участникам сразу начать работать с API, не тратя дни на настройку сертификатов и криптографии.
Тестовые данные: без них не работает «ощущение банка»
Чтобы участникам было интересно «играть в банкиров», нужны данные, которые ведут себя как настоящие: разные профили клиентов, разные продукты, живая история операций. Поэтому я собрал несколько сегментов (сотрудники, VIP, предприниматели, бизнес/юрлица, студенты, пенсионеры), наполнил банки продуктами и сгенерировал транзакции с реалистичными паттернами (география, MCC‑коды, названия мерчантов и т.д.). На старте стенда получилось 3 банка в облаке с работающими базовыми API , 9300 тестовых клиентов и ~1 млн транзакций.
Доработки «по живому»
Дальше пошли итерации. Через пару дней после старта я занялся переводами – и они очень вовремя заработали к Хэллоуину. Студенты и отдел маркетинга любят тематические истории, и мы не упустили момент.
Следующим шагом стало «упаковать» шаблон банка: убрать лишнее, сделать границы понятнее и подготовить основу для встраивания в экосистему. Шаблон я вынес в отдельный репозиторий: https://github.com/GalkinTech/bank-in-a-box.
Понимал, что участники хакатонов сейчас продвинутые в использовании ИИ‑ассистентов: дать им «базу», которую можно быстро поднять и модифицировать, – максимально эффективно. Правда, воспользовались этим не все (то ли не сразу стало заметно, то ли проще писать с нуля), но в финале, по стилю кода и интерфейсов, ИИ‑генерация часто считывалась сразу: характерные смайлики, академичные и многословные коммиты…
Завершающей итерацией стали API по оставшимся продуктам и «онбординг» под сценарии: подача заявки, скоринг и т.д.
Итоговые цифры (в конце хакатона)
~32 000 строк Python‑кода
437 коммитов (feat – 104, fix – 124, docs – 82, security – 10)
~1.5 млн вызовов API участниками за хакатон
Claude sonnet 4.5 беспощадно тратит токены на написание избыточной документации, даже когда в правилах ему явно это запрещаешь делать.
Неожиданный поворот: атаки на стенд
Помимо продуктового трека, на хакатоне были и треки по безопасности. И случилась типичная человеческая ошибка: участникам безопасностных треков дали адрес моего стенда, а не отдельного стенда с «боевым» продуктом ГОСТ-API‑Gateway.
В итоге учебную песочницу начали атаковать как реальную: сканирование, попытки SQL‑инъекций, XSS, «прощупывание» на RCE и другие классические техники.
Что пытались эксплуатировать:
- SQL Injection: ' UNION SELECT NULL--, WAITFOR DELAY, DROP TABLE
- XSS: <script>alert(1)</script>, <iframe src=javascript:alert('XSS')>
- SSTI (Server-Side Template Injection): {{5584*7323}}, {system("sleep 15")}
- DoS: попытки вызвать pg_sleep() и зависание БД
- Path Traversal и другие классические векторы
Спасибо SQLAlchemy ORM (параметризованные запросы), JSON API (без рендеринга HTML) и базовой валидации. Но один вектор «прошёл»: через endpoint регистрации участников (DCR API) удалось загрязнить БД вредоносными именами команд. Пришлось:
Написать скрипт для очистки (удалили 108 фейковых участников и 1,471 вредоносных логов)
Добавить строгую валидацию входных данных
Настроить rate limiting в Nginx (50 req/min для API, 5 req/min для login)
Внедрить geo-блокировки и honeypot-пути для сканеров
Самый забавный момент: к финалу команды по безопасности попросили доступ к API, чтобы демонстрировать свои наработки на этом стенде.
Что я вынес из этого эпизода:
публичный = под атакой с первой минуты – защиту нужно закладывать сразу, а не после инцидента;
даже учебный стенд нужно проектировать как «production-ready» (лимиты, логирование, наблюдаемость);
input validation должна быть везде по умолчанию, а не «потом допилим»;
периметр и адреса – такая же часть продукта, как API;
«реалистичность» привлекает не только продуктовые команды, но и сканеры со всего мира.
Любой пет‑проект, опубликованный в интернете, мгновенно попадает в поле зрения автоматизированных сканеров и интерес недоброжелателей.
Результаты: что построили команды
Самая приятная часть – посмотреть, что команды сделали с этой инфраструктурой, когда она перестала мешать и начала помогать. Ниже – несколько работ трека «мультибанк», которые запомнились сильнее всего.
1 место – SoloTech
единый финансовый профиль: продукты из разных банков «в одной картине»;
интеллектуальные сценарии поверх транзакций (рекомендации, риски, налоговые вычеты/отчёты).
2 место – Синтакс
автоматизация налоговой отчётности для самозанятых;
путь «от транзакций к чекам» с проверками и автозаполнением.
3 место – Maestro API
агрегатор мультибанковских данных с ИИ‑чатом;
BDUI‑подход: виджеты/представления под разные задачи (портрет, советы, разбор транзакций);
MCP-сервер банковских API, что в свою очередь потенциально помогает отвязаться от обратной совместимости изменений в API. (MCP – Model Context Protocol)
Спецноминации
PHOENIX
Мультибанк, который пытается гарантировать успешную оплату даже если на выбранном счёте не хватает средств – за счёт автоматизированного перевода с других счетов «в момент оплаты».
Киберлига - Семейный мультибанк
Другие идеи, которые встречались у команд
агрегатор и советник по кэшбэк‑предложениям (выбор оптимальных категорий/карт);
мониторинг банковских продуктов (поиск «подводных камней»);
поиск выгодного момента покупки валюты;
автоматическое ночное перераспределение средств для повышения доходности без потери доступности;
ассистенты: брокерские/криптосценарии, менеджерские консультации;
виртуальные счета (виртуальная группировка средств без изменения их реального нахождения);
и ещё много вариаций на тему «как сделать мультибанк полезным, а не просто витриной данных».
Выводы и планы
Пятый юбилейный хакатон показал, что предоставление участникам реалистичной инфраструктуры вместо статических заглушек меняет всё. Участники смогли сосредоточиться на создании продуктов, а не на борьбе с API, и результаты это подтверждают.
Ключевые инсайты:
Реалистичные тестовые данные критичны для качественных прототипов
Шаблоны и инфраструктура as code сильно ускоряют старт
ИИ‑ассистенты меняют скорость разработки на хакатонах
Мультибанкинг открывает огромное поле для инноваций
Как ИИ меняет хакатоны
Самое заметное изменение за последние годы – скорость. Команды с помощью промптов собирают функционал за считанные часы: от идеи до работающего прототипа – один вечер.
Но у этой скорости есть обратная сторона: появляется соблазн брать объёмом фич, а не качеством. Хочется, чтобы в финале выигрывала не «самая длинная лента возможностей», а проработанные сценарии, устойчивость, понятные ошибки и демонстрация того, что прототип действительно «живёт» и востребован.
При этом самое ценное на хакатоне по‑прежнему рождается не из «ускоренной генерации», а из инновационности и нестандартных решений: сильной продуктовой гипотезы, неожиданной механики, хорошей сборки сценария. Это то, что ИИ пока не умеет «придумать за команду» – он скорее помогает быстрее разработать и запустить.
Возможно, продуктовые хакатоны со временем превратятся в мини‑акселераторы: за месяц команды при поддержке экспертов запускают и проверяют гипотезы на реальных пользователях, смотрят метрики и делают выводы.
А со стороны инфраструктуры задача – ещё сильнее снизить порог входа и упростить интеграцию. Возможно, стоит давать не только «бетонированные API», но и готовые прокси‑обвязки – например, MCP‑серверы (Model Context Protocol) – чтобы ИИ‑агенты могли «общаться» с банковской инфраструктурой через гибкого посредника. Бонус: обвязка живёт отдельно от API, и изменения меньше ломают интеграции.
Вместо эпилога
Буду рад комментариям и предложениям – особенно если вы делаете свои прототипы на основе моего шаблона. В идеале – предлагайте улучшения через GitHub (issues / pull requests), чтобы это развивалось «снежным комом». Репозиторий с шаблоном банка: https://github.com/GalkinTech/bank-in-a-box.
Хочется верить, что платформа, на которой прошёл этот хакатон, со временем переродится в постоянную инфраструктуру для финтех‑экспериментов. А может, увидимся на хакатоне в 2026 году.
Спасибо!
