Fraud detection and prevention is always a batter field. Fraudsters will keep finding new ways to game the system. On the other hand, that is a big business opportunity. Let see how crowded the market is:
This is a hand selected list of some notable players in this markets. There are couple interesting observations:
Machine learning (or AI) is a must-have feature to the product.
Big data is still a treasure box with big potential.
Rule based system is still popular (it is old fashion?).
A hyper system combining rules and AI will be promising.
Visualization can be helpful and user friendly for customers.
Anyway, here are two nice summaries from seon.io and unfraud.com:
If you work on e-commerce, beside making sure the online payment is smooth, another critical task is to deal with fraud! Fraud shares lots of common characteristics with (information) security. Good guys and bad guys are always fighting endlessly, just like Marvel comics: super heroes vs. super villains.
Credit: Marvel Comics
Most company either builds an in-house solution or use some market available solution. So what is the hard core of a fraud management system?
Before answering this question, maybe we can go through a simple e-commerce checkout flow (you know in reality, it will be much more complex):
In last 5 years, I have worked on three fraud management systems. In a plaintext, we gather all possible “evidences” of fraudsters and try to convict the “crime”. Translate the previous sentence to technical words: a payment transaction comes to a rule engine, it will run bunch of rules at real time, then outputs a decision like reject, approve, review, etc. Based on the configuration and the business model (Merchant on Record or not, etc.) , the payment system will take corresponding action.
To build the rule engine, Drools is a popular choice. Of cause, we can build a similar in-house version too. The key is the rules. Here is a list of some rules:
Be in the Horzion project for months now, learn lots of new things and it might be a good time to document some learnings.
To switch from monolithic service to micro service means a total mightset change. The frist thing is to become a DevOps. You need to write/debug/test your code, build/deploy the code locally and remotely and monitor the service. This is very chanllenging in mature company because thses functions are isolated into different teams/organizations.
Here are some components in building microservice:
authentication for internal and external users
something need special handling:
how to handle exception: you can throws an exception in one service and hope another service catch it in old fasion.
how to pass data between services: if several services need to process the same request at different stage. if you need to merge the reply from couple services? or some service need the same intermedian data?
how to resolve service dependency: the business logic can be sync or async.
how to handle failover: if a service not available, will it retry and how?
how to document your service: this will impact how user can easily use the APIs
What is the term? “The simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions.” – Roy Fielding
To understand this, we need first to understand what is the benefit: decouple client and server of RESTful API. In current API development, the client follows the API specification and any change at server side will break the client code.
How to solve this? Image if the client follow the action told by the server and the code is adaptive enough to the actions. Then the server can evolve independently.
Recently, I get involved into the activity of scale an existing application to support much higher throughput. It is all about scalability! Mysql with sharding still doesn’t work. Cacheing need to be improved. How to cooperated with new analytic system?