Краудфандинговая платформа — не просто сайт, где компания публикует заявку, а инвесторы переводят деньги. Система должна связать проверку участников, раскрытие условий, заключение договоров, расчёты и последующий учёт обязательств. Ошибка в любом из этих звеньев может обернуться не только сбоем сервиса, но и нарушением закона или спором о том, кто и на каких условиях вложил средства.
Для начала нужно определить модель продукта. P2B — это финансирование бизнеса частными инвесторами, а не отдельная юридическая форма. За этим названием могут стоять займы компаниям, инвестиции в ценные бумаги или другие способы привлечения средств. У каждого варианта свои договоры, денежные потоки и требования к раскрытию информации. Поэтому архитектуру нельзя выбирать, пока не определено, какие именно права получает инвестор и какую роль играет оператор платформы.
Сначала — юридическая модель, затем — код
В России работу инвестиционных платформ регулирует Федеральный закон № 259-ФЗ. Он устанавливает требования к операторам и инвестиционной деятельности через платформу; для оператора имеет значение включение в реестр Банка России. Но не всякий сервис коллективного финансирования автоматически подпадает под один и тот же режим: юридическая квалификация зависит от того, как устроено предложение и какие отношения возникают между участниками.
Например, выдача займа бизнесу и приобретение инвестором ценной бумаги — разные сценарии. В первом случае система должна поддерживать параметры займа, график платежей, начисление процентов и учёт погашений. Во втором потребуются процессы, связанные с выпуском или обращением соответствующих инструментов и фиксацией прав инвесторов. Нельзя без отдельной проверки считать платформу посредником по любой сделке или обещать пользователю возврат вложений: риск и обязанности сторон определяются законом и договором.
Юридические требования следует переводить в конкретные правила продукта. Если для участия нужна проверка личности, нельзя оставить её необязательной кнопкой. Если до инвестирования пользователь должен увидеть сведения о проекте и рисках, система должна сохранять, какая версия материалов была доступна ему в момент принятия решения. Такая связь между нормой, интерфейсом и записью в системе снижает число неоднозначных ситуаций при проверках и разборе жалоб.
Из чего складывается техническая архитектура
Для первой версии обычно достаточно модульной архитектуры без преждевременного дробления на десятки микросервисов. Она проще в разработке и сопровождении, но позволяет выделить ключевые домены: учётные записи и проверку клиентов, проекты и заявки, договоры, платежи, инвестиционные операции, уведомления и отчётность. Если нагрузка или организационные границы вырастут, отдельные части можно будет вынести в самостоятельные сервисы.
В основе платформы должен быть не набор экранов, а контролируемый процесс сделки. Компания подаёт заявку и документы; система проверяет комплектность и запускает необходимые проверки; оператор принимает решение о публикации; инвестор знакомится с условиями и проходит предусмотренные этапы идентификации; затем оформляется сделка, поступают средства и обновляется учёт. Для каждого шага важно определить, кто вправе его выполнить, какие данные нужны и что произойдёт при отказе, отмене или истечении срока.
Отдельного внимания требует финансовый учёт. Баланс в личном кабинете не должен быть единственным источником истины. Нужен журнал операций, где фиксируются основания каждой записи: поступление, возврат, выплата, комиссия или исправление. Записи следует делать так, чтобы историю нельзя было незаметно переписать; корректировки оформлять отдельными событиями с указанием причины и ответственного. Сверка с банком и платёжными партнёрами помогает обнаружить расхождения до того, как они затронут пользователей.
Денежный маршрут проектируют вместе с юристами и банком, а не после запуска интерфейса. В зависимости от модели могут применяться специальные счета и предусмотренные законом способы расчётов. Система должна различать собственные средства оператора и деньги участников, обрабатывать возвраты и не считать перевод завершённым только потому, что пользователь увидел сообщение об успехе. Подтверждение операции должно поступать из надёжного платёжного контура и сверяться с внутренним учётом.
Для договоров и раскрытия условий понадобится хранить версии документов, дату и способ принятия, а также подтверждение личности подписанта. Электронная подпись и электронные документы должны применяться с учётом закона № 63-ФЗ и выбранной схемы заключения сделок. Полезно проектировать хранение так, чтобы по конкретной инвестиции можно было восстановить всю цепочку: что видел пользователь, какую сумму выбрал, какой документ принял и как прошёл платёж.
Проверки пользователей и защита данных
Проверки клиента — не разовая форма регистрации. В зависимости от роли участника и применимых требований платформе могут понадобиться идентификация, проверка полномочий представителя компании, сбор сведений о бенефициарах и оценка операций. Требования законодательства о противодействии отмыванию доходов, включая закон № 115-ФЗ, необходимо соотнести с конкретной деятельностью оператора. Практически это означает хранение результатов проверок, фиксацию причин отказа и возможность повторной проверки при изменении данных.
Персональные данные обрабатываются по правилам закона № 152-ФЗ. В архитектуре стоит разделить сведения, необходимые для публичной карточки проекта, и документы с данными клиентов; ограничить доступ по ролям; шифровать чувствительную информацию и вести журнал обращений к ней. Сроки хранения и удаления нужно определить заранее: данные нельзя бесконечно держать «на всякий случай», но и удалять их вопреки обязанности подтвердить сделку или исполнить требования закона нельзя. Отдельно проверяют правила локализации и трансграничной передачи данных, если используются зарубежные облака или подрядчики.
Защита платформы включает не только шифрование. Нужны многофакторная аутентификация для сотрудников и привилегированных пользователей, разделение полномочий, управление секретами, резервное копирование и план восстановления после сбоя. Критичные действия — изменение реквизитов, ручная корректировка платежа, публикация проекта — стоит подтверждать дополнительной проверкой. Журналы должны помогать расследовать инциденты, но сами не превращаться в хранилище лишних персональных данных.
Что учесть до запуска
Регуляторные требования лучше закладывать в продуктовую модель: определить статусы сделки, обязательные документы, правила допуска и отказа, порядок возвратов, отчётность и роли сотрудников. Затем эти правила можно проверять автоматически — например, не давать опубликовать проект без утверждённого набора материалов или завершить сделку без требуемого подтверждения. Автоматизация не заменяет юридическую экспертизу, но помогает одинаково применять правила и сохранять доказательства их исполнения.
До запуска полезно испытать не только штатный сценарий, но и неприятные: платёж прошёл у банка, но не отразился в платформе; проект снят после приёма части средств; инвестор оспаривает подпись; у компании сменился представитель; оператору нужно выгрузить сведения для проверки. Такие случаи показывают, выдерживает ли архитектура реальную работу, а не только красивую демонстрацию. Для P2B-сервиса надёжность в итоге определяется тем, насколько точно система связывает договор, деньги и историю решений.
