Как выбрать подрядчика для FinTech: 12 вопросов для каждой компании

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

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

1. Какой подтверждённый опыт в регулируемом FinTech у вас есть?

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

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

2. Кто будет отвечать за безопасность, соблюдение требований и риски третьих сторон?

Попросите подрядчика нанести на одну карту активы, участников, данные, средства, границы доверия, способы злоупотребления и обязательства вашей компании, самого подрядчика, поставщиков облачных услуг, обработчиков платежей, служб установления личности и субподрядчиков. Ответ должен различать юридическую ответственность, выполнение контрольных мер, создание доказательств, сотрудничество во время инцидентов и остаточный риск. Для среды платёжных карт определите, какие требования PCI DSS выполняет каждая сторона и как контролируется её состояние. Для финансовой организации в ЕС, на которую распространяется DORA, критичные или важные услуги ИКТ могут требовать оценки риска до заключения договора, ведения реестров, прозрачности субподряда, прав на аудит и доступ, помощи во время инцидентов, возврата данных и проверенных условий выхода.

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

3. Как вы будете проверять продукт и связанные с ним обязательства?

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

Требуйте зафиксированных предположений, критериев приёмки и прослеживаемости требований. Показательный прототип или завершённая сквозная часть продукта должны проверить самый рискованный процесс с реальными поставщиками, формой данных, задержкой, отказами и ручными операциями. Решите, кто отвечает за продукт, толкование требований, окончательное согласование и изменения. Подрядчик должен выявлять противоречия и неизвестные величины, а не механически превращать каждое пожелание в задачу. Исследование успешно, когда оно снижает риск решений и чётко определяет, что не будет создано.

4. Какая архитектура соответствует фактам и почему?

Предложенная архитектура должна учитывать объём и характер операций, требования к согласованности и аудиту, доступность и восстановление, место хранения данных, интеграции, возможности команды, независимость выпусков, границы безопасности, отчётность и полную стоимость эксплуатации. Попросите кандидатов сравнить своё решение хотя бы с одним более простым вариантом. Модульная монолитная система иногда лучше сохраняет целостность операций и скорость изменений, чем преждевременный переход к микросервисам; управляемые услуги могут снизить эксплуатационную нагрузку, но создать ограничения, зависимость от одного поставщика или высокую стоимость выхода.

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

5. Как держать под контролем внешние интеграции и движение средств?

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

Уточните, кто отвечает за отношения с каждым поставщиком и кто может связаться с ним во время инцидента. Там, где это уместно, изолируйте интеграции в отдельных модулях с устойчивыми внутренними договорами, чтобы внешние особенности не распространялись на весь продукт. Не принимайте фразу «мы уже это интегрировали» за доказательство: программные интерфейсы, программы сертификации, коммерческие условия, регионы и поведение поставщиков меняются. Для каждой критичной зависимости требуйте демонстрацию в условиях, приближённых к рабочим, или отдельную задачу по исследованию.

• 6. Кто именно будет выполнять работу? До подписания договора познакомьтесь с руководителями продукта, архитектуры, разработки, качества, безопасности, данных и исполнения. Проверьте выделенное время, место работы, трудоустройство или субподряд, подходящий опыт, язык и пересечение рабочих часов, правила замены, проверку биографических данных там, где она оправдана, и перечень людей с доступом к регулируемым системам или данным.
• 7. Как будут управлять исполнением и изменениями? Попросите описать планирование, доказательства, демонстрации, оценки, зависимости, журналы рисков и решений, контроль выпусков, отчёты о состоянии и прогноз, передачу проблем, изменение объёма и приёмку. Требуйте заранее сообщать плохие новости. Продвижение должно быть видно по завершённым результатам, пригодным к эксплуатации, а не по условным баллам, загрузке людей или уверенным процентам.
• 8. Какие проверки и контрольные меры включены? Свяжите с рисками доказательства модульных, компонентных, интеграционных, сквозных и авторизационных проверок, проверок совместимости интерфейсов, безопасности, переноса, сверки, быстродействия, устойчивости, доступности для людей с инвалидностью и восстановления. Определите среды, данные, независимую оценку, тяжесть дефектов, устранение, ответственность за ложные срабатывания, условия разрешения на выпуск и сохраняемые доказательства.
• 9. Кто владеет продуктом и контролирует его? Чётко закрепите права на исходный код, проекты, документацию, код инфраструктуры, собранные программные материалы, учётные записи, домены, сертификаты, данные, технические показатели и записи решений. Определите лицензии и предшествующую интеллектуальную собственность, обязанности по открытому коду, доступ, форматы выгрузки, передачу прав, право упоминать работу в перечне выполненных проектов, сроки хранения, удаление, передачу дел и право привлечь другую команду.

10. Что входит в цену и из-за чего она может измениться?

Попросите всех кандидатов оценить одинаковый объём работ и одинаковые предположения. В предложении должны быть отдельно указаны исследование, проектирование, реализация, перенос данных, интеграции, среды, облачные ресурсы и лицензии, безопасность и соответствие требованиям, независимое тестирование, сертификация или подключение к поставщику, документация, обучение, запуск, усиленная поддержка после запуска, гарантия, обычная поддержка, поездки, налоги и резерв. Определите обязанности заказчика и расходы на третьих лиц. Низкая цена разработки вводит в заблуждение, если готовность к рабочей эксплуатации позднее оплачивается через запросы на изменения.

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

11. Кто и по каким правилам будет эксплуатировать и поддерживать продукт?

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

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

12. Могут ли прежние клиенты подтвердить работу в сложных ситуациях?

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

Если последствия ошибки значительны, проверяйте утверждения по нескольким источникам. Изучите открытые корпоративные реестры, указанные сертификаты и их объём, доказательства страхования при необходимости, отчёты по безопасности в условиях контролируемого доступа, финансовую и кадровую устойчивость, привлечение субподрядчиков, результаты проверок на санкции и конфликты интересов, а также прямые рекомендации. Уважайте конфиденциальность: ответственный подрядчик не станет раскрывать исходный код, уязвимости, персональные данные или регулируемые доказательства другого клиента ради продажи.

Подходящий подрядчик для FinTech не просто соглашается с требованиями. Он выявляет предположения, доказывает действенность контрольных мер, объясняет компромиссы и защищает способность клиента эксплуатировать и контролировать продукт и при необходимости выйти из сотрудничества.— GARNO.TECH Engineering Team

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

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

Закрепляйте в договоре ответ, а не презентацию. Превратите существенные утверждения в объём работ, названные роли, уровни сервиса, приёмку, права на аудит и сотрудничество, условия субподряда, места выполнения, обязанности по безопасности, помощь во время инцидентов, права собственности, доступ к данным и их возврат, контроль изменений, прекращение, переход и доказательства. Оставьте внутреннего ответственного: передача работы вовне не передаёт ответственности. Подходящий подрядчик делает риски видимыми, предлагает соразмерные меры контроля и оставляет продукт более пригодным к эксплуатации, чем он был до сотрудничества.

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