As a part of the PPBW (Polish Platform for Homeland Security), we have developed tools that help investigators and prosecutors to conduct investigations of financial crimes and manage the data gathered. The most important task is to transform data into knowledge that allows for classification of illegal activities and assignment of sanctions based on the roles of people in companies. In this demo we present an application of the Semantic Data Library (SDL) to the problem of gathering, managing, querying and interpreting data relevant to building the evidence necessary for an indictment. The SDL uses and integrates a rule engine, a relational database, an ontology and a set of rules specific to a given crime typology. This combination allows querying and inferring a crime scheme and identifies possible charges; in particular, it discovers crime activities and roles (of particular types of owners, managers, directors and chairs) using concepts, appropriate relations and rules. We present results achieved with SDL and an ontology, called the 'minimal model,' of a fraudulent disbursement committed by management, accompanied by money laundering. Prospects on future development of the SDL tool are presented.
One of the most costly and hard to trace crimes is economic crimes, such as a
VAT tax fraud, or fraud. The level of complicity and amount of proxy and scam
companies involved make it difficult to identify crime schemes. Another issue is to
properly formulate an indictment based on evidence, that, in particular, identifies
roles and activities of members of a crime group. In previous work [
In this demo we apply our approach to fraudulent disbursement combined with
money laundering [
Surprisingly, the system performs better than an average prosecutor on a charge assignment. We will elaborate on details of this statement in a future work. This demo aims at proving that the system is practical and can be of big help if extended to a larger set of crimes. Since the analytic capability of institutions, such as the Police or Prosecutor’s Office in Poland, is limited, the system has to hide the complexity of data structures and reasoning engines and expose friendly interfaces.
The paper is organized as follows. Section 2 presents the SDL architecture and functionalities. Section 3 describes a Hydra case which exemplifies an important type of fraudulent disbursement scheme and the Hydra-case-like simulated input data generation. In Section 4 we execute selected queries according to the minimal model ontology. Conclusions and future work are presented in Section 5. 2
SDL integrates ontologies, relational data and rules that represent domain
knowledge. The architecture of this system is presented in Figure 1. The central part,
which gathers input from other system elements and processes rules, are the two Jess
engines [
The set of functionalities allows the SDL library to answer queries to the
relational database using ontology and rules. The tool uses hybrid reasoning (forward
and backward) for query execution. The backward method is responsible for
gathering data from the relational database and the forward chaining is used to answer
a given query. The Minimal Model ontology that conceptualizes financial crimes
(presented in [
Another set of rules is the domain knowledge set, which is expressed in SWRL
[
There is one more set of rules – production rules; these are used to map between
ontology axioms (properties and classes) and data stored in a relational database.
These are defined in Jess-specific language [
Our so-called minimal model ontology comes from experience based on detailed analysis of descriptions, indictments and sentences of around 10 criminal cases. The most “clean” case of fraudulent disbursement is the so-called Hydra Case.
In the Hydra case, the Chief Executive Officer (CEO) of company A (Hydra) subcontracted construction work. The work was then consecutively subcontracted through a chain of phony companies B, C, and D (Hermes, Dex, Mobex). Each company was getting a commission for money laundering and falsified documents stating that the contracted work had been done. Actually, company A itself did what was identified as “subcontracted construction work”.
At the end of the chain, the owner of a single-person company D attempted to withdraw cash, and there was a suspicion that this cash would reach the management of company A “under the table”. The crime scheme of the Hydra case is presented on the demo description site (http://150.254.41.181/).
A definition of the minimal model in application to financial crimes, expressed in
OWL language using the editor Protégé 4.0, is presented in [
It is important to correctly model the sequence of activities in the company
structure that lead to decisions and transactions. We illustrate this in the example of
the three-level structure of authorization (this is easy to generalize to more levels, but
the intent is to make it compatible with the Hydra case). The chain of activities is the
following: in the Hydra case, acceptance of construction work done by B at a given
site is first signed by a manager in A responsible for a work supervision at this site
(MiddleLevelManager); this is followed by a signature of the higher level manager –
a Director of the company responsible for supervision of all sites. A Director may be
authorized to accept invoices and order a payment – technically this is fraud and in
the case of Hydra, was done by a written authorization on the back of the invoice. The
role of the Principal (the top level of authorization, which, however, could have not
been exercised) was analyzed in detail in [
The Principal might not have known that the work has not been done. However, he was the one who signed the contract for subcontracting and thus could be implicated. Had the Principal of company A been a person who on the basis of the work acceptance document had ordered the payment of A to B, upon issuance of an invoice by B, he would be directly implicated. 3.2
For a practical demonstration of the minimal model ontology, we need data stored in a relational database. We implemented a generation tool in Java which enables us to generate a relational database with the size of a case as parameters: the number of companies and number of documents (invoices, work approval documents and money turnovers). The Hydra case generator generates data concerning: • Information about employees and their position in a company • Invoices with all obligatory elements (payer, seller, product, etc.) • Work approval documents (or the lack of them) • Signatures on documents • Goods and services • Companies and their legal form • Money turnovers: money transfers, payments and withdrawals • Legal articles (name, ID and content) • Information about illicit personal gains and damages to companies (with values)
Other facts, like who knows about what (Person knowsAbout document) – these
data result from testimonies. These facts are in the form of RDF triples (the table
contains three columns: subject, predicate, object)
The seed of the generator is constant, so if the number of the documents is growing
(the number of companies is fixed), the query results (i.e., the number of cases found
criminal) from the bigger database contains all the results from the smaller database
(and some extra results, possibly). The tool generates the Hydra case in four variants
[
To realize what could be possible questions to the system, we present the relevant part of one count of charges in the Polish Penal Code: “Article 296.
§ 1. Whoever, while under an obligation resulting from provisions of law, a decision of a competent authority or a contract to manage the property or business of a natural or legal person, or an organizational unit which is not a legal person, by exceeding powers granted to him or by failing to perform his duties, causes it to suffer considerable material damage, shall be subject to the penalty… • § 2. If the perpetrator of the offence specified in § 1 acts in order to gain a material benefit… • § 3. If the perpetrator of the offence specified in § 1 or 2 causes significant material damage of great extent… • § 4. If the perpetrator of the offence specified in § 1 or 3 acts unintentionally…”
The specificity and the simple nature of the Hydra case is that all persons, possibly including the CEO, knew that they were committing a crime; therefore, the model does not have concepts and data explaining their intentions. It is extremely difficult to model and answer predicates like: “exceed powers granted to him” (which could depend, for example, on taking an excessive risk) or “fail to perform his duties”. A judge has to answer these questions that pertain to a given crime’s attributes. At this stage our model does not contain such soft crime attributes. It contains facts and hard concepts, such as “cause a company to suffer considerable material damage”. The system is not prepared to answer directly all questions a judge might ask. However, we could ask questions: all counts of criminal activities of a person X, or all persons subject to counts of a charge C.
At present, the system does not reason on a partial set of facts. Rather, it assumes that the set of facts is complete and allows querying for elements of crime attributes. We do not have an option that allows a user to pose his/her own query. We restrict the use to a preselected query.
We have prepared five queries to test different aspects of the query answering mechanism. Queries were executed with the use of the hybrid reasoning process (forward and backward chaining). Graphical representation of the queries is presented on the demo description site.
The first query contains only variables (without any values) and exploits hierarchy rules. The second query contains variables and values; it exploits ontological rules (for inComplicityWith symmetric property). The third query contains only variables and exploits hierarchy rules. The fourth and fifth queries contain variables and values, and exploit various characteristics of the knowledge base as coded by rules. The last two queries are computationally demanding - the property fallsUnder needs almost all rules to be fired, because it requires evidence why a person falls under a given article. It is obvious that a rule can be fired more than once (if appropriate facts exist in the Jess working memory).
The demo queries were executed on three databases, generated according to
methodology presented in Section 3.2. These databases differ in the size of the
generated documents, values of money, turnovers, etc. The numbers of companies and
employees are the same in every database (20 companies and 240 people). Generated
databases contain the following numbers of documents (and money turnovers): 20,
100, 200. A mapping between a relational database and ontology consists of 57
mapping rules, and the set of domain knowledge rules contains 291 rules (42 SWRL
rules from the ontology, instead 41 as in [
All queries exploit mapping rules (because they are responsible for gathering
data from the relational databases). For anonymity, the numbers in responses to
queries are IDs of objects (persons, companies); if needed they can be transformed
into real names. Queries without any values sometimes need more time to execute
because SDL has to check all possible variable bindings from the database. Results of
the executed queries are presented in Table 1. The SDL Demo is available on this site:
http://150.254.41.181/. Rules fired means how many rules fired in the backward
chaining engine during the reasoning process. Queries where executed on a computer
with the following parameters: Core2Duo 2GHz, 2GB Ram; Java Heap Space was set
at 1024MB.
As we can see, simple queries (1, 2, 3) are executed in an efficient way (if we look at
how many rules were fired). For more complex reasoning (queries 4 and 5), further
optimization is needed. It is worth noticing that it takes 4 minutes for Pellet to classify
our Minimal Model ontology with instantiation of the Hydra case. Our tool is more
efficient for simplified reasoning without the full advantages of the OWL DL
language (we mostly use hierarchies of concepts and relations computed by Pellet and
SWRL rules). More sophisticated reasoning with the Jess engine is available using the
OWL Meta-model from OWL2Jess [
We also compared our results with the Jess engine using forward and backward chaining separately. Appropriate scripts were loaded into two Jess engines. Facts (the same as in databases) were loaded from files. The times of executing queries for the same database were approximated, because the reasoning process is the main part of the query execution. Differences between queries execution were not higher than 500ms.
The time of executing queries in the forward chaining engine (data from the first database) was around 250ms for each query (data loading took 375ms). From the second database: 16s (query), 15s (facts). While loading data from the third database, the size of the Java heap space was reached (both engines), so the queries could not be executed. The times in a backward chaining engine are the following: 325ms (each query), 485ms (facts) for data from the first database, and 20s (each query), 183s (facts) in the second. It is obvious that for small databases, it is better to store data (facts) in the engines’ working memory. But for the bigger databases, the problem with scalability occurs. Future investigation and modification of our hybrid reasoning method are necessary to obtain performance comparable to the forward chaining in the Jess engine. At the demo time we demonstrate the result of a method that avoids backward chaining and improves performance to a level comparable to the forward chaining in the Jess engine. 5
We demonstrated that the SDL library can be used to solve practical problems with formally defined semantics (in our case the minimal model ontology). We realize that our tools need extensions and optimization.
In the next version of the SDL tool, we intend to apply a new conflict resolution
strategy which will be a combination of the “depth” and “breadth” strategies. In the
implemented strategy, SQL queries (data retrieval) will be executed in a more
efficient way, which will make our approach more scalable and useful. Another useful
feature we are going to implement is the reasoning path, which can be presented to
the user and can explain what evidence proves that a person falls under a concrete
legal article. Analysis of justifications [
The demo serves several purposes. It is evidence of the growing power of rulebased systems. It can already be employed by prosecutors and judges for training purposes. Moreover, upon a crime typology extension, it can be used as an expert system. Our plan is to commercialize such a tool under the name “Anti-Fraud Future”.
Extensions in some directions are relatively easy. To account for fraudulent
disbursement committed by non-management workers, one has to think of possible
schemes [
Acknowledgement. This work was supported by the Polish Ministry of Science and Higher Education, Polish Technological Security Platform grant 0014/R/2/T00/06/02 in the first stage of the work and by PUT DS 45-083/10 grant in the later stage.