Быстрый старт
Эта страница помогает быстро пройти продукт целиком: предприниматель создаёт заявку, система проверяет сведения и считает показатели, банк разбирает исключения и принимает решение, а клиент видит следующий шаг до подписания и моделируемой выдачи.
Рабочий контур
Откройте нужную точку входа в новой вкладке:
- Кабинет предпринимателя: создание заявки, ответы на запросы, сравнение условий и подписание.
- Кабинет сотрудника банка: очередь, карточка заявки, проверки, решение и аудит.
- Swagger API: HTTP-контракт и доступные операции.
Для локального запуска и переменных окружения используйте инструкцию разработчика. Архитектуру и отдельные виды диаграмм можно открыть в технической документации.
Содержание
Маршрут заявки
- В кабинете предпринимателя выберите компанию, продукт, цель, сумму и срок.
- Заполните сведения о компании, согласия и документы, затем отправьте заявку.
- Система получает доступные сведения, запускает проверки и рассчитывает рейтинг, индексы готовности и рекомендацию.
- При расхождениях в профиле компании система может создать запрос на уточнение. Сотрудник банка также может запросить сведения вручную. Клиент отвечает и прикладывает подтверждение.
- В банковском АРМ сотрудник открывает карточку, проверяет источники и документы, смотрит объяснение scoring и принимает решение либо меняет условия.
- Клиент сравнивает исходные условия с предложением или встречным предложением. После принятия переходит к подписанию.
- Дорожная карта показывает, кто действует сейчас, что блокирует движение и какой следующий шаг доступен.
Возможности продукта
Кабинет предпринимателя
Кабинет предназначен для прохождения заявки, а не для заполнения формы без обратной связи. В нём есть:
- паспорт компании с регистрационными данными, владельцами, оборотами, налоговыми признаками, БКИ, документами и залогом;
- список и история нескольких независимых заявок компании;
- выбор цели, продукта, суммы, срока и обеспечения;
- кредитный рейтинг с грейдом, уровнем риска, факторами, источниками и датой обновления;
- два независимых показателя: здоровье компании и готовность конкретной заявки;
- компас уверенности, который показывает, заявлен факт самостоятельно, подтверждён одним или несколькими источниками, имеет расхождение или требует ручной проверки;
- песочница условий и симулятор переговоров до отправки заявки;
- дорожная карта с текущим этапом, ответственным, блокером, запросами и возможными ветками;
- ответы на запросы банка, загрузка подтверждения и передача вопроса менеджеру;
- сравнение исходных условий с изменёнными условиями, история решений, подписание и моделируемая выдача.
Песочница не создаёт заявку и не обещает одобрение. Реальная заявка появляется только после явного подтверждения.
Продукты и условия
В демо доступны четыре продукта:
Ставка формируется из конфигурируемой ключевой ставки, спреда продукта и надбавки грейда. Число на экране не является обещанием одобрения или фиксированной ставкой вне текущей конфигурации.
Проверки, доказательства и запросы
Проверки смотрят на статус компании, право заявителя действовать, владельцев, налоги, БКИ, банковские обороты, документы, залог, дубли заявок, расхождения и ограничения продукта.
Автоматический запрос в текущем API создаётся для расхождений между источниками профиля компании: ИНН, названия, адреса или вида деятельности. Он содержит перечень требуемых подтверждений и причины расхождения. Запрос не создаётся, если уже открыт другой запрос, заявка заблокирована или приостановлена либо scoring рекомендует отказ. Остальные случаи разбирает сотрудник банка через ручные действия; автоматического запроса со сроком для каждого неполного поля сейчас нет.
Scoring и decision engine
Scoring рассчитывает baseline scorecard без обязательной зависимости от внешней ML-модели. Результат включает:
- score и грейд;
- здоровье компании и готовность заявки;
- confidence и список факторов с влиянием;
- recommendation: одобрение, встречное предложение, запрос информации, ручная проверка или отказ;
- режим автономности и объяснение результата.
Decision engine применяет правила продукта и политики после scoring. Он не отдаёт модели право менять статус заявки, отправлять оффер или обходить проверки. Открытое расхождение, неподтверждённый залог, недоступный источник, критичный стоп-фактор или ручной флаг требуют соответствующего запроса или участия менеджера.
Важно различать два результата: score описывает оценку факторов и качества данных, а решение определяет допустимый операционный шаг по правилам продукта. Рейтинг сам по себе не является решением банка.
Альфи, ассистент для клиента и банка
Альфи помогает сориентироваться в заявке в клиентском кабинете и банковском АРМ. Текущая версия выбирает заранее заданную подсказку по странице, статусу заявки и доступным действиям.
В клиентском кабинете Альфи:
- показывает вопрос открытого запроса и ведёт к следующему шагу заявки;
- помогает открыть заявку, продолжить черновик или перейти к подписанию;
- сообщает, когда заявка находится на рассмотрении, отклонена или заблокирована.
В банковском АРМ Альфи:
- открывает старейшую заявку в очереди, которая ждёт действия сотрудника;
- показывает подсказку по статусу, блокеру и рекомендации scoring;
- ведёт к блоку доступных действий в карточке заявки.
Альфи не выполняет команды за пользователя и не меняет решение. Подсказки формируются локальными правилами (cabinetHint, armHint и getAlfiGuidance); подключение LLM и диалоговые действия относятся к плану развития, а не к работающему контуру.
Банковское АРМ
АРМ собирает работу сотрудника вокруг очереди и карточки заявки. В очереди видны статус, приоритет, SLA, срочность, риск, готовность, ответственный и причина попадания заявки в фокус.
В карточке объединены паспорт компании, источники, расхождения, документы, compliance, залог, scoring, recommendation, decision engine, предложения, комментарии, история и аудит. Сотрудник может:
- назначить ответственного и передать заявку;
- принять или отклонить доказательство;
- запросить данные, вернуть заявку на уточнение или повторить проверку источника;
- изменить сумму, срок, продукт или обеспечение;
- создать встречное предложение;
- подтвердить рекомендацию, изменить её с причиной или отказать;
- включить срочный режим, поставить заявку на паузу, заблокировать или вернуть в работу;
- отменить заявку без выдачи.
Комментарии разделены на клиентские, внутренние и handoff для следующего сотрудника. Любое существенное действие получает автора, причину и запись в истории.
Управляемая автономность
Автономность начинается с рекомендации и проходит контроль, а не включается как безусловное автоодобрение. Для связки продукта, диапазона суммы и политики система отслеживает подтверждения менеджеров, ручные изменения, отмены, пропущенные факторы и стабильность результата.
Режимы:
new: обязательная проверка сотрудником и контрольное окно;verified: сокращённый контроль при накопленной статистике;stable: контролируемое автоодобрение для разрешённого сценария;paused: автоматизация остановлена из-за роста ошибок или drift.
Даже в stable менеджер может перехватить предложение до принятия клиентом. Критичные расхождения, неподтверждённый залог, превышение лимита, подозрительные данные и нестандартный продукт не проходят без человека. Изменение уровня автономности требует разрешённой роли, причины и аудита.
Дорожная карта и статусы
Диаграмма описывает полный публичный маршрут: DRAFT, SUBMITTED, VALIDATING, UNDER_REVIEW, NEEDS_INFO, OFFERED, ACCEPTED, SIGNING и FUNDED, с отдельными исходами REJECTED, CANCELLED и BLOCKED. В текущем API новая отправленная заявка сразу сохраняется как in_review и отображается как UNDER_REVIEW: SUBMITTED и VALIDATING не возникают как отдельные сохранённые статусы демо. Черновик до отправки остаётся в клиентском интерфейсе.
Дорожная карта в интерфейсе показывает не только название статуса. Она связывает текущий шаг с ответственным, объяснением, блокером, клиентским действием и доступными исходами: уточнение, встречное предложение, отказ, ручная проверка или выдача.
Внутренние стадии вроде проверки документов, compliance, scoring и policy check не выдаются клиенту как отдельные публичные статусы. Это позволяет объяснить движение заявки без раскрытия лишней внутренней последовательности.
Подписание и моделируемая выдача
После принятия предложения система переводит заявку к подготовке договора. Клиент видит условия до подтверждения, затем проходит моделируемое подписание и получает финальный статус FUNDED в демо-сценарии.
Моделируемая выдача не означает подключение к реальной банковской системе. Её задача показать полный путь после решения: принятие условий, подписание, финализацию и запись результата в историю.
История, аудит и повторяемость действий
События заявки сохраняют переходы, действия ролей, причины решений, изменения условий, handoff и события автономности. Клиент видит историю своей заявки, сотрудник банка получает расширенный аудит.
Команды заявки отправляются с ключом идемпотентности. Повтор запроса не должен создавать второе действие или второй переход. Доменная проверка выполняется на сервере: интерфейс не может локально перепрыгнуть через разрешённый workflow.
Сценарии для демонстрации
Ниже перечислены продуктовые ветки, включая варианты из плана развития. Они описывают ожидаемое поведение, а не служат подтверждением, что каждый переход доступен в текущем демо. Для воспроизводимых шагов реализованного контура используйте сценарии проверки.
Основной путь
Расхождение оборота создаёт запрос. Клиент отвечает и прикладывает подтверждение, менеджер принимает доказательство, заявка получает предложение, клиент принимает условия и доходит до FUNDED.
Встречное предложение
Запрошенная сумма не проходит по платёжной нагрузке. Менеджер в симуляции меняет сумму или срок, клиент сравнивает исходные и новые условия, затем принимает или отклоняет встречное предложение.
Контролируемое автоодобрение
Стабильный сценарий проходит policy check, предложение уходит в контрольное окно, а менеджер может перехватить его и вернуть решение в ручной контур.
Ручная проверка и срочность
Источник БКИ недоступен или есть расхождение. Заявка переходит на ручную проверку, клиент запрашивает срочный режим, менеджер назначает контроль, повторяет проверку и фиксирует результат.
Что смотреть разработчику
- Диаграмма состояний заявки: публичный workflow с переходами и управляющими исходами.
- Архитектура: component overview, API internals, repository и deployment по отдельности.
- API: локальный и опубликованный Swagger, правила команд и идемпотентности.
- Локальная разработка: запуск, окружение и проверка основного сценария.
- Модель данных: таблицы заявки, заданий, проверок и аудита.
- Сценарии проверки: воспроизводимые шаги для текущего демо.
В разделах выше отделены работающий контур и продуктовая модель. Точный список доступных операций определяется Swagger запущенного API.