Difference between revisions of "Red Dot Payment - Project Overview"

From Analytics Practicum
Jump to navigation Jump to search
Line 43: Line 43:
 
|}
 
|}
 
<!------- Details ---->
 
<!------- Details ---->
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Sample Data</strong></font></div></div>==
+
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Project Introduction and Background</strong></font></div></div>==
'''''*Due to sensitivity of data, sample data will not be shown here. Please refer to the submitted reports for more details.'''''
+
Founded by a group of visionary financial technology payment experts in 2011, Red Dot Payment (RDP) has grown into a trusted online payment company providing premium payment solutions and expertise to the brightest merchants across Asia Pacific. Bringing best-in-class practices, RDP is the trusted FinTech partner of banks, merchants, payment schemes, payment gateways, non-banking financial institutions, security and fraud management system providers.
 +
<br><br>
 +
In 2016, RDP grew to handle millions of transactions across the globe, managed by a dedicated 40-person strong operation - with headquarters in Singapore, and offices in Thailand and Indonesia. Its products and services include - RDP connect, InstanCollect, InstanPay, InstanPromo and InstanToken.
 +
<br><br>
 +
The following depicts RDP’s business model:<br>
 +
<center>[[File:BusinessModelRDP.jpg|1000px]]</center><br>
 +
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Business Problem and Motivation</strong></font></div></div>==
 +
While RDP handles millions of transactions across the globe, the company has not yet been able to derive any conclusive analysis from its transaction data. There is untapped potential that is unexplored here, as they operate online and thus have the advantage of easily collecting large amounts of valuable data about their merchants as well as their customers. In addition, there are many data points captured previously with little insights derived, resulting in business decisions being driven mainly by intuition. Thus, by providing our team with their existing data, RDP hopes to gather a deeper understanding of their data. Moving forward, RDP hopes to make more informed decisions utilising the patterns we identify from the data.
 +
<br><br>
 +
After meeting with our client to provide updates and generate insights for them, these are the following areas that our client is interested in:
 +
<br><br>
 +
'''Industry Strategy:''' RDP is interested to find if our data analysis can provide insights as to which markets or industries they should target in retaining or recruiting new merchants
 
<br>
 
<br>
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Metadata</strong></font></div></div>==
+
'''Visual Dashboard:''' The creation of a visual dashboard to showcase our data analysis will be well anticipated by RDP
Previously, we only have the transaction data of 2017 provided by RDP.  
+
 
Moving on, we managed to obtain transaction data of 2016 as well.
+
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Meetings with Project Coordinator, Project Client and Team</strong></font></div></div>==
 +
Our team aims to meet our Project Coordinator, Professor Kam Tin Seong on average of at least once every week in order to ensure that we are progressing on the right track. We also met our client/project sponsor once a month to update them on our progress and validate our analysis, while our internal team meetings are held at least twice a week. All minutes can be found under "Project Documentation".
 +
 
 +
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Project Objectives</strong></font></div></div>==
 +
Previously, we have identified the following objectives in our proposal:
 +
<br><br>
 +
1. To observe and develop meaningful insights from RDP’s datasets by performing exploratory data analysis.
 +
<br>
 +
2.  To develop a visual dashboard. This will aid RDP in understanding some of their current business issues, as well as benchmark metrics and attributes that the company may not be currently analysing.
 +
<br>
 +
3.  To formulate recommendations to improve their future business activities based on our findings.  
 
<br><br>
 
<br><br>
Below are the definitions of common terms used in their business model:
+
Moving forward, on top of the above project objectives, we have further added on new objectives we aim to achieve in our study in terms of exploratory data analysis:
 
<br><br>
 
<br><br>
'''''MERCHANT''''' - A merchant is a business, often a retailer, that operates online. Each merchant has appointed RDP to be its payment processor to handle online transactions between them and their customers.  
+
'''Objective 1:''' Identify relationship between approved/rejected transaction rates and (i) the month of the year, (ii) day of the week and (iii) time of the day.
 
<br><br>
 
<br><br>
''<b>CUSTOMER</b>'' - A customer is an entity that makes a transaction with the merchant. For a transaction to be made, a customer must make contact with a merchant and provide their payment details (e.g. Credit card number) to the merchant through RDP’s payment processing gateway.
+
'''Objective 2:''' Identify relationship between approved/rejected transaction rates and number of transactions per merchant
 
<br><br>
 
<br><br>
The following table shows the list of variables in the data and their associated description:
+
'''Objective 3:''' Identify star and laggard merchants in terms of approved transactions
 
<br><br>
 
<br><br>
 +
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Scope of Project</strong></font></div></div>==
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! NAME !! TYPE !! DESCRIPTION
+
! Task !! Description 
 
|-
 
|-
| date_created || Date Time || Data and time at which the transaction was carried out between merchant and customer
+
| Gather Requirements || Confirm and gather sponsor requirements
 
|-
 
|-
| period || Integer || Month of the year the transaction was carried out between merchant and customer
+
| Initial Research and Preparation || Conduct preliminary data exploration and define project objectives and scope
 
|-
 
|-
| hour || Integer || Hour in a day the transaction was carried out between merchant and customer
+
| Project Proposal || Prepare project proposal and Wikipage
 
|-
 
|-
| day || Integer || Day of the week the transaction was carried out between merchant and customer
+
| Data Exploration and Preparation || Ensuring that data is clean and can be analysed using analytical software; We also have to transform data (e.g. remove outliers and recode variables for analytical software to read); and conduct exploratory data analysis
 
|-
 
|-
| time || Time || Time at which the transaction was carried out between merchant and customer
+
| Model Building || Through research findings and experience, we will attach and test suitable models to our data. We have used Interactive Binning and Time Series data analysis to generate insights
|-
 
| name || Alphanumeric || Name of merchant
 
|-
 
| amount of money || Decimal || Total transaction amount - unstandardised currency
 
|-
 
| currency || CHAR(3) || Currency of the transaction amount - usually in SGD or USD
 
|-
 
| converted value || Decimal || Total transaction amount - standardised in SGD
 
|-
 
| reason_code || Alphanumeric || A unique code tagged to each reason for each approved or rejected transaction made by customer
 
|-
 
| reason_code_description || Alphanumeric || Description of the reason for each approved or rejected transaction made by customer
 
|-
 
| card_data1 || Integer || First 6 digits of customer’s card number - reveals details about the issuing bank and card type
 
|-
 
| card_data2 || Integer || Last 4 digits of customer’s card number
 
|-
 
| contact_ip_address || Alphanumeric||  IP address of the customer
 
|-
 
| contact_ip_country || Alphanumeric || IP country of the customer
 
|-
 
| Bin [based on log10] || Integer || Bin number each merchant belongs to
 
|}
 
<br>
 
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Data Cleaning</strong></font></div></div>==
 
For data cleaning, we carried out the following steps:<br><br>
 
'''<big>General Cleaning</big>'''
 
<br><br>
 
1. Compiled 2016-2017 data <br>
 
2. Standardised all merchants’ names and currency into uppercase: e.g. Realised that JMP Pro recognises characters with uppercase and lowercase separately<br>
 
3. Standardised currency of all transaction values: Converted all non-SGD values into SGD values, based on average monthly historical exchange rates found on OANDA.com<br>
 
4. Split ‘date_created’ column into ‘date’ and ‘time’ columns.<br>
 
5. Created a new column ‘period’ to indicate the respective month of each date in the  ‘date’ column (e.g. 01/01/16 → Period 1; 01/01/17 → Period 12)<br>
 
6. Created a new column ‘hour’ to indicate respective hour of each time in the ‘time’ column (e.g. 1:00:00 AM → 1; 1:00:00 PM → 13)<br>
 
7. Created a new column ‘day’ to indicate respective day in the week for each data in the ‘date’ column (e.g. Monday is assigned a value of 1, Sunday is assigned a value of 7)<br>
 
8. Removed deactivated or terminated merchants
 
  - 2016: 41 transactions removed;
 
  - 2017: 841 transactions removed<br>
 
9. Removed rows with ambiguous or illegible characters/ negative transaction value on JMP Pro:
 
  - Removal of 1563 rows with ambiguous or illegible characters;
 
  - Removal of 2 rows with negative transaction value
 
<br><br>
 
'''<big>Removal of Outliers</big>'''
 
<br><br>
 
There were transactions with transaction value as high as 5.41212e+15. Such transaction, as shown in Figure 1, represents top 0.5% of all transactions, and has a very large difference in value compared to the bottom 99.5%. This would result in a very skewed distribution of transaction value (see Figure 2a), leading to inaccurate results during exploratory data analysis. Thus, it is essential that we remove these outliers. In addition, through our client meetings, we realised that our data includes test cases - i.e. False transactions carried out by merchants to test RDP payment modes; While we are not able to fully determine whether a transaction is a test case or not (as our client cannot give us a benchmark for a transaction value that would define a test case), we can reduce the number of test cases by eliminating the bottom 0.5% of all transactions.
 
<br><br>
 
<center>[[File:Figure1RDP.jpg|200px]]<br>
 
<small>Figure 1: Summary Statistics for ‘Converted Value’</small></center>
 
<br/>
 
<br>
 
* Remove transactions with transaction value belonging to top 0.5% and bottom 0.5% of all transactions
 
* In addition, we also remove transactions with transaction value less than $1, as we realised that there were still many transactions with value <$1. Based on our team’ perspectives, these transactions are likely to be test cases, as it is rather impossible to have transaction value <$1 across two years. Thus, these transactions are necessary to be removed.
 
<br><br>
 
<center>[[File:Figure2RDP.jpg|400px]]<br>
 
<small>Figure 2a: Johnson SI Transformed Converted value distribution before removing outliers</small></center>
 
<br/>
 
<center>[[File:Figure3RDP.jpg|400px]]<br>
 
<small>Figure 2b:  Johnson SI Transformed Converted value distribution after removing outliers</small><br></center><br><br>
 
- '''Before Removing Outliers'''<br>
 
- Total number of transactions: 2,310,781<br><br>
 
 
 
- '''After Removing Outliers'''<br>
 
- Total number of transactions: 2,282,080<br>
 
- Excluded number of transactions: 28,701<br>
 
<br>
 
==<div style="background: #DD597D; line-height: 0.3em; font-family:calibri;  border-left: #CFCFCF solid 15px;"><div style="border-left: #FFFFFF solid 5px; padding:15px;font-size:15px;"><font color= "#F2F1EF"><strong>Data Preparation</strong></font></div></div>==
 
We have identified the most common types of transaction in the following:<br>
 
1. Approved or Completed Transaction<br>
 
2. Bank Rejected Transaction<br>
 
3. Authentication Failed<br>
 
4. Duplicate Merchant_TranID Detected<br>
 
<br>
 
Moving forward, we will only be analysing the approved transactions, and the top 3 types of rejected transaction, in order to narrow down the scope of our work.
 
<br><br>
 
<big>'''Interactive Binning'''</big>
 
<br>
 
From our data, we realised that there is huge discrepancy in the total number of transactions carried out by each merchant from 2016-2017; The range varies from 1 to 1212019. As stated in our refined objectives, we hope to identify the over-performing (star) and underperforming (laggard) merchants through the use of Line of Fit graphs. We have decided to group the merchants into 5 bins (cut-points for binning at 20 percentiles) based on total number of transactions per merchant, as we realised that compared to the Line of Fit graphs for all merchants, grouping them into 5 bins provide better model fit.
 
<br>Next, we rename each bin into the following:<br>
 
{| class="wikitable"
 
 
|-
 
|-
! Bin [Based on Log10]  (Group) !! Number of transactions per merchant (Range) !! Number of merchants
+
| Project Revision (Mid-Term) || Assisted by RDP through obtaining feedback during our sponsor meeting
 
|-
 
|-
| 1 || <= 7 || 72
+
| Mid-term Preparation || Prepare mid-term report, presentation and Wikipage
 
|-
 
|-
| 2 || 8 - 52 || 72
+
| Model Validation and Refinement || Perform Time Series Clustering; Conduct independent sample t-tests (e.g.  Ensure the results are similar when attached to different years of study) and refine analysis of data
 
|-
 
|-
| 3 || 53 - 286 || 73
+
| Insights and Recommendations || Create visualisation from analysis results and formulate recommendations for our client
 
|-
 
|-
| 4 || 287 - 1479 || 69
+
| Project Revision || Assisted by RDP through obtaining feedback during our client meeting; Align our final deliverables with client requirements
 
|-
 
|-
| 5 || > = 1480 || 75
+
| Final Preparation || Prepare abstract and full paper, final Wikipage update and final presentation with necessary deliverables
 
|}
 
|}

Revision as of 20:23, 1 March 2018

HOME

 

PROJECT OVERVIEW

 

PROJECT FINDINGS

 

PROJECT DOCUMENTATION

 

PROJECT MANAGEMENT

 

ANLY482 HOMEPAGE

Background Data Source Methodology

Project Introduction and Background

Founded by a group of visionary financial technology payment experts in 2011, Red Dot Payment (RDP) has grown into a trusted online payment company providing premium payment solutions and expertise to the brightest merchants across Asia Pacific. Bringing best-in-class practices, RDP is the trusted FinTech partner of banks, merchants, payment schemes, payment gateways, non-banking financial institutions, security and fraud management system providers.

In 2016, RDP grew to handle millions of transactions across the globe, managed by a dedicated 40-person strong operation - with headquarters in Singapore, and offices in Thailand and Indonesia. Its products and services include - RDP connect, InstanCollect, InstanPay, InstanPromo and InstanToken.

The following depicts RDP’s business model:

BusinessModelRDP.jpg


Business Problem and Motivation

While RDP handles millions of transactions across the globe, the company has not yet been able to derive any conclusive analysis from its transaction data. There is untapped potential that is unexplored here, as they operate online and thus have the advantage of easily collecting large amounts of valuable data about their merchants as well as their customers. In addition, there are many data points captured previously with little insights derived, resulting in business decisions being driven mainly by intuition. Thus, by providing our team with their existing data, RDP hopes to gather a deeper understanding of their data. Moving forward, RDP hopes to make more informed decisions utilising the patterns we identify from the data.

After meeting with our client to provide updates and generate insights for them, these are the following areas that our client is interested in:

Industry Strategy: RDP is interested to find if our data analysis can provide insights as to which markets or industries they should target in retaining or recruiting new merchants
Visual Dashboard: The creation of a visual dashboard to showcase our data analysis will be well anticipated by RDP

Meetings with Project Coordinator, Project Client and Team

Our team aims to meet our Project Coordinator, Professor Kam Tin Seong on average of at least once every week in order to ensure that we are progressing on the right track. We also met our client/project sponsor once a month to update them on our progress and validate our analysis, while our internal team meetings are held at least twice a week. All minutes can be found under "Project Documentation".

Project Objectives

Previously, we have identified the following objectives in our proposal:

1. To observe and develop meaningful insights from RDP’s datasets by performing exploratory data analysis.
2. To develop a visual dashboard. This will aid RDP in understanding some of their current business issues, as well as benchmark metrics and attributes that the company may not be currently analysing.
3. To formulate recommendations to improve their future business activities based on our findings.

Moving forward, on top of the above project objectives, we have further added on new objectives we aim to achieve in our study in terms of exploratory data analysis:

Objective 1: Identify relationship between approved/rejected transaction rates and (i) the month of the year, (ii) day of the week and (iii) time of the day.

Objective 2: Identify relationship between approved/rejected transaction rates and number of transactions per merchant

Objective 3: Identify star and laggard merchants in terms of approved transactions

Scope of Project

Task Description
Gather Requirements Confirm and gather sponsor requirements
Initial Research and Preparation Conduct preliminary data exploration and define project objectives and scope
Project Proposal Prepare project proposal and Wikipage
Data Exploration and Preparation Ensuring that data is clean and can be analysed using analytical software; We also have to transform data (e.g. remove outliers and recode variables for analytical software to read); and conduct exploratory data analysis
Model Building Through research findings and experience, we will attach and test suitable models to our data. We have used Interactive Binning and Time Series data analysis to generate insights
Project Revision (Mid-Term) Assisted by RDP through obtaining feedback during our sponsor meeting
Mid-term Preparation Prepare mid-term report, presentation and Wikipage
Model Validation and Refinement Perform Time Series Clustering; Conduct independent sample t-tests (e.g. Ensure the results are similar when attached to different years of study) and refine analysis of data
Insights and Recommendations Create visualisation from analysis results and formulate recommendations for our client
Project Revision Assisted by RDP through obtaining feedback during our client meeting; Align our final deliverables with client requirements
Final Preparation Prepare abstract and full paper, final Wikipage update and final presentation with necessary deliverables