Siru mobile has a fraud detection system that estimates the fraud probability of a purchase and, if very likely to be the case, blocks the purchase or related mobile number as soon as possible.
There are several challenges in this field:
- It must be precise – to avoid blocking legitimate purchases
- It must be fast – a fraudster can wreak havoc if not stopped quickly
The previous implementation was based on information accessible through a native graph database (OrientDB) which (in time) became too slow, over-bloated, hard to maintain and, shortly, not viable for a real-time response.
It was originally asked if this information was possible to be ported to a traditional SQL database. Some years ago, when this idea was first expressed, the way of building graph over database was overly inefficient and unnatural: graph exploration is a recursive activity and standard SQL did not implement such way.
Things came to a turning point when MySQL introduced the first recursive constructs. Using the keyword “WITH RECURSIVE” became possible to navigate a graph-like structure with only one query without any workarounds.
With the improvement, the migration of the anti-fraud database to a SQL became feasible but there were still questions to answer. Would all current features be ported? Were there limitations? What would be the performance over the same tasks?
After a preliminary analysis it became clear that there was no limitation whatsoever in the features that could be ported: from a mathematical point of view the SQL graph representation and exploration could be implemented now in a natural (recursive) way without structural penalties or workaround needed.
Performances could not be estimated and needed to be measured. A first prototype was built and filled with a large share of the live data. After years of live information were ported to the new database in less than a day, enthusiasm started to spark.
Several adjustments were needed to match the previous structure (which could not be matched completely because some changes were required) and the database was rebuilt several times until it finally showed reliability.
The performance increase proved to be dramatic. From seconds in the previous version to tens of milliseconds with the new implementation.
What remained to measure was the consistency. Several tools were built to prove that the new system was consistent with the old one, in terms of information stored and updates. After the validation the project could finally go live.
Now the Siru fraud detection system can boast a much faster database that allows for real-time connections and checks. The ability to update and read the data has improved significantly, with a reduction of technical problems and a better customer experience.