IWBIS 2016 c 2016 IEEE

978-1-5090-3477-2/16/$31.00

Design And Implementation Of Merchant Acquirer

Data Warehouse at PT. XYZ
<RYD5XOGHYL\DQLDQG%RIDQGUD0RKDPPDG
)DFXOW\RI&RPSXWHU6FLHQFH8QLYHUVLWDV,QGRQHVLD
(PDLO\RYD#FVXLDFLGERIDQGUD#JPDLOFRP

Abstract— Merchant acquirer is a business of acquiring debit merchant acquirer PT. XYZ
card, credit card, and prepaid card transactions using EDC
(electronic payment terminals) in merchants. It is included in one TABLE I. MONTHLY TRANSACTION'S REPORTING PROCESS
of the top business priority areas in PT. XYZ. It is in the area of 



 
 

retail payments and deposits. It increases fees based incomes, 
 
$


##
" 

cheap funds, and high yield loans. In order to improve its 0-

 !(
#$



+ $
$
 

business performance, PT. XYZ needs the best strategy. "
$' ",
# #
However, a good strategic decision needs an adequate of useful
"!"$ #
$

%"(
#"!$

information. Currently, information that is provided by  ' 
/
%$#
 %"$ #
reporting staffs involved many manual tasks in the process. In $"#$ #
$
consequence, the data cannot be provided quickly, and it has
"#$ 
$
#


!%$
 ' 


*
#"&"*
$



some complexity limitation. As a solution for this problem, PT. 0
%$#
$"#$ #
$  ' 
%#
$

XYZ needs a data warehouse for its merchant acquirer business. !!$ *
This research will focus on the design and the implementation of
!



the data warehouse solution using a methodology that is !
#$



0-

$"#$ #
$
%#

developed by Ralph L. Kimball. Finally, data warehouse is $"#$ #
$
#!"#$
!!$ #
# #
developed which is suitable for merchant acquirer PT. XYZ's

"!"$ #
$

needs. "$
#"!$
$

"


/
%$#
#!"#$
$"#$ #
$
Keywords— data warehouse; EDC; Kimball; merchant
" ## $
"
#
& %!
$
"

1
%$#
acquirer !" ## $
#
!& $
$
$

%")
$
.
%$
I. INTRODUCTION #%")
$

"#%$#
%#
$
$#
#&


Information Technology has provided competitive advantages %$!%$ .
%$
 #"
 "
for many companies. Not only as a supporting tool for daily

routine activities, but also as a tool to help decision support. As a
tool for daily routine activities, it is called as OLTP (Online
Transaction Processing). IT is used as a tool to administer trading,
asset, or employee's data. As a tool to help decision support, it is
called as OLAP (Online Analytical Processing). IT is used as a tool
to make business performance reports, analyze customer's
behaviors, etc.
This research will focus on OLAP. On the early period,
companies used the OLTP's database for OLAP. It increased the
OLTP's database loads, but the performance of the OLAP system
itself was not very good. On the other hand, researchers showed
that OLAP needs a different database structure. So the concept of
Data Warehouse is born [9].
The Data Warehouse is a perfect solution for Merchant
Acquirer PT. XYZ. As shown in Table 1, currently, reporting staffs
need to gather data from various systems, process it manually, then
send the reports through emails. If Data Warehouse is already
implemented, all the data sources will be integrated in one
database, the processing steps can be done automatically, and the
results can be accessed through web portal. All the process will be
easier and faster.
The purposes of this research are:
1. Building a data warehouse that meets the requirement of
merchant acquirer PT. XYZ
2. Building an analysis tools that meets the requirement of
 

II. LITERATURE STUDY
Data warehouse is a multi-dimensional database that is
separated from the operational system. It is used by the users
to get the required information for decisions making. The
characteristics of Data Warehouse are subject oriented,
integrated, time variant, data granularity, and non volatile
[7][9][12].
Merchant Acquirer is the problem domain of this
research. It is a bank or other institution that cooperates with
merchant to enable the customers in doing transactions using
credit or debit card. It also has responsible on the settlement
process [5].
Bill Inmon and Ralph Kimball are two major
researchers in the development of Data Warehouse
methodologies. Each has its own different approaches. Bill
inmon saw Data Warehouse from enterprise-wide's point of
view. Bill Inmon's approach is top-down. On the other hand,
Ralph L. Kimball saw Data Warehouse as an immediate
solution for the employees to analyze data. Kimball's
approach is to make each department's Data Mart first, then
the enterprise Data Warehouse will be constructed from those
data marts. Kimball's approach is bottom-up [1].
47
 IWBIS 2016 c 2016 IEEE
978-1-5090-3477-2/16/$31.00
This research will be conducted using Ralph L. 2. Transaction's Amount
Kimball’s methodology, because of these reasons: Transaction's amount is used to calculate the amount of fee
• Faster implementation (merchant discount rate) and the amount of customer's fund in
Kimball’s approach is bottom-up. So the scope of the the account. It is needed by the business unit to get information
research could be limited. So this research will only cover about its business performance.
the highest priority informations requirement of merchant 3. Number of EDC
acquirer PT. XYZ. Therefore, the users will get immediate Number of EDC is needed as the portfolio of merchant
benefits from the Data Warehouse implementation. acquirer PT. XYZ. Based on the number of EDC, merchant
• Easier implementation acquirer PT. XYZ generates plan for operational and business
Dimensional modelling in Kimball’s approach makes strategies.
easier understanding between the users and the system
4. Number of Transactions based on the response time category
developers.
It shows how fast is the transaction processed by the EDC. This
III. METHODOLOGY fact is used to estimate the quality of the EDC and the
infrastructures. The fact will also summarize the customer
The whole process of this reasearch can be seen at Fig. 1.
experience, in doing transactions at merchant using PT. XYZ's
The majority of the methodology is based on the Ralph
EDC.
Kimball’s bottom-up approach.
There are 8 steps that need to be followed. Starting from
finding problem definitions, doing literature study, setting out The dimensional model of data warehouse merchant acquirer
the methodology, analyzing, designing, and implementing PT. XYZ can be seen at Fig. 2.
data warehouse, reporting, and finalizing conclusion.
Dimension Table
Output: Output: Response Time Category
Problem Conclusion
Research Conclusion - Category
Definitions
Question Suggestion
Dimension Table: Time
Fact Table - Date
Output: Deployment and Output: Response Time - Day
Literature Study Theoritical Operational User guide - Date - Month
Framework Technical guideline - Location - Year Dimension Table
- Resp Time Category Card Type
- Frequency - Card Type
User Interface Output:
Output: Data Visualization Dimension Table
Methodology Design and
Methodology Analysis tools Fact Table Location
Implementation - Regional Office Fact Table
Report Number of EDC
- Date Transactions
Dimension Table: - Date
- Location
Data Warehouse Administrator - Location
Data Warehouse - Administrator
Analysis and - Regional Office - Adminstrator
- Segment
Implementation - Segment
Design - Vendor Dimension Table:
- Number of EDC Segment - Vendor
Output: Output: - Card Type
- Segment
Scope of research Staging database - Transactions
Information requirement Data Cube Dimension Table: Frequency
Vendor - Transactions
Data warehouse implementation
- Vendor Amount
Fig. 1. Research Methodology Fig. 2. Data Warehouse Model

The technology architecture design of data warehouse

IV. DATA WAREHOUSE ANALYSIS AND DESIGN
There are several work units involved in the business of
merchant acquirer in PT. XYZ. This research will only focus
on the requirement of two units: the Business unit and the IT
Operations unit.
From many business processes of both work units, two
business processes are selected. Those are the transaction
process and the EDC deployment process. It requires 6
dimensions (point-of-view): the regional office of the
administrators, the regional office of the location, merchant
segments, vendors, card types, and response time categories.
It also requires 4 data as the facts:
1. Transaction's Frequency
Transaction's frequency is needed to get the number of
transactions processed. This is usefull for the infrastructure's
capacity planning. It is also needed by the business unit to get
information about its business performance.
merchant acquirer PT. XYZ can be seen at Fig. 3. It consists
of 4 parts:
1. Operational sources system
It is the data sources of Data Warehouse Merchant Acquirer
PT. XYZ. The data sources are limited on two formats:
Microsoft Excel 2007 and AS400 file.
2. Data staging area
It is the temporary storage for data from operational sources
system, before processed into the right format. Microsoft
SQL Server 2005 is used for this data staging area.
3. Data presentation area
It is the storage for data that already been processed. Data
presentation area is also uses Microsoft SQL Server 2005,
especially the Microsoft SQL Server Analysis services.
4. Data access tools
The data access tools is built using Microsoft SQL Server
Reporting Services on Microsoft SQL Server 2005.

48
 IWBIS 2016 c 2016 IEEE
978-1-5090-3477-2/16/$31.00

Fig. 3. Technology Architecture

V. DATA WAREHOUSE IMPLEMENTATION

The implementation uses Microsoft SQL Server Integration
Services. The flow process can be seen at Fig. 4. The flow process is
divided into 2 parts:

Fig. 5. Data Warehouse Implementation

1) Extract and Transform
Extract is the process of gathering all data from operational
sources system, and transform is the process of transforming it into
usable forms. The data which is extracted and transformed are about
transaction, EDC, merchant, and response time. The source of
transaction data is transaction log from ICS (Integrated Card
Systems) on AS400 machine. The file system name is
BMDATPFIN/TRANSRPF.
The source for EDC data is from Excel Files of the related work
unit. The source for response time data is transaction log in ICS. The
file system name is BMDATPTPI/TPPALGPF.
VI. USER INTERFACE
The user interface enables the users to access all
information in the Data Warehouse. The users are staffs in the
Business unit and the IT Operations unit.
A. Data Visualization
This user interface is used by high level manager. The
information is about transaction's amount based on regional
office (locations) and transaction's frequency based on
response time's category (Fig. 6).

Fig. 6. Data Visualization

B. Data summary
Data summary is used by the middle level manager. The
user can measure transaction, number of EDC, and response
Fig. 4. Extract, Transform, and Load
time based on some dimensions (Fig.7).

2) Load
It is a process of loading data into the fact tables and the
dimension tables. The transaction and response time fact table is
updated using previous day's data. The EDC profile fact table is
updated using the day before yesterday's data. The dimension tables
are updated only if there is any new value existed. The physical
model of data warehouse merchant acquirer PT. XYZ can be seen
on Fig. 5. Fig. 7. Data Summary

C. Data Details
This user interface is used by the reporting staffs to make ad-
hoc reports, as demanded by the higher level management. It

49
 IWBIS 2016
includes all details which is needed to make any actionable
reports (Fig. 8).
Fig. 8. Data Details
Testing has been conducted to ensure that the data
warehouse is suitable for merchant acquirer PT. XYZ, and
can be the solution for the existing problems. It shows that
the user can make monthly transaction reports in about 8
seconds. It is 14 minutes and 52 seconds, or about 99,11%,
faster than before data warehouse implemented.
VII. CONCLUSIONS AND SUGGESTIONS
A. Conclusions
As the result of this research, a data warehouse has been
built to meet the requirement of business and operational of
merchant acquirer PT. XYZ. The business unit needs
information about transaction's frequency and amount. The IT
Operations unit needs information about terminals (EDC),
merchant, and response time. An analysis tools has been built
to access information of merchant acquirer PT. XYZ. There are
three form of user interfaces: data visualization, data summary,
and data details.
The existance of data warehouse merchant acquirer PT.
XYZ has shorten the amount of time needed to access
information. For example, in the making of monthly
transaction report, the time efficient is 99,11%.
c 2016 IEEE
978-1-5090-3477-2/16/$31.00
B. Future Work
Further research can be conducted to fulfill more
information requirement of the merchant acquirer PT. XYZ.
For example, the information about Merchant Discount Rate
and Funding. Those two things could add up as
measurements (facts).
REFERENCES
[1] Mary Breslin. 2004. Data Warehouse Battle of The Giants: Comparing The
Basic of The Kimball and Inmon Models. Minneapolis: Business Intelligence
Journal.
[2] Ramon P. Degennaro. 2006. Merchant Acquirer and Payment Card
Processors: A Look inside the Black Box. Atlanta: Federal Reserve Bank
of Atlanta.
[3] R. L. Ackoff. 1989. From Data to Wisdom in The Journal of Applies
Systems Analysis, Volume 16, Page 3-9.
[4] Rüdiger Wirth dan Jochen Hipp. 1999. CRISP-DM: Towards a Standard
Process Model for Data Mining. Germany: ESPRIT.
[5] Indonesia Card Transaction Reports, Bank Indonesia,
http://www.bi.go.id/web/id/Statistik/
Statistik+Sistem+Pembayaran/APMK/Transaksi.htm, Oktober 2012.
[6] Liautaud dan Mark Hammond. 2000. E-Business Intelligence: Turning
information into knowledge into profit. New York: McGraw-Hill.
[7] Jiawei Han dan Micheline Kamber. 2001 Data Mining: Concepts and
Techniques. San Francisco: Morgan Kaufmann Publishers.
[8] Paulraj Ponniah. 2010. Data Warehousing Fundamentals For IT
Professionals. New Jersey: John Wiley & Sons Inc.
[9] Ralph Kimball dan Margy Ross. 2002. The Data Warehouse Toolkit.
New York: John Wiley and Sons, Inc.
[10] Roger S. Pressman. 2010. Software Engineering, A Practiotioner’s
Approach. New York: McGraw-Hill.
[11] Vidette Poe, dkk. 1997. Building a Data Warehouse for Decision Support.
New Jersey: Prentice Hall.
[12] William H. Inmon. 2005. Building the Data Warehouse. Indianapolis:
Wiley Publishing, Inc.
[13] Arief Bandung Wahyudi. 2010. Perancangan Data Warehouse dan
Penerapan Data Mining pada Transaksi E-Channel Studi Kasus Bank
XYZ. Jakarta: MTI UI
[14] Johanes Parulian Tamba. 2003. Perancangan Data Warehouse studi
kasus: PTX. Jakarta: MTI UI
[15] Wiryawan Setiadi. 2001. Perancangan Data Warehouse Studi Kasus PT.
Bank Mandiri. Jakarta: MTI UI.
50