Buyer-Seller Message Fraud Mitigation

Overview

Buyers and sellers communicate in written through various communication

channels eg. Email, messaging etc. These communication channels could be
used unethically by Fraudsters to stimulate Fraud.
Aim is to analyze the written communication between users (buyers and
sellers) and taking action would check the potential fraud.

Tenets
 Support to analyze written communication within the scope of checking
Fraud between any two external parties.
 Ability to analyze written communication for fraud based on Non-
Contextual configurable text patterns/Keywords which are extendable
with minimum effort.
 Availability of diverse actions that can be taken on messages.
 Support to analyze communication for fraud which are difficult to check
with keywords through contextual patterns.

Goals
 Build Infrastructure to enable fraud detection by analyzing the message
feed.
 Ability to take following actions on the message based on suspicion
level:
1. Drop the message from being delivered to the recipient.
2. Delay the message for a certain time before being delivered to
the user.
3. Queue the Message for Investigation with the specified SLA.
4. Educate the recipient by either adding text to the message or
send the link to the recipient which is accessible to only Sellers
and not buyers in our case.
 Adaptable platform in place to provide quantified score of suspicion
using diverse modes of Evaluation based on which the above-mentioned
Actions could be evaluated and actioned into.
 Proposed Design:

NLP (Sentiment
Data Store IWQueuingService
Analysis of the text)

Investigator

Suspicion Decision Message Mutator

Messages
evaluator Settlement State Setter
Evaluator

Educator
(part of
Mutator)

Delayed Drop
Queue per

Buyer Seller Message Platform Blocker Design

Description of each component:

Suspicion Evaluator:
This is the main component of the system that drives the strategy for checking
fraud in the message by quantifying the suspicion.
The suspicion evaluator has a plugin architecture which enables multiple
modes for evaluating fraud.
We would be building our framework onto which strategy will keep evolving
with time based on the following modes for suspicion evaluation:

Short term solution: Non-Contextual Pattern Evaluation based on keyWords.

This proceeding will be able to quickly react to known, ongoing fraud patterns
with a high exposure and a low false positive rate. However, it is expected that
the messages will be changed, allowing fraud to continue. Detecting new
keywords and updating them will require manual effort and time. This will not
completely close the loop hole, but will assist reducing the scope.

Long term solution:

Creation of ML models based on customer, order and message characteristics
and metadata. This will automate the detection of unknown patterns and take
action unto them.
Contextual Evaluation based on structuring of sentence (This would further
evolve into sentimental analysis combining several sentences)

Decision Settlement:
Take set of Actions based on the suspicion Level.
Various actions available are:
 Queue the message for Investigation.
 Mute the message for X hours.
 Drop/Block the message.
 Send the message to Mutator.

Investigator:
This component handles the Investigation aspects of the fraud suspicious
messages. Following actions performed by the investigator:
 Queue the Message using the IWQueuing Service into the TRMS Queue
for Investigation.
 Get the status of the EnQueued queue.

Message State Setter:

Handles the message state changes according to the decision made by
previous component and persist the messages in their rightful destination.
Messages could be persisted on the basis of their state into: Delayed Queue,
Dropper and passed into Mutator.

Educator:
The aim of educator is to educate the recipient of the fraud suspicious nature.
This is to be achieved by appending the messages into the original message
body highlighting the Amazon Policy and requesting the receipt to take a
responsible action. Educator is going to be a part of Mutator, which is another
component of Buyer Seller Messaging Platform.

Data Store:
Storing messages being which has been dropped along with the suspicion
attributes, annotation and tagging.
This would enable us to check the correctness of our decision and guide us in
optimizing our strategy.

Design Pattern:
Model View Controller(MVC) Pattern without UI based views would be a good
design pattern in our use case.
Decision Settlement would act as the controller that controls the various
actions to be taken on the messages.

Algorithm for Non-Contextual Suspicion Evaluation:

Edit Distance algorithm to be used to get the closeness of the text against the
configured keywords.

Data Security
Data involved are the private messages between the customers and sellers
which falls in the category of RED data (Highly confidential data). Sometimes
the data involved could be highly critical as well (in case the sender sends the
payment info).
Data by default is stored in the encrypted form.
Buyer Seller Message Platform has a library that handles the decryption and
encryption of the incoming messages which would be utilized by us before
applying the Suspicion evaluation and at the Message Setter State.
Technology Stack
Application Stack: Java/Spring/Guice

Modeling Stack: To explore various available tools based on their cost and
efficiency:
AWS ML
(Pro: Takes Care of the Programming aspect and automates the Model
Creation Completely
Con: Limited to Linear Model and small fine tuning according to our needs
)
Dryad
(Pro: Based on the Spark Cluster, would save time on Infrastructure
Deployment
Con: Real Time Prediction unavailable
)
Spin off own Spark Cluster and create the Model
(
Pro: Can Configure absolutely according to our needs
Con: Invest time for Infrastructure
)

Other Tools for Modeling Efficiency:

R:
For Visualizing and Analyzing the Data as well as Feature Engineering
Model Factory:
For Advanced purpose of the above

Open Question:
What happens to the attachments? Do we store them along with messages?
Can we send them as part of Investigations? If yes, Should we?
Appendix:

Buyer Seller Messaging Platform Architecture

References:
https://w.amazon.com/bin/view/RiskMining/BRM/IDRedirect/Impl/
https://w.amazon.com/bin/view/RiskMining/BRM/IDRedirect
https://www.wikiwand.com/en/Edit_distance
https://w.amazon.com/index.php/NLP_Framework/NLP_Components#Senti
ment_Analysis

Sim:
https://issues.amazon.com/issues/RM-2571