Выбор IT-подрядчика для банковского сервиса влияет на сроки запуска, устойчивость продукта и способность команды развивать его после релиза. Цена и презентация дают лишь часть картины: важно понять, кто именно будет работать над проектом, как исполнитель обращается с данными и зависимостями, что входит в поддержку и кому принадлежат результаты.
Практичная оценка строится на проверяемых вещах: опыте в регулируемой среде, разборе архитектурных решений, сценариях безопасности и нагрузки, договорных условиях и полной стоимости владения. Например, IT-компания Self — один из вариантов для знакомства с тем, как бизнес-команда представляет свои услуги. При выборе подрядчика такую публичную информацию стоит дополнять предметной проверкой проекта и команды.
Универсального срока или схемы работы для всех банковских продуктов нет. Надёжный процесс начинается с ясного распределения ответственности между банком и исполнителем, а затем проверяется на конкретных сценариях — от интеграции с легаси-системой до передачи кода внутренней команде.
Работа начинается с пользовательских и бизнес-сценариев: кто и зачем использует сервис, какие операции выполняет, что происходит при ошибке или недоступности внешней системы. Затем команда уточняет ограничения банка, требования к данным и интеграциям, формирует архитектуру и план разработки. Если на старте пропустить сценарий отказа, он всё равно проявится — например, когда платёж отправлен, а подтверждение от партнёра задержалось.
Подрядчик может отвечать за проектирование, разработку, тестирование, подготовку к запуску и сопровождение. Банк при этом определяет продуктовые приоритеты, предоставляет доступы и сведения о внутренних системах, утверждает правила работы с данными и принимает решения в своей зоне ответственности. Такое распределение нужно закрепить до начала работ: иначе спор о том, кто должен подготовить тестовый контур или согласовать интеграцию, задержит релиз.
Задачи различаются по типу. При разработке MVP команда проверяет ключевые гипотезы и выпускает минимально необходимый набор функций; при развитии действующего сервиса важны совместимость и безопасное внедрение изменений; интеграционный проект сосредоточен на взаимодействии систем и обработке ошибок между ними. По приведённым в брифе данным ассоциации «Финтех», ориентир для MVP банковского мобильного приложения в 2025–2026 годах — 6–9 месяцев при команде от 15 человек; это ориентир, а не гарантия срока для конкретного проекта.
В регулируемой среде подрядчик помогает реализовать согласованные меры, но не снимает с банка ответственность за соблюдение применимых требований. Для сложного продукта часто подходит выделенная команда (Dedicated Team), которая работает в процессах банка и участвует в планировании, ревью и передаче знаний. Модель «сдал-принял» хуже подходит там, где интеграции и приоритеты уточняются по ходу проекта.
До подписания договора стоит выяснить, как исполнитель защищает среду разработки, управляет доступами и проверяет изменения в коде. Попросите описать процесс проверки зависимостей, устранения найденных уязвимостей и остановки релиза при критичном дефекте. Общего обещания «следуем лучшим практикам» недостаточно: важны роли, инструменты и артефакты, которые можно проверить.
Требования к системе зависят от её назначения, архитектуры и роли участников. В брифе упомянуты ГОСТ Р 57580.1-2017 и уровень защищённости УЗ-2, однако применимость конкретного уровня и процедур нужно проверять для системы и регулируемого контура. До оценки проекта следует сверить актуальные нормы со специалистами банка, отвечающими за безопасность и соответствие требованиям.
Доступ к персональным и платёжным данным нужно ограничивать по принципу минимальной необходимости. Полные данные карты — PAN и CVV — не следует хранить у подрядчика без надлежащего соответствия применимым требованиям; архитектуру стоит проектировать с минимизацией доступа и токенизацией. Для проверки попросите схему потоков данных: по ней видно, какие сведения получает исполнитель, где они обрабатываются и как удаляются после завершения работ.
Интеграция с СБП требует выполнения применимых требований, но состав обязательных мер зависит от схемы интеграции. То же относится к криптографии и средствам защиты: их набор нельзя определять только по названию сервиса. Согласуйте с банком, какие проверки нужны до запуска, кто готовит доказательства выполнения требований и как будет проходить аудит.
Модель Fixed Price удобна, когда границы работ и критерии приёмки достаточно стабильны: стоимость и состав этапа можно закрепить заранее. Если требования часто уточняются, жёсткая фиксация объёма приводит к цепочке согласований и дополнительных оценок. Выделенная команда позволяет менять приоритеты итерациями, но требует от банка участия в планировании и доступности владельцев продукта.
Сравнивать предложения нужно по полной стоимости владения (TCO). В неё входят разработка, инфраструктура, лицензии, мониторинг, поддержка, обновления и передача знаний внутренней команде. В смете могут отсутствовать лицензии на проприетарное ПО, базы данных и инструменты мониторинга; эти расходы стоит выявить до старта, а не после появления первого счёта.
Отдельно оцените расходы на сопровождение и адаптацию сервиса к изменениям требований. В брифе доля до 30% бюджета на ежегодные обновления приведена как ориентир для обсуждения TCO, а не как универсальная норма. Запросите расчёт по сценариям: что произойдёт с затратами, если добавится интеграция, изменится инфраструктура или потребуется независимая проверка.
Сравнивать модели по одному обещанию фиксированной суммы рискованно. Полезнее сопоставить, что включено в каждый этап, как оформляются изменения и какие знания останутся у банка после релиза. Если стоимость поддержки обозначена расплывчато, попросите раскрыть состав работ, тарифы и порядок перехода от гарантийных исправлений к платному сопровождению.
Сравнивайте не только портфолио, но и доказательства того, как команда работает в регулируемой среде. Попросите показать обезличенные артефакты: схему архитектуры, план тестирования, пример документации, описание процесса управления уязвимостями и рекомендации клиентов. Опыт прохождения проверок ЦБ и ФСТЭК может быть релевантнее перечня коммерческих запусков, если проект требует соответствующей подготовки.
| Критерий | Что запросить | Какой риск выявляет проверка | Тревожный ответ |
|---|---|---|---|
| Опыт в регулируемой среде | Роли в проектах и примеры подготовки к проверкам, без раскрытия закрытых данных | Недооценку требований к процессам и документации | Только общие рассказы о коммерческих запусках |
| Система управления безопасностью | Подтверждение области действия ISO 27001 и описание практик разработки | Подмену проверки продукта наличием сертификата | Обещание, что сертификат гарантирует безопасность конкретного сервиса |
| Фактический состав команды | Имена ролей и доступность ключевых специалистов на этапах проекта | Замену представленных архитекторов после подписания договора | Отказ назвать ответственных или закрепить порядок замены |
| Код и документация | Правила доступа к репозиторию, образец документации и условия передачи прав | Зависимость банка от исполнителя после релиза | Передача только собранного продукта без исходников и описания системы |
| Зависимости и поддержка | Порядок контроля библиотек, обработки уязвимостей и расчёт сопровождения | Скрытые риски в открытых компонентах и рост текущих расходов | Нет процесса реагирования или ясного перечня включённых работ |
ISO 27001 может свидетельствовать о формализованной системе управления информационной безопасностью, но не заменяет анализ архитектуры и кода. Проверьте область действия сертификата и попросите объяснить, как процессы применяются к вашей команде и проектной среде. Отдельно уточните, какой стек предлагают и насколько реально поддерживать его силами банка или доступных специалистов.
Показательный тест зрелости — разобрать сценарий обнаружения уязвимой библиотеки: кто её заметит, кто уведомит банк, кто остановит релиз и кто зафиксирует исправление. Ответ с распределёнными ролями и проверяемыми действиями говорит о процессах больше, чем общий перечень сертификатов.
Тревожный сигнал — расхождение между командой на презентации и специалистами, которые приходят на рабочие встречи, или предложение шаблонного решения без оценки банковских процессов. Попросите закрепить ключевые роли в плане проекта и договориться о порядке замены специалистов. Права на исходный код, документацию и другие результаты, а также порядок передачи репозиториев должны быть отражены в договоре.
В договоре и приложениях зафиксируйте границы работ, результаты каждого этапа и критерии приёмки. Уточните, кто получает доступ к репозиториям, когда передаются исходный код и документация, как оформляются права на результат и что происходит при смене состава команды. Если определить эти условия только перед релизом, банк может получить код, который сложно проверить и поддерживать.
Поддержку и гарантийные исправления нужно описать отдельно: какие дефекты устраняют без дополнительной оплаты, как принимают обращения и какие работы относятся к развитию продукта. Уточните период поддержки после запуска, график дежурств и тарифы на задачи, которые не входят в сопровождение. Это помогает заранее увидеть расходы, которые иначе обнаруживаются уже после сдачи проекта.
В брифе целевая доступность банковских сервисов указана как 99,9% и выше, но конкретный SLO или SLA, окно измерения и последствия нарушения согласовываются для проекта. В договоре определите источник данных для измерения, перечень исключений и порядок разбора инцидента. Штрафы сами по себе не предотвращают простой и не гарантируют отсутствия регуляторных последствий.
Перед приёмкой включите независимый аудит безопасности кода и сверку документации с фактической системой. Проверяйте не только прохождение тестов, но и то, может ли внутренняя команда развернуть сервис, отследить ошибку и восстановить работу по переданным инструкциям. Независимая проверка особенно полезна, когда исполнитель одновременно разработал решение и подтверждает его готовность к эксплуатации.
Начните с ограничений и целей проекта: опишите основные сценарии, внутренние системы, чувствительные данные и условия эксплуатации. Не пытайтесь заранее перечислить каждый возможный случай. Требования удобнее уточнять итерациями, сохраняя общий контур и документируя решения, принятые после тестирования.
Затем запросите подтверждение релевантного опыта и проведите техническую сессию с теми, кто будет работать над проектом. Проверьте состав команды, архитектурный подход, безопасность и смету: кто отвечает за интеграции, тестирование, документацию и передачу знаний. Опыт подготовки к проверкам ЦБ и ФСТЭК оценивайте по конкретным ролям и артефактам, а не по одному упоминанию в презентации.
До старта согласуйте этапы, приёмку, SLA, права на результат и порядок работы с изменениями. В смете отдельно зафиксируйте лицензии, инфраструктуру и сопровождение. После этого запустите ограниченный пилот с понятными критериями успеха и независимой проверкой перед передачей в эксплуатацию.
На переговорах задайте вопросы, которые проверяют не общие обещания, а готовность команды к ограничениям проекта:
Короткие ответы на вопросы, которые часто влияют на выбор архитектуры, модели размещения и коммерческие ожидания от проекта.
Готовый продукт стоит оценивать по стоимости адаптации, соответствию внутренним процессам и ограничениям, а также условиям обновления. Разработка с нуля даёт больше контроля над архитектурой и развитием, но требует оценить ресурсы на создание и дальнейшую поддержку. Сравните оба варианта на одном наборе сценариев и включите в расчёт стоимость интеграций, лицензий и зависимости от поставщика.
Возможность зависит от типа данных, модели их обработки, инфраструктуры и требований конкретного контура. Российское облако и инфраструктура иностранного провайдера создают разные правовые и операционные условия; нельзя делать общий вывод по одному слову «облако». До выбора модели проверьте актуальные требования к локализации и защите данных, а также распределение ответственности между банком и оператором сервиса.
Единой фиксированной законом ставки комиссии для всех торговых точек нет: условия зависят от договора, банка, отрасли и параметров обслуживания. IT-подрядчик может предложить технологию или интеграцию, но обещание конкретного тарифа относится к коммерческим условиям эквайера. Проверяйте его в договоре с банком и уточняйте, какие ограничения или дополнительные платежи влияют на итоговую стоимость.
Алгоритм помогает оценивать заявки, если обучен на качественных и репрезентативных данных, но качество модели нужно постоянно контролировать. Изменение состава клиентов или экономической среды может вызвать дрейф модели и ухудшить прогнозы, поэтому важны мониторинг, объяснимость решений и человеческий контроль. Ни модель, ни автоматизация не гарантируют отсутствия дефолтов.