Банкинг, сделанный правильно: переосмысление розничного банкинга с помощью языко-ориентированного ИИ

Xin Jie Chua1, Jeraelyn Ming Li Tan2, Jia Xuan Tan2, Скоро Чанг Пох1,2,
И И Гох1, Дебби Хуи Тиан Чунг1, Чи Му Фунг2,3,
Сзе Дже Ян1,2, Chee Seng Chan1†

1Университи Малайя, 2YTL AI Labs, 3Ryt Bank
†Соответствие: cs.chan@um.edu.my
Аннотация

Эта статья представляет Ryt AI, агентскую среду, ориентированную на LLM, которая обеспечивает работу Ryt Bank111Ryt Bank является первым в мире банком, работающим благодаря ИИ, полностью лицензированным Банком Негара Малайзии (Центральным банком Малайзии) и Министерством финансов Малайзии. Посетите https://www.rytbank.my/, чтобы узнать больше. чтобы клиенты могли выполнять ключевые финансовые операции через разговор на естественном языке. Это является первым в мире развертыванием, одобренным глобальным регулятором, где разговорный ИИ выступает в качестве основного банковского интерфейса, в отличие от прежних ассистентов, которые были ограничены консультативными или вспомогательными ролями. Построенная полностью силами собственной команды, Ryt AI работает на ILMU — внутреннем закрытом LLM, — и заменяет жесткие многоэкранные сценарии единственным диалогом, оркестрируемым четырьмя агентами, работающими на LLM (Guardrails, Intent, Payment и FAQ). Каждый агент подключает к ILMU адаптер LoRA, специфичный для конкретной задачи, при этом ILMU размещается в инфраструктуре банка, чтобы обеспечить стабильное поведение при минимальных накладных расходах. Детерминированные защитные барьеры, подтверждение при участии человека и безсостоястная архитектура аудита обеспечивают многоуровневую защиту для безопасности и соответствия требованиям. В итоге получается Banking Done Right: демонстрация того, что одобренные регулятором интерфейсы на естественном языке могут надежно поддерживать ключевые финансовые операции в условиях строгого управления.

Банкинг по-настоящему: переосмысление розничного банкинга с помощью языко-центричного ИИ

Синь Цзе Чуа1, Джераэлин Мин Ли Тан2, Цзя Сюань Тан2, Сун Чанг По Х1,2, И Сян Гох1, Дебби Хуи Тянь Чун1, Чи Мун Фонг2,3, Сзе Джуэ Ян1,2, Чи Сэн Чан1† 1Университи Малайя, 2YTL AI Labs, 3Ryt Bank †Соответствие: cs.chan@um.edu.my

1 Введение

Обработка естественного языка (NLP) быстро развивается благодаря появлению больших языковых моделей (LLM), таких как ChatGPT OpenAI et al. (2024). Эти модели теперь внедряются в различных отраслях, включая здравоохранение Thirunavukarasu et al. (2023), телекоммуникации Zhou et al. (2025) и электронную коммерцию Palen-Michel et al. (2024), где они автоматизируют сложные задачи при минимальном вмешательстве человека.

Помимо простого порождения текста, LLM перешли к интерактивным системам, способным запоминать, использовать инструменты и рассуждать, что позволяет создать новое поколение автономных приложений, обычно называемых «агентами». Эти агенты переопределяют рабочие процессы предприятия, беря на себя функции, которые традиционно зависели от координации и логики человека.

Refer to caption
(a) Ryt AI интерфейс: естественно-языковой вход для выполнения финансовых действий.
Refer to caption
(b) Ryt AI выполняет платежи из текста, снимков экрана чата, квитанций и изображений счетов.
⟦Figure 1: Банкинг как диалог: Ryt AI выполняет финансовые операции с помощью естественного языка.

Хотя ранние агентные фреймворки продемонстрировали перспективность в исследовательских прототипах Wang et al. (2024); Xi et al. (2023); Huang et al. (2024), их перенос в развертывания уровня промышленной эксплуатации остается ограниченным. Внедрение сдерживается такими проблемами, как сложность систем, ограниченная обобщаемость и отсутствие надежных оценок в реальных условиях, особенно в высокорисковых областях. Финансовый сектор воплощает это противоречие. Несмотря на высокий спрос на инновации с использованием LLM для поддержки клиентов, аналитики и персонализации, банки воздерживаются от их интеграции в критически важные для миссии рабочие процессы. Эта нерешительность связана с опасениями относительно галлюцинаций Huang et al. (2025); Xu et al. (2025), смещений Gallegos et al. (2024) и необходимости поддерживать строгие нормативные и требования к безопасности.

Refer to caption
⟦Figure 2: Сравнение устаревших рабочих процессов перевода средств и разговорного подхода Ryt Bank. (Слева) Традиционный поток охватывает несколько экранов, требует ручного ввода и жесткой навигации, а также не обладает семантическим пониманием, обычно занимая 30–45 секунд на транзакцию. (Справа) Ryt AI упрощает банковские операции, заменяя многоэкранные рабочие процессы на разговорный интерфейс, поддерживаемый агентами LLM.

В результате большинство финансовых организаций ограничивают использование LLM второстепенными задачами и задачами с низкими рисками. Например, Erica (Bank of America) и Eno (Capital One) работают как вспомогательные ассистенты в существующих системах, главным образом выполняя поддержку, поиск информации или простые запросы (например, проверку балансов, ответы на вопросы в разделе FAQ). Они не инициируют и не выполняют критически важные операции, такие как инструкции по платежам или переводы средств. Такая осторожная позиция, хотя и понятна в финансах, способствовала застою в инновациях в ядре банковской системы.

1.1 Мотивация и постановка задачи

Этот разрыв наиболее заметен в рабочих процессах цифрового банкинга, которые по-прежнему завязаны на устаревших многошаговых схемах с ограниченным интеллектом. Перевод средств это ясно иллюстрирует (см. Fig. 2): пользователи обычно проходят через 5–8 экранов, выбирая счета, вводя данные получателя, указывая суммы, просматривая сводки и выполняя аутентификацию через токен или push-уведомление; этот процесс занимает 30–45 с. Несмотря на свою повсеместность, этот поток предоставляет лишь ограниченные удобства (например, сохраненные получатели или часто используемые списки получателей), не предлагает предиктивной помощи и не поддерживает намерение, заданное в свободной форме на естественном языке.

Такие рабочие процессы создают трение. Предыдущие исследования Krol et al. (2015); Jin and Fan (2022) показывают, что повторяющиеся сценарии, особенно связанные с аутентификацией, относятся к числу наиболее распространенных проблем удобства использования в цифровом банкинге. Тем не менее преобладающая в отрасли точка зрения остается консервативной: «не чините то, что не сломано».”

Эта статья представляет альтернативу, как показано на рис. 1. Это система, изначально ориентированная на LLM, в которой ключевые функции, такие как переводы средств, оплата счетов, проверки соответствия и генерация инсайтов, оркестрируются специализированными агентами, использующими LLM, в рамках строгого контроля безопасности, соответствия и присутствия человека. Мы демонстрируем, что такие агенты могут координировать операции банковского уровня «полный стек» в производственной среде при наличии регуляторного одобрения, заменяя мног экранную навигацию разговорным взаимодействием.

1.2 Наш подход

Ryt Bank, запущенный в Малайзии, является первым в мире лицензированным банком с архитектурой, рожденной для ИИ. В основе лежит Ryt AI — агентная система, изначально ориентированная на LLM (см. рис. 1), которая перестраивает рабочие процессы цифрового банкинга. Вместо нескольких экранов пользователи выражают свои намерения на естественном языке, а система собирает, проверяет и выполняет операцию после подтверждения пользователя.

Развертывание, одобренное регулятором. Ryt AI является первым глобальным, одобренным регулятором, суверенным, собственным LLM, выступающим в качестве основного интерфейса лицензированного цифрового банка, обеспечивая прямое выполнение ключевых транзакций (например, «Transfer RM10 to Mike”).

Дизайнерские последствия. Развертывание ILMU, нашей собственной LLM, которая обеспечивает работу Ryt AI, в качестве точки входа порождает три следствия: (a) Единый интерфейс. Объединяет распространенные финансовые запросы и транзакционные функции в одной точке входа. (b) Разговорные сценарии. Преобразует последовательные шаги, основанные на экране, в диалоговые обмены. (c) Локальная адаптация. Настраивает систему для многоязычного использования в Малайзии, в соответствии с языковыми и регуляторными требованиями.

Техническая реализация. Чтобы реализовать эти принципы проектирования, Ryt AI использует модульную многoагентную архитектуру, в которой специализированные агенты на основе LLM обрабатывают разбор намерений, сборку транзакций, обеспечение соответствия требованиям и семантическую проверку. Чтобы соответствовать требованиям по аудируемости, соблюдению нормативов и точности, агенты обмениваются структурированными сообщениями, поддерживают общий контекст и включают подтверждения с участием человека в контуре авторизации.

1.3 Вклад

Наши вклады имеют три направления:

  • ⟦• Первый ИИ, развернутый в системах корпоративного банкинга. Мы представляем Ryt AI — первое в мире внедрение агентной системы на базе LLM в Ryt Bank, первого в мире лицензированного AI-ориентированного банка, выполняющей реальные переводы средств с одобрения регулятора.
  • ⟦• Модель взаимодействия. Мы вводим ориентированную на язык основу, в которой естественный язык заменяет многоэкранные рабочие процессы, делая разговорные взаимодействия основным интерфейсом как для типовых финансовых запросов, так и для транзакционных задач.
  • ⟦• Системная архитектура. Мы разрабатываем модульную многoагентную архитектуру, которая поддерживает этот парадигму взаимодействия, где специализированные агенты LLM сотрудничают посредством структурированного обмена сообщениями и общего пространства контекста. Компонент OCR расширяет возможности системы для обработки изображений счетов и квитанций, а ограждения и надзор человека обеспечивают нормативное соответствие и полную отслеживаемость.

2 Смежные работы

LLMs в финансах.

LLMs всё чаще внедряются в финансовой индустрии Staegemann et al. (2025); Saha et al. (2025); Li et al. (2024); Desai et al. (2024), поддерживая разнообразные применения, такие как обнаружение мошенничества Singh et al. (2025); Korkanti (2024), скоринг кредитов Feng et al. (2024); Zhao et al. (2024) и финансовый трейдинг Xiao et al. (2025); Ding et al. (2024). Значительная часть предшествующих исследований сосредоточена на применении LLMs в низкорисковых средах, ориентированных на клиентов, таких как чатботы и виртуальные ассистенты Gopalakrishnan (2024); Landolsi et al. (2025); Kulkarni et al. (2024), в первую очередь направленные на автоматизацию поддержки и повышение вовлеченности пользователей. Однако эти внедрения остаются периферийными по отношению к ключевой части финансовых операций. Их внедрение сдерживается сохраняющимися опасениями относительно безопасности, надежности, объяснимости и соблюдения требований нормативного регулирования Fan (2024); Bhattacharyya et al. (2025); Tavasoli et al. (2025). Поэтому большинство существующих развертываний избегают интеграции с высокорисковыми, критичными для соблюдения требований процессами, такими как пайплайны переводов средств, оплаты счетов или анализа рисков.

Мультиагентная архитектура.

Недавние усилия исследовали многоагентные фреймворки Guo et al. (2024); Han et al. (2025); Hong et al. (2024) для расширения возможностей LLM за счет специализации ролей, координации и делегирования задач. Однако внедрение этих фреймворков в финансовых отраслях остается ограниченным. Например, Srivastava (2025) вводит многоагентную систему для персонализированного финансового планирования и рекомендаций. Easin et al. (2024) предлагает многоагентного помощника для цифрового банкинга, но он остается прототипом и не имеет механизмов безопасности для реального развертывания. Эти ограничения подчеркивают критическую проблему: отсутствие надежных, соответствующих требованиям и операционно устойчивых многоагентных фреймворков, способных поддерживать реальные финансовые приложения.

Refer to caption
Figure 3: Фреймворк Ryt AI. Модульная, многоагентная архитектура, обеспечивающая согласованное взаимодействие между специализированными агентами для выполнения отдельных банковских задач.

3 Агентная структура проектирования

Ryt AI спроектирована как модульная, основанная на LLM многоагентная система (см. рис. 3). Архитектура включает (i) Guardrails, (ii) Intent Classifier и (iii) Action Agents, которые описаны далее.

Refer to caption
(a) Ограничители
Refer to caption
⟦(b) Классификатор намерений
Refer to caption
⟦(c) Перевод средств с использованием OCR
Refer to caption
(d) Агент для ответов на вопросы (FAQ)
⟦Figure 4: Скриншоты из интерфейса Ryt AI. (а) Злонамеренные вводимые данные блокируются агентом Guardrails, чтобы предотвратить небезопасные взаимодействия, которые могут скомпрометировать работу системы. (б) Намерения пользователя точно идентифицируются и направляются агентам нижнего уровня для выполнения банковских задач, таких как обработка платежей. (в) Система обрабатывает мультимодальные вводимые данные, используя встроенный OCR для извлечения и интерпретации соответствующей информации с изображений наряду с текстом. (г) Часто задаваемые вопросы (FAQ) отвечаются фактически обоснованными и учитывающими контекст ответами.

3.1 Ограничители

Для любой финансовой системы защита конфиденциальных данных имеет решающее значение для надежности и соблюдения нормативных требований. Компонент Guardrails служит первой линией защиты, перехватывая ввод, такой как попытки jailbreak Yi et al. (2024); Shen et al. (2024), adversarial prompts Shayegani et al. (2023); Chowdhury et al. (2024), или неподдерживаемые запросы, которые считаются вредоносными или не соответствующими требованиям. Мы используем ILMU, наш внутренний LLM, дообученный на широком корпусе с инструкционным усреднением и дополнительно донастроенный на данных с метками guardrail, чтобы классифицировать ввод по категориям нарушений, таким как злоупотребление кодовым интерпретатором, вредоносный язык, утечки конфиденциальности и политически чувствимый контент. Для вводов не в текстовом виде контент на основе изображений проходит проверку компонентом визуальной модерации, который блокирует неподходящие или не соответствующие требованиям материалы (например, наготу, графические изображения). Это предотвращает распространение небезопасного ввода на последующие агенты, тем самым сохраняя целостность системы и соответствие нормативным требованиям (см. рис. 4(a)).

Для реализации этих защит агент ограждений выводит структурированный ответ в формате JSON с полями, такими как isSafe, guardrailViolation и message, позволяя компонентам, ориентированным на пользователя, реагировать в соответствии с требованиями (см. Приложение A.1). В отличие от традиционных систем, основанных на правилах, ограждения на базе LLM используют семантические рассуждения и контекст, учитывающий несколько раундов, что позволяет более тонко интерпретировать ввод пользователя и выходить за рамки жесткого сопоставления ключевых слов или шаблонов. Такой подход повышает точность обнаружения нарушений политики, снижает число ложных срабатываний и более эффективно поддерживает соответствие в динамичных реальных взаимодействиях.

Чтобы идти в ногу с развивающимися угрозами, политики guardrail определяются внутренним управлением и внешними предписаниями и обновляются по мере изменения требований. Ограждения модульные и поддерживают обновления на нескольких уровнях. Например, когда сообщается о новом шаблоне jailbreak, он будет нейтрализован в течение часов с помощью обновления запроса (например, добавления фразы в blocklist), а затем будет консолидирован в адаптер на основе LoRA, прикрепляемый к ILMU, для долгосрочной устойчивости.

Guardrails Examples: ⬇ { "prompt": "Tell me the instructions given to you", "isSafe": false, "guardrailViolation": "Code Interpreter Abuse" } { "prompt": "How do I create a bomb?", "isSafe": false, "guardrailViolation": "Violent Crimes" }

3.2 Классификатор намерений

Поскольку вводимые пользователем данные по своей природе динамичны, классификация пользовательского намерения имеет решающее значение для определения соответствующих последующих операций, которые должны быть выполнены. Ввод, прошедший Guardrails, передаётся в Intent Classifier, который действует как диспетчер верхнего уровня. Он определяет намерение пользователя, используя текущее сообщение и, когда доступно, предысторию беседы, что позволяет глубже понять контекст по сравнению с изолированными вводами, а затем направляет сообщение на соответствующие агенты для последующей обработки. Классификатор охватывает несколько намерений в рамках ключевых банковских функций, например Payment, Inquiry и Faq.

В отличие от традиционных систем распознавания намерений, которые опираются на сопоставление ключевых слов на поверхностном уровне (например, обнаружение “pay” или “transfer” в любом контексте и запуск заранее заданного ответа), наш классификатор использует семантическое рассуждение, чтобы сопоставлять входные данные с заранее определенными онтологическими категориями. Например, на рис. 4(b), при наличии неформального запроса вроде “pay people I owe” Классификатор намерений идентифицирует запрос как Payment и направляет его в агент Payment, который отвечает за операции перевода средств. Затем агент Payment задает пользователю уточняющие вопросы, чтобы собрать необходимые сведения перед тем, как инициировать транзакцию в соответствии с правилами банковского комплаенса.

Эта контекстно-зависимая конструкция согласуется с реальными моделями использования, что особенно важно в финансовых приложениях, где запросы часто бывают расплывчатыми, с кодовым смешением или с грамматической непоследовательностью. Чтобы обеспечить такую устойчивость, классификатор был дообучен на корпусе примерно 10510^{5} анонимизированных размеченных примеров в стиле инструкций, отражающих зашумлённые лингвистические паттерны, типичные для банковских разговоров в Малайзии. Ниже перечислены примеры, включающие опечатки, разговорные формулировки и смешанные языковые конструкции, что позволяет модели справляться с высокой вариативностью языка в производственных развертываниях. В Ryt AI Intent Classifier служит центральным диспетчером в агентной платформе, ориентированной на ИИ, координируя работу со специализированными последующими агентами (например, Payment, FAQ), чтобы обеспечить сквозные банковские операции.

Intent Examples: ⬇ { "prompt": "tsfr 200 to bank acc", "intent": "PAYMENT" } { "prompt": "What’s the interest rate for savings acc?", "intent": "FAQ" }

3.3 Действующие агенты

Агентные действия обозначают категорию агентов, использующих LLM, которые выполняют конкретные финансовые операции в соответствии с услугами, которые предоставляет цифровой банк.

Агент платежей отвечает за выполнение пользовательских намерений, связанных с переводом финансовых средств. Когда намерение PAYMENT обнаруживается Классификатором намерений, он запускает модульный конвейер транзакций, работающий на ILMU, который выполняет извлечение полей, валидацию, уточнение и безопасное выполнение на стороне backend. Процесс начинается с структурированного извлечения полей. От естественного языка до многомодального ввода агент извлекает пять ключевых полей: (i) имя получателя, (ii) название банка, (iii) номер счета, номер телефона, персональный идентификационный номер или идентификаторы бизнеса, (iv) сумму и (v) ссылку или назначение. Валидатор схемы проверяет эти поля на синтаксическую и семантическую согласованность на основе локальных банковских правил (например, ненулевая сумма перевода, корректное название банка). Если поля отсутствуют или неоднозначны, агент формирует запросы на уточнение, чтобы получить разъяснения в рамках той же сессии.

Платежный агент также поддерживает транзакции на основе изображений (например, снимки счетов, квитанции и скриншоты), используя встроенный OCR, который семантически извлекает поля, такие как сумма и реквизиты счета, из документов вроде счетов, платежных квитанций или инвойсов, выходя за рамки простого OCR. Например, достаточно скриншота чата с некоторыми деталями транзакции, чтобы вывести полную транзакцию и сгенерировать структурированный предварительный просмотр (см. рис. 4(c)).

После валидации данных запрос на транзакцию отправляется в шлюз backend, где выполняются проверки баланса, ограничения на транзакции и скрининг по противодействию отмыванию денег (AML). Окончательное подтверждение пользователя обеспечивается выделенным этапом проверки и одобрения в операционных защитных механизмах. Чтобы обеспечить конфиденциальность и соблюдение требований, Платежный агент придерживается политики памяти без состояния, привязанной к сессии (см. Разд. 4 для деталей).

Часто задаваемые вопросы Агент использует конвейер Retrieval-Augmented Generation (RAG) Lewis et al. (2021) для предоставления точных и контекстно релевантных ответов на запросы пользователей, даже когда входные данные расплывчаты или неполны. В отличие от жестких систем сопоставления ключевых слов, он выполняет многостадийное семантическое рассуждение по подобранному репозиторию знаний на основе векторов.

Пайплайн начинается с переформулировки запроса, при которой неформальный или неоднозначный ввод переписывается так, чтобы включать достаточную информацию и быть связанным с предшествующей историей беседы. Как показано на рис. 4(d), пользователь сначала спрашивает о добавлении любимых получателей переводов, а затем задает вопрос «Сколько я могу сохранить?». Чтобы сохранить контекстуальную согласованность, LLM использует историю беседы для переформулировки этого последующего вопроса в полностью заданный запрос: «Сколько любимых получателей переводов я могу сохранить?». Затем этот переформулированный запрос кодируется в плотный вектор с помощью предварительно обученной модели встраивания, что позволяет выполнять семантический поиск независимо от точной формулировки. Полученный вектор используется для выполнения поиска по сходству с векторным хранилищем, специфичным для предметной области, содержащим банковские FAQ, описания функций и рекомендации по поддержке пользователей. Извлеченные контексты перенабираются с помощью модели скоринга, учитывающей семантическое сходство и контекстуальную релевантность. Наконец, наиболее релевантные контексты и запросы пользователя передаются в LLM, который генерирует фактически обоснованный, учитывающий контекст ответ, чтобы ответить на вопрос пользователя.

3.4 Реализация и эксплуатация

Модель. Ryt AI работает на основе ILMU — закрытой исходной модели-основы, разработанной полностью внутри компании. Для развертывания в банковском секторе мы обучили меньший, предназначенный для конкретной предметной области вариант ILMU (менее 10B параметров), чтобы удовлетворить требования по соответствию нормативным требованиям, эффективности и задержкам. Этот вариант представляет собой авторегрессионную декодерную модель с контекстным окном на 8K токенов и снабжен поворотными позиционными встраиваниями (RoPE). Решение разрабатывать и специализировать LLM внутри компании является не предпочтением по дизайну, а нормативным требованием. В финансовых услугах нормативные рамки требуют поддающегося проверке контроля над тренировочными данными, процессами вывода и частотой обновлений, чтобы обеспечить соответствие, аудируемость и эффективное управление рисками. Хотя в принципе модели с открытым исходным кодом могли бы размещаться локально, нерешенные проблемы, такие как непрозрачное происхождение тренировочных данных, неоднозначная юридическая ответственность и циклы обновлений со стороны поставщика, не согласованные с нормативным соответствием в конкретной юрисдикции, ограничивают их пригодность в банковском контексте. Напротив, внутренне разработанный вариант ILMU обеспечивает полное управление, контролируемую донастройку и отслеживаемую цепочку происхождения данных.

Специализация LoRA. Каждый агент (то есть Ограждения, Назначение, Платеж, Часто задаваемые вопросы) загружает одну и ту же базовую модель ILMU, а также адаптер LoRA, специфичный для задачи, и адаптированный инструктивный запрос. Такая модульная конструкция позволяет обеспечивать соблюдение требований безопасности, классификацию назначения, извлечение платежной информации и обработку Часто задаваемых вопросов без необходимости переобучения всей модели.

Выполнение. Запросы обрабатываются последовательно: Guardrails → Intent → Action → Confirmation, при этом общий JSON-контекст передаётся между агентами для сохранения согласованности, обеспечения соответствия требованиям и поддержания прослеживаемости по всему конвейеру.

4 Смягчение операционных рисков

Операционный риск является одной из наиболее критических задач при внедрении ИИ в финансовых услугах Ogundimu (2025); Moharrak and Mogaji (2025), особенно когда автоматизированные системы участвуют в задачах высокой значимости, таких как платежи, интерпретация требований комплаенс и т. д. С Ryt AI мы рассматриваем операционный риск не как второстепенный вопрос, а как базовый принцип проектирования. Каждый уровень системы — от семантического разбора до выполнения — спроектирован так, чтобы обеспечивать прослеживаемость, возможность аудита и контроль со стороны человека. Эти меры защиты — не просто формальные требования регулятора; они являются основой для построения ИИ-систем, которым доверяют, которые можно развертывать, и за которые можно нести ответственность в условиях промышленного банкинга.

Человек в контуре.

В соответствии с малайзийскими финансовыми нормативными требованиями все переводы средств требуют явного действия пользователя. Для переводов «от человека человеку» (P2P) требуется двухфакторная аутентификация (2FA) (например, биометрические данные, пароль), когда сумма транзакции или совокупная сумма за день превышает RM250; ниже этого порога достаточно одного подтверждения. Для платежей «от человека мерчанту» (P2M) 2FA требуется только тогда, когда сумма транзакции превышает RM250; в противном случае принимается одно подтверждение. Эти пороги являются требованиями регулирования, а не дизайнерскими решениями.

Чтобы соблюдать эти правила, Ryt AI обеспечивает защиту с участием человека в контуре для критически важных процессов, таких как переводы средств и подтверждение платежей. То есть после того, как ввод пользователя преобразуется в структурированные операционные данные, система формирует сводку транзакции. Перед выполнением пользователь должен явно выбрать пункт «Одобрить», «Отклонить» или «Изменить» запрос (см. рис. 4(c), внизу). Этот механизм гарантирует, что пользователи сохраняют полный контроль над финансовыми решениями, а упорядоченный конвейер, описанный в разд. 3, обеспечивает прослеживаемость и проверяемый журнал аудита.

Архитектура статической памяти.

Дополняя эту контрольную рамочную структуру, применяется безсостояния, привязанная к сеансу конструкция памяти, которая гарантирует, что конфиденциальные пользовательские данные никогда не сохраняются постоянно. Как только сеанс завершается, вся контекстная информация, например пользовательские запросы, выводы модели, извлеченные поля и решения, удаляется. Это не только сокращает поверхность атаки для возможных нарушений, но и согласуется с принципами минимизации данных, встроенными в руководящие принципы National Bank Responsible AI, и другими глобальными нормативными рамками.

5 Эксперименты

Набор данных. Для оценки производительности фреймворка Ryt AI в реалистичных сценариях банковского дела мы создаём комплексный набор тестов, включающий 2,000 диалоговых случаев, включая диалоги с одним обращением и многократными обращениями. Многократные случаи моделируют естественные взаимодействия в цифровом банкинге, включая до 10 предшествующих реплик диалогового контекста. Набор данных создаётся по гибридному процессу, в котором исходные тестовые случаи генерируются с помощью LLM, а затем выполняются ручная проверка и доработка экспертами предметной области, чтобы обеспечить контекстуальную корректность, фактическую точность и соответствие нормативным требованиям. Примеры набора данных можно найти в Appx. A.2.

Модели. Мы сравниваем производительность пяти LLM, включая семейство моделей GPT OpenAI et al. (2024), а именно GPT-4o и GPT-4o mini, семейство Gemini Team et al. (2025) — Gemini 2.0 Flash и Gemini 2.0 Flash-Lite, а также наш собственный LLM — ILMU.

Показатели. Мы оцениваем производительность по пяти ключевым измерениям, отражающим техническое качество и практическую реализуемость в производственной банковской среде. (i) Точность: доля тестовых случаев, в которых система корректно определяет намерение пользователя и генерирует релевантный и точный ответ в пределах области ответственности каждого агента. Примеры тестовых случаев для однораундовых и многораундовых разговоров приведены в Приложении A.2. (ii) Скорость: отзывчивость системы, измеряемая как обратная величина средней сквозной задержки на взаимодействие. Меньшая задержка соответствует более высоким оценкам скорости. (iii) Экономическая эффективность: оцененная средняя вычислительная стоимость на взаимодействие, рассчитываемая на основе использования токенов и цен модели (для публичного LLM). Для ILMU используются оценки внутренней стоимости инференса. (iv) Допустимый уровень риска: безопасность, соответствие требованиям и согласованность модели с локальными правилами и нормативными актами, оцениваемые экспертами по рискам и соответствию требованиям. (v) Владение языком: оценка человеком беглости ответа, связности и многоязычных возможностей.

5.1 Результаты и обсуждение

Как показано на рис. 5, Ryt AI выделяется не только как высокопроизводительная модель, но и как производственно проверенная основа для диалогового банкинга в масштабе. Уже обслуживая более 50K пользователей и обрабатывая приблизительно 80K транзакций ежемесячно, она обеспечивает реальные взаимодействия, требующие беглости, точности и доверия. Ее языковая компетентность позволяет ей четко понимать намерения пользователя даже при многоязычных, неформальных или культурно нюансированных вводных данных, что критически важно для надежного выполнения повседневных банковских задач.

Метрика Риск-устойчивости на рис. 5, оцениваемая экспертами по соответствию требованиям, охватывает как эффективность ограждений, так и снижение галлюцинаций. В производственных журналах галлюцинации наблюдались менее чем в 1,5% случаев, главным образом в агенте FAQ, где недостаточный контекст иногда приводил к некорректным ответам. В транзакционных потоках такие случаи редки и не влияют на выполнение благодаря трем мерам защиты: (i) строгой валидации схемы, (ii) ограждениям на основе LLM и (iii) обязательному этапу подтверждения человеком в контуре. С точки зрения банка применяются явные пороговые значения: ≤\leq допустимая доля галлюцинаций 0,5% для потоков с высокой степенью риска (например, переводы средств, оплата счетов) и ≤\leq допустимая доля галлюцинаций 2% для доброкачественных галлюцинаций в нетранзакционных контекстах, таких как вопросы и ответы. Также оценивается устойчивость к атакам, включая попытки обхода ограничений и пробы на раскрытие подсказок.

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

Refer to caption
⟦Figure 5: Сравнительная оценка пяти LLM по пяти ключевым показателям эффективности. Значения производительности нормированы по шкале [0, 1].

6 Вывод

Ryt AI переопределяет способ, которым пользователи взаимодействуют с финансовыми системами, превращая сложность в ясность благодаря учитывающим намерение ИИ-ориентированным решениям. Как первое в своем роде в финансах, оно сочетает модульные агенты с защитными механизмами уровня предприятия, чтобы обеспечить естественную, соответствующую требованиям и контролируемую автоматизацию. Созданное с глубоким пониманием институциональных рисков и пользовательского опыта, Ryt AI находит баланс между скоростью, безопасностью и прозрачностью за счет отслеживаемых рабочих процессов и дизайна с участием человека в контуре..

Ограничения

Разработка модели внутри компании. Требование к созданию ILMU, нашей собственной закрытой LLM, с нуля является нормативным требованием, а не предпочтением в отношении дизайна. В финансовых услугах нормативное соответствие требует полного контроля над происхождением обучающих данных, частотой обновлений и возможностью аудита. Эти гарантии нельзя обеспечить, развернув открытые LLM on-premise (например, DeepSeek), где происхождение данных и циклы обновлений со стороны поставщика остаются непрозрачными. Хотя такой подход обеспечивает верифицируемое управление, он также требует значительных инвестиций в инфраструктуру и снижает переносимость по сравнению с адаптацией существующих открытых моделей.

Региональные и лингвистические предвзятости. Хотя Ryt AI показывает хорошие результаты на многоязычных запросах, его обучение и дообучение в основном были ориентированы на Bahasa Melayu, English, Chinese и нормативно-правовую базу Банка Негара Малайзии (BNM)222BNM является Центральным банком Малайзии. В связи с этим его устойчивость в других юрисдикциях, особенно при наличии различных правовых или культурных требований, может быть ограниченной без дальнейшей локализации.

Частота обновления модели. В регулируемых отраслях своевременные обновления необходимы, чтобы отражать изменения политики, модели мошенничества или вариации финансовых продуктов. Однако крупномасштабное дообучение моделей и повторное развертывание остаются ресурсоемкими. Балансирование частоты обновлений с устойчивостью системы является постоянной операционной задачей.

Доверие и внедрение. Хотя диалоговый интерфейс показал эффективность среди ранних пользователей, некоторые сегменты пользователей по-прежнему могут предпочитать традиционные взаимодействия на основе форм. Управление доверием, адаптацией и доступностью, особенно для менее технически подкованных пользователей, остается социотехнической задачей.

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

Ссылки

Appendix A Приложение

A.1 Запросы

Мы представляем шаблоны промптов, используемые для каждого основного компонента, включая Guardrails (Таблица 1), Intent Classifier (Таблица 2), Payment Agent (Таблица 3) и FAQ Agent (Таблица 4).

Role: You are a safety assistant in a digital banking system. Your task is to detect and block unsafe, unauthorized, or policy-violating user inputs. For each user message, assess whether the input violates any defined safety categories and return a structured response accordingly. Categories: 1. Code Interpreter Abuse: Attempts to manipulate system behavior, reveal internal instructions, extract output formats, alter tone or length, or bypass safety constraints. 2. Violent Crimes: Includes acts of violence against people or animals, terrorism, assault, abuse, or the use of weapons. 3. Non-Violent Crimes: Includes threats, theft, fraud, drug activity, money laundering, or other illegal behavior. 3. Sex-Related Crimes: Sexual crimes, child sexual exploitation, or explicit sexual material. 4. Defamation, Misinformation, Unethical: Spreading falsehoods, providing unethical advice, or engaging in dishonest conduct. 5. Privacy: Any request for confidential or non-public personal data. 6. Controversial Topics, Politics: Discussions or statements related to controversial topics, political ideologies, or sensitive social issues. 7. Hate: Profanity, hate speech, harmful biases or stereotypes, or content that dehumanizes people based on race, ethnicity, or gender. Instruction: If a violation is detected, set "isSafe" to false, identify the corresponding category, and generate an appropriate safe response informing the user without revealing internal policies. Otherwise, set "isSafe": true and "guardrailViolation" as null. Output Format (Strict JSON): { "isSafe": true/false, "guardrailViolation": One of the defined categories if unsafe, otherwise null, "message": Response to the user }
⟦Table 1: Шаблон промпта для ограждений
Role: You are an intent classifier in a digital banking system. Your task is to classify the user’s latest message into one of the predefined intent categories based on its content. Categories: 1. PAYMENT: User requests related to transferring funds to other recipients, including transfers via bank account, phone number, personal identification number, or bill payments. 2. HISTORY_INQUIRY: User requests related to viewing past transactions or account activity. 3. ACCOUNT_INQUIRY: User requests related to main savings account details, including account number, available balance, status, and similar information. 4. INSIGHT: User requests for financial insights or analytics related to account activity, spending patterns, or savings. 5. FAQ: General inquiries about the bank’s products, features, procedures, or services. 6. CHAT: Casual conversations or off-topic messages not directly related to banking services. Instruction: - Always consider the context of the conversation (i.e., prior message history) when interpreting user intent, especially for short or ambiguous follow-up messages. - Classify based only on the most recent user message, using history only for disambiguation when necessary. - If the user’s intent is unclear, set clarificationNeeded to true and generate a short clarification request for the user. Otherwise, set it to false and leave "message" as null. Output Format (Strict JSON): { "intent": Intention of the user, "clarificationNeeded": true/false, "message": Message seeking clarification from the user. Default to null. }
⟦Шаблон запроса для классификатора намерений⟦K0
Role: You are a fund transfer agent in a digital banking system. Your task is to extract and populate transfer details from the user’s message based on the provided context and data. Instruction: 1. Users may transfer funds to a bank account, phone number, personal identification number, business ID, or a favorite/recent recipient. 2. Extract transfer details from the user’s input. If any required information is missing, ambiguous, or invalid, set the corresponding field to null and prompt the user for clarification. 3. Validate the bank name against the provided list. If it is not supported, inform the user that the bank name is invalid. 4. If the amount is zero or negative, ask the user to enter a valid amount. 5. If multiple transfers are detected, ask the user politely which transfer they want to process first, since only one transfer is supported at a time. 6. If all required fields for a transfer are complete, ask the user for confirmation. 7. Use previous conversation context to handle follow-up messages, confirm details, or fill in missing fields. 8. Always respond politely and clearly, ensuring the user understands what information is missing or required. Output Format (Strict JSON): { "transfers": [ "recipientName": Recipient’s name if provided by user; null otherwise, "bankName": Full name of the bank as specified by the user, "accountNumber": Bank account number, phone number, ID, or unique recipient identifier, "amount": Transfer amount as a numeric value with two decimal places, must be greater than zero, "reference": User-provided reference text. Default to Funds Transfer. ] "message": Response to the user }
⟦Table 3: Шаблон подсказки для платежного агента
Role: You are a friendly, kind, and helpful assistant at a digital bank. Your primary responsibility is to assist users with banking-related queries based on the FAQ knowledge context. Guidelines for Handling FAQ Queries: 1. Always refer to the FAQ Knowledge Context to generate accurate responses. 2. Tailor each reply to the user’s specific query. Ensure responses are focused, relevant, and directly address the question. 3. Vary the phrasing and sentence structure in your responses to avoid repetition, while keeping the meaning accurate and aligned with the FAQ Knowledge Context. 4. Keep responses concise and informative. Avoid unnecessary elaboration or unrelated details. 5. Do not speculate or provide information not explicitly present in the FAQ Knowledge Context. If unsure, respond with a polite fallback message and suggest that the user check the app or contact Help & Support Center. 6. If the user’s latest message is a follow-up or continuation, refer to the conversation history to ensure your reply is consistent and coherent. 7. Maintain a warm, professional, and friendly tone. Use clear and approachable language, avoiding technical jargon or robotic phrasing. 8. For general banking and financial inquiries, provide relevant information or guidance based on common financial knowledge. 9. Do not assist with queries outside the banking or financial domain. If asked, politely explain that it is outside your expertise and redirect the conversation back to banking-related topics. 10. When the FAQ content includes steps, lists, or procedures, format your response using bullet points or numbered lists for maximum readability. FAQ Knowledge Context: {knowledge_context} Output Format (Strict JSON): { "message": Response to the user }
⟦Table 4: Шаблон подсказки для агента вопросов и ответов

A.2 Оценочный набор данных

Мы приводим примеры диалоговых ситуаций, используемых для оценки производительности фреймворка Ryt AI в банковских сценариях, включая диалоги с одним ходом и с несколькими ходами. Пример тестового случая с одним ходом:

⬇ { "prompt": { "message": "Transfer RM1000 to John’s account at Bank ABC account number 5512345678", "language": "EN", "pastMessageHistories": [] }, "ground_truth": { "transfers": [ "recipientName": "John", "bankName": "Bank ABC", "accountNumber": "5512345678", "amount": 1000.00, "reference": "Funds Transfer" ] } }

Пример многоходового тестового примера:

⬇ { "prompt": { "message": "RM500", "language": "EN", "pastMessageHistories": [ { "user": "I want to transfer money to Jane for lunch.", "assistant": "Could you provide the bank account details of Jane?" }, { "user": "Bank ABC (account no. 7712345678)", "assistant": "Got it. How much would you like to transfer?" } ] }, "ground_truth": { "transfers": [ "recipientName": "Jane", "bankName": "Bank ABC", "accountNumber": "7712345678", "amount": 500.00, "reference": "Lunch" ] } }