Fraud Detection Solution for Telecommunications Provider

Industry: Telecommunications

Services: wireless voice, messaging, and mobile internet

Company / Brand: Play (P4 Sp. z o.o. part of Iliad Group)

Customer base: 13 million active users

Peak events throughput (in the fraud domain):  200k events per second at peak

The initial scope of implementation:

Business domain: Fraud

Engines and processing modes: Flink streaming

The final scope of Nussknacker implementation:

Business domains: 

• Real-time marketing communications
• Customer Relationship Management: customer retention, automated customer service (chatbot / IVR), recommendation engine
• Fraud Detection System
• Lawful interception 

Engines and processing modes: 

• Flink in streaming and batch
• Lite in request-response processing mode

Background

After several years of using an off-the-shelf fraud management system, Play was looking for a new solution which would allow it to detect fraud in real time. Unfortunately at the time none of the considered systems offered a real-time feature. Additionally, Play believed that none of the vendors offered a cost and time-effective way of extending their package functionality and fraud detection capabilities. The positive experience with the Nussknacker implementation in the Real-Time Marketing domain convinced Play that Nussknacker may be the right solution.

Solution highlights:

• Ca 70 Nussknacker scenarios for fraud detection and problematic usage patterns - the latter result in alerts for the customers
• 200k events per second at peak

Challenges:

• Development time. Fast development cycles are essential in the fraud domain as fraud schemes are continually evolving. The off-the-shelf fraud detection platforms considered by Play were perceived as expensive to customise and with long delivery cycles in cases when existing off-the-shelf tool configuration capabilities were not sufficient.
• Real-time rather than batch. Play already had an off-the-shelf batch-oriented fraud detection system. Play believed that real-time fraud detection was a must.
• Engineering complexity. The technical nature of events produced by telecommunication systems, with extreme volumes of events produced in real time requires mastery of tools like Flink. High throughput and the ability to deal with streamed events with low latency were must-haves.
• The user. The fraud detection algorithms ideally should be developed by non-programmers with domain-specific knowledge. The ideal tool should abstract the complexities of streaming, time windows, 3GL programming, etc - ideally allowing the domain experts to focus exclusively on the algorithm and the data. A visualisation of the decision logic graph was regarded as an important feature.

How Nussknacker helped to address the challenges: 

• Tool for not-so-technical users. Nussknacker not only abstracts out the technical complexities of Flink, time windows, data enrichments, and REST API calls but also presents the decision algorithm in the form of a graph rather than a text file with code. The key business-level rules which control the behaviour of the scenarios are abstracted into decision tables and can be easily modified. The Fraud Team can easily develop complex detection scenarios; because this can be done with low development effort, the team can devote the majority of its capacity to the fraud domain rather than technology or development challenges.

• Allows to focus on the problem (fraud detection), not the implementation. Development of the fraud detection logic ceased to be a barrier for Play - both in terms of technical implementation and time required between the identification of a new fraud scheme and implementing the fraud detection scenario. As a result, Play’s Fraud team can focus on improving its fraud intelligence rather than implementations per se.   

• Architectural and feature fit. CDRs (Call Detail Records) are ingested by Nussknacker from Kafka;  Nussknacker natively processes data streams (Kafka), ensuring very high throughput and low latency which are critical for fraud detection and then prevention. Enriching incoming data stream with data from external sources is also easy; as the result the range of data used for fraud detection can evolve together with the algorithm. Finally, Nussknacker (thanks to Flink) supports  time windows queries, allowing to (resource) efficiently implement detection of:
  • SPAM
  • SIM cloning 
  • SIM boxing
  • IRSF fraud
  • Wangiri
  • High usage and Bill Shock
  • Bursts of untypical usage

• Sensitivity tuning and obfuscation. Because Nussknacker uses expression language to (among others) formulate conditions, it was easy to set up obfuscated detection thresholds to prevent easy reverse engineering by fraudsters. Similarly, sensitivity thresholds can range from very simple ones to very complex ones, formulated as elaborate expressions.

• Ease of experimentation. With Nussknacker it is very easy to experiment with the decision algorithms. Variations (experiments) of the “main” algorithm can be created and deployed within minutes and they can be easily set up to act on subsets of input data. Trivial changes to the algorithms can take seconds to make it to production. The Play’s Fraud Team can easily experiment with the algorithm and have immediate feedback without any IT involvement.

Future plans:

• Credit scoring. In Poland mobile telco services and in particular handset sales involve credit risk - there is a group of customers that pays for their handsets in instalments. On top of the credit risk, there is also a fraud risk - where customers sign contracts without any intention to pay for handsets. The need for the continuous evolution of the credit risk and fraud detection algorithms, Nussknacker’s ability to enrich data from external sources (“feature stores”) and infer ML models will make Nussknacker a powerful tool in the hands of the Credit Risk team.