Разработка и поддержка комплексных банковских сервисов для «Окто Банк»

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

Цель проекта

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

Задачи

- Внедрить новые модули и интеграции с ключевыми системами (антифрод, АБС, платёжные шлюзы).

- Обеспечить бесперебойную работу карточных операций (VISA, HUMO, UZCARD).

- Реализовать функционал микрозаймов и трансграничных платежей.

- Обновить архитектуру управления лимитами, сессиями и токенами.

- Обеспечить гибкую поддержку и развитие существующего мобильного приложения.

- Своевременно адаптировать платформу под изменяющиеся регуляторные требования.

1. Внедрение нового функционала

- Интеграция с государственной системой антифрода для защиты от мошенничества.

- Подключение и настройка взаимодействия с банковскими системами и платёжными шлюзами.

- Реализация трансграничных платежей, включая валютные операции.

- Разработка сервиса учёта комиссий в АБС.

- Внедрение механизма микрозаймов и логики расчёта процентных ставок.

- Реализация системы управления картами, включая криптопродукты.

- Настройка логики управления лимитами по операциям.

- Реализация Session Management для контроля активных пользовательских сессий.

- Разработка Token Revocation — отзыва токенов в целях безопасности.

2. Поддержка существующих систем

- Поддержка карточных операций и интеграций с VISA, HUMO, UZCARD.

- Стабилизация взаимодействия мобильного приложения с АБС.

- Поддержка платёжных шлюзов и обработка операций через операторов.

- Развитие админ-панели мобильного приложения — системы управления контентом, пользователями и аналитикой.

- Доработки под новые регуляторные требования, включая изменения в AML/KYC.

3. Исправление ошибок

- Оптимизация авторизации и идентификации пользователей.

- Устранение ошибок при проведении транзакций.

- Повышение стабильности и отказоустойчивости системы.

Команда проекта

- Backend (Java) — 4 разработчика

- Frontend (Flutter) — 2 разработчика

- QA — 2 тестировщика

- Analytics — 2 аналитика

- DevOps — 1 инженер

Этап A — Discovery / подготовка требований

Цель: собрать все входные данные, бизнес-требования, регуляторные ограничения и технические ограничения.

Участники: 2 аналитика, product owner (представитель банка), 1 старший разработчик (backend), DevOps (консультация).

Действия:

- Интервью с владельцами продукта и стейкхолдерами.

- Сбор нормативных требований (AML/KYC/локальные правила платежей).

- Составление базового сценария пользовательских потоков (user flows) и вариантов ошибок.

- Анализ зависимостей: какие АПИ/сервисы уже есть в АБС, какие понадобится подключить.

- Оценка рисков (безопасность, соответствие регуляторике, внешние SLA).

Артефакты: BRD / Confluence-страница, список API/интеграций, матрица рисков, перечень метрик успеха.

Этап B — Архитектура и проектирование

Цель: утвердить архитектурные решения, контракт API, модель данных.

Участники: backend lead, 1 devops, 2 аналитика, security specialist (если есть), frontend lead (для UX-импакта).

Действия:

- Создать диаграммы компонент и последовательностей (sequence diagrams).

- Определить API-контракты (request/response, ошибки, версии).

- Спроектировать схему хранения данных (БД) — учёт комиссий, кредиты, лимиты.

- Специфицировать требования по безопасности: шифрование, токены, OTP, ревокация токенов.

- Определить требования к SLA/латентности для трансграничных платежей.

Артефакты: API спецификации (OpenAPI), ER-диаграммы, архитектурные решения (ADR), список acceptance-criteria.

Этап C — Планирование и разбиение задач

Цель: подготовить backlog, спринты, критерии приёмки.

Участники: весь состав разработки + QA + аналитики.

Действия:

- Разбить фичу на эпики/задачи в трекере (GitLab/Jira).

- Оценить задачи (story points / часы).

- Назначить владельцев задач.

- Подготовить тест-план: unit, интеграционные, e2e и тесты безопасности.

Артефакты: sprint backlog, test plan, release checklist.

Этап D — Разработка

Цель: реализовать код по спецификации.

Участники: 4 backend (Java), 2 frontend (Flutter).

Действия (backend):

- Реализация API и бизнес-логики (микрозаймы, лимиты, сессии).

- Интеграция с внешними системами (антифрод, АБС, платёжные шлюзы) через адаптеры/агрегаторы.

- Механизмы Token Revocation: таблицы отзыва, обработчики, hook-методы.

- Audit-логирование критичных операций.

Действия (frontend):

- Интерфейсные изменения (UX для микрозаймов, управления картами, ошибок).

- Реализация безопасной авторизации/интерфейсов обработки ошибок.

DevOps:

- Настройка CI/CD пайплайнов, environment (dev/stage/prod).

- Тестовые стенды для интеграции с антифрод и платёжными шлюзами (sandbox).

Артефакты: коммиты, merge requests с описанием, контейнерные образы.

Этап E — Тестирование

Цель: убедиться, что функционал работает корректно и безопасно.

Участники: 2 QA, 2 аналитика (валидация бизнес-логики).

Виды тестов:

- Unit-тесты (разработчики).

- Интеграционные тесты (внешние API).

- E2E тесты (пользовательские сценарии).

- Нагрузочные тесты (особенно для трансграничных платежей).

- Security тесты: SAST/DAST, тесты на токен-ревокацию, тесты на уязвимости в авторизации.

Критерии приёмки:

- Все критичные баги исправлены.

- Процент тестового покрытия по ключевым функциям (оговаривается).

- SLA/latency в рамках спецификации.

Этап F — Деплой и интеграция

Цель: безопасный и контролируемый выпуск в production.

Участники: DevOps, backend lead, релиз-менеджер, аналитики.

Действия:

- Canary / blue-green deployment для минимизации рисков.

- Миграции БД в транзакциях, rollback-скрипты.

- Проверочный прогон smoke-тестов после деплоя.

- Включение мониторинга и алертинга перед релизом.

Артефакты: release notes, миграционные скрипты, откатные планы.

Этап G — Мониторинг, поддержка и оптимизация

Цель: отслеживать поведение сервиса и быстро реагировать на инциденты.

Участники: DevOps, 4 backend (on-call rota), QA (регрессионные тесты).

Действия:

- Настройка дашбордов (latency, error rates, TPS, success rates платёжных операций).

- Регулярные ретроспективы и планирование оптимизаций.

- Поддержка FAQ/Runbook для оператора службы поддержки.

KPIs: % успешных транзакций, MTTR (среднее время восстановления), количество инцидентов.

Этап A — Триаж и приоритизация заявок

Цель: быстро классифицировать запросы (bugfix, enhancement, regulatory).

Участники: аналитики, product owner, backend lead.

Действия:

- Ежедневный stand-up triage.

- Определение SLA по типам заявок.

Артефакты: приоритизированный backlog, SLA-матрица.

Этап B — Непрерывная разработка и релизы

Цель: регулярные безопасные релизы мелких изменений.

Действия:

- Малые релизы (weekly/biweekly) через CI/CD с автоматическими тестами.

- Feature flags для включения/выключения функционала без деплоя.

- Документирование изменений в админ-панели и обновление руководств.

Этап C — Регуляторные доработки

Действия:

- Быстрое проведение impact analysis при изменении регуляторной базы.

- Приоритетное выделение задач.

- Координация с юридическим отделом и службой безопасности.

Критерии приёмки: соответствие чек-листам регулятора + аудит логов.

Процесс реагирования (Incident Management)

Шаг 1 — Обнаружение: мониторинг и алерты, тикет от поддержки.

Шаг 2 — Триаж: аналитик/QA классифицирует (P0/P1/P2).

Шаг 3 — Стратегия исправления: горящий фикс на проде (hotfix) или плановый багфикс.

Шаг 4 — Исправление и тест: разработчик делает PR → ранние smoke-тесты → deploy в canary → наблюдение.

Шаг 5 — Post-mortem: разбор инцидента, root cause analysis, запись действий в runbook.

Участники: on-call разработчик, QA, DevOps, аналитик, product owner.

Артефакты: инцидент-репорт, RCA (корневая причина), план предотвращения.

- Доля успешных транзакций (%) — по платежным шлюзам и межбанку.

- Среднее время отклика API (ms).

- Количество инцидентов P0/P1 в месяц.

- MTTR (среднее время восстановления).

- Время от запроса до продакшн-релиза для регуляторных задач.

- Точность расчёта комиссий (сверка с бухгалтерией).

- Покрытие тестами критичных модулей (unit/integration).

- Период наблюдения (observability window) с усиленным on-call.

- Сбор метрик и сравнение с baseline.

- Регрессионное тестирование и план оптимизаций.

- Документирование: How-to, API-guide, change-log, user-facing сообщения (если требуется).

- Ретроспектива и внесение улучшений в процесс.

Повышена скорость проведения операций и стабильность системы.

Реализованы новые банковские продукты, включая микрозаймы и криптокарты.

Уровень инцидентов и ошибок сократился на 35%.

Система стала соответствовать актуальным регуляторным требованиям.

Улучшено взаимодействие пользователей с мобильным приложением и backend-сервисами.