A semantic rule based digital fraud detection

Ontologies vs. database models

Currently, ontologies are the best way to represent knowledge in a dynamic environment. It makes knowledge shareable and reusable. Additionally, ontologies can describe the terms and vocabularies of a domain. Ontologies allow knowledge bases and logic to be combined and turned into inferred knowledge via an inference engine. By using ontologies, we can reduce the modeling cost. One can extend and reuse ontologies for different applications and domains. The two basic data representational models are databases and ontologies. The relational databases have been in use for quite some time for storing and querying data. On the other side, ontologies with context have appeared as an alternative to databases with more enriched meaning. Ontologies make knowledge shareable and reusable (Dadjoo & Kheirkhah, 2015). The reasoning capabilities of ontologies make it possible to derive implicit facts from the knowledge base.

A database is usually designed for a specific application. For every application, one must create a new database. However, ontologies can be reused in different applications and domains as per need. Ontologies also help us in expressing the semantics in a better way as compared to databases. Since databases are schema-oriented, strict schema rules must be followed to create new records. The reasoning/inferring capability of ontologies makes it possible to produce new knowledge. Ontological classes, properties, and axioms can be mapped to a database’s tables, attributes, and constraints, respectively (Martinez-Cruz, Blanco & Vila, 2012).

Motivation

A hybrid solution based on data mining and a complex network classification algorithm is presented by Zanin et al. (2018). The authors proposed a solution to detect credit card fraud. Our proposed solution has fraud detection and deterrence capabilities. Our work derives facts from the given knowledge base based on logical reasoning. These facts are not described explicitly and are referred to as inferred knowledge. Our solution also generates alerts on suspicious transactions along with their severity level.

Our contribution

In this work, we have proposed an ontology-based alert model for Financial Fraud Detection and Deterrence (FFD). The main contributions of this research work are:

1. We have created a comprehensive FFD ontology with 40 classes and sub-classes. The FFD ontology identifies suspicious transactions based on customers’ bank transactions. It also relates transactions with each other to find out any malicious behavior.

2. We have also developed rules using the Apache Jena framework, for our fraud alert systems.

3. The proposed ontology-based alert model has extra features for money laundering detection and deterrence.

4. The proposed IRB alert generation algorithm stops fraud before it occurs.

5. Our work also adds a taxonomy of literature review to facilitate a bird’s eye view.

The rest of the paper is structured as follows: ‘Related Work’ presents related work. In ‘Types of Fraud’, types of fraud are explored. Furthermore, an explanation of our proposed system is discussed in ‘System Model and Problem Formulation’. In addition, ontology construction methodology is presented in ‘Ontology Construction Methodology’. Moreover, formal representation of FFD ontology is discussed in the subsection of ‘Ontology Construction Methodology’. ‘FFD Ontology Implementation’ and ‘Ontology Validation’ present the ontology implementation and its validation, respectively. The evaluation setup, results, and discussion are presented in ‘Simulation Setup and Results’. Finally, ‘Conclusions and Future Work’ presents the conclusion.

Credit card fraud

CC fraud is the unauthorized use of a CC to perform illegal transactions. CC frauds are often committed by using stolen credit or debit cards. The development of an accurate system for CC fraud detection is a critical problem. Many fraud detection techniques have been proposed by researchers for CC fraud detection. Behera & Panigrahi (2015) proposed a three-layered system for CC fraud detection using fuzzy clustering and neural network. In the first phase, the system performs verification of card details. It then calculates suspicious scores by using fuzzy clustering. Finally, the solution performs suspicious activity detection.

Money laundering

The process of hiding the source of illegitimate money is known as Money Laundering (ML). ML fraud is performed by transferring money via shell corporations, bank accounts, etc. The key reason behind any fraud is to get illegal financial benefits. Detecting ML is a challenge since fraudsters often find new ways to launder money. A lot of ML detection systems and techniques have been analyzed and practiced in recent years. A hybrid of Hash-Based Association (HBA) and Graph-Theoretic (GT) method was used by Suresh, KT & Sweta (2016) and Pooja et al. (2018) for ML detection, respectively. This method identified the traversal path of the laundered money using the HBA approach. Moreover, it detected the agent of ML by using the GT Approach. Carnaz, Nogueira & Antunes (2017) proposed an ontology-based framework to detect ML.

Online transaction fraud

An online transaction (also known as a PIN-debit transaction) is a process of transferring money or funds online. Online Transaction (OT) fraud is an illegitimate transaction, which occurs via the internet. The payment system has five entities, i.e., cardholders, merchants, card issuers, acquirers, and a payment corporation network. These entities are involved in financial transactions (El Orche, Bahaj & Alhayat, 2018). The problem of OT fraud detection continues to grow. An account of ongoing research to detect OT frauds in financial institutes is present in Fig. 2. The figure also presents the timeline of (CC, ML, and OT) fraud detection techniques reviewed in this article.

System description

In this section, we present an enhanced financial fraud detection system. Our ontology-based alert model has added features, i.e., severity levels of alerts based on intimation rules. As a result, our proposed solution performs better. A high-level system architecture is shown in Fig. 3, and the proposed IRB alert generation algorithm is shown in Algorithm 1. Furthermore, the step-by-step execution of the proposed system are described below:

• The first step will be to extract data from external data source(s), e.g., relational database(s). This data will then be preprocessed and saved in the ontological database. After that, each account’s transaction threshold will be calculated. This threshold will then be utilized by the inference engine during rules evaluation against each account’s transaction. The use of dynamic threshold will allow the system to be more effective as it will give a view of the transactional behavior of the customer. Moreover, with the help of a dynamic threshold, the system will adapt to the changing behavior of the customer with time.

• The rules used by the inference engine will define the criteria of setting the severity level of a suspicious alert. If an alert was previously generated for a customer’s account, then, the system might increase the hit count in the alert. The solution will also set the alert-id of the previous alert as the parent-id of the current alert and will increase the severity level. This will allow the system to detect recurring suspicious transactions. Chaining alerts together will also result in a trace of similar alerts which could later be used for inspection & audit.

• As mentioned earlier, the alerts will be generated based on intimation-rules with a certain severity level. The system can generate three different levels of alerts as described below.     Level 1: Suspected alert, when the first occurrence is identified (Severity Level: Low).     Level 2: Investigation Required (Severity Level: Medium).     Level 3: Fraud Detected (Severity Level: High).The severity levels can be used by the fraud notification module to generate emails or SMS etc.

 
_______________________ 
Algorithm 1 IRB Alert Generation Algorithm_________________________________________ 
  1:  Input Data:- Original data, Inferred data, Alert rules, Alert generation rules 
  2:  Output:- Alert notifications, Transaction IRI, Transaction ID, Severity level 
  3:  Data entry in the ontological database 
  4:  Data preprocessing and saving 
  5:  for All data from relational a database to resource description framework 
     store do 
 6:       Calculate account transaction thresholds 
  7:       Apply rules (executed by inference engine) 
  8:       if Indicate risks then 
 9:            Apply intimation rule 
10:            if  Severity level ≥ high  then 
11:                  Pass through severity levels 
12:                  If fraud detected!! 
13:                  Generate alert notifications 
14:            end if 
15:            Return Transaction IRI, ID, Severity level 
16:       end if 
17:  end for____________________________________________________________________________    

Problem formulation

We formulate the problem of financial fraud detection as a single-objective optimization problem. Suppose, there are two transactions T_cml and T_cnr. (1)${\displaystyle T_{\mathrm{cml},}=\left\{T_{\mathrm{cml},1},T_{\mathrm{cml},2},T_{\mathrm{cml},3},..,T_{\mathrm{cml,m}}\right\}}$ (2)${\displaystyle T_{\mathrm{cnr,}}=\left\{T_{\mathrm{cnr},1},T_{\mathrm{cnr},2},T_{\mathrm{cnr},3},..,T_{\mathrm{cnr,n}}\right\}}$ Where, T_cml are transactions from commercial account and T_cnr are transactions from consumer account. (3)${\displaystyle T=T_{\mathrm{cml}}\cup T_{\mathrm{cnr}}}$ In transactions T, fraudulent F and legitimate L transactions are the subset of transaction T, (F ⊂ T, L ⊂ T). Whereas, F and L contains the number of fraudulent and legitimate transactions, respectively. (4)${\displaystyle F=\left\{F_1,F_2,F_3,..,F_m\right\}}$ (5)${\displaystyle L=\left\{L_1,L_2,L_3,..,L_n\right\}}$ (6)${\displaystyle T=F\cup L}$ Transaction is either legitimate or fraudulent, as states shown in Eq. (7) (7)${\displaystyle {\alpha }_{ij}=\left\{\begin{array}{cc}1,\hfill & \text{is fraudulent},\hfill \\ 0,\hfill & \text{is legitimate}.\hfill \end{array}\right.}$

The objective is to minimize fall-out and miss rate as shown in the following equation. (8)${\displaystyle Minimize\sum _{i=1}^n\sum _{j=1}^{m}F{N}_{ij}+F{P}_{ij}\ast {\alpha }_{ij}}$

Where False Negative (FN) is the number of objects of set F, which were expected as an object of L incorrectly. False Positive (FP) is the number of objects of set L, which were expected as an object of F incorrectly. FP is also known as the fall-out rate.

Formal representation of FFD ontology

An ontology represents knowledge in an easily shareable and reusable manner. It describes the terms and their relationships within the given domain. An ontology consists of concept, relation, and attribute identifiers along with data types (Cimiano, 2006). Moreover, the structure of ontology can be represented as formal logic as shown below: (9)${\displaystyle O=Ontology=\left(C,{\le }_t,S,P\right)}$ where C is the set of classes, ≤_t on C is called concept hierarchy. S stands for subclasses, P represents predicate (relationships). Moreover, they can be represented as follows: (10)${\displaystyle C=\left(\right.\prod _{i=1}^n{C}_i,{\le }_t\left)\right.}$

where i = (1,2,3, …,n) and ≤ fulfills the conditions as shown below. (11)${\displaystyle \forall a,\left(a\le a\right)}$ (12)${\displaystyle \forall a\forall b,\left(a\le b\wedge b\le a⟹a=b\right)}$ (13)${\displaystyle \forall a\forall b\forall c,\left(a\le b\wedge b\le c⟹a\le c\right)}$ (14)${\displaystyle \forall a\left(a\le topelement\right)}$

Ontology development

The first step of ontology development is to perform data preprocessing. The data items from this step are selected and transformed into an ontology. All the irrelevant and redundant information is filtered out to make the data more meaningful. This process of filtering out data is often referred to as dataset normalization. Our proposed system models, domain knowledge into ontology and defines rules on top to support reasoning. The inference engine uses these rules to infer new knowledge to aid in the identification of suspicious transactions. The knowledge base used by our proposed system consists of customer transaction data. The ontology model consists of classes, subclasses, objects, datatype properties, and instances. The transactional data contains the amount and their frequency in each interval. We have designed a three-layered ontology as described below.

i. Conceptualization of the Domain Layer:

In the domain layer customer’s transactions are modeled in various forms. Classes, subclasses, properties (object/datatype), and instances are created in this layer. The key classes of our proposed ontology are account, person, purposes, suspicious alerts, and transaction types.

ii. Ontology Layer:

This layer defines restriction on classes via Ontology Web Language (OWL) to facilitate logic. A graphical representation of the proposed FFD ontology with its classes and subclasses is shown in Fig. 4.

iii. Rule Layer: To infer new knowledge from the existing knowledge, rules are developed on top of the ontology OWL layer. In this study, the rules are created in Jena. Jena is a semantic web toolkit (Carroll et al., 2004). It is a Java framework for the creation of applications for the Semantic Web. Three levels of rules are executed by the inference engine. We have created rules based on the Anti Money Laundering (AML) guidelines shared by the financial regulatory authority. The values of the Threshold Amount (TA) can vary depending on the financial institution. The threshold values also depend on the AML guidelines of different countries. For the purposes of this work, we have suggested a few threshold values to aid our proof of concept. Our suggested four TA values are: TA1 is equal to 10000 USD, TA2 is 8000 USD, TA3 is 5000 USD and TA4 is equal to 3000 USD.

Ontology reasoning

Once the knowledge base is developed, it is populated with transaction records and appropriate rules. The reasoner then infers logical information from the set of asserted facts. The inference rules are commonly specified through an ontology language. Traditional reasoning engines (Pellet, HermiT, FaCT++, etc.) can be used for reasoning (Khamparia & Pandey, 2017). We have used the FaCT++ 1.6.5 reasoning engine in this work.

Results by querying on inferred ontology

Once the inference engine infers knowledge based on the given rules, the information (asserted or inferred) can be queried. SPARQL is a query language that is often used to get the required information (Sirin & Parsia, 2007). In our work, we have also used SPARQL to query the FFD ontology.

OntoClean methodology

In this work, we have used OntoClean (Guarino & Welty, 2004) for ontology verification. It is a formal method for evaluating the ontological sufficiency of taxonomic relationships. The property of a property is known as meta-property. Unity, identity, rigidity, dependency, and essence are meta properties (formal notions) of OntoClean. Meta property can be further classified into three main labels (+, -, ∼). The description of each label is shown in Table 1.

OntoClean has devised a method to characterize properties and classes and their relations in an ontology. OntoClean attaches the meta properties to each concept and removes false relationships. It further checks the consistency, conciseness, and completeness of ontology. In this work, we have used the OntoClean method for the validation of FFD ontology. The proposed ontology is validated by using meta-properties i.e., unity, identity, rigidity, dependency as depicted in Fig. 4. The validation criteria of the OntoClean method are shown below.

Constraints and assumptions

For validating and ensuring the accuracy of ontology, conditions are applied to classes and properties (Guarino, 2004). Assume, there are two properties, X and Y, when Y subsumes X, so their resulting restrictions hold as follows:

1) If Y has anti-rigid (∼R), then X must have anti-rigid (∼R).

2) An ∼R property cannot subsume a +R property.

3) If Y is rigid (+R), then X must be rigid (+R).

4) An +R property cannot subsume a ∼R property.

5) If Y has identity (+I), then X must have identity (+I).

6) If Y is unity (+U), then X must be unity (+U).

7) If Y is anti-unity (∼U), then X must be anti-unity (∼U).

8) An ∼U property cannot subsume a +U property.

9) If Y has dependence, then X must have dependence (+D).

Dataset

For experiments, we have used a real dataset. The dataset contained 1048576 individual transactions. In the dataset, transactions are classified on the basis of days, weeks, and months. The key values from our dataset are the total deposit and withdrawal amount. The frequency of deposits and withdrawals based on days, weeks, and months is also present in the dataset. The transaction records are separated by deposits and withdrawal to capture the flow of money.

Simulation tools

The experiments were conducted on a Haier Laptop 7G-5 h with 1.70 GHz Intel Core i3 and 4Gb RAM running Windows 10. In this work, we have used simple tools for compiling results. The tools used are listed below:

1. Eclipse IDE 2018-09 (4.9.0)

2. Java 1.8.0_151

3. Protege 5.2.0 Ontology Editor

4. SPARQL query language

5. Apache Jena 3.9.0 Semantic Web Framework

6. FaCT++ 1.6.5 Reasoner

For writing and compiling code, we have used the Eclipse IDE. We used Java for writing our logic along with a Java-based Apache framework: Jena. With Jena, we manipulated ontologies and rules whilst FaCT++ 1.6.5 was used to infer knowledge from the knowledge base. We used Protege 5.2.0 to develop FFD ontology and SPARQL query language to query the financial fraud detection ontology. In the next subsection, we discuss the experimental results of FFD in detail.

Evaluation measures

Before we describe the experimental results, we first introduce the metrics. In this work, the metrics we used for performance comparison of the FFD system are accuracy, precision, recall, F-measure, and Matthews Correlation Coefficient (MCC). Furthermore, the formulas of the aforementioned measures are presented below: (15)${\displaystyle Accuracy=\frac{TP+TN}{TP+FP+TN+FN}}$ (16)${\displaystyle Precision=\frac{TP}{\left(TP+FP\right)}}$ (17)${\displaystyle Recall=\frac{TP}{\left(TP+FN\right)}}$ (18)${\displaystyle F-measure=\frac{2\ast Precision\ast Recall}{Precision+Recall}}$ (19)${\displaystyle MCC=\frac{TP\ast TN-FP\ast FN}{\sqrt{\left(TP+FP\right)\left(TP+FN\right)\left(TN+FP\right)\left(TN+FN\right)}}}$

Where,

• True Positive (TP) = Number of Legitimate Transactions (LTs) which were identified correctly.

• False Negative (FN) = Number of LTs which were expected as Fraudulent Transactions (FTs) incorrectly.

• True Negative (TN) = Number of FTs which were identified correctly.

• False Positive (FP) = Number of FTs which were expected as LTs incorrectly.

Results and performance comparison

Our proposed solution generates alerts at the onset of suspicious activity. Alerts can be generated with either of the three severity levels discussed in ‘System Model and Problem Formulation’. Alert notifications generated by the FFD system are shown in Fig. 5. We have compared our proposed solution with ontological and non-ontological solutions. For ontological solutions, our comparison is based on the number of classes, subclasses, and properties i.e., data and object. The ontological solutions in comparison have a small number of classes and properties. This means that a narrower domain was considered to solve the issue of financial fraud. Since our solution covers a wider area of the financial fraud domain with a greater number of classes and properties. We believe that our solution is better at detecting and deterring the threat of financial fraud. Table 2 shows a comparative analysis of FFD and other ontologies on the basis of classes, subclasses, and properties.

We have also compared our solution with other non-ontological solutions on the basis of various benchmarks.

We are using metrics, i.e., accuracy, precision, recall, and F-measure. The said comparison between FFD and non-ontological solutions e.g., RF-I and RF-II, (Xuan, 2018) are shown in Fig. 6. Before we do the comparison, we need to calculate the accuracy, precision, recall, and F-measure using Eqs. (15)–(18). The results show that the accuracy and precision of the FFD system increases, while the F-measure decreases when compared to RF-II. The recall achieves the greatest value when compared to RF-I. It is evident from Fig. 6 that our solution achieves the highest precision and accuracy among all benchmarks.