Fraud Detection at BlackBuck
Image Source: MIT News
Blackbuck offers many value added services to fleet owners apart from end-to-end management of freight services for corporates & offering a low cost marketplace for shippers & truck owners. These include Fuels, Tolls (read FASTag), GPS etc. Most of these value added services require a solid payment infrastructure to facilitate seamless digital transaction
To ensure superior customer experience, our payment system consists of many microservices like inbound, outbound, fraud etc. Most important services among these are the Inbound Service (This is integrated with many payment gateways by which customers can pay for Blackbuck services) and the Outbound Service (This service is integrated with different payment gateways to either return money to source or to give incentives).
FRAUD TYPES
Considering these are digital payment transactions and that BlackBuck also offers special incentive schemes to promote usage of our services, there exists a strong likelihood for frauds to happen. Listed below are some of the common types of fraud we have seen:
Payment instrument fraud : Payment instruments refer to the different types of cards like credit card, debit card etc . The common cases observed here include a) Instances where a person uses other person's card or transacts using a) stolen card etc b) In some cases where the same customer is found to use more than 10 different credit/debit cards.
Misuse of incentive : We sometimes run Referral Schemes where fleet owners are rewarded for referring new users to the BlackBuck platform. For eg. If a new user signs up with an existing user’s referral code and performs X Rs worth transaction, Y Rs is given as referral benefit to the new user and the person who referred to him.
We have seen many cases of fraud reported in this system. (Customers started creating dummy users by colluding with a sim seller to get as many new sims as they want) and all these new users were given Y Rs along with the person who refers so X*Y Rs was incurred as a “loss” by BlackBuck and random dummy users were being introduced into the system who would drop off anyway in 1-2 months. This also provides an incorrect picture of the actual retention numbers of the product.
SOLVING FOR CASES OF FRAUD
Post an extensive research, we came up with a solution to identify the clusters of users based on IMEI numbers of devices. When a new user who is signing up from a device and that device IMEI belongs to an existing cluster, then the user and the referrer will not be given any referral benefit and this new user will become part of this cluster. In each cluster we created a graph connecting IMEI number, phone number and some other attributes.
In Blackbuck, we have many services which provide incentives and if this solution is tightly coupled with a specific service, then it will create dependency on the owner service. Hence we decided to create a platform where we will feed the data into the system and any other service can add their rules in the rule engine and rule engine will be responsible to run rules on the data.
Next challenge was to pick the right data storage and as I mentioned earlier that we wanted to create a graph between different attributes which automatically ruled out the possibility of using mysql or any other relational database. Among available graph databases we had decided to use orientDB.
OrientDB is an open source Nosql DBMS written in Java which supports all modes like schema-full, schema-less and schema-mixed and provides extendible-hashing and b-tree based indexing and supports key/value, and documents. In orientDB relationships are managed as graphs which connect records.
System architecture and flow :
Whenever a user goes for any transaction, a request is first sent from the Accounting service to the fraud service which runs predefined rules and returns a double number between 1-5. 1 being low risk and 5 is the highest risk profile. After getting a response from the fraud service, the accounting service decides whether it should go ahead with the transaction or not. After the completion of a transaction, the accounting service sends transaction related data as events to the fraud service via broker.
Why Use A Broker Software : In Blackbuck, we handle a high number of transactions - that is why sync calls were avoided as we did not want to bombard the fraud service with the data which will be used later. This led to choosing Kafka because consumers can consume data at their own pace without putting pressure on the service.