Telecoms Fraud Management

 Fraud Management  Comments Off on Telecoms Fraud Management
May 232010

Fraud Management systems are designed to detect and prevent the fraudulent behaviors of the users which cause revenue losses.

There are multiple types of telecommunication frauds that needs to be addressed by these systems. Different fraud types should be detected and handled by different algorithms.
Below, I list some techniques that are used to detect the common fraud types:

Collision Checks: Collision checks check the time period between the two calls that have been done by the same subscriber. If the two calls belong to a previously specified time window, this is considered as a technical fraud, more specifically, a SIM cloning fraud.

Velocity Checks: Suppose, you received a call record saying that a subscriber had made a call at 10:00 AM from London. After some time, at 10:05, you receive another call record for the same subscriber from Istanbul. Since it is not possible for an individual to travel this distance within 5 minutes, this points to SIM cloning. Velocity checks make use of GIS data to figure out the distance between two locations. The second parameter they look for is the delta time between the calls made.

Blacklists: Blacklist checks are done on the blacklist fields in the CDR data (generally IMEI number) and generate a fraud case immediately. IMSI, MSISDN, B Number, Cell Id data can also be blacklisted.

Threshold Checks: FMS systems enable you to put thresholds on specific fields or accumulations based on these fields. SIM thefts (Total number of calls for this subscriber today, Total minute in the month, total $ amount of the calls etc.)

New Subscriber Checks: Subscription frauds are the frauds that appear when the subscriber gives false information to the service provider. He/she will be able to use the services with this false information without intent to pay. It will be impossible for the provider to find and charge this customer. It has been seen that the fraudulent subscribers use similar false identity information when they are trying to regain network entry. If the fraudulent user gave the name John Doe in his first subscription, in the second attempt, he uses a similar name, such as Johnny Doe. FMS systems have the new subscriber checks which can identify phonetic matches and cross matches to detect subscription frauds.

Pattern checks: Pattern checks look for specific patterns in the user activities. Patterns are series of “if” conditions. They usually have a time window where these conditional checks will be applied. A pattern could be “if the user is using the same phone (same IMEI) and makes calls with more than 3 SIMs (different IMSI) within an hour”.(IMEI should be present in the CDR) This pattern, for example, is written to detect the SIM Stuffing fraud. (SIM Stuffing is spreading the usage among different subscriber accounts to bypass Fraud systems. Fraudsters use different cloned SIMs(IMSIs) from the same terminal(IMEI) and use the service in small units(say 1 minutes per day per imsi). This way it will be hard to figure out if this is a sim stuffing behaviour.) Or I can write a pattern saying that if the same IMSI makes more than X international calls and these are destined to different countries. This pattern will catch a Sim Gateway fraud. Pattern checks are very powerful and can detect multiple fraud types.

Profile checks: FMS system has the usage data of the user thus it can generate a profile for that specific user. The calling patterns of the users are continuously monitored by the system and the corresponding profile is updated. For example, suppose I am a subscriber who has not made any international call in the last 12 months. This month, I started calling international numbers extensively. This is an off-profile behavior and may point to a fraud.

After those checks are done, alarms are generated if necessary. One alarm or multiple alarms may/will trigger case generation. Fraud Management department inspects those cases and take corrective actions to prevent frauds. These actions vary such as notifying the subscriber or suspending the service. Cases are marked as fraud or non fraud along with a detailed description prior to closure.

FMS can do basic rating. Calls can be rated based on the subscriber’s rating plan. Sophisticated rating/discounting scenarios may not be applied by the FMS systems. This is not their core responsibility. The rating function is generally used to accumulate the usage in terms of dollars.

FMS systems deal with lots of information and this makes them database depended. The FMS include usage information, customer information, rate plan information, alarm information, case information etc. Usage information can be fetched directly from the NEs or from a mediation system. Customer information is imported from other systems. HLR, Billing and CRM are the possible external repositories to get synched. (HLR can be the most up-to-date one). FMS also gets cell coordinates from the GIS systems and black-white-grey IMEI lists from the EIR systems.

May 162010

Billing systems collect usage records from devices and generate bills per customer based on predefined rules.

Different systems in a service provider’s infrastructure produce logs about the usage. We call them usage data records or UDRs. If the usage is for voice calls, we call them CDRs, if the usage is about bandwidth; we call it IPDR or UDR. These logs are collected, aggregated, validated and converted to a common format that is understood by the billing system. These collection related tasks belong to Mediation systems. (You may want to read about my previous post about Mediation from here). The Mediation system passes usage records to the billing system over a predefined protocol (ftp, sftp, propriety etc).

The first task of the billing system is to rate the usage data. This is done by the rating engine module. The Rating Engine looks for the specified fields in the usage data records which identify the subscriber account. (Guiding) For voice, this could be the originating number field. (MSISDN and/or IMSI in mobile communications). For data/content, again it could be MSISDN, IMSI, username or a device specific field.

After the rating engine identifies the customer account, it tries to find a price plan (rate plan) for that specific subscriber. Rate plans are the plans that are negotiated at the order capturing phase. Rate plans say for example “between 9 PM and 7 am the calls are for free, other times x cents per minute and international calls are y cents per minute. 100 local minutes are free with a minimum monthly cost of z dollars”.

After the rate plan is identified, usage records can be charged using the other fields of the record. These could be call type, terminating number, session start time, session end time, location (cell id) etc.

A CDR file does generally include usage records from many customer accounts. So, the rating engine processes the usage records line by line add the corresponding dollar-amount information to the record. (In some scenarios, event based taxation is also applied. This is also done by the rating engine). Rounding is also applied at this stage. Rated records are stored on a separate table on the billing system which is also called the billing pool.

The next step is billing/invoicing which is handled by the billing engine. The billing engine takes the rated CDRs from the billing pool and aggregates the usage. The volume discounts, free minutes (allowances), cross-product discounts are applied at this point. Other charge types such as recurring charges; one time charges (such as installation or activation) and taxes based on the taxation rules (based on customer, service or location) are also added to the bill.

A note about the free minutes: Free minutes can be applied to the bill in two ways. In the first approach, the rating engine also accumulates the total usage per customer and rates the usage records accordingly. That is to say, if I have 60 free minutes and my last 5 minutes of usage bring my on-going monthly usage to 40 minutes, the rating engine rates this last call as zero dollars. In the second approach, the rating engine does not care about the accumulated usage information. Rather, it charges the usage records one-by-one based on the price plan. When the billing time comes, the free minutes are deducted from the overall usage.

The invoicing engine takes the bills and formats the invoices. It includes account information, due dates and some marketing messages and finally sends the invoice to the printing house to be delivered to the customers. (Or if electronic delivery is set, it is emailed.)

Billing/Invoicing is a time and CPU intensive process so the billing cycle concept was introduced. Billing cycles are the instruments that allow the operator to distribute the batch processing load of the rated records. Instead of invoicing all the customers on the last day of the month, customers to be invoices are spread over different days of the month. Billing cycles could also be used to manage the cash flow of the operator.

I need to add some information about the charging. Charging is “assigning a value to a service usage or product”. Charging should be considered as the same as rating. According to TMForum, Charging is the combination of rating and rate level discounts. We do not have a “Billing” process in the eTOM hierarchy. However, we have charging, bill inquiry handling, bill payments management and other billing related processes. So, we should consider “Billing” as a practice rather than a process.

Up to now, I talked about the offline charging. We charged the usage records in offline. In telecommunications systems this generally refers to the postpaid services where you charge the service after the usage. The online charging, on the other hand, is the instrument used; to be able to provide pre-paid services. I will detail prepaid billing in another post. It is enough to mention that the rating function is done on-the-fly in those online systems. In our everyday talks, we sometimes use the term charging for online charging/prepaid billing, and billing for offline charging/postpaid billing. It is ok as long as it does not lead to any confusion. We just need to remember that the charging is a sub function of billing practice (prepaid or postpaid billing)

After the bill is delivered to the customer, it is stored in the billing system’s archives. The bill record would be useful in other processes such as inquiries, audits, revenue assurance etc.

Telecom Applications Map – TAM

 NGOSS  Comments Off on Telecom Applications Map – TAM
May 092010

TAM (Telecom Application Map) is one of the frameworks of the NGOSS (Frameworx) initiative. Its main goal is to draw the boundaries of the OSS/BSS applications. Standardized business processes and the applications that run those business processes, emerged in parallel. However, the OSS application vendors named and scoped their applications by themselves without following a standard. This led to confusion among the customers (service providers). That’s why, TAM started as an initiative that was triggered by the service providers. The service providers needed an application map where they can see the scope of their current and future OSS/BSS applications. They created a complete view of applications. TAM will help the providers to identify the missing applications within their infrastructure. It will also help to discover the overlapping functionalities. Why should I maintain 2 applications that are capable to run the same functionality? That’s where the TAM helps.

TAM is a logical view of applications. That is to say, it does not include any platform dependent, or implementation specific information. Rather, it focuses on the applications and their capabilities to perform business process requirements.

TAM can also help in creating RFI/RFP documents. Suppose you want to issue an RFP and constructing the compliancy matrix that will be submitted to the vendors. Which functionalities should be asked? You can utilize TAM for this purpose. If you will invest on an Order Management application, open TAM, and find the Customer Order Management application. Ask your vendors how they can comply with these functionalities. A real time saver…

The framework is mapped to eTOM and SID frameworks. How? via the domains. We have seen that eTOM Level 0 domains (concepts) are consistent with the SID domains (which include the ABEs). This domain concept continues in the TAM framework. TAM also includes the domains “Market/Sales, Product Management, Customer Management, Service Management, Resource Management and Supplier/Partner Management”. The concept is the same but the naming is different. TAM calls these as “Application Areas”.

Application Areas are composed of Applications. There are Customer Management Applications, Service Management Applications etc. Each area will include applications under it. For each application we can see the overview, functionality and supported business services section. Like eTOM, TAM was also designed in a hierarchical structure. Applications that are listed in Level 1 may also be decomposed into lower levels sub-applications (Level 2 and below). These sub applications are also called modules. A customer order management application should have an orchestration (workflow) module. This module can also be decomposed into order distribution and order tracking modules. (This is the L3 detail). Vendors heavily use this module concept within their applications and they apply separate licenses per module. This also gives the provider the option to select the modules it wants from the application. If another, previously bought application has a workflow module that can be reused in the order management, while procuring for an Order Management application; I may not want to buy that specific module.

TAM brings a common application dictionary that can be used by multiple types of stakeholders. It represents an application standardization which also guides the vendor products. Vendors use it for marketing purposes. TAM mappings are used by the vendors to draw the scope (footprints) of their applications. Service providers utilize it for creating RFPs, deciding on the IT transformation strategies which will lead them to increased automation and organizational efficiency.