K3 – пруденциальный норматив, установленный Национальным Банком Республики Казахстан, который определяет максимальный размер риска на одного заемщика. Методику расчета этого норматива определяет постановление Правления Национального Банка №170 от 13.09.2017. В целях расчета этого норматива группа заемщиков, связанных между собой по нескольким критериям, рассматривается как один заемщик. Для того, чтобы вычислить значение норматива K3, банку нужно определить группы связанных заемщиков среди своих клиентов.
Постановление задает несколько критериев, по которым заемщики признаются связанными (аффилированными). Аффилированность может возникнуть в результате родства крупных участников или руководителей юридических лиц, из-за наличия договора доверительного управления между заемщиками, предоставления одним заемщиком гарантий по обязательствам другого и т.д. Цепочки связей, в результате которых образуются группы аффилированных заемщиков, могут быть достаточно длинными. Перед банками встает непростая задача реализовать алгоритм автоматической группировки заемщиков, который будет пересматривать состав групп при появлении новой информации.
Рассмотрим простой пример. Пусть существуют две группы заемщиков, связанные так, как показано на рисунке ниже. Затем появляется информация о том, что Jane Doe является акционером "Minimarkets LLC". В результате появления такой связи обе группы заемщиков должны быть объединены в одну.
Такая задача идеально подходит для того, чтобы решать ее с помощью правил логического вывода на графе. Исходную информацию для решения задачи удобно представить в виде графа: заемщики, договоры доверительного управления, предметы залога и другие объекты можно представить как вершины графа, а отношения между ними – как рёбра. Типы вершин и рёбер образуют "словарь" предметной области, который можно представить в виде машинно-читаемой онтологической модели. Затем в терминах этой онтологии можно сформулировать правила, в соответствии с которыми будут устанавливаться связи между элементами модели.
Создадим простую онтологическую модель, в которой будут присутствовать классы (типы сущностей) "Персона" и "Организация", а также свойства, которыми могут быть связаны между собой объекты этих классов: "является учредителем", "является родственником", "является руководителем" и др. В терминах такой модели легко сформулировать правила, например:
ЕСЛИ А – Организация, B – Персона, B является учредителем A, ТО A является аффилированным лицом с B, B является аффилированным лицом с A
Свойство "является аффилированным лицом" необходимо сделать транзитивным. Тогда машина логического вывода будет делать вывод о том, что если A аффилирован с B, B аффилирован с C, то A аффилирован с C. Этого достаточно, чтобы начать строить длинные цепочки связей.
Например, если существуют организации A и C, учредителями которых является одна и та же персона B, то благодаря приведенному выше правилу и транзитивности свойства "является аффилированным лицом" будет автоматически вычислено, что организации A и C аффилированы.
Добавив другие правила, формулировки которых вытекают из постановления Правления Национального Банка, получим модель, в которой отношения аффилированности между участниками групп будут вычисляться автоматически. Каждый участник такой группы будет связан свойством "является аффилированным лицом" со всеми остальными ее участниками.
Как реализовать на программном уровне вычисление групп заемщиков описанным способом? Необходима программная система, которая способна обрабатывать большой объем часто меняющихся данных, представленных в соответствии с онтологической моделью, с помощью правил логического вывода. Реализация на графе без концептуальной схемы и правил, с выражением логики на языке Gremlin или аналогичном, проигрывает в легкости управления логикой при изменении бизнес-требований и возможностях контроля целостности данных. Традиционные графовые СУБД, предназначенные для хранения онтологий – хранилища триплетов, RDF triple stores – не оптимальны для обработки данных в необходимом по условиям задачи режиме. Наше решение, DataVera EKG Platform, позволяет обойти ограничения, связанные с объемом и частотой обновления данных, а также предоставляет функционал, отсутствующий в большинстве реализаций графовых СУБД.
Платформа состоит из двух компонентов. Обработку информации обеспечивает компонент виртуализации данных, DataVera EKG Provider. Он предоставляет программный интерфейс (API), с помощью которого можно работать с данными, структура которых соответствует онтологической модели. Физически данные при этом хранятся в реляционной СУБД. DataVera EKG Provider обеспечивает:
- контроль прав доступа к информации,
- сохранение сведений обо всей истории изменения каждого объекта,
- применение правил контроля целостности и правил логического вывода в соответствии со спецификацией SHACL.
Взаимодействовать с данными можно как с помощью языка запросов SPARQL, входящего в стек технологий работы с онтологическими моделями, так и с помощью REST API или механизма подписки через Kafka. Другой компонент платформы, DataVera EKG Explorer, предоставляет пользовательский интерфейс для работы с данными.
Чтобы продемонстрировать решение задачи определения групп аффилированных контрагентов, мы создали стенд, структура которого показана на следующем рисунке. В графовой СУБД класса RDF triple store (Apache Fuseki) хранится в машинно-читаемом виде концептуальный уровень онтологической модели. В реляционной СУБД Postgres находятся фактические данные о контрагентах – организациях и персонах. Импорт фактических данных в платформу из корпоративных систем банка происходит с помощью REST API или очередей Kafka.
Структура фрагмента несложной онтологической модели для нашего сценария показана на следующем рисунке.
Приведем пример правила SHACL, делающего вывод об аффилированности двух агентов на основании существования договора доверительного управления между ними:
Каждое правило SHACL применимо к определенному классу(-ам) онтологии. Приведенное здесь правило применимо к объектам класса Trust_agreement. Правила применяются в тот момент, когда происходит изменение данных о любом объекта этого класса.
Идентификатор измененного объекта подставляется в SPARQL-запрос, представляющий «тело» правила, вместо переменной $this. Таким образом, при создании или изменении любых данных договора устанавливается отношение аффилированности между участвующими в нем организациями – принципалом и управляющим. Все факты, полученные в результате работы правил логического вывода, помечаются в базе данных как результат действия правила. Если в будущем объект будет удален или изменен так, что условие правила перестанет выполняться, выведенные факты будут автоматически удалены. API EKG Provider предоставляет также специальный метод, позволяющий актуализировать весь логический вывод по определенному объекту – например, в случае, если изменения в данные были внесены напрямую в СУБД в обход API платформы.
Вывод одних новых фактов может породить появление следующих новых фактов. Вернемся к ситуации на первом рисунке этой статьи, где были показаны две группы аффилированных контрагентов. Пусть в базе данных появляется информация о том, что Jane Doe является акционером "Minimarkets LLC". Сработает правило, которое установит между этими двумя контрагентами отношения аффилированности. Поскольку свойство "является аффилированным" (hasK3GroupRelative) транзитивно, установление новой связи такого типа приведет к появлению новых фактов по цепочке, которые в конце концов свяжут между собой всех контрагентов обеих групп.
В этом и состоит основная ценность правил логического вывода для описываемой нами задачи: состав групп аффилированных контрагентов автоматически меняется по мере того, как меняются факты, записанные в базу данных. Ценность же онтологий состоит в том, что описание самой структуры данных и логику правил аналитик может изменить в любой момент без вмешательства в программный код или в физическую структуру СУБД, без остановки работы системы – достаточно внести соответствующие изменения в модель. Если в какой-то момент выйдет новая редакция постановления, устанавливающего критерии аффилированности, внести изменения в логику работы программной системы можно будет за считанные минуты.
Покажем, как пользователь и разработчик могут взаимодействовать с данными, представленными в соответствии с моделью. Пользователь работает с данными через интерфейс DataVera EKG Explorer. Здесь он может фильтровать, сортировать, экспортировать в Excel данные, в том числе те, которые получены в результате работы правил логического вывода.
Разработчик и программный код прикладных компонентов взаимодействуют с платформой путем обмена сообщениями через очереди Kafka или через REST API. Через Kafka удобно организовать экспорт в EKG Provider актуальных данных о бизнес-объектах из корпоративных систем банка. Через REST API удобно получать сведения о результатах работы логического вывода. Например, чтобы узнать, с какими заемщиками аффилирована компания "Premium Estate", нужно выполнить запрос к REST-сервису:
В ответе сервиса будут перечислены значения всех свойств объекта. Для свойств, значения которых получены в результате работы правил логического вывода, в атрибуте Inferred приводится идентификатор правила, которое привело к появлению в базе нового факта.
Можно воспользоваться и SPARQL-интерфейсом для работы с данными. Например, пусть нас интересуют все владельцы компаний, аффилированных с "Fast food delivery". Чтобы выполнить запрос, воспользуемся панелью Apache Fuseki, изменив адрес сервиса на SPARQL точку доступа DataVera EKG Provider:
Подчеркнем, что ответ сформирован DataVera EKG Provider на основе данных, фактически находящихся в реляционной базе данных Postgres – в этом и состоит суть технологии виртуализации данных. Разработчик или созданный им программный компонент имеет возможность работать с данными, находящимися в реляционной СУБД, так, как будто они находятся в графе в хранилище триплетов RDF.
