Как выбрать компанию для разработки fintech-решений: гайд для бизнеса

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

Короткий ответ такой. В шортлист стоит брать команды, которые уже запускали продукты именно в вашем сегменте (платежи, кредитование, трейдинг, банкинг), могут показать, как закрывают требования PCI DSS, GDPR и KYC/AML в коде и процессах, и готовы начать с платного discovery, прежде чем называть фиксированный бюджет. Дальше в гайде объясняем, как проверить эти три вещи, не будучи юристом по комплаенсу или senior-инженером.

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

Что охватывает разработка fintech-решений

«Fintech» очень широкое понятие. Команда, которая сделала отличное приложение для личного бюджета, не обязательно справится с платформой эмиссии карт. Прежде чем сравнивать компании, определите, к какой из категорий относится ваш продукт.

Цифровой банкинг. Приложения необанков, открытие счетов, управление картами, история транзакций, цели накоплений. Самое сложное здесь редко интерфейс. Сложность в интеграции с banking-as-a-service провайдером или core banking системой, а также в онбординге, который проходит KYC-проверку и при этом не теряет половину регистраций.

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

Кредитные платформы. Выдача кредитов, скоринг, сбор документов, графики погашения, работа с просрочкой. Такие продукты держатся на пайплайнах данных и логике решений. Если для кредитного скоринга используется AI, EU AI Act относит это к высокорисковым сценариям, и после Digital Omnibus 2026 года эти требования начнут действовать с декабря 2027-го. Ваш подрядчик должен знать эту дату.

Regtech. Мониторинг транзакций, AML-скрининг, автоматизация отчётности, audit trail. Regtech-продукты покупают команды комплаенса, поэтому каждый экран оценивают одним вопросом: смогу ли я защитить это перед регулятором?

Есть и смежные сегменты: трейдинг и брокеридж, криптокошельки и биржи, инвестиционные платформы, insurtech. У каждого своя терминология и свои типичные провалы.

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

Какие возможности по комплаенсу и безопасности проверить

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

PCI DSS. Если продукт хранит, обрабатывает или передаёт карточные данные, на него распространяется PCI DSS. Версия 4.0.1 единственная действующая версия стандарта, и с 31 марта 2025 года обязательны все её требования, включая те, что раньше имели пометку «future-dated». Спросите подрядчика, как он уменьшает PCI scope. Хороший ответ упоминает токенизацию через платёжного провайдера, hosted payment fields и то, что «сырые» номера карт никогда не попадают на ваши серверы.

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

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

KYC/AML. Большинство продуктов не строят верификацию личности с нуля, а интегрируют KYC-провайдера и сервис AML-скрининга. От подрядчика нужен опыт именно с такими интеграциями: статусы ожидания верификации, повторная проверка, совпадения с санкционными списками, очереди ручной проверки для вашего комплаенс-офицера.

Шифрование данных. Шифрование при хранении и передаче является базой. Спросите об управлении ключами (кто ими владеет, как они ротируются), шифровании отдельных полей для особо чувствительных данных и о том, как секреты держат вне репозитория кода.

Регуляторный опыт по рынкам

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

ЕС. DORA полностью применяется с 17 января 2025 года. Регламент распространяется на финансовые организации, а через договоры затрагивает и их ICT-провайдеров. Поэтому регулируемый клиент будет спрашивать своего технологического партнёра об обработке инцидентов, планах выхода и субподрядчиках. PSD3 и новый Payment Services Regulation политически согласовали в ноябре 2025 года, в 2026-м идёт их формальное принятие. Большинство норм, как ожидается, начнёт действовать примерно через 21 месяц после вступления в силу, то есть ориентировочно в 2028 году. Если в ваших планах open banking или платежи в ЕС, закладывайте это уже сейчас.

США. Большинство fintech-компаний не работают по единой федеральной лицензии. Перевод средств лицензируется отдельно в каждом штате (специальная хартия OCC существует, но редко становится первым шагом для стартапа), потребительские данные регулирует GLBA, а платёжные сети имеют собственные требования. Подрядчик не обязан быть юристом, но должен понимать, когда функция (например, хранение средств клиентов) меняет ваш регуляторный статус.

Великобритания, FCA. Режим FCA имеет собственные правила по consumer duty, операционной устойчивости и аутсорсингу. Если у вас есть авторизация FCA или вы планируете её получить, спросите подрядчика, работал ли он с командами, которые документировали аутсорсинговые договорённости для регулятора.

Технические критерии оценки

Когда с комплаенсом всё выглядит надёжно, проверьте, способна ли команда действительно построить то, что вам нужно, и в нужном масштабе.

API-интеграции. Типичный fintech-продукт взаимодействует со многими внешними сервисами: платёжными провайдерами, KYC, AML, банками-партнёрами, бухгалтерией, CRM, аналитикой. Попросите конкретный пример интеграции, которая сломалась в продакшене, и как её чинили. Ключи идемпотентности, повторные попытки, dead-letter очереди и задачи по сверке должны прозвучать без подсказок.

Core banking системы. Если вы подключаетесь к core banking платформе или banking-as-a-service провайдеру, спросите, работала ли команда с такими системами раньше. Модели данных там необычные, песочницы часто ограничены, а документация не всегда точна. Опыт здесь экономит недели.

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

Laravel, Node.js и остальной стек. Единственно правильного fintech-стека не существует. Мы часто используем Laravel для бэк-офиса, админ-панелей и API с насыщенными бизнес-правилами, а Node.js для функций реального времени: лент котировок, уведомлений, дашбордов на вебсокетах. Важнее фреймворка сам ход мысли. Компания по разработке fintech-решений должна объяснить, почему стек подходит именно вашему продукту, какой рынок специалистов под него и насколько легко будет позже передать код другой команде.

Релевантность портфолио. Здесь нужны доказательства. Попросите кейсы из вашего сегмента и посмотрите, что именно делал подрядчик. Например, среди наших кейсов fintech-проектов есть очень разные по объёму работы: аукционная платформа реального времени для трейдеров растительного масла в Швейцарии (Easy Trade), UX/UI для лондонского форекс-брокера с более чем 30 десктопными экранами и мобильными версиями (Infinox), личный кабинет инвестора с обменом фиатных средств и криптовалюты на внутренний стейблкоин (PlantEco), а также информационная брокерская платформа, где мы перенесли более 1 500 страниц контента на новую CMS (EarnForex). Хороший подрядчик честно скажет, какие из его проектов близки к вашему, а какие нет.

Модели сотрудничества и ценообразование

Преобладают три модели, и каждая подходит разным этапам fintech-продукта.

Fixed price. Объём, сроки и бюджет согласуются заранее. Модель хорошо работает для чётко определённого MVP или отдельного модуля, например кабинета мерчанта. Плохо работает, когда регуляторные требования или API партнёров ещё не ясны, потому что каждое изменение превращается в change request.

Time and materials. Вы платите за фактически потраченные часы. Подходит для продуктов, где требования будут меняться после разговоров с регуляторами, банками-партнёрами и первыми пользователями. Риск в разрастании бюджета, поэтому настаивайте на еженедельных отчётах и месячном потолке бюджета.

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

Наша позиция: для большинства fintech-продуктов самый безопасный старт это короткий этап discovery для программного проекта, затем MVP по фиксированной цене или с ограниченным бюджетом, а дальше выделенная команда. Именно на discovery фиксируют требования комплаенса, интеграции и риски, прежде чем кто-то назовёт окончательную цифру.

Если вы взвешиваете аутсорс и собственную команду, у нас есть отдельный гайд по аутсорсингу разработки ПО, где подробнее разобраны риски (IP, зависимость от подрядчика, коммуникация).

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

Тревожные сигналы при проверке подрядчиков

Большинство неудачных выборов подрядчика было видно заранее. Вот сигналы, к которым мы отнеслись бы серьёзно.

Портфолио не совпадает с задачей. В портфолио одни лендинги и интернет-магазины, а единственный fintech-проект это концепт на Dribbble. Дизайн важен, но торговая платформа или платёжный бэкенд требуют инженерной глубины, которую такое портфолио не показывает.

Нет опыта с комплаенсом. Спросите: «Какие из ваших проектов проходили оценку PCI DSS или due diligence подрядчиков со стороны банка?» Если ответ размытый, команда будет учиться за ваш счёт.

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

Никаких вопросов о вашем регуляторном статусе. Компания по разработке кастомного fintech-ПО, которая не спрашивает, есть ли у вас лицензия, работаете ли вы с лицензированным партнёром или планируете подаваться, не думает о рисках, которые будете нести вы.

Непонятно, кому принадлежит код. В договоре должно быть указано, что код ваш, репозитории размещены в вашем аккаунте (или передаются по графику), а инфраструктура задокументирована. Всё остальное создаёт зависимость от подрядчика.

Один человек делает всё. Один «full-stack» разработчик в качестве всей команды платёжного продукта означает, что код, работающий с деньгами, никто не ревьюит.

Как Solar Digital работает с fintech-проектами

Мы команда дизайнеров и инженеров из Украины, зарегистрированная в Великобритании, работаем с клиентами в США, Великобритании и Европе. Вот как выглядит наша fintech-работа на практике.

Сначала discovery. До оценки мы описываем продукт: роли пользователей, движение средств, регулируемые точки, сторонних провайдеров и данные, подпадающие под GDPR или PCI DSS. Результат: документ со скоупом, эскиз архитектуры и список рисков, с которыми можно пойти к любому подрядчику, даже к конкуренту. Этот этап ведут наши бизнес-аналитики, и обычно он экономит больше, чем стоит.

Fintech-портфолио, которое можно проверить. Наша fintech-работа охватывает продукты для трейдинга, брокериджа, инвестиций и управления финансами для клиентов из Швейцарии, Великобритании, Словении, Франции и США. Кейсы собраны в разделе разработка для fintech и crypto, и мы охотно покажем те, что ближе всего к вашему продукту.

Разработка с приоритетом безопасности. Code review каждого изменения, отдельные окружения, управление секретами, журнал аудита для чувствительных действий и шифрование, заложенное в модель данных, а не добавленное перед запуском. Интерфейсы проектируем с тем же подходом: в финансовом UX рискованные действия должны быть понятными и неторопливыми, а рутинные быстрыми.

Дизайнеры и инженеры в одной команде. В fintech запутанный экран является риском для комплаенса, а не только проблемой UX. Наши дизайнеры работают рядом с инженерами, которые реализуют сценарии, поэтому шаги KYC, состояния ошибок и экраны подтверждения проектируются с учётом реальных ограничений.

Если вы сейчас сравниваете подрядчиков, запишитесь на звонок с нашим бизнес-аналитиком. Мы посмотрим на идею продукта, честно скажем, подходим ли вам, и укажем на вопросы комплаенса, которые стоит закрыть до старта разработки.