Решения · Финансовые услуги
Приложение для финансовых услуг оценивается по тому, что происходит на его границах: что пишется в журнал, что происходит, когда клиент запрашивает свои данные обратно, что видно из преддоговорной информации и что происходит, когда запланированная задача не запускается. Мы строим механику; кредитная политика остается вашей.
Уже построеноПлатформа кредитования в продакшене, проверяемая извне сегодня: публичная часть — это статически скомпилированное приложение с 50 экранами, среди которых четыре калькулятора — кредит, соответствие, рефинансирование, график платежей — страницы по типу кредита, преддоговорная информация и маршрут, по которому клиент запрашивает свои персональные данные; бизнес-часть — это модульный backend на TypeScript с 16 модулями и 18 таблицами в схеме данных, среди которых договор, платёж, журнал аудита, запрос по персональным данным, загруженный документ, ежедневный снимок показателей и выполнение запланированной задачи. Карта сайта в продакшене перечисляет 227 адресов, а румынские и русские маршруты отвечают оба — проверено мной 06.09.2026. Оговорка, которую мы говорим: доказательство — из кода и публичных ответов, а не из внутреннего поведения сервера — мы не проверяли, на какой версии работает продакшен, и не проверяли, что все 16 модулей активны на live.
Кредитной компании не нужен сайт. Ей нужна полная цепочка: запрос поступает онлайн, проходит через поток принятия решения, формирует договор, генерирует график платежей и оставляет след в аудите. Каждое отсутствующее звено в цепочке превращается в человека, который копирует данные из одного места в другое, а в финансовых услугах каждая ручная копия — это и проблема соответствия, а не только времени.
Структура, которую мы строим, прямо отражает это в данных. В платформе, которую мы цитируем, схема содержит 18 таблиц, и их список говорит больше, чем любое описание архитектуры: запрос, договор, платеж, одноразовый код, сессия, запрос обратного звонка, шаблон уведомления, журнал уведомлений, ежедневный снимок показателей, запуск запланированной задачи, статья, перенаправление адреса, настройка видимости, внутренняя заметка, журнал аудита, загруженный документ, запрос о персональных данных. Backend разделен на 16 модулей, среди которых один посвящен исключительно правам субъекта данных.
Публичная часть — это не декорация: четыре калькулятора — кредит, соответствие условиям, рефинансирование и график платежей — плюс отдельные страницы по типу кредита и преддоговорная информация. В потребительском кредитовании преддоговорная информация — это не имиджевая страница: это обязанность показать условия до того, как человек возьмет на себя обязательство. Мы рассматриваем ее как требование к продукту, а не как юридический текст, приклеенный в конце. Румынские маршруты остаются без префикса, а русские идут по собственному сегменту, с каноническими и альтернативными метками, сгенерированными из языка активного маршрута.
И предел, который нужно сказать до договора: поток принятия решений по заявкам — правила, пороги, одобрение — ваш. Мы строим механику, по которой заявка проходит, документируется и становится договором. Мы не пишем кредитную политику и не берем на себя оценку заявителя; это решения с юридическими последствиями, которые принадлежат уполномоченному учреждению.
Что входит
Заявка поступает онлайн и существует как собственная сущность, со видимым статусом и экраном отслеживания для клиента. Загруженные документы имеют свою таблицу, договор — свою, платеж — свою. Разница по сравнению с формой, которая отправляет письмо, в том, что через три месяца можно ответить по данным на вопрос «что случилось с заявкой от 12 марта».
Договор и график не собираются вручную в отдельном документе: они выходят из данных одобренной заявки. Это единственный вариант, при котором цифра в договоре и цифра в графике не могут отличаться, а клиент, который звонит с документом в руках, говорит об одном и том же, что и оператор, который смотрит в систему.
Кредит, соответствие условиям, рефинансирование и график платежей — отдельные публичные экраны без аутентификации. В потребительском кредитовании калькулятор — это первое реальное взаимодействие: человек хочет увидеть платеж до того, как поговорит с кем-либо. А рефинансирование — это калькулятор, отдельный от кредитного, не тот же самый под другими ярлыками.
Отдельная страница, а не абзац в подвале. Причина практическая: если информирование не находится на пути, по которому человек идет перед подписанием, оно не выполняет свою работу ни для него, ни для учреждения. Текст ваш и ваших юристов; мы строим место, момент и прослеживаемость.
Есть публичная страница, через которую клиент запрашивает свои персональные данные, выделенный backend-модуль и экран администрирования для полученных запросов, а также таблица, где они хранятся. Практический итог: законный срок ответа можно соблюсти без того, чтобы кто-то вручную открывал базу данных — и можно доказать через год, что он был соблюден.
Журнал аудита — это собственная таблица, отдельная от внутренних заметок операторов. Разделение важно при проверке: одно — технический учет того, что произошло, другое — то, что коллега написал о деле. Если их смешать, первое становится нечитаемым, а второе — документом.
Есть таблица для запусков плановых задач и одна для ежедневных снимков показателей. На финансовой платформе задача, которая не запускалась три ночи подряд, — проблема серьезнее, чем упавшая страница: снаружи этого не видно, но это меняет цифры. Поэтому запуск записывается, а не предполагается.
Румынские маршруты остаются без префикса, русские идут по отдельному сегменту, с каноническими и альтернативными метками, сгенерированными из языка активного маршрута. На карте сайта в production — 227 адресов. Для кредитной компании в Республике Молдова русская часть — не перевод из вежливости, а половина заявителей.
Проверки перед публикацией, миграции базы данных, запускаемые отдельной командой в production, генерация секретов, резервная копия и восстановление базы — все как скрипты в репозитории, а не как шаги в документе. В системе, которая ведет контракты и платежи, «восстановление» должно быть командой, которую вы пробовали, а не намерением.
Traseul
Что означает поданная заявка, одобренная заявка, полученный платеж; что происходит с заявкой, на которую не ответили; что переходит в закрытое состояние, когда внешний сервис не отвечает. Мы поставляем документ по словарю и инвариантам, потому что на финансовой платформе термин, используемый в двух смыслах, позже превращается в две разные цифры в двух отчетах.
Журнал аудита и учет документов не добавляются в конце; они являются частью первой рабочей версии. Мы поставляем полный поток от заявки к контракту, с его следом, на тестовых данных — не экраны, которые хорошо выглядят поверх пустой базы.
Публичные экраны, калькуляторы, страницы по типу кредита и преддоговорная информация, с румынскими адресами без префикса и русскими на отдельном сегменте, с корректными каноническими метками. Мы поставляем карту сайта, сгенерированную из данных, и проверку того, что обе версии отвечают.
Проверка перед публикацией, миграции в production отдельной командой, генерация секретов, резервная копия и восстановление — проверенные, а не просто записанные. Мы передаем репозиторий, документ ввода в эксплуатацию и доступы. Восстановление базы демонстрируется при передаче, один раз, в вашем присутствии.
Данные
Правила различаются от одной отрасли к другой. Это те, что применяются в финансовых услугах.
Случай
Ситуация
Первоначальное требование в кредитном проекте почти всегда звучит одинаково: «сайт с формой заявки». Проблема появляется на втором месяце, когда кто-то спрашивает, где договор, кто изменил досье и как мы отвечаем на запрос о доступе к персональным данным в установленный законом срок.
Что мы построили
Мы построили платформу в двух половинах, в одном репозитории. Публичная часть — это статически скомпилированное приложение, с 50 экранами: четыре калькулятора — кредит, соответствие требованиям, рефинансирование, график платежей — страницы по типу кредита, преддоговорная информация, отслеживание статуса заявки и страница, через которую клиент запрашивает свои персональные данные. Бизнес-часть — модульный backend на TypeScript, с 16 модулями — среди которых аутентификация, права по ролям, поток заявок, документы, платежи, уведомления, запланированные задачи и один, посвященный правам субъекта данных, — поверх схемы с 18 таблицами: заявка, договор, платеж, одноразовый код, сессия, загруженный документ, журнал аудита, запрос по персональным данным, запуск запланированной задачи, ежедневный снимок показателей и остальное.
Что получилось
Цепочка полная: заявка входит, проходит путь, порождает договор и график, и каждый шаг оставляет след. Запросы по персональным данным имеют собственный маршрут, с экраном администрирования, значит, установленный законом срок можно соблюдать и доказать. Публичная часть проверяема снаружи: 227 адресов на карте сайта, с обеими живыми языковыми версиями.
Чего этот случай не говорит
Доказательство — в коде и в публичных ответах, а не во внутреннем поведении сервера: мы не проверяли, на какой версии работает production, и не то, что все 16 модулей активны на live. Поток принятия решения по заявкам — правила, пороги, одобрение — принадлежит клиенту; мы построили механику, а не кредитную политику.
Вопросы
Вы. Правила, пороги и одобрение — это политика уполномоченного учреждения, а не поставщика программного обеспечения. Мы строим механику, по которой заявка проходит, документируется, превращается в договор и график платежей, и оставляет след. Поставщик, который берет на себя решение по кредиту, продает то, на что не имеет права.
Есть публичная страница, через которую он это запрашивает, отдельный модуль backend, экран администрирования и таблица, в которой запрос хранится. Значит, можно ответить в срок и потом это доказать. Что не является техническим решением: что можно удалить и что нужно хранить согласно финансовому законодательству — это устанавливается с вашими юристами до внедрения.
Из данных утвержденной заявки, вместе с графиком платежей — оба из одного источника, чтобы они не могли различаться. Что остается вашим — это содержание договора и его условия. Договор, составленный вручную в отдельном документе, — классическое место, где появляются две разные цифры для одного и того же кредита.
Потому что в потребительском кредитовании информация должна быть на том пути, по которому идет человек до того, как он примет на себя обязательство, а не в подвале. Мы рассматриваем это как часть продукта: место, момент и трассируемость — наши, текст — ваших юристов.
По меньшей мере столько, сколько соответствует разным решениям. На платформе, которую мы цитируем, их четыре — кредит, соответствие требованиям, рефинансирование, график платежей — потому что рефинансирование не то же самое вычисление, что и новый кредит, а график отвечает на другой вопрос, чем ставка. Один калькулятор со многими полями использовать сложнее, чем четыре простых.
Нет, и это правило, а не предпочтение: мы строим и тестируем на тестовых данных. Доступ к реальным данным, когда он необходим, предоставляется назначенным лицам, на установленный срок и с записью в журнале. В финансовой системе «мне нужно было посмотреть в production» — это фраза, которая должна появиться в журнале, а не в разговоре.
Это видно, потому что запуски записываются в отдельную таблицу, рядом с ежедневными снимками показателей. Это важно именно потому, что задача, которая не запустилась, не дает никаких видимых внешне симптомов — сайт отвечает, экраны выглядят нормально, но цифры больше не движутся.
Ни одной цифры по объему, по ставке, по числу заявок или клиентов, даже если она публично отображается на его сайте — потому что это его утверждение, а не наше измерение. Что мы можем показать — это структуру: сколько модулей, какие таблицы, какие публичные экраны, что проверяется при публикации. То же правило будет применяться и к вашей работе.
Публичную часть можно проверить сейчас: карта сайта имеет 227 адресов, а румынская и русская версии одного калькулятора обе отвечают. Backend-часть читается из кода — модулей и схемы данных — а не из поведения сервера: мы не проверяли, на какой версии работает production, и не проверяли, что все модули активны на live, и предпочитаем написать это, чем оставить противоположное впечатление.
Расскажите о своём процессе. Вместе определим, что стоит построить, что можно подключить и как проверим результат.