МАДРИГАЛ ОИС: КАК МЫ РАЗРАБАТЫВАЛИ ПЛАТФОРМУ ДЛЯ ЦФА

За 2025 год разработки платформы МАДРИГАЛ ОИС я понял: создавать сложные системы - это про людей, регуляцию и архитектуру. Рассказываю как это было, какие вызовы встретили и какие уроки вынесли.

Пост для разработчиков, аналитиков и тех, кто интересуется блокчейном в России. За последний год я участвовал в разработке платформы МАДРИГАЛ ОИС - оператора информационной системы для цифровых финансовых активов. Это был первый пилотный проект такого масштаба для нашей компании. 100 человек, 5 команд, 12+ месяцев интенсивной работы. Хочу поделиться не просто результатом, а тем, как мы к нему пришли.

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

⚡️ НАЧАЛО: КОГДА СЛУШАТЬ ВАЖНЕЕ, ЧЕМ ПРОДАВАТЬ

Большинство IT-подрядчиков начинают с демонстрации возможностей. Мы сделали наоборот. Мы спросили клиента: "Что вам НУЖНО? Не то, что у нас есть. А что вам необходимо для успешного запуска платформы?"

Месяц обсуждений. Бесконечные совещания. Мы собирали не только техничные требования - нам были нужны бизнес-требования, регуляторные ограничения, требования безопасности. Потом с командой мы думали: как это всё реализовать? Не "вот что у нас есть", а "вот как наше решение решает вашу проблему".

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

🤫 ПЕРВЫЙ РЕАЛЬНЫЙ ВЫЗОВ: НАДЕЖНОСТЬ И УДОБСТВО

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

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

Это заняло больше времени, чем мы планировали. Но это было необходимо. Потому что потом, когда платформа пошла в production, людям не нужно было ее переучивать.

🔴 ГЛАВНАЯ БОЛЬ: КОГДА КОД И ЗАКОН КОНФЛИКТУЮТ

Через несколько месяцев выяснилось что-то более сложное. Правильный с точки зрения IT код не всегда соответствует закону. И наоборот - правильный с точки зрения закона код может быть архитектурно неоптимальным.

Пример. Нужно было хранить данные по ЦФА на блокчейне. Но блокчейн прозрачен - все данные видны всем узлам. А закон о персональных данных (152-ФЗ) требует конфиденциальности. Блокчейн создан для прозрачности. Это фундаментальный конфликт.

Мы решали это 3-4 месяца. Итоговое решение: off-chain хранилище для чувствительных данных. На блокчейне хранятся только хэши и ссылки. Это позволило нам сохранить надежность блокчейна, но защитить приватные данные пользователей. Это не революционно, но для нас это было важно пройти это самим.

🛡 БИТВА С РЕГУЛЯЦИЕЙ: КОГДА НУЖНО ОБЪЯСНИТЬ НЕВОЗМОЖНОЕ

Чем ближе мы подходили к защите перед Банком России, тем более абстрактными становились вопросы. Регулятор не спрашивал "как вы храните данные". Он спрашивал "почему вы это делаете именно так".

Вот конкретный случай. Мы выбрали архитектуру: разные ЦФА хранятся в разных блокчейн-каналах. Это имеет смысл: безопасность, изоляция между активами, контроль. Но когда мы это показали регулятору, он спросил: "Почему вы ДРОБИТЕ информацию? Разве это не нарушает целостность данных?"

Вот это был момент. Сначала казалось, что мы выбрали неправильно. Потом понял - просто нужно лучше объяснить. Мы собрали команду, подготовили ответ. И объяснили: "Это не дробление. Это разделение по безопасности. Каждый актив в отдельном канале повышает надежность, а не её ухудшает. Вот почему..."