Развитие цифровой банковской платформы «Окто Банк»

«Окто Банк» развивает цифровую финансовую экосистему, в которой одновременно работают классические банковские сервисы, карточные продукты, микрофинансовые инструменты, трансграничные платежи и решения, связанные с криптопродуктами.

Для такого продукта недостаточно просто добавлять новые функции. Любое изменение затрагивает сразу несколько уровней инфраструктуры: мобильное приложение, backend, АБС, платёжные шлюзы, антифрод-системы и внешние финансовые сервисы.

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

В рамках проекта мы подключили команду из 11 специалистов:

— 4 Java-разработчика отвечали за backend и бизнес-логику;

— 2 Flutter-разработчика развивали мобильный клиент;

— 2 QA-инженера занимались функциональным, интеграционным и нагрузочным тестированием;

— 2 аналитика работали с требованиями и бизнес-логикой;

— 1 DevOps-инженер отвечал за инфраструктуру, CI/CD и процессы поставки.

Таким образом, проект охватывал полный цикл разработки — от анализа требований и проектирования архитектуры до релиза, мониторинга и дальнейшей поддержки.

Что нужно было решить

Основной фокус работы можно разделить на три направления.

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

Второе — безопасность. Для финансового сервиса критичны управление сессиями и токенами, контроль операций, антифрод-механизмы, аудит действий и соответствие требованиям AML/KYC.

Третье — стабильность. Карточные операции и платёжные сценарии должны продолжать работать даже тогда, когда параллельно меняется backend, мобильное приложение или одна из внешних систем.

В результате проект объединил разработку нового функционала, интеграционные работы, техническую поддержку и устранение инцидентов в едином процессе.

1. Расширили функциональность платформы

Одним из направлений стала работа с банковскими и платёжными сервисами.

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

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

Дополнительно была разработана логика:

— учёта комиссий в АБС;
— управления операционными лимитами;
— контроля пользовательских сессий;
— отзыва токенов;
— аудита критически важных операций.

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

2. Перестроили подход к безопасности

Для банковского продукта безопасность нельзя рассматривать как отдельный этап после разработки.

Поэтому соответствующие требования учитывались ещё на этапе проектирования: определялись правила работы с токенами, сессиями, OTP, критическими операциями и внешними интеграциями.

Для контроля доступа реализовали Session Management и Token Revocation. Критические действия дополнительно фиксировались в audit-логах.

В процессе тестирования использовались SAST/DAST-проверки, интеграционные и end-to-end сценарии, а также отдельные проверки авторизации и механизмов отзыва токенов.

3. Сохранили работоспособность действующих сервисов

Параллельно с разработкой нового функционала команда продолжала поддерживать существующую банковскую инфраструктуру.

В зоне ответственности оставались карточные операции VISA, HUMO и UZCARD, взаимодействие мобильного приложения с АБС, платёжные шлюзы и административная панель приложения.

Отдельное направление — адаптация системы под изменения регулирования, включая требования AML/KYC.

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

Организация разработки

Работу выстроили как последовательный цикл, который можно масштабировать под разные банковские задачи.

Сначала аналитики собирали требования, ограничения и зависимости между системами. На этом этапе формировались пользовательские сценарии, API-зависимости и карта рисков.

Затем команда переходила к архитектурному проектированию: создавались API-контракты, ER-диаграммы, sequence diagrams и архитектурные решения.

После этого требования переводились в backlog. Для задач определялись оценки, владельцы и критерии приёмки, а QA заранее формировали тест-план.

Разработка велась одновременно на backend и frontend. Java-команда отвечала за API и бизнес-логику, Flutter-разработчики — за пользовательскую часть мобильного приложения, DevOps — за окружения и процессы поставки.

Перед production-релизом функциональность проходила несколько уровней проверки: unit, integration, E2E, нагрузочные и security-тесты.

Для снижения рисков при выпуске использовались контролируемые сценарии деплоя, включая canary/blue-green подходы, транзакционные миграции БД, rollback-сценарии и обязательные smoke-тесты после релиза.

Поддержка и работа с инцидентами

Отдельно выстроили процесс сопровождения уже работающей системы.

Все обращения проходили через триаж: команда определяла тип задачи — ошибка, доработка или регуляторное изменение — и назначала соответствующий приоритет и SLA.

Для небольших изменений использовались регулярные weekly/biweekly-релизы, CI/CD и feature flags. Это позволяло выпускать изменения небольшими порциями и при необходимости быстро отключать отдельную функциональность.

Для инцидентов использовалась пятиступенчатая схема:

обнаружение → классификация → выбор способа исправления → тестирование и релиз → post-mortem.

После серьёзных инцидентов команда проводила RCA, фиксировала корневую причину и обновляла runbook, чтобы снизить вероятность повторения проблемы.

Контроль качества

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

— доля успешно завершённых транзакций;
— среднее время ответа API;
— количество P0/P1-инцидентов;
— MTTR;
— время вывода регуляторных изменений в production;
— точность расчёта комиссий;
— покрытие критических модулей unit- и integration-тестами.

После релиза команда продолжала отслеживать систему в усиленном режиме: сравнивала новые показатели с baseline, контролировала ошибки и производительность, проводила регрессионное тестирование и формировала план дальнейшей оптимизации.

В результате проект получил не только новые банковские функции, но и более устойчивый процесс развития цифровой платформы.

Ключевые результаты:

— реализованы микрозаймы с расчётом процентных ставок;
— добавлена поддержка криптокарт и соответствующей логики управления;
— реализованы трансграничные и валютные операции;
— подключена государственная антифрод-система;
— расширено взаимодействие с АБС и платёжными шлюзами;
— реализованы механизмы управления сессиями, лимитами и отзыва токенов;
— обеспечена поддержка VISA, HUMO и UZCARD;
— система адаптирована под актуальные требования AML/KYC;
— стабильность и качество существующих сервисов повышены;
— количество инцидентов и ошибок удалось сократить на 35%.