?

Log in

No account? Create an account

serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Увлекательное расследование с АрхиГраф.СУЗ
serge_gorshkov
В новой версии АрхиГраф.СУЗ мы реализовали конструктор правил логического вывода. Расскажу о его применении на примере задачи поиска признаков хищения средств. Конечно, есть множество других задач, где СУЗ может быть эффективно применен; я выбрал именно этот кейс в качестве нашего ответа широко раскручиваемой за рубежом системе Palantir.

Опишем наш кейс. Пусть имеется крупная организация, ПАО «СпецЦветСнаб», которая на конкурсной основе размещает подряды на некие работы. С нашей системой работает эксперт, проводящий расследование возможных коррупционных схем вокруг этих подрядов. В качестве исходных данных для анализа у него есть реестр банковских платежей всей цепочки контрагентов ПАО «СпецЦветСнаб» на какую-то глубину (представим, что наш эксперт работает в финансовой разведке, и имеет доступ к такой информации).

Гипотеза эксперта состоит в том, что некие сотрудники ПАО «СпецЦветСнаб» могут вступать в сговор с представителями подрядчиков: они обеспечивают выигрыш конкурсов определенными компаниями, а затем получают от подрядчиков «вознаграждение». Если такие факты действительно имели место, то в платежах можно будет обнаружить цепочки, по которым деньги передаются от подрядчиков этим сотрудникам. Разумеется, следы будут тщательно спрятаны, но ведь для этого и нужны умные аналитические технологии…

Итак, прежде всего нашему эксперту нужно построить цепочки платежных отношений между компаниями: кто кому перечислял деньги. На основе моря платежей мы хотим построить простые и понятные связи между конкретными компаниями.

1. Предположим, у нас в базе уже есть сведения о компаниях, физических лицах и их счетах. Первое правило, которое мы построим, звучит так: «Если компания А перечисляла деньги компании B, то компания B является бенефициаром компании A». Под словом "бенефициар" мы понимаем здесь только то, что компания B получает средства от сотрудничества с компанией A.



Конечно, в реальном кейсе правило нужно бы было уточнить для учета суммарного объема транзакций и промежутка времени, на котором они происходили.
Конструирование правила происходит путем создания логического уравнения, состоящего из двух частей – «если» и «то» (условия и вывод).  Правило сконструируем по такой логике:

Если
         A – расчетный счет, принадлежащий компании B
И   C – расчетный счет, принадлежащий компании D
И   E – транзакция, в которой счетом плательщика является A
И   E – транзакция, в которой счетом получателя является C
То
   Компания D является бенефициаром компании A

Интерфейс конструктора правил выглядит так:

asuz2.png

Слева расположено дерево «папок», в которые мы можем помещать правила, в середине – список правил в выбранной папке. Справа находится конструктор, в котором можно задать как свойства правила в целом, так и его условия и вывод. Вот как эта форма выглядит для нашего первого правила:

asuz3.png

Для сокращения изображения мы поместили на этом рисунке формы редактирования условий и свойств правила рядом друг с другом, хотя в интерфейсе СУЗ одна из них находится под другой.

2. Конечно, одиночные связи между компаниями нам не слишком полезны. Свойство нужно сделать транзитивным: если A является бенефициаром B, а B – бенефициаром C, то A является бенефициаром C. После добавления этого правила наши злоумышленники смогут создавать сколь угодно длинные цепочки перечисления средств, использовать для этого разные счета – системе это не создаст никаких сложностей.

3. Умный злоумышленник не будет создавать непрерывных цепочек перечисления средств – от A к B, от B к C и так далее. Гораздо лучше перечислить средства от A к B, а затем от некой «посторонней» фирмы D – к C. Тем не менее, почти наверняка связь между B и D все-таки будет. Мы создадим два правила для того, чтобы определять их аффилированность по общему адресу регистрации, и по наличию общих собственников. Конечно, это очень простые правила, в реальной ситуации их нужно будет дополнять, но для модельного примера достаточно и их.

Для сравнения адресов нам понадобится разделить адрес на составляющие – город, улицу и номер дома. В реальной жизни это не составит проблемы, т.к. в ЕГРЮЛ все адреса приведены в соответствии с КЛАДР. Учредителей мы можем тоже получить из ЕГРЮЛ, а можем – определить на основании тех платежей, которые делают компании. В нашем примере мы создали правило, согласно которому физическое лицо является учредителем тех компаний, которые делали ему перечисления с назначением, содержащим слово «Дивиденды». Теперь мы можем выявить аффилиатов и замкнуть разорванные цепочки отношений «является бенефициаром»:

asuz4.png

4. Теперь займемся установлением связей между компаниями и физическими лицами. Для этого нам понадобятся правила, определяющие тип отношений на основе того, платежи с какими основаниями проходят между компанией и физ. лицом.

  • Если компания платит дивиденды, значит, физ. лицо – ее учредитель;

  • Если компания платит зарплату, значит, физ. лицо – ее сотрудник;

  • Отдельно также выделим отношения, связанные с выдачей и возвратом займов – они могут использоваться для перевода денег с фиктивной компании частным лицам.

Все эти правила имеют одинаковую структуру: например, если находится хотя бы один платеж от компании физическому лицу, в назначении которого указано «зарплата» или «заработная плата», то делается вывод, что человек является сотрудником организации.

5. Дальнейшая работа аналитика состоит в построении гипотез о том, как могут выглядеть цепочки передачи денег. Аналитик будет составлять правила до тех пор, пока не проверит все гипотезы.
Простейший вариант цепочки выглядит так (для упрощения диаграммы покажем стрелками направление перечисления средств между компаниями и от компаний к юр. лицам, хотя по факту картина чуть сложнее – перечисления происходят между принадлежащими им счетами):

asuz5.png

Правило сформулируем так:

Если
     Компания А является бенефициаром компании B
   И физ. лицо C является сотрудником компании B
   И [      физ. лицо C получал займ от компании A
        ИЛИ физ. лицо C является учредителем компании A
        ИЛИ физ. лицо C является сотрудником компании A ]
То
   Создать новый объект, имеющий тип «Подозрительная связь»
   Новый объект имеет головную организацию B
   Новый объект имеет компанию-бенефициара A
   Новый объект имеет физ. лицо-бенефициара C

Поскольку создание нового объекта при получении вывода нам еще не встречалось, покажем, как выглядит форма вывода в этом случае:



Применение этого правила в нашем демонстрационном примере не дает результатов – злоумышленники не столь наивны, чтобы создавать такие простые цепочки. Аналитику придется усложнить правило.

6. Следующая гипотеза, построенная аналитиком, состоит в том, что на каком-то этапе цепочка перечислений была разорвана за счет использования аффилиатов:

asuz6.png

Запрос усложнится, но результатов в нашем примере также не даст.

7. И вот, наконец, верная гипотеза. Эксперт предположил, что конечная фирма в цепочке перечисления платила деньги не напрямую коррумпированному сотруднику головной компании, а одному или нескольким подставным физическим лицам, а они уже далее рассчитывались с фигурантом. Схема правила будет такой:

asuz7.png

Для удобства восприятия мы указали у каждого объекта имя переменной, которая используется для его обозначения в правиле. Запишем само правило:

Если
            Компания А аффилирована с компанией D
   И компания D является бенефициаром компании E
   И физ. лицо F является сотрудником компании E
   И физ. лицо C переводил деньги физическому лицу F
   И [      физ. лицо C получал займ от компании A
        ИЛИ физ. лицо C является учредителем компании A
        ИЛИ физ. лицо C является сотрудником компании A ]
То
   Создать новый объект, имеющий тип «Подозрительная связь»
   Новый объект имеет головную организацию E
   Новый объект имеет компанию-бенефициара A
   Новый объект имеет компанию-бенефициара D
   Новый объект имеет физ. лицо-бенефициара F
   Новый объект имеет физ. лицо-бенефициара C
   Новый объект имеет название «Возможный вывод средств ?E через ?A, ?D, ?C в интересах ?F»

При формировании вывода в шаблон строки названия вместо символов типа ?E будут подставлены названия объектов, соответствующих этим переменным в решении.
Для применения правил нужно нажать кнопку «Применить правила» в интерфейсе конструктора. Правила могут применяться и автоматически в фоновом режиме, но для отладки удобнее сделать это в явном виде.

asuz8.png

Правила применяются на несколько проходов до тех пор, пока на каком-то проходе модель не останется без изменений. Это необходимо для обработки рекурсии правил – результаты применения одного правила могут влиять на исходные данные другого. По ходу применения правил, система выводит номер прохода, название правила, количество созданных/удаленных в результате него фактов (да, у нас поддерживаются негативные утверждения, то есть в качестве вывода может выступать не только создание новых фактов, но и опровержение имеющихся), и время выполнения. Нажав на количество фактов, созданных по какому-либо правилу, можно увидеть техническую информацию, которая поможет при отладке правил:

asuz9.png

В результате применения последнего правила, созданного экспертом, были добавлены новые объекты типа «Подозрительная операция». Эксперт может найти их при помощи нескольких вариантов поискового интерфейса, самый простой из которых выглядит так:

asuz10.png

Эксперту остается перейти на каждый из этих объектов, чтобы увидеть детали обнаруженной схемы.

asuz11.png

На этой странице отображаются все связи текущего объекта, причем факты, полученные в результате логического вывода, а не известные априорно, подсвечены (в нашем примере все факты получены так, поскольку и сам объект «Подозрительная связь» создан в результате применения правила). При наведении на факт можно увидеть, каким правилом он выведен.
В нижней части страницы расположена диаграмма связей текущего объекта. Из приведенной диаграммы следует, что средства ПАО «СпецЦветСнаб» выводились через компании «Полянка», «Сирень» и физ. лицо по фамилии Петров, в интересах физ. лица Семенов.

Перейдя на страницу информации о Семенове, увидим, что он замешан в двух вариантах схемы вывода средств – через Петрова и Сидорова. Также из схемы видно, что Семенов является сотрудником ПАО «СпецЦветСнаб».

asuz12.png

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

asuz13.png

Перечисления зарплаты нас не интересуют, а вот «возврат долга» и «материальная помощь» – вполне. Платежи с таким назначением приходили с двух расчетных счетов: 40703344500000035654, принадлежащего Петрову, и 40703344500000094599, принадлежащего Сидорову. Общая сумма перечислений с них составила 2 млн. руб. – это и есть ответ на наш вопрос.

Собрав общую картину, эксперт получит следующую схему вывода средств:

asuz14.png

На этой диаграмме везде приведена общая сумма платежей – на самом деле все они были разбиты на несколько перечислений разного размера.

Разумеется, кроме платежей, показанных на этой диаграмме, в базе присутствует огромное множество других транзакций.
Цель эксперта достигнута. Кроме того, в процессе решения одной конкретной задачи он построил шаблон, который в дальнейшем будет автоматически применяться для выявления подобных схем.

Конечно, мы рассмотрели весьма условный пример только одного, очень специализированного применения системы АрхиГраф.СУЗ. Те же принципы работы с информацией можно использовать в системах поддержки принятия решений, для автоматического анализа вновь поступающей информации, при работе аналитика с логической витриной данных (напомню, что к АрхиГраф.СУЗ можно подключить в качестве источников информации любые хранилища и сервисы, в том числе основанные на технологиях Big Data), в экспертных системах самого широкого назначения и так далее. И, конечно же, представленный пример является полностью вымышленным, а все возможные совпадения – случайны :)

  • 1
Ручной перебор правил - очевидное слабое место этой технологии.

В каком смысле ручной перебор? Мы один раз создали правила, дальше они работают без нашего участия. Можно их запускать вручную, но это только с целью отладки. В посте не показано, но на самом деле там еще возвращается кое-какая развернутая служебная информация по каждому правилу, которая поможет понять, почему оно не работает как задумано (если возникла такая ситуация).

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

Насчет транзитивности - тут транзитивно отношение "является бенефициаром". Аффилиированность не делал транзитивным, но можно сделать, кстати.

Это два разных уровня логического вывода. Первый - это те правила, которые есть в OWL по умолчанию: транзитивность, симметричность, инверсивность свойств, подклассы и т.п.
Это есть, причем можно реализовать двумя способами: включить entailment-режим в хранилище, или вычислять вывод для этих правил в нашем движке. Мы предпочитаем второй способ, потому что при этом видно, какие триплеты выведены (и по какому правилу), а какие - являются исходными данными. В Jena тоже в принципе можно отловить выведенные триплеты, но только через Java API - через SPARQL-запросы нельзя.

Второй уровень - это правила, конструируемые пользователем, ради чего собственно весь движок и сделан. Грубо говоря, это аналог SWRL. Это все остальные правила в приведенном примере. Ничего плохого в них не вижу :) На одних базовых правилах далеко не уедешь.

Меняем перечисление средств на передачу средств и система умирает. Ну и "(представим, что наш эксперт работает в финансовой разведке, и имеет доступ к такой информации)." надо менять минимум на следователя обложенного ордерами.
Ну и Петров получил деньги в отделении, положил на карточку жены в другом банке и сделал перевод Семенову тоже убьет схему.
Слишком много надо загрузить в Архиграф, чтобы он принес пользу в данном случае ИМХО.

Если одно физ. лицо передавало другому наличные - да, дело усложняется. По косвенным признакам можно кое-что поискать и в этом случае, например - близкие по времени события "Петров снимал наличные со счета" и "Семенов вносил наличные на счет", "Семенов покупал валюту" и т.д.

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

Что надо загрузить слишком много - да, согласен. Однако кейс навеян Palantir'ом, который демонстрируют именно на таких примерах. Там у них, грубо говоря, ЦРУ проводит такие расследования, и у них есть доступ ко всей этой информации.
На самом деле, тут будет комбинация с логической витриной данных, о которой я писал в прошлом посте. Понятно, что все-все банковские транзакции не собрать ни в одной базе. Поэтому витрина выберет транзакции только по тем счетам, которые принадлежат фигурантам, и будет делать это далее по цепочке.

В общем, этот рассказ надо рассматривать не как рекламу инструмента для расследователей коррупционных схем - это было бы слишком узко - а как демонстрацию возможностей новой версии СУЗ. Понятно, что как данные, так и правила могут быть из любой предметной области.


Палантир интересен визуализацией разнородных связей, что позволяет увидеть паттерны до того, как они описаны правилом.

Насколько понял из описания Palantir, ручной перебор правил там тоже является слабым местом. Для того чтобы сработала геометрическая интуиция, количество отображаемых связей надо ограничить из каких-то соображений. А цепочки передачи денег — они как пути господни, неисповедимы.

Будь я экспертом, расследующим возможные коррупционные схемы, то просто спросил бы что-то вроде этого:
SELECT DISTINCT ?C { <CompanyA> (rdf:Property|^rdf:Property)+ ?C (rdf:Property|^rdf:Property)+ <CompanyB> }
А там бы уже смотрел, что это за ?C.

У Сергея хоть эти правила можно одноразово ввести в конструкторе, а не каждый раз задавать мышекликаньем. То есть по крайней мере для мониторинга пригодно.

  • 1