International Journal of Computer Applications (0975 – 8887)

Volume 168 – No.11, June 2017

Database Implementation and Testing of Dynamic

Credit Card Fraud Detection System
Anita Jog Anjali Chandavale, PhD
PG Student, Professor,
MIT College of engineering, Department of Information Technology,
Kothrud, Pune. MIT College of Engineering, Pune

ABSTRACT and Cristián Bravo [5] has suggested the approach which
Credit card frauds are increasing with the increase in use of combines inherent attributes derived from the characteristics
plastic money. These frauds include the transactions done of incoming transactions and the customer spending history
either by stealing the physical card or using card data such as using the primary characteristics such as Recency–
card number, expiry date and pin number. There is a need to Frequency–Monetary. Also, the network of credit card holders
recognize customer spending pattern and apply validations for and merchants is taken into account to validate their
incoming transaction. Suspicious transactions can go under relationship by calculating time-dependent suspiciousness
rigorous security checks. This paper describes the database score for each network object. Intrinsic feature extraction is
implementation of credit card fraud detection system which is implemented using supervised learning by exploring spending
adaptive to concept drift environment. The system is designed patterns. Serol Bulkan and Yusuf Sahin describe a system
using PL-SQL stored procedures and JAVA. The validation that makes use of cost sensitive decision tree approach. The
procedure and testing results are included in this paper. approach minimizes total misclassification costs but also
identifies splitting attribute at non-terminal nodes [9].
General Terms Author has compared this approach against traditional
Pattern Recognition, Security, credit card, fraud detection, classification models on real life data. Yiğit Kültür[15] has
stored procedure. focused on analyzing the cardholder spending behavior and
proposes a novel cardholder behavior model for detecting
Keywords credit card fraud. The model is named Cardholder Behavior
Concept drift, self learning, credit card fraud detection. Model (CBM). He has used sensitivity, specificity, false
positive rate, precision, accuracy to evaluate the customer
1. INTRODUCTION behavior model.
There is tremendous growth in the use of Credit cards. People
are encouraged to use plast ic mone y to control the 3. PROPOSED WORK
corruption. Apart from the corruption control issue, credit The proposed and implemented solution is built on above
card is gaining popularity due to online shopping trend. mentioned fundamental solution for fraud detection. It is
Retailers, merchants are offering discounts on online based on the layered architecture. The different layers used
shopping. Customers prefer Online shopping since it helps are 1 ) data, 2) utility, 3) manager and 4 ) controller. Data
explore m a n y items with few clicks. Customers also layer stores following data types 1) Historical, 2 )
compare the amount charged by different vendors for the same Transactional. The validation model contains rule set to
thing. validate each customer. Data layer also includes stored
procedures that are used for validation purpose. Utility layer
Personal details are exposed over the network during online contains common utilities supporting other layers. Manager
transactions. It results in loss of heavy monetary value layer is used for executing each task independently while
worldwide every year. As per cybercrime report [13], t h e controller wraps all the small tasks that need to be done for
r a t i o o f transaction volume ($28 Trillion) v s f r a u d every user action. This technique ( Concept Drift
t r a n s a c t i o n s ( $ 1 6 b i l l i o n ) is 0.06%. I.e. 19% Adaptation) is implemented by periodically updating the
increase in fraud transactions while the customer base grew model using scheduler. Following section explains flow of
by 15%. So it is utmost priority for electronic transactions credit card transaction followed by implementation details
processing Companies to maintain customer trust and protect of the proposed system.
their business by smartly detecting frauds. The important
aspect to prevent the credit card fraud is to analyze the 3.1 Overview of credit card processing
customer spending pattern thoroughly and apply validation There are 4 basic steps involved in credit card processing. First
rules to categorize the transaction to be either fraud or one is authorization. When customer swipes the card, his
genuine. The paper includes following sections. Section 2 credentials are sent to the bank with which the card machine is
describes the related work. Section 3 detailed out the registered and then subsequently forwarded to the card issuing
proposed work. In section 4 s h o w s results, Section 5 bank. Card issuing banks authenticates the request and
provides end conclusion, and Section 6 includes referred depending upon its response, transaction can either proceed or
papers and sites. denied for sale. Second step is batching where merchant groups
all day’s transactions and submits to the bank for payment
2. RELATED WORK processing. Third step is clearing where group of transactions
There are several data mining techniques suggested for fraud received are segregated and sent to appropriate bank through
detection [8][6][1][11]. Artificial Intelligence, Neural card network. Card issuing bank deducts the interchange fee
networks, genetic programming, Support Vector machine, and sends remaining amount through the network. Last step is
Decision tree. etc. [2][3][7][10]. Véronique Van Vlasselaer

42
 International Journal of Computer Applications (0975 – 8887)
Volume 168 – No.11, June 2017

Funding in which merchant’s bank subtracts appropriate Figure 2 shows the architecture diagram of the proposed
charges and transfers the money to merchant’s account. system. The system is mainly divided into four layers
Controller layer, Manager Layer, Utility layer and data layer.
Controller Layer wraps all tasks that need to be
performed for every user action. It sends the request to
1. Initiate End
appropriate manager to execute each action sequentially. It
of Day takes help from alert utility depending upon the response
Credit Card Merchant
Machine
Processing received from manager layer. Each controller class
represents one user action. It determines necessary steps that
need to be executed to complete given task.
7. Acquirer subtracts
2. Send Batch of discount rates (1-2%) Manager Layer is responsible for executing below
transactions to and pays merchant mentioned action with the help of database tables and stored
Acquirer remaining
procedures. It sends response code to the controller.
Authentication Manager is the first manager that gets called
from controller. Authentication manager is used to verify the
userId, password. The authentication manager returns error
message in case of invalid user or password. It returns the
customer details if the user id, password is valid. After passing
Acquirer Bank 6. Card Network sends all the preliminary checks, controller calls fraud detection
3. Batch sent to remaining amount to manager to detect any suspicious behavior of transaction. It
Mediator for Acquirer calls stored procedures written in PL-SQL. At the last,
Clearance issuer controller calls Transaction manager to process the
transaction with respect to debit or credit etc.

Card Network
Utility Layer is responsible of reporting, notifications, alerts
triggered by manager layer.
Database Layer includes transactional data, historical data,
5. Issuers subtract
and set of stored procedures. Transactions that are marked
4. Network Distributes Interchange fees (1- suspicious by the algorithm are kept in separate table
transaction to 2%) and sends fraud_log_tbl. Following section tells about database
respective Issuers remaining for clearing architecture.

Card Issuer Bank

Figure 1: Overview of credit card processing

3.2 Proposed System

In a nutshell the component Builder uses historical
transactional data to build the model. This model is a set of
attributes for identifying fraudulent transaction. The Online
fraud detected uses this model to detect suspicious
characteristics in each incoming transaction. Based on the
decision from online fraud detector, another component
called transaction processor aborts or proceeds with the
transaction for further processing. Next component called
offline calibrator is a scheduler which runs periodically.
Offline calibrator is responsible for rebuilding the model
using transactions and fraud detections after previous run of
the scheduler. This model is updated weekly to cater newly
added records. The application consists of modules such as
Login, Account Statement Viewer, PDF a n d E x c e l
Download to actual transaction execution covering various
validations. Validations are performed at 2 intervals, 1) Figure 2: Proposed system architecture
During actual transaction and 2) periodically heuristic
checks are applied across entire customers set to recognize
suspicious Pattern of transaction.

43
 International Journal of Computer Applications (0975 – 8887)
Volume 168 – No.11, June 2017

3.3 Database Architecture etc. e.g. For location it stores delimited locations list. If a
transaction comes from a new city then it goes in HOLD. The
design allows customized attributes by Account.
Fraud_log_tbl logs all Blocked transactions.
customer_spending_pattern_tbl is used to store he customer
spending behavior such as how many transactions customer
performs in a day, how much amount spent daily, how much
amount spent weekly, number of transactions executed in a
week, weekly amount limit, monthly transactions, monthly
limit.
Below are main stored procedures which do the job of
identifying the fraudulent transaction. These stored
procedures are divided into three modules as shown in table
below.
Details of each stored procedure are explained below.

3.3.1 perform_HeuristicSearchforVendor:
Figure 3: Database architecture This stored procedure performs heuristic search across all the
accounts to find the pattern of similar transactions within
Figure 3 gives the quick overview of database same time period, amount, and vendor. E.g. online hackers are
architecture. The historical transactional data is analyzed known to do small and similar amount transactions across
and derived known patterns are stored in database tables. millions of accounts. Customers generally are not even aware
These act as validation rules to identify the suspicious of such frauds if they do not monitor the account regularly
transaction. These validation rules are explained below in however the hackers earn millions at the loss of credit-card
stored procedure section. The patterns are nothing but issuer. In these cases the suspected transactions are put on
characteristics obtained from customers’ historical HOLD and kept in different table. After customer
transactions to identify the spending pattern. These confirmation, these transactions can proceed or aborted.
characteristics are stored in various tables as mentioned Similarly such a vendor will also marked as Fraud i.e.
below in Figure 4. restricting any further transactions. If there are more than 100
transactions within 2 hours having amount difference less than
10, then these transactions could be due to hacking. So these
transactions are marked as suspicious
Table 1: Overview of stored procedures

Stored Procedure Name Function

populate_AccountValidat This stored procedure

ionTbl populates the data in
"account_validation_tbl"
using historical transactions.
perform_HeuristicSearch
This table contains attributes
forVendor
for each account to validate
the transaction. Attributes
populate_CustomerSpen
include minimum amount
dingPatternTbl
spent, maximum amount
spent, location where
populate_RFMAttributeT customer perform the
bl transaction etc.
validateCustomerPattern
To apply the rules built by
validate_AccountAttribut first module on the incoming
Figure 4: Important tables involved in credit card es transaction to check if it is
fraud detection suspicious or genuine
validate_RFMAttributes
Customer_Vendor_tbl stores RFM attributes (Recency, bulkpopulate_TestValida
Frequency, and Monetary) value for each customer-vendor Test all the conditions
tionTbl
pair. The incoming transaction is validated against attributes
to check if it is within the threshold value. For example, if it
is quarterly, then last transaction date and current date for 3.3.2 Populate_RFMAttributeTbl:
same vendor is compared. If it is found that the difference This stored procedure populates the Recency, Frequency, and
between two transactions is less than a quarter, then after Monitory values for each Customer-Vendor pair. It populates
adding 20% variation, transaction is put on HOLD. Customer the minimum and maximum transaction amounts, Frequency
feedback is needed to decide how to process suspicious of transactions that customer deal with particular vendor. It
transactions. Customer care will work with customer to mark reads the records form transaction table and group the
it genuine or fraud. Account_validation_tbl stores various transactions by customer Id, Vendor Id. Within the group, the
attribute level validations. I.e. Min/Max amount, Location count of transactions is considered. Depending upon the

44
 International Journal of Computer Applications (0975 – 8887)
Volume 168 – No.11, June 2017

count, the frequency is calculated as shown in below table; Along with the number of transactions, amount also is
One year data is taken into account while doing this calculated for day, week and month spent by that customer.
calculation. Now the amount of current transaction is added and then it is
compared against daily limit stored in
Table 2: Customer-Vendor transaction frequency customerSpendingPatternTbl. The count is also increased by 1
calculation to consider current transaction. This count is compared
No of transactions for customer- Frequency against daily transaction limit stored in
vendor group customerSpendingPatternTbl. Similar checks are applied for
weekly count, weekly amount limit, monthly count and
Transaction Count >100 Daily monthly amount limit.
Transaction count between 45 to 100 Weekly
3.3.6 validate_AccountAttributes:
Transaction count between 20 to 44 Bi-weekly This stored procedure validates the incoming transaction
Transaction count between 9 to 19 Monthly against “account_validation_tbl” table. This attributes are
common values such as minimum amount, maximum amount,
Transaction count between 3 to 8 Quarterly location of transaction etc. If customer lives in Pune and
Transaction count < 3 Yearly works at Hinjewadi, his most probable location is Pune. If he
travels to Mumbai once a while, his list of locations will
contain Pune, Mumbai. So if there is sudden transaction from
3.3.3 Populate_AccountValidation & Delhi, it is marked as suspicious and put on HOLD.
SP_Populate_AccountValidationAll: 3.3.7 validate_RFMAttributes:
This stored procedure populates the transacted cities,
This stored procedure validates the customer-vendor specific
minimum amount, and maximum amount values for each
attributes. From historical data, customer_vendor_tbl is
Account. First one is specific to an Account, whereas the later
populated by “populate_RFMAttribute”.
one does the same operation across ALL Accounts.
“customer_vendor_tbl” has the customer-vendor relationship.
From transaction history, distinct locations are found from This includes what is the frequency of transaction with
where customer usually does the transactions for particular particular vendor, what is the amount usually customer spend
account. The locations are collected and made a list of cities with the vendor. For example, the electricity bill is paid
separated by comma. This list is stored in monthly and suddenly there are 3 transactions with electricity
accountValidationTbl table along with what is the minimum bill in same month, it is marked as suspicious. Or customer
amount, maximum amount. visits D-Mart every month for grocery and 3 transactions with
amount greater than given threshold happens, it is marked as
3.3.4 Populate_CustomerSpendingPattern: suspicious.
This stored procedure populates the Customer’s spending
pattern i.e. weekly/monthly/daily transaction count, minimum 3.3.8 bulkpopulate_TestValidationTbl:
amount, and maximum amount spent against each Account. This stored is specially designed for testing various flows
This tracks down the customer spending pattern in a specific from backend database and for performance testing. Hundreds
period. For example, customer usually buys breakfast from of transactions can be tested with this stored procedure one by
cafeteria. Then while coming back from office, he buys tea or one. It reads batch of transactions from transaction table and
some snacks from another vendor. Also shops some grocery apply all the validations one by one to check if it is
items from grocery store. So daily transaction count will be 3 suspicious.
and daily amount limit will be in between 60 to 200. Every
week, he goes to Big Bazar for shopping, fills petrol in the car 4. RESULT
etc. So weekly count will be 2 and amount will be in the range The graphical user interface (GUI) is also designed to test a
of 3000 to 4500. Similarly the monthly pattern can be derived particular transaction to be a fraud or genuine. Validation
where the electricity bill is paid, car wash charges are paid, results are displayed.The transactions that are put on HOLD
and parking or toll charges are paid. Thus typical customer can proceed or abort depending upon customer feedback. If
spending pattern is derived and stored in customer confirms the transaction to be genuine then
customer_spending_pattern_tbl. To calculate the daily, transaction processing is completed by entering in
weekly transaction count, this stored procedure first calculates Transactiontbl table. Secondly the status is marked as
the number of transactions done in every week for that COMPLETED in fraud_log_tbl. And lastly the stored
account over one year. Then average is calculated. procedures are executed to recalibrate the validation rules.
This is to prevent marking similar transaction as suspicious in
3.3.5 validateCustomerPattern: future. If customer confirms the transaction to be fraudulent,
This stored procedure validates the incoming transaction then transaction status is updated in fraud_log_tbl as
against the data in customer_spending_pattern_tbl table. If cancelled. And no further action is taken on this.
customer usually spends around 200 Rs. every day in 2
transactions then suddenly there are 5 transactions happens The data is obtained from kaggle.com. Dataset includes
then there are more chances that the credit card is stolen or transactions made by credit cards by European cardholders.
someone else is using credit card details to buy the things. So With some modifications synthetic data is also inserted into
all these suspicious transactions are put on HOLD and wait the database to validate different scenarios.
for customer confirmation. Similarly if customer goes and test_transaction_tbl table is created to collect the test results.
buys a single item but of 1000Rs, then also, it is suspicious Each column in this table represents status of each validation
since daily limit is 200Rs. For this when new transaction rule. bulkpopulate_TestValidationTbl is a stored procedure
request is received, the number of transactions are calculated specially designed to test various scenarios. This also gives the
that are done in same day, number of transactions done in performance parameters to check how much time system will
same week, number of transactions done in the same month. take for checking thousands of transactions.

45
 International Journal of Computer Applications (0975 – 8887)
Volume 168 – No.11, June 2017

Figure 5: screen capture showing fraud summary page to view transactions that are HOLD

Table 3: Performance result

5. CONCLUSION
No of Execution Time (ms) Self-Learning algorithms for fraud detection in credit cards is
transactions a need of the hour as Plastic and Online transaction base is
growing at a fast pace. There is also a need for periodically
1046 1777 recalibration of Algorithm. The approach suggested above is
suitable in such an environment since it recalibrates, and
1884 3872 customizes by logical entity. It is a hybrid system having
2730 6360 Network based extension and concept drift adaptation. The
model is customized based on recent and past transactions.
3576 9663 The suggested model is dynamic and customized with 81%
accuracy in transactions filtering rate. Thus, the system is
4422 13470
providing necessary support system to end users and credit
card companies to freely use Plastic and electronic money.

6. REFERENCES
16000 [1] Emanuel MinedaCarneiro, “Cluster Analysis and
14000 Artificial Neural Networks: A Case Study in Credit
Card Fraud Detection,” in 2015 IEEE International
12000
Con- ference
10000
Time [2] V. Mareeswari, “Prevention of Credit Card Fraud
8000 Detection based on HSVM”. 2016 IEEE International
(ms)
6000 Conference On Information Communication And Em-
4000
bedded System.

2000 [3] Carlos A. S. Assis, “A Genetic Programming Approach

for Fraud Detection in Electronic Transactions” in
0
Advances in Computing and Communication Engi-
1046 1884 2730 3576 4422 neering (ICACCE), 2015 Second International
Transaction count Conference
[4] Andrea Dal Pozzolo, "Credit Card Fraud Detection
Figure 6: Performance graph and Concept-Drift Adaptation with Delayed
Parameters used to measure the system accuracy are sensitivity, Supervised Information",
precision, false positive rate, negative predictive value and [5] Véronique Van Vlasselaer, "APATE: A novel
accuracy as shown in table 2. [15] approach for automated credit card transaction fraud
detection using network-based extensions" published in
Table 4: System evaluation result Deci- sion Support Systems 2015
Sensitivity Precision Accuracy [6] Dhiya Al-Jumeily, "Methods and Techniques to Support
42.24% 10.20% 81.12% the Development of Fraud Detection System", IEEE
2015

46
 International Journal of Computer Applications (0975 – 8887)
Volume 168 – No.11, June 2017

[7] Dustin Y. Harvey, "Automated Feature Design for Springer [11] Andrea Dal Pozzolo, Olivier Caelen,”
Numeric Sequence Classifica- tion by Genetic Learned lessons in credit card fraud detec- tion from a
Programming", IEEE TRANSACTIONS ON practitioner perspective” , Expert Systems with
EVOLUTIONARY COMPUTATION, VOL. 19, NO. Applications 41,2014.
4, AUGUST 2015
[12] How a credit card is processed
[8] Mukesh Kumar Mishra, "A Comparative Study of https://www.creditcards.com/credit-card-
Chebyshev Functional Link Artificial Neural Network, news/assets/HowACreditCardIsProcessed.pdf
Multi-layer Perceptron and Decision Tree for Credit
Card Fraud Detection", 2014 13th International [13] Global Card Fraud Damages Reach $16B
Conference on Information Technology http://www.pymnts.com/news/2015/global-card-fraud-
damages-reach-16b/
[9] Sahin Yusuf, BulkanSerol, DumanEkrem,”A Cost-
Sensitive Decision Tree Approach for Fraud Detection”, [14] Credit Card Fraud Detection
Expert Systems with Applications, vol.40, pp.5916- https://www.kaggle.com/dalpozz/creditcardfraud
5923, 2013 [15] Yiğit Kültür, "A Novel Cardholder Behavior Model for
[10] Kang Fu, Dawei Cheng, Yi Tu, and Liqing Zhang, Detecting Credit Card Fraud”, IEEE international
“Credit Card Fraud Detection Using Convolutional conference on commuting and communication
Neural Networks”, Neural Information Processing, engineering, 2015

IJCATM : www.ijcaonline.org 47