Основатель финтех-проекта без CTO: как выбрать компанию, которая спроектирует, построит и передаст вам платформу

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

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

У меня есть финансирование, но нет CTO. С чего начать?

Привнести в проект техническую экспертизу можно тремя способами. Различаются они в основном тем, кто проверяет работу исполнителя.

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

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

Что должен дать мне этап проектирования архитектуры до того, как будет написан какой-либо код?

Этап проектирования архитектуры должен заканчиваться документами, написанными так, чтобы ваш советник мог их проверить, а вы — в них разобраться:

• Одна страница об объёме работ: какой продукт идёт первым (терминал для ваших клиентов, брокерские системы за ним или биржа), для какого рынка и каких первых пользователей
• Схема системы и всего, к чему она подключается: брокеры или биржи, банки и платёжные провайдеры, проверка личности, поставщики рыночных данных
• Путь одной заявки от экрана клиента до рынка и обратно — с отмеченными риск-проверками и тем, что происходит, когда обрывается соединение
• Что система обязана записывать, как долго и для кого, — исходя из правил вашей лицензии
• Где она будет работать: облачные или серверные аккаунты, открытые на имя вашей компании
• Договоры с третьими сторонами, которые должна подписать ваша компания, и какие из них ждёт разработка
• Первый релиз в письменном виде, включая то, что в него намеренно не вошло
• Открытые риски и оценка по каждому этапу, а не одна цифра на всё

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

Какие лицензии и правила определяют разработку?

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

Регуляторы рассматривают ваши системы как часть заявки:

• В Великобритании FCA просит заявителей «продемонстрировать, что технологии или системы, которые вы будете использовать, готовы к осуществлению регулируемой деятельности, на которую подана заявка». FCA также оценивает, смогли бы вы, «если бы мы выдали вам разрешение сегодня», вести деятельность, на которую подали заявку
• В США брокер-дилер регистрируется в SEC и вступает в саморегулируемую организацию, например FINRA, прежде чем начать деятельность. Стандарты допуска FINRA включают системы связи и системы для операционной работы, которые «в разумной мере обеспечивают непрерывность бизнеса», и «систему учёта, позволяющую Заявителю соблюдать требования к ведению записей на федеральном уровне, уровне штатов и саморегулируемых организаций»
• В ЕС заявка на получение статуса поставщика услуг в сфере криптоактивов должна содержать «техническую документацию по ИКТ-системам и мерам безопасности, а также их описание нетехническим языком». Компания, которая хочет управлять торговой платформой для криптоактивов, должна вдобавок описать правила работы платформы, свою процедуру и систему выявления рыночных злоупотреблений

Сроки у регулятора измеряются месяцами. В руководстве FCA для заявителей, последний раз обновлённом в марте 2026 года, сказано, что полную заявку от такой компании, как брокер, обычно рассматривают в течение шести месяцев, а рассмотрение неполной может занять до двенадцати. По MiFID II — закону ЕС об инвестиционных компаниях — заявителю должны сообщить, выдано ли разрешение, в течение шести месяцев после подачи полной заявки. По MiCA — регламенту ЕС о криптоактивах — надзорный орган проверяет полноту заявки в течение 25 рабочих дней и принимает решение в течение 40 рабочих дней с момента получения полной заявки, приостанавливая отсчёт не более чем на 20 рабочих дней, пока ждёт ответов на свои вопросы. Правила FINRA позволяют заявителю обратиться на уровень выше, если решения нет через 180 дней после подачи или к более позднему сроку, согласованному в письменной форме.

Правила определяют и то, что система хранит. Инвестиционная компания в ЕС обязана вести записи обо всех своих услугах, деятельности и сделках, «достаточные для того, чтобы компетентный орган мог выполнять свои надзорные задачи», и хранить записи звонков и электронной переписки по заявкам клиентов пять лет, а по требованию органа — до семи. Такие требования определяют, как хранятся данные, с самого первого проекта архитектуры.

Как проверить, что компания действительно доводила финтех-системы до прода?

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

• Проверьте клиента сами. Если компания говорит, что построила платформу для регулируемого клиента, открытые реестры покажут, есть ли у этого клиента разрешение регулятора: в США — BrokerCheck от FINRA, в Великобритании — реестр финансовых услуг FCA (Financial Services Register), в ЕС — реестр ESMA, где перечислены получившие разрешение поставщики услуг в сфере криптоактивов
• Позвоните клиенту из рекомендаций сами, без представителей компании на линии, и спросите, что сломалось после запуска и как компания с этим справилась
• Возьмите советника на показ системы, чтобы он задал вопросы, которые не можете задать вы
• Если компания говорит, что инженеры, построившие ту систему, будут работать над вашей, впишите их имена в договор

Чётко определите, какой опыт засчитывается. И платёжное приложение, и торговую платформу называют финтехом, но ломаются они по-разному. Для торгового или брокерского продукта просите показать системы, в которых заявки по пути на рынок проходят через код этой компании.

Что должно быть в договоре о коде, аккаунтах и передаче?

Оплата кода сама по себе не делает его вашим. В Великобритании в руководстве Ведомства по интеллектуальной собственности (Intellectual Property Office) сказано, что первым законным обладателем авторского права на заказное произведение является тот, кто его создал, «если вы письменно не договорились об ином». В США передача авторского права действительна только в письменной форме, с подписью правообладателя или его уполномоченного представителя. Сам пункт о владении разбирается в статье о проверке выделенной команды. Для разработки в финтехе добавьте такие условия:

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

Если ваша компания будет инвестиционной компанией, поставщиком услуг в сфере криптоактивов или торговой площадкой в ЕС, на неё распространяется Закон о цифровой операционной устойчивости (DORA), который применяется с 17 января 2025 года. Статья 30 DORA устанавливает минимальные условия договоров на технологические услуги, которые регламент называет ИКТ-услугами; среди них — регионы или страны, где данные обрабатываются и хранятся, возврат ваших данных, если поставщик станет неплатёжеспособным, прекратит деятельность или договор закончится, а также права на расторжение со сроками уведомления. Договоры на услуги, которые поддерживают критические или важные функции, должны вдобавок предусматривать стратегии выхода с обязательным переходным периодом. Спросите своего юриста, какие части вашего соглашения с исполнителем подпадают под этот регламент, особенно поддержка и хостинг после запуска.

Как разбить работу на этапы и платежи?

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

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

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

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

Какие тревожные сигналы стоит замечать при выборе партнёра для финтех-разработки?

• Фиксированная цена и дата запуска в первом же ответе, прежде чем кто-то спросил, на какую лицензию вы подаёте заявку или к каким брокерам и биржам будете подключаться
• План запуска, в котором нет места ни решению регулятора, ни тестам подключения у ваших брокеров
• Бесплатный этап проектирования архитектуры без письменного права на документы, из-за чего вы не можете передать проект другой компании
• Учётные данные брокера или биржи либо облачный аккаунт, оформленные на имя компании-исполнителя
• «Наша платформа соответствует требованиям». Лицензия есть не у софта, а у вашей компании. Спросите, на соответствие каким правилам проверяли архитектуру и кто это делал
• Сопротивление, когда вы приводите независимого советника проверить архитектуру
• Примеры из финтеха — сплошь сайты и дашборды, без единой системы, через которую проходят заявки или деньги

Где здесь место amBrain?

Из видов компаний, описанных выше, amBrain — инженерная компания. amBrain делает софт с 2019 года.

Услуги amBrain в трейдинге перечислены так: «Разработка торговых терминалов, систем управления ордерами и биржевая интеграция по протоколу FIX». amBrain построил торговый терминал для Spectre Trade. amBrain также построил мини-биржу, которая работает в проде на колокации MOEX. Клиент мини-биржи не называется.

То, как amBrain работает с клиентами, компания описывает одной строкой: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». Это исключение — как раз такая оговорка, которую статья советует чётко очертить, поэтому попросите у amBrain поимённый список этих компонентов до подписания. Эта статья — не кейс, и её проверки относятся к amBrain в той же мере, что и к любой другой компании.

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