CA2241227A1 - Telephone fraud detection system - Google Patents
Telephone fraud detection system Download PDFInfo
- Publication number
- CA2241227A1 CA2241227A1 CA002241227A CA2241227A CA2241227A1 CA 2241227 A1 CA2241227 A1 CA 2241227A1 CA 002241227 A CA002241227 A CA 002241227A CA 2241227 A CA2241227 A CA 2241227A CA 2241227 A1 CA2241227 A1 CA 2241227A1
- Authority
- CA
- Canada
- Prior art keywords
- call detail
- detail records
- alarm
- fraud
- call
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 19
- 230000003139 buffering effect Effects 0.000 claims abstract 8
- 238000000034 method Methods 0.000 claims description 28
- 238000004891 communication Methods 0.000 claims description 9
- 238000001914 filtration Methods 0.000 claims 2
- 230000008569 process Effects 0.000 description 23
- 238000012544 monitoring process Methods 0.000 description 21
- 238000010586 diagram Methods 0.000 description 7
- 150000002500 ions Chemical class 0.000 description 5
- 240000004760 Pimpinella anisum Species 0.000 description 4
- 239000000969 carrier Substances 0.000 description 4
- 239000000872 buffer Substances 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 239000013256 coordination polymer Substances 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- ATJFFYVFTNAWJD-UHFFFAOYSA-N Tin Chemical compound [Sn] ATJFFYVFTNAWJD-UHFFFAOYSA-N 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- GWUSZQUVEVMBPI-UHFFFAOYSA-N nimetazepam Chemical compound N=1CC(=O)N(C)C2=CC=C([N+]([O-])=O)C=C2C=1C1=CC=CC=C1 GWUSZQUVEVMBPI-UHFFFAOYSA-N 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/47—Fraud detection or prevention means
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/36—Statistical metering, e.g. recording occasions when traffic exceeds capacity of trunks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/01—Details of billing arrangements
- H04M2215/0148—Fraud detection or prevention means
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13512—800 - freefone
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13515—Indexing scheme relating to selecting arrangements in general and for multiplex systems authentication, authorisation - fraud prevention
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13545—Indexing scheme relating to selecting arrangements in general and for multiplex systems monitoring of signaling messages, intelligent network
Abstract
A fraud detection system is disclosed for telephone PBX calls. The system includes a fraud data server for buffering the call detail records relating to inbound 800 number calls and outbound international calls. A threshold manager is connected at its input to an output of the fraud data server for detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records, and generates an alarm. The output of the threshold manager is connected to an input of the fraud data server for buffering the alarm incident to respective call detail records. A computer workstation is connected to the fraud data server for receiving packets of call detail records relating to alarm data, in a filtered preselected format.
The workstation includes a monitor for displaying the alarm data on a graphical interface.
The workstation includes a monitor for displaying the alarm data on a graphical interface.
Description
TELEPHONE FRAUD DETECTION SYSTEM
Field of the Inven~ion The present invention relates to telephone systems, and more particularly to a fraud detection and monitoring system for PBX use.
Background of the Invention Phone fraud is an ever-increasing problem in this country. To combat the problem, long-distance carriers are developing products to detect fraud in its early stages. In recent years, customer liability for the unauthorized use of customerpremise equipment (CPE) and calling card numbers to make long-distance calls is estim~te~ at over $2 billion ~nnll~lly. In some cases, a customer may incur charges in excess of $100,000 over the course of one weekend. To m~int~in good relationswith the public, long distance carriers, including MCI, often assume the majority of the liability for these calls. As a result, both carriers and customers are increasingly seeking measures to reduce the occurrence of phone fraud. Phone fraud consists of two types: CP~ related and calling card. This invention deals with CPE related 15 fraud.
CPE-related fraud occurs when a third party gains illegal access to a customer's PBX (private branch exchange) and steals the dial tone to make outgoing calls. This is a particular problem with hackers dialing 800 (toll-free) numbers and then ~inin~ access to an outbound trunk. Outgoing calls are charged to the CPE
20 owner regardless of the origination of the call. From a financial standpoint, the worst and most costly form of abuse involves international calls.
At the present time, fraud analysis of PBX use is typically done by m~ml~lly reviewing call data records, after an initial data sorting, to detect patterns indicative of fraud. However, as will be appreciated, this is a laborious and time-consuming 25 process which results in long delays between the actual occurrence of fraud and the m~ml~l review and detection thereof.
Brief Descr~ption of the Present Inven~ion The present system is referred to as MCI Detect~ and provides long distance carriers such as MCI with an automated (and improved) method of detecting fraud.MCI Detect~ is a trademark of MCI Comml-nications Corporation. In the recent 5 past, two types of calls have been the focus of most of the fraudulent CPE-related activity and the cause of the greatest ~mancial liability for MCI and its customers.
Fraud is suspected when an lml~ l calling pattern is det~cte 1, such as the following:
~ Inbound 800 number calls (hereinafter referred to as inbound 800);
Outbound international calls (hereinafter referred to as outbound international);
~ Numerous short duration calls which may indicate that hackers are attempting entry.
The invention mor~itors the two types of non-residential calls that are most susceptible to fraud:
Excessively long calls which may indicate that hackers are using inbound trunks to make outbound calls;
An unusual number of calls to foreign countries;
~ An unusual number of calls during non-business hours.
Fraud may also be suspected when calls originate from prisons, pay phones, 20 hotels, hospitals, etc. The call detail records (CDRs) associated with each call contain information digits which provide this type of information. Calls ori~in~tin~
from certain dialing areas, such as ~nh~tt~n, may also be cause for concern.
NOTE: A dialing area is known as a Numbering Plan Area--Network Number Exchange (NPA-NXX).
Past experience with fraud also reveals suspect numbers which may be specific phone numbers (ANIs or ~--torn~tic Number IdP-ntifir~tiorls) or ~ ic~ted access lines (DALs). Both an ANI and a DAL can be tracked to a specific home or business.
Prepared with information about how to detect CP~-related fraud, MCI was able to W O 97~3085 PCT~US96/20337 determine which data to collect in order to develop monitoring plans for its customers. For calls to specific 800 numbers or from certain ANIs or DALs, MCI
collects the following:
~ Total number of short-duration calls Total number of long-duration calls ~ Total number of calls of any type ~ Total number of c--m~ tive minlltes from any type of call.
MCI Detect keeps count of the number of calls in each category over previously defined time periods such as during non-business hours on a weekend.
10 Customers may specify what is considered to be a long or short call, or too many calls. The maximum allowable amount in any category is a threshold. Excee~lin~
a threshold results in an alarrn.
MCI Detect also permits customers to associate a risk with certain types of calls. For inbound 800 calls, risk factors may be assigned to calls from specific 15 NPA-NXXs, informationdigits, and countries. Foroutbound internationalcalls, the risk may be assigned to calls to specific countries only. When a risk is associated with a call, the statistic for that call is multiplied by the assigned risk factor (any number between 1.0 and 100.0). For example, if an outbound call to Cuba is assigned a risk of 2.0, then such a call is counted twice. In this way~ a threshold is 20 exceeded more quickly. It does not mean, however, that this call will automatically generate an alarm.
MCI also m~int~in~ a global list of suspect numbers so that it can monitor callsfrom specific numbers (ANIs or DALs) where fraud has been detected in the past.
Customers may modify this list to suit their purposes. When a call from a suspect 25 number is detected, an alarm is immediately generated regardless of the current totals in relevant monitoring categories.
The purpose behind compiling so many statistics is that customers may combine them in a variety of ways to create a truly customized monitoring plan.
The first component for fraud control is the switched network used by MCI
to provide long distance services to its customers. Switching is the ability to route calls to dirrerellt locations within the public phone network on a call-by-call basis rather than limiting tr~n~mi~ion between predetermined fixed points. For example, 5 a call from New York to Los Angeles may be routed through Chicago in one in~t~nre and through Atlanta and Denver in another. At each point in the network where lines converge, a switch is in place. The switch makes, breaks, or changes connectionsamong the phone circuits in order route calls to their destination.
Co-located with every switch are co~ er systems, adjunct processors (APs), 10 which assist in loading billing information and software into the switch. MCI's billing software, Traffic 2000 (T2000), also acts as a screening device by ex~minin.~
the detailed information (call detail records [CDRs]) associated with each call. Only relevant CDRs--non-residential inbound 800 calls and outbound international calls --are sent to MCI Detect. This prevents the fraud data system from becoming 15 overwhelmed with data.
MCI Detect accepts the CDRs, immediately analyzes the call traffic, and keeps a running total of the counts (for example, number of short-duration calls) and thresholds for each monitoring plan stored in its database. Each monitoring plan is a set of parameters which govern how fraud will be detected for a specific type of 20 call. MCI has developed several generic plans, but customers may also develop their own plans.
Each monitoring plan has three features:
Thresholds ~ Risk factors Suspect numbers.
A threshold is a number which, when excee~le~, generates an alarm in MCI
Detect indicating possible fraud. For example, if a customer indicates that it should receive no more than 1000 calls to its 800 number on any given business day, then WO 97123085 PCTrUS96~0337 the number "1000" is a threshold, and the 1001st call will generate an alarrn.
Thresholds may be specified for the time of day and/or the day of the week.
Furthermore, a threshold may be app~ied to each category for which MCI Detect keeps counts, including the number of short-duration calls, long-duration calls, and 5 cllm~ tive mimltes.
As described previously, risk factors and suspect numbers help to determine the likelihood of fraud based on the assumption that some types of calls more clearly indicate fraud than others. For example, a call from a high-risk dialing area may be assigned a weight of 3Ø Each time such a call is recorded, relevant counts are10 multiplied by a factor of 3 and thresholds are excee~le~ more quickly. The detection of a suspect number immediately triggers an alarm in MCI Detect. It is not necessary to apply weights to these numbers.
Every MCI commercial c -~t -m~r is autom~tic~lly ~ ign~l to a Universal Pk~n initially. Customized plan data is later entered by MCI representatives. Inbound and 15 outbound thresholds are provided in separate plans; therefore~ a customer can have both an inbound plan and an outbound plan active simlllt~n~ously. (Table 1 and Table 2 in Figs. S and 6 show two examples of customer monitoring plans.) When an alarm is generated by MCI Detect, it is also prioritized. The priority is a multiple of the number of times a threshold has been exceeded. For example,20 if the threshold was 10 and the relevant count has reached 50, then the priority of the alarm is 5 (50 . 10) .
Each alarm is available to an MCI fraud analyst via an MCI Detect Workstation. The workstation is a PC with access to a Fraud Data Server and retrieves the next available alarm of the hi~hest priority. The analyst investigates the 25 alarm data and, if fraud is suspected, notifies the customer and suggests appropriate actions to stop the fraud.
Based upon both MCI's and the customer's experiences with fraud, the customer's monitoring plan(s) may be modified with a new set of parameters or w o 97/23n85 PCTAJS96/20337 suspect numbers. This fine tuning is n~efle 1 to more accurately detect fraud and to prevent false alarms.
Since the elapsed time between the completion of a call and the generation of an alarm by MCI Detect is 15 mimltes or less, a significant improvement has been5 made over the 3-4 days required previously. MCI p}ans to reduce this time further to the point where fraud is detect~l while the call is in progress. Detecting fraud in progress permits actions to limit its impact, such as ~hlltting down a DAL, to be taken as quickly as possible. In addition to ch~rlging the way that calls are processed at the switch level, in-progress detection requires effective calling statistics and a 10 complete and current list of suspect numbers.
In maximi7ing the flexibility of customer monitoring plans, MCI Detect both minimi7es false alarms and provides advantages over current competing products.
The features that put MCI Detect above the competition are the following:
~ The flexibility to specify the ANIs and DALs that will be monitored and the monitoring ~resholds and parameters for each.
~ MCI Detect's timely detection and notification of 15 mimltes or less.
~ Calls to all foreign countries are monitored, not just a subset consisting of high-fraud countries.
~ Risk factors are applied to NPA-NXXs, information digits, and specific countries, which minimi7.es false alarms and also provides early notification of abnormal calling patterns.
~ Customers will have the option of specifying any of the following media for alarm notification: telephone, MCI MaillU, fax, pager Integrated Network Management Services (INMS), or Integrated Customer Workstation (ICW).
To increase customer involvement in fraud detection, MCI will allow MCI
customers to monitor their own inbound 800 and outbound international traffic.
W 0 97/23085 PCTrUS96~0337 Using MCI Detect directly, customers may create, modify, and delete monitoring plans and view alarms.
Brief Description of the Figures The above-mentioned objects and advantages of the present invention will be 5 more clearly understood when considered in conjunction with the accompanying drawings, in which:
Fig. 1 is an overview of the present fraud detection system in block diagram form.
Fig. 2 is a block diagram of the system architecture for the present invention, 10 indicating greater detail than that shown in Fig 1.
Fig. 3 is a block diagram of the workstation, as shown in Fig. 2.
Fig. 4 is a glossary table of abbreviations.
Figs. 5 and 6 are examples of monitoring plans that include various pàrameters for detecting fraud.
Fig. 7 is a flow diagram of the overall process corresponding to the system of Fig. 2.
Fig. 8 is a flow diagram of a fraud data server process.
Fig. 9 is a flow diagram of a threshold manager process.
Fig. 9a is a flow diagram of a call h~n~l~in~ process.
Detailed Descrip~ion Of The Inven~ion Referring to Fig. 1, MCI Detect architecture 10 consists of three basic systems:
~ MCI Detect Workstation 12 ~ MCI Detect Threshold Manager (TM) 14 Fraud Data Server 16.
W O 97~3085 PCT~US96~0337 Each system is resident on a separate computer, and the software is unique to the local computer platform.
The following will describe the system operation as indicated in Figs. 2 and 3.
Referring to Fig. 2, the architecture of the present invention is shown in greater detail. The MCI network 4 generates call detail records (CDRs) which areinput to an IBM-based computer system, indicated in block 6 as a T2000 (Traffic 2000). The system stores CDRs generated by the network 4. The T2000 system conventionally processes billing data, as indicated by reference numeral 8. The 10 CDRs and billing data are ret~in~l in the T2000 for a period of time normallyrequired to conduct fraud analysis. Typically, this would be for a period of 24 hours. The components 4, 6 and 8~ employed by MCI Detect 10, constitute prior art.
With continlle-l reference to Fig. 1, the output of the T2000 can provide call records including CDRs and billing data to the input of the MCI Detect system 10, 15 and more particularly to a fraud data server (FDS) 16. The server is of conventional design and includes a buffer for recently retrieved call records which have beenobtained from the T2000. The FDS provides call records to a threshold manager (TM) which processes the call records by reviewing the fields thereof and comparing these fields with established thresholds. When thresholds are excee~lefl they indicate 20 the possible occurrence of fraud.
Alarms are generated by the threshold manager 14 when such thresholds are e~ceede~. The alarms are Ll;~ Pd to the FDS 16 that subsequen~y c-)mml-nir~t~s the alarms to the workstation 12. The workstation also has access to the call records buffered in the FDS 16 so that an analyst at MCI, or an analyst at the network 25 customer site, may have access to the necessary information to finally determine the occurrence of fraud. Since the FDS normally only buffers previously recently retrieved records, the workstation 12 may obtain older call records by querying the T2000.
W 0 97~3085 PCT~US96120337 The workstation 12 is preferably a PC workstation operating with an OS/2 operating system. Fig. 3 indicates the workstation 12 in greater detail. The workstation commllnicates bidirectionally with the FDS 16, the latter keeping track of updated alarm conditions fed back from the TM 14. The FDS produces alarm S sllmm~ries from the alarm data fed back from the TM 14. The col~-",ll,-ications manager 18 provides alarm sllmm~ry information packets to other objects of the workstation. In Fig. 3, the presence of recent actual alarrn ~llmm~ries, tabulatable on a priority basis, is indicated by object 22. Call detail records, as indicated by workstation object 24, are presented in graphical interface forrnat to an analyst who 10 can change the status of a particular alarm situation, as well as various status conditions. These changes are communicated to the FDS 16 by virtue of a commllnications path back through the alarm s-lmm~ry object 22 and the comm-mications manager 18. From tirne to tirne, it may be necess~ry to change the thresholds of the TM 14. Threshold conditions vary for di~rele~lt accounts, according 15 to preselected sets of parameters, referred to plan management, and in-lic~ted in Pig.
3 by object 20. The parameters are shown in various examples in Figs. 5 and 6.
The MCI Detect Work~tn~n Each MCI Detect workstation 12 may be an IBM PS/2 (486-based) personal co~ uLel running OS/2 version 2.1 or later. IBM's Presentation Manager~ provides20 the graphical user interface. The workstation commllnicates (via TCP/IP Protocol) with the Fraud Data Server 16 to extract alarm and plan data as previously mentioned. Up to 50 analysts may log onto MCI Detect workstations at one time.
The estim~te~l workload per workstation is 100 alarm resolution attempts per 24 hours.
WO 97/2308~ PCT/US96/20337 MCI Detect Threshold Manager The MCI Detect Threshold Manager provides real-time threshold analysis (that is, it continuously monitors for plan thresholds that have been exceeded) using algorithms (for example, number of short-duration inbound 800 calls). Examples are indicated in Figs. 5 and 6. It receives call detail records from the Fraud Data Server 16 and returns alarms which may be retrieved and examined using an MCI Detect workstation. The threshold manager resides on an IBM RS/6000 computer running the AIX operation system.
Fr~ud Data Serl~er The MCI Detect workstation 12 interacts with the Fraud Data Server 16 to obtain current and historical fraud-related data, including CDRs, thresholds and other plan data, and alarms.
The Fraud Data Server system consists of four major functional systems-~ Fraud Communications Gateway (FCG)--acts as the interface with external data systems and elimin~tes unwanted CDRs from entering the data server. This interface allows commllnication protocols to be changed without affecting the rest of the fraud data systems.
~ Fraud Parser (FP)--reformats CDRs for processing and passes the records to the threshold manager.
Fraud Data Server (FDS)--manages databases of current and archived alarrn data, customer plans, and other miscellaneous data.
~ Fraud Cu~ ication Distributor (FCD)--provides the data server with the ability to co~ ul~icate with multiple fraud workstations.
Alarrns and call information are sent to the fraud workstations via this interface.
W O 97/2308~ PCTrUS96/20337 The Fraud Data Server resides on a separate IBM RS/6000 computer running under the AIX operating system and using the SYBASE relational fl~t~b~e management system.
Process Flow Charts The process for Inbound 800 fraud detection is identified. An analogous process is conducted for Outbound International fraud detection.
In reference to Figs. 2 and 7, which show the overall process and system for fraud detection, a raw call record 702 is sent from Traffic 2000 System 6. This call record contains numerous data regarding a single call. The call record 702 is input 10 to the Fraud Data Server Process 704, which is specified in detail later in reference to Fig. 8. The Fraud Data Server Process 704 formats the call record into a message that is readable by the Threshold Manager. The Fraud Data Server (FDS) then feeds the formatted call record to the Threshold Manager (TM) as input to the Threshold Manager Process 706, which is specified in detail later in rererellce to Fig. 9. The 15 Threshold Manager Process 706 det~ -illes the need for generating an alarm, as well as the priority of that alarm. If the TM determines an alarm is needed, an alarrn 708 is generated and sent back to the FDS to be recorded in a database and presented to the Workstation 12 (Fig. 1).
In reference to Fig. 8, which shows the Fraud Data Server Process 704 in 20 detail, the raw call record 702 is input to the process 802 in which the FDS gateway receives the call record. The FDS then parses the data 804 and extracts the data that is pertinent to fraud detection, namely the following fields:
~ Country Code ~ Call Duration ~ Info Digits (identifies the service type of call) W O 97~308~ PCT~US96nO337 ~ Service Number (for Inbound 800, this is dialed 800#; for Outbound Int'l, this is the ANI if switched access, or the Switch/Trunk i.d. if dedicated access) ~ Suspect Number (used in TM to match against suspect numbers identified in customer's monitoring plan; for Inbound 800, it is origin~ting ANI; for Outbound Int'l, it is the Int'l Direct Dialed Digits) ~ Customer ID
~ Site ID
~ Tirne since mi(lnight that completed call termin~te-l (either party hung up) ~ Switch/Trunk id (for Inbound 800, where it isn't identified as Service Number) The FDS then formats the record into a message that is readable by the Threshold Manager (TM) and places the forrnatted message in the TM Inbound 15 Mailbox 806. (If the call record origin~te~l from an Outbound International call, the formatted m~age is placed in the TM Outbound Mailbox).
In reference to Fig. 9, which shows the Threshold Manager Process 706 in detail, the TM reads the message in the Inbound Mailbox 902 and determines the message type 904. Alternative to a message representing call record data, a message 20 may represent a request to update a customer's monitoring plan. The TM determines if the message is to process a call or to update a monitoring plan 906.
If the message is to update a plan, the TM executes that update 910.
If the message is to process a call, the TM proceeds to process the call 908, which is shown in detail in Fig. 9a.
In reference to Fig. 9a, which shows how the TM processes a call 908 to determine if an alarm is to be generated, the TM begins by reading the service number 912 (which represents the dialed 800 number for an Inbound 800 call). It then determines if it has processed this service nurnber before 914. If the TM has not W O 97/2308~ PCTAJS96/20337 processed this number before, it will assign the service number to the lowest level of specification of the customer's monitoring plan 916. This is for the purpose of associating call counts and durations for that number to the appropriate part of the monitoring plan. Examples of Inbound 800 levels of specification in ascending order 5 are:
800 number plus supplemental identification codes 800 number Corporate Identification Code Customer ID
Universal plan For example, if the service number is simply an 800 number, the TM will assign the service number to that part of the ma~ltoring plan that specifies thresholds and counts for that particular 800 number. If no match of service numbers or other codes are found, assignment defaults to a universal monitoring plan.
The TM will then send an update of this plan assignment to the FDS 918. The process then proceeds to the sarne point it would have been if the TM had determined, from 914, that the number had been processed before.
If the TM determines that the service number has been processed before 914, it queries the part of the customer's monitoring plan that the number is assigned to 20 and deterrnines the current thresholds and counts 920 for that number. Counts relate to the number of short-duration calls, long-duration calls, total call time, and suspect number calls. Thresholds represent the maximum number of counts a number may reach before triggering an alarm.
The TM then calculates new counts 922 by augmenting ~)ro~liate counts 25 based on call data associated with the service number. For example, if the service number is an 800 number for which a call lasted 20 minlltes (considered long-duration), the long-call count is increased by one.
The TM then applies a risk factor 924 to the call data. A risk factor representsa co-efficient that is entered by the customer to in~1ir~te increased risk associated with a particular NPA-NXX, country, calling area, or info digits. If none is entered, the default risk factor is 1. The TM calculates risk-adjusted counts 926 by multiplying 5 the actual counts by the risk factor. For example, if the customer enters a risk factor of 3 for calls received from NPA-NXX 202-887, and a call record is received for a short-duration 800 call from the ANI 202-887-nnnn, the short-duration count of the monitoring plan is increased by 3.
The TM then matches the new risk-adjusted count to the ap~ro~liate threshold 10 to determine if the threshold has been surpassed 928. If it hasn't, no alarm is generated 930. If the threshold has been surpassed, then the TM calculates the priority 932 of the potential a~a~m. The priority is defined as:
risk-adjusted count threshold The TM then determines if the calc~ teA priority of the current call message is greater than the priority of the previous call message 934. This is to prevent flooding the FDS with alarms if a string of threshold-breaking call counts come in;
only a single alarm is needed in such a case. A history of priorities is kept since the previous miAnight; it is refreshed every midnight.
If the current priority is not greater than the previous priority, no alarm is generated 936. If the current priorit.,v is greater than the previous priority, the TM
sends an alarm to the FDS 938.
Accordingly, as will be appreciated from the previous discussion, the present invention makes available a fraud detection and analysis system which combines a25 threshold manager interConn~cteA with a workstation to filter information relevant to fraud, for example, culled from a particular site which may be the subject of fraudulent activity in a PBX system tr~n~ tin~ inbound 800 number calls, as well as outbound international calls.
W O 97/23085 PCT~US96/20337 It should be understood that the invention is not limited to the exact details of construction shown and described herein for obvious modifications will occur to persons skilled in the art.
Field of the Inven~ion The present invention relates to telephone systems, and more particularly to a fraud detection and monitoring system for PBX use.
Background of the Invention Phone fraud is an ever-increasing problem in this country. To combat the problem, long-distance carriers are developing products to detect fraud in its early stages. In recent years, customer liability for the unauthorized use of customerpremise equipment (CPE) and calling card numbers to make long-distance calls is estim~te~ at over $2 billion ~nnll~lly. In some cases, a customer may incur charges in excess of $100,000 over the course of one weekend. To m~int~in good relationswith the public, long distance carriers, including MCI, often assume the majority of the liability for these calls. As a result, both carriers and customers are increasingly seeking measures to reduce the occurrence of phone fraud. Phone fraud consists of two types: CP~ related and calling card. This invention deals with CPE related 15 fraud.
CPE-related fraud occurs when a third party gains illegal access to a customer's PBX (private branch exchange) and steals the dial tone to make outgoing calls. This is a particular problem with hackers dialing 800 (toll-free) numbers and then ~inin~ access to an outbound trunk. Outgoing calls are charged to the CPE
20 owner regardless of the origination of the call. From a financial standpoint, the worst and most costly form of abuse involves international calls.
At the present time, fraud analysis of PBX use is typically done by m~ml~lly reviewing call data records, after an initial data sorting, to detect patterns indicative of fraud. However, as will be appreciated, this is a laborious and time-consuming 25 process which results in long delays between the actual occurrence of fraud and the m~ml~l review and detection thereof.
Brief Descr~ption of the Present Inven~ion The present system is referred to as MCI Detect~ and provides long distance carriers such as MCI with an automated (and improved) method of detecting fraud.MCI Detect~ is a trademark of MCI Comml-nications Corporation. In the recent 5 past, two types of calls have been the focus of most of the fraudulent CPE-related activity and the cause of the greatest ~mancial liability for MCI and its customers.
Fraud is suspected when an lml~ l calling pattern is det~cte 1, such as the following:
~ Inbound 800 number calls (hereinafter referred to as inbound 800);
Outbound international calls (hereinafter referred to as outbound international);
~ Numerous short duration calls which may indicate that hackers are attempting entry.
The invention mor~itors the two types of non-residential calls that are most susceptible to fraud:
Excessively long calls which may indicate that hackers are using inbound trunks to make outbound calls;
An unusual number of calls to foreign countries;
~ An unusual number of calls during non-business hours.
Fraud may also be suspected when calls originate from prisons, pay phones, 20 hotels, hospitals, etc. The call detail records (CDRs) associated with each call contain information digits which provide this type of information. Calls ori~in~tin~
from certain dialing areas, such as ~nh~tt~n, may also be cause for concern.
NOTE: A dialing area is known as a Numbering Plan Area--Network Number Exchange (NPA-NXX).
Past experience with fraud also reveals suspect numbers which may be specific phone numbers (ANIs or ~--torn~tic Number IdP-ntifir~tiorls) or ~ ic~ted access lines (DALs). Both an ANI and a DAL can be tracked to a specific home or business.
Prepared with information about how to detect CP~-related fraud, MCI was able to W O 97~3085 PCT~US96/20337 determine which data to collect in order to develop monitoring plans for its customers. For calls to specific 800 numbers or from certain ANIs or DALs, MCI
collects the following:
~ Total number of short-duration calls Total number of long-duration calls ~ Total number of calls of any type ~ Total number of c--m~ tive minlltes from any type of call.
MCI Detect keeps count of the number of calls in each category over previously defined time periods such as during non-business hours on a weekend.
10 Customers may specify what is considered to be a long or short call, or too many calls. The maximum allowable amount in any category is a threshold. Excee~lin~
a threshold results in an alarrn.
MCI Detect also permits customers to associate a risk with certain types of calls. For inbound 800 calls, risk factors may be assigned to calls from specific 15 NPA-NXXs, informationdigits, and countries. Foroutbound internationalcalls, the risk may be assigned to calls to specific countries only. When a risk is associated with a call, the statistic for that call is multiplied by the assigned risk factor (any number between 1.0 and 100.0). For example, if an outbound call to Cuba is assigned a risk of 2.0, then such a call is counted twice. In this way~ a threshold is 20 exceeded more quickly. It does not mean, however, that this call will automatically generate an alarm.
MCI also m~int~in~ a global list of suspect numbers so that it can monitor callsfrom specific numbers (ANIs or DALs) where fraud has been detected in the past.
Customers may modify this list to suit their purposes. When a call from a suspect 25 number is detected, an alarm is immediately generated regardless of the current totals in relevant monitoring categories.
The purpose behind compiling so many statistics is that customers may combine them in a variety of ways to create a truly customized monitoring plan.
The first component for fraud control is the switched network used by MCI
to provide long distance services to its customers. Switching is the ability to route calls to dirrerellt locations within the public phone network on a call-by-call basis rather than limiting tr~n~mi~ion between predetermined fixed points. For example, 5 a call from New York to Los Angeles may be routed through Chicago in one in~t~nre and through Atlanta and Denver in another. At each point in the network where lines converge, a switch is in place. The switch makes, breaks, or changes connectionsamong the phone circuits in order route calls to their destination.
Co-located with every switch are co~ er systems, adjunct processors (APs), 10 which assist in loading billing information and software into the switch. MCI's billing software, Traffic 2000 (T2000), also acts as a screening device by ex~minin.~
the detailed information (call detail records [CDRs]) associated with each call. Only relevant CDRs--non-residential inbound 800 calls and outbound international calls --are sent to MCI Detect. This prevents the fraud data system from becoming 15 overwhelmed with data.
MCI Detect accepts the CDRs, immediately analyzes the call traffic, and keeps a running total of the counts (for example, number of short-duration calls) and thresholds for each monitoring plan stored in its database. Each monitoring plan is a set of parameters which govern how fraud will be detected for a specific type of 20 call. MCI has developed several generic plans, but customers may also develop their own plans.
Each monitoring plan has three features:
Thresholds ~ Risk factors Suspect numbers.
A threshold is a number which, when excee~le~, generates an alarm in MCI
Detect indicating possible fraud. For example, if a customer indicates that it should receive no more than 1000 calls to its 800 number on any given business day, then WO 97123085 PCTrUS96~0337 the number "1000" is a threshold, and the 1001st call will generate an alarrn.
Thresholds may be specified for the time of day and/or the day of the week.
Furthermore, a threshold may be app~ied to each category for which MCI Detect keeps counts, including the number of short-duration calls, long-duration calls, and 5 cllm~ tive mimltes.
As described previously, risk factors and suspect numbers help to determine the likelihood of fraud based on the assumption that some types of calls more clearly indicate fraud than others. For example, a call from a high-risk dialing area may be assigned a weight of 3Ø Each time such a call is recorded, relevant counts are10 multiplied by a factor of 3 and thresholds are excee~le~ more quickly. The detection of a suspect number immediately triggers an alarm in MCI Detect. It is not necessary to apply weights to these numbers.
Every MCI commercial c -~t -m~r is autom~tic~lly ~ ign~l to a Universal Pk~n initially. Customized plan data is later entered by MCI representatives. Inbound and 15 outbound thresholds are provided in separate plans; therefore~ a customer can have both an inbound plan and an outbound plan active simlllt~n~ously. (Table 1 and Table 2 in Figs. S and 6 show two examples of customer monitoring plans.) When an alarm is generated by MCI Detect, it is also prioritized. The priority is a multiple of the number of times a threshold has been exceeded. For example,20 if the threshold was 10 and the relevant count has reached 50, then the priority of the alarm is 5 (50 . 10) .
Each alarm is available to an MCI fraud analyst via an MCI Detect Workstation. The workstation is a PC with access to a Fraud Data Server and retrieves the next available alarm of the hi~hest priority. The analyst investigates the 25 alarm data and, if fraud is suspected, notifies the customer and suggests appropriate actions to stop the fraud.
Based upon both MCI's and the customer's experiences with fraud, the customer's monitoring plan(s) may be modified with a new set of parameters or w o 97/23n85 PCTAJS96/20337 suspect numbers. This fine tuning is n~efle 1 to more accurately detect fraud and to prevent false alarms.
Since the elapsed time between the completion of a call and the generation of an alarm by MCI Detect is 15 mimltes or less, a significant improvement has been5 made over the 3-4 days required previously. MCI p}ans to reduce this time further to the point where fraud is detect~l while the call is in progress. Detecting fraud in progress permits actions to limit its impact, such as ~hlltting down a DAL, to be taken as quickly as possible. In addition to ch~rlging the way that calls are processed at the switch level, in-progress detection requires effective calling statistics and a 10 complete and current list of suspect numbers.
In maximi7ing the flexibility of customer monitoring plans, MCI Detect both minimi7es false alarms and provides advantages over current competing products.
The features that put MCI Detect above the competition are the following:
~ The flexibility to specify the ANIs and DALs that will be monitored and the monitoring ~resholds and parameters for each.
~ MCI Detect's timely detection and notification of 15 mimltes or less.
~ Calls to all foreign countries are monitored, not just a subset consisting of high-fraud countries.
~ Risk factors are applied to NPA-NXXs, information digits, and specific countries, which minimi7.es false alarms and also provides early notification of abnormal calling patterns.
~ Customers will have the option of specifying any of the following media for alarm notification: telephone, MCI MaillU, fax, pager Integrated Network Management Services (INMS), or Integrated Customer Workstation (ICW).
To increase customer involvement in fraud detection, MCI will allow MCI
customers to monitor their own inbound 800 and outbound international traffic.
W 0 97/23085 PCTrUS96~0337 Using MCI Detect directly, customers may create, modify, and delete monitoring plans and view alarms.
Brief Description of the Figures The above-mentioned objects and advantages of the present invention will be 5 more clearly understood when considered in conjunction with the accompanying drawings, in which:
Fig. 1 is an overview of the present fraud detection system in block diagram form.
Fig. 2 is a block diagram of the system architecture for the present invention, 10 indicating greater detail than that shown in Fig 1.
Fig. 3 is a block diagram of the workstation, as shown in Fig. 2.
Fig. 4 is a glossary table of abbreviations.
Figs. 5 and 6 are examples of monitoring plans that include various pàrameters for detecting fraud.
Fig. 7 is a flow diagram of the overall process corresponding to the system of Fig. 2.
Fig. 8 is a flow diagram of a fraud data server process.
Fig. 9 is a flow diagram of a threshold manager process.
Fig. 9a is a flow diagram of a call h~n~l~in~ process.
Detailed Descrip~ion Of The Inven~ion Referring to Fig. 1, MCI Detect architecture 10 consists of three basic systems:
~ MCI Detect Workstation 12 ~ MCI Detect Threshold Manager (TM) 14 Fraud Data Server 16.
W O 97~3085 PCT~US96~0337 Each system is resident on a separate computer, and the software is unique to the local computer platform.
The following will describe the system operation as indicated in Figs. 2 and 3.
Referring to Fig. 2, the architecture of the present invention is shown in greater detail. The MCI network 4 generates call detail records (CDRs) which areinput to an IBM-based computer system, indicated in block 6 as a T2000 (Traffic 2000). The system stores CDRs generated by the network 4. The T2000 system conventionally processes billing data, as indicated by reference numeral 8. The 10 CDRs and billing data are ret~in~l in the T2000 for a period of time normallyrequired to conduct fraud analysis. Typically, this would be for a period of 24 hours. The components 4, 6 and 8~ employed by MCI Detect 10, constitute prior art.
With continlle-l reference to Fig. 1, the output of the T2000 can provide call records including CDRs and billing data to the input of the MCI Detect system 10, 15 and more particularly to a fraud data server (FDS) 16. The server is of conventional design and includes a buffer for recently retrieved call records which have beenobtained from the T2000. The FDS provides call records to a threshold manager (TM) which processes the call records by reviewing the fields thereof and comparing these fields with established thresholds. When thresholds are excee~lefl they indicate 20 the possible occurrence of fraud.
Alarms are generated by the threshold manager 14 when such thresholds are e~ceede~. The alarms are Ll;~ Pd to the FDS 16 that subsequen~y c-)mml-nir~t~s the alarms to the workstation 12. The workstation also has access to the call records buffered in the FDS 16 so that an analyst at MCI, or an analyst at the network 25 customer site, may have access to the necessary information to finally determine the occurrence of fraud. Since the FDS normally only buffers previously recently retrieved records, the workstation 12 may obtain older call records by querying the T2000.
W 0 97~3085 PCT~US96120337 The workstation 12 is preferably a PC workstation operating with an OS/2 operating system. Fig. 3 indicates the workstation 12 in greater detail. The workstation commllnicates bidirectionally with the FDS 16, the latter keeping track of updated alarm conditions fed back from the TM 14. The FDS produces alarm S sllmm~ries from the alarm data fed back from the TM 14. The col~-",ll,-ications manager 18 provides alarm sllmm~ry information packets to other objects of the workstation. In Fig. 3, the presence of recent actual alarrn ~llmm~ries, tabulatable on a priority basis, is indicated by object 22. Call detail records, as indicated by workstation object 24, are presented in graphical interface forrnat to an analyst who 10 can change the status of a particular alarm situation, as well as various status conditions. These changes are communicated to the FDS 16 by virtue of a commllnications path back through the alarm s-lmm~ry object 22 and the comm-mications manager 18. From tirne to tirne, it may be necess~ry to change the thresholds of the TM 14. Threshold conditions vary for di~rele~lt accounts, according 15 to preselected sets of parameters, referred to plan management, and in-lic~ted in Pig.
3 by object 20. The parameters are shown in various examples in Figs. 5 and 6.
The MCI Detect Work~tn~n Each MCI Detect workstation 12 may be an IBM PS/2 (486-based) personal co~ uLel running OS/2 version 2.1 or later. IBM's Presentation Manager~ provides20 the graphical user interface. The workstation commllnicates (via TCP/IP Protocol) with the Fraud Data Server 16 to extract alarm and plan data as previously mentioned. Up to 50 analysts may log onto MCI Detect workstations at one time.
The estim~te~l workload per workstation is 100 alarm resolution attempts per 24 hours.
WO 97/2308~ PCT/US96/20337 MCI Detect Threshold Manager The MCI Detect Threshold Manager provides real-time threshold analysis (that is, it continuously monitors for plan thresholds that have been exceeded) using algorithms (for example, number of short-duration inbound 800 calls). Examples are indicated in Figs. 5 and 6. It receives call detail records from the Fraud Data Server 16 and returns alarms which may be retrieved and examined using an MCI Detect workstation. The threshold manager resides on an IBM RS/6000 computer running the AIX operation system.
Fr~ud Data Serl~er The MCI Detect workstation 12 interacts with the Fraud Data Server 16 to obtain current and historical fraud-related data, including CDRs, thresholds and other plan data, and alarms.
The Fraud Data Server system consists of four major functional systems-~ Fraud Communications Gateway (FCG)--acts as the interface with external data systems and elimin~tes unwanted CDRs from entering the data server. This interface allows commllnication protocols to be changed without affecting the rest of the fraud data systems.
~ Fraud Parser (FP)--reformats CDRs for processing and passes the records to the threshold manager.
Fraud Data Server (FDS)--manages databases of current and archived alarrn data, customer plans, and other miscellaneous data.
~ Fraud Cu~ ication Distributor (FCD)--provides the data server with the ability to co~ ul~icate with multiple fraud workstations.
Alarrns and call information are sent to the fraud workstations via this interface.
W O 97/2308~ PCTrUS96/20337 The Fraud Data Server resides on a separate IBM RS/6000 computer running under the AIX operating system and using the SYBASE relational fl~t~b~e management system.
Process Flow Charts The process for Inbound 800 fraud detection is identified. An analogous process is conducted for Outbound International fraud detection.
In reference to Figs. 2 and 7, which show the overall process and system for fraud detection, a raw call record 702 is sent from Traffic 2000 System 6. This call record contains numerous data regarding a single call. The call record 702 is input 10 to the Fraud Data Server Process 704, which is specified in detail later in reference to Fig. 8. The Fraud Data Server Process 704 formats the call record into a message that is readable by the Threshold Manager. The Fraud Data Server (FDS) then feeds the formatted call record to the Threshold Manager (TM) as input to the Threshold Manager Process 706, which is specified in detail later in rererellce to Fig. 9. The 15 Threshold Manager Process 706 det~ -illes the need for generating an alarm, as well as the priority of that alarm. If the TM determines an alarm is needed, an alarrn 708 is generated and sent back to the FDS to be recorded in a database and presented to the Workstation 12 (Fig. 1).
In reference to Fig. 8, which shows the Fraud Data Server Process 704 in 20 detail, the raw call record 702 is input to the process 802 in which the FDS gateway receives the call record. The FDS then parses the data 804 and extracts the data that is pertinent to fraud detection, namely the following fields:
~ Country Code ~ Call Duration ~ Info Digits (identifies the service type of call) W O 97~308~ PCT~US96nO337 ~ Service Number (for Inbound 800, this is dialed 800#; for Outbound Int'l, this is the ANI if switched access, or the Switch/Trunk i.d. if dedicated access) ~ Suspect Number (used in TM to match against suspect numbers identified in customer's monitoring plan; for Inbound 800, it is origin~ting ANI; for Outbound Int'l, it is the Int'l Direct Dialed Digits) ~ Customer ID
~ Site ID
~ Tirne since mi(lnight that completed call termin~te-l (either party hung up) ~ Switch/Trunk id (for Inbound 800, where it isn't identified as Service Number) The FDS then formats the record into a message that is readable by the Threshold Manager (TM) and places the forrnatted message in the TM Inbound 15 Mailbox 806. (If the call record origin~te~l from an Outbound International call, the formatted m~age is placed in the TM Outbound Mailbox).
In reference to Fig. 9, which shows the Threshold Manager Process 706 in detail, the TM reads the message in the Inbound Mailbox 902 and determines the message type 904. Alternative to a message representing call record data, a message 20 may represent a request to update a customer's monitoring plan. The TM determines if the message is to process a call or to update a monitoring plan 906.
If the message is to update a plan, the TM executes that update 910.
If the message is to process a call, the TM proceeds to process the call 908, which is shown in detail in Fig. 9a.
In reference to Fig. 9a, which shows how the TM processes a call 908 to determine if an alarm is to be generated, the TM begins by reading the service number 912 (which represents the dialed 800 number for an Inbound 800 call). It then determines if it has processed this service nurnber before 914. If the TM has not W O 97/2308~ PCTAJS96/20337 processed this number before, it will assign the service number to the lowest level of specification of the customer's monitoring plan 916. This is for the purpose of associating call counts and durations for that number to the appropriate part of the monitoring plan. Examples of Inbound 800 levels of specification in ascending order 5 are:
800 number plus supplemental identification codes 800 number Corporate Identification Code Customer ID
Universal plan For example, if the service number is simply an 800 number, the TM will assign the service number to that part of the ma~ltoring plan that specifies thresholds and counts for that particular 800 number. If no match of service numbers or other codes are found, assignment defaults to a universal monitoring plan.
The TM will then send an update of this plan assignment to the FDS 918. The process then proceeds to the sarne point it would have been if the TM had determined, from 914, that the number had been processed before.
If the TM determines that the service number has been processed before 914, it queries the part of the customer's monitoring plan that the number is assigned to 20 and deterrnines the current thresholds and counts 920 for that number. Counts relate to the number of short-duration calls, long-duration calls, total call time, and suspect number calls. Thresholds represent the maximum number of counts a number may reach before triggering an alarm.
The TM then calculates new counts 922 by augmenting ~)ro~liate counts 25 based on call data associated with the service number. For example, if the service number is an 800 number for which a call lasted 20 minlltes (considered long-duration), the long-call count is increased by one.
The TM then applies a risk factor 924 to the call data. A risk factor representsa co-efficient that is entered by the customer to in~1ir~te increased risk associated with a particular NPA-NXX, country, calling area, or info digits. If none is entered, the default risk factor is 1. The TM calculates risk-adjusted counts 926 by multiplying 5 the actual counts by the risk factor. For example, if the customer enters a risk factor of 3 for calls received from NPA-NXX 202-887, and a call record is received for a short-duration 800 call from the ANI 202-887-nnnn, the short-duration count of the monitoring plan is increased by 3.
The TM then matches the new risk-adjusted count to the ap~ro~liate threshold 10 to determine if the threshold has been surpassed 928. If it hasn't, no alarm is generated 930. If the threshold has been surpassed, then the TM calculates the priority 932 of the potential a~a~m. The priority is defined as:
risk-adjusted count threshold The TM then determines if the calc~ teA priority of the current call message is greater than the priority of the previous call message 934. This is to prevent flooding the FDS with alarms if a string of threshold-breaking call counts come in;
only a single alarm is needed in such a case. A history of priorities is kept since the previous miAnight; it is refreshed every midnight.
If the current priority is not greater than the previous priority, no alarm is generated 936. If the current priorit.,v is greater than the previous priority, the TM
sends an alarm to the FDS 938.
Accordingly, as will be appreciated from the previous discussion, the present invention makes available a fraud detection and analysis system which combines a25 threshold manager interConn~cteA with a workstation to filter information relevant to fraud, for example, culled from a particular site which may be the subject of fraudulent activity in a PBX system tr~n~ tin~ inbound 800 number calls, as well as outbound international calls.
W O 97/23085 PCT~US96/20337 It should be understood that the invention is not limited to the exact details of construction shown and described herein for obvious modifications will occur to persons skilled in the art.
Claims (7)
1. A fraud detection system for telephone PBX calls in a telephone network generating call detail records for the PBX calls, the system comprising:
a fraud data server for buffering the call detail records;
a threshold manager connected at its input to an output of the fraud data serverfor detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records, and generating an alarm in response thereto;
means connecting an output of the threshold manager to an input of the fraud data server for buffering the alarm incident to respective call detail records; and a computer workstation connected to the fraud data server for receiving packets of call detail records relating to alarm data, in a filtered preselected format, the workstation including a monitor for displaying the alarm data on a graphicalinterface.
a fraud data server for buffering the call detail records;
a threshold manager connected at its input to an output of the fraud data serverfor detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records, and generating an alarm in response thereto;
means connecting an output of the threshold manager to an input of the fraud data server for buffering the alarm incident to respective call detail records; and a computer workstation connected to the fraud data server for receiving packets of call detail records relating to alarm data, in a filtered preselected format, the workstation including a monitor for displaying the alarm data on a graphicalinterface.
2. A fraud detection method for telephone PBX calls in a telephone network generating call detail records for the PBX calls, the method comprising the steps:
buffering the call detail records;
detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records;
generating an alarm in response thereto;
buffering the alarm incident to respective call detail records;
transmitting packets of call detail records relating to alarm data, in a filtered preselected format, to a computer workstation including a monitor, for displaying the alarm data on a graphical interface.
buffering the call detail records;
detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records;
generating an alarm in response thereto;
buffering the alarm incident to respective call detail records;
transmitting packets of call detail records relating to alarm data, in a filtered preselected format, to a computer workstation including a monitor, for displaying the alarm data on a graphical interface.
3. A fraud detection system for telephone PBX calls in a telephone network generating call detail records for the PBX calls, the system comprising:
a fraud data server having:
(a) communication gateway means for interfacing the server with the telephone network and filtering out unwanted call detail records;
(b) parsing means for reformatting call detail records to a preselected format;
(c) means for storing databases of current and archived call detail records;
and (d) communication distributing means for providing a communication path between the fraud data server and a computer workstation;
a threshold manager connected at its input to an output of the fraud data serverfor accepting the call detail records from the parsing means and detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records, and generating an alarm in response thereto;
means connecting an output of the threshold manager to an input of the fraud data server for buffering the alarm incident to respective call detail records;
the computer workstation connected to the communication distributing means of the fraud data server for receiving packets of call detail records relating to alarm data, in a filtered preselected format, the workstation including a monitor for displaying the alarm data on a graphical interface.
a fraud data server having:
(a) communication gateway means for interfacing the server with the telephone network and filtering out unwanted call detail records;
(b) parsing means for reformatting call detail records to a preselected format;
(c) means for storing databases of current and archived call detail records;
and (d) communication distributing means for providing a communication path between the fraud data server and a computer workstation;
a threshold manager connected at its input to an output of the fraud data serverfor accepting the call detail records from the parsing means and detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records, and generating an alarm in response thereto;
means connecting an output of the threshold manager to an input of the fraud data server for buffering the alarm incident to respective call detail records;
the computer workstation connected to the communication distributing means of the fraud data server for receiving packets of call detail records relating to alarm data, in a filtered preselected format, the workstation including a monitor for displaying the alarm data on a graphical interface.
4. The system set forth in claim 3 further comprising means connected to the telephone network for storing call detail records generated by the network; and means for connecting the call detail records to the commumication gateway means of thefraud data server.
5. A fraud detection method for telephone PBX calls in a telephone network generating call detail records for the PBX calls, the method comprising the steps:
providing a communication gateway for interfacing the server with the telephone network;
filtering out unwanted call detail records;
parsing the filtered call detail records for reformatting them to a preselected format;
storing databases of current and archived call detail records;
providing a communication path for the current and archived call detail records to a computer workstation;
accepting the parsed call detail records for detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records;
generating an alarm in response thereto;
buffering the alarm incident to respective call detail records;
the computer workstation receiving packets of call detail records relating to alarm data, along the communication path, in a filtered preselected format.
providing a communication gateway for interfacing the server with the telephone network;
filtering out unwanted call detail records;
parsing the filtered call detail records for reformatting them to a preselected format;
storing databases of current and archived call detail records;
providing a communication path for the current and archived call detail records to a computer workstation;
accepting the parsed call detail records for detecting numerical counts exceeding preselected threshold values, in predetermined fields of the call detail records;
generating an alarm in response thereto;
buffering the alarm incident to respective call detail records;
the computer workstation receiving packets of call detail records relating to alarm data, along the communication path, in a filtered preselected format.
6. The method of claim 5 further comprising the step of selectively graphically displaying data processed by the workstation.
7. The method of claim 5 further comprising the steps of storing call detail records generated by the network; and connecting the call detail records to the communication gateway.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/577,888 | 1995-12-22 | ||
| US08/577,888 US5805686A (en) | 1995-12-22 | 1995-12-22 | Telephone fraud detection system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2241227A1 true CA2241227A1 (en) | 1997-06-26 |
Family
ID=24310543
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002241227A Abandoned CA2241227A1 (en) | 1995-12-22 | 1996-12-20 | Telephone fraud detection system |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5805686A (en) |
| EP (1) | EP0868811A1 (en) |
| CA (1) | CA2241227A1 (en) |
| MX (1) | MX9805049A (en) |
| WO (1) | WO1997023085A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107819924A (en) * | 2017-11-06 | 2018-03-20 | 东软集团股份有限公司 | A kind of recognition methods of spam phone number, device and equipment |
Families Citing this family (63)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7747243B2 (en) | 1992-03-24 | 2010-06-29 | Boatwright John T | Call security system |
| US6643362B2 (en) * | 1998-11-19 | 2003-11-04 | Global Crossing, Ltd. | Call-processing system and method |
| JPH11502982A (en) * | 1995-03-30 | 1999-03-09 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | Detect unauthorized use of communication services |
| US6601048B1 (en) * | 1997-09-12 | 2003-07-29 | Mci Communications Corporation | System and method for detecting and managing fraud |
| WO1997006643A1 (en) * | 1995-08-07 | 1997-02-20 | British Telecommunications Public Limited Company | Route finding in communications networks |
| US5937043A (en) * | 1996-11-27 | 1999-08-10 | Mciworldcom, Inc. | Mechanism for a system and method for detecting fraudulent use of collect calls |
| US6327352B1 (en) * | 1997-02-24 | 2001-12-04 | Ameritech Corporation | System and method for real-time fraud detection within a telecommunications system |
| US6373935B1 (en) * | 1997-06-30 | 2002-04-16 | Sprint Communications Company L.P. | Workstation for calling card fraud analysis |
| US6466778B1 (en) | 1997-07-22 | 2002-10-15 | British Telecommunications Public Limited Company | Monitoring a communication network |
| GB9715498D0 (en) * | 1997-07-22 | 1997-10-01 | British Telecomm | Monitoring a communication network |
| US7096192B1 (en) | 1997-07-28 | 2006-08-22 | Cybersource Corporation | Method and system for detecting fraud in a credit card transaction over a computer network |
| US7403922B1 (en) | 1997-07-28 | 2008-07-22 | Cybersource Corporation | Method and apparatus for evaluating fraud risk in an electronic commerce transaction |
| US6208720B1 (en) * | 1998-04-23 | 2001-03-27 | Mci Communications Corporation | System, method and computer program product for a dynamic rules-based threshold engine |
| US6175923B1 (en) | 1998-12-08 | 2001-01-16 | Senetas Corporation Limited | Secure system using images of only part of a body as the key where the part has continuously-changing features |
| US6249575B1 (en) | 1998-12-11 | 2001-06-19 | Securelogix Corporation | Telephony security system |
| US7133511B2 (en) * | 1998-12-11 | 2006-11-07 | Securelogix Corporation | Telephony security system |
| US6226372B1 (en) | 1998-12-11 | 2001-05-01 | Securelogix Corporation | Tightly integrated cooperative telecommunications firewall and scanner with distributed capabilities |
| US6687353B1 (en) | 1998-12-11 | 2004-02-03 | Securelogix Corporation | System and method for bringing an in-line device on-line and assuming control of calls |
| US6760420B2 (en) | 2000-06-14 | 2004-07-06 | Securelogix Corporation | Telephony security system |
| US6718024B1 (en) | 1998-12-11 | 2004-04-06 | Securelogix Corporation | System and method to discriminate call content type |
| US20010012346A1 (en) * | 1999-01-29 | 2001-08-09 | Alex Terry | Interactive billing system utilizing a thin web client interface |
| US6526389B1 (en) | 1999-04-20 | 2003-02-25 | Amdocs Software Systems Limited | Telecommunications system for generating a three-level customer behavior profile and for detecting deviation from the profile to identify fraud |
| US6442265B1 (en) * | 1999-05-06 | 2002-08-27 | At&T Corp | Method for detecting and reducing fraudulent telephone calls |
| CA2279684C (en) | 1999-08-05 | 2007-05-15 | Vtech Communications, Ltd. | Method and apparatus for telephone call fraud detection and prevention |
| US6404871B1 (en) | 1999-12-16 | 2002-06-11 | Mci Worldcom, Inc. | Termination number screening |
| US6404865B1 (en) * | 1999-12-17 | 2002-06-11 | Worldcom, Inc. | Domestic to country call intercept process (CIP) |
| US6396915B1 (en) | 1999-12-17 | 2002-05-28 | Worldcom, Inc. | Country to domestic call intercept process (CIP) |
| US6335971B1 (en) | 1999-12-17 | 2002-01-01 | Mci Worldcom, Inc. | Country to country call intercept process |
| JP2003529160A (en) | 2000-03-24 | 2003-09-30 | アクセス ビジネス グループ インターナショナル リミテッド ライアビリティ カンパニー | System and method for detecting fraudulent transactions |
| US6570968B1 (en) * | 2000-05-22 | 2003-05-27 | Worldcom, Inc. | Alert suppression in a telecommunications fraud control system |
| US7324634B2 (en) * | 2000-08-09 | 2008-01-29 | British Telecommunications Public Limited Company | Telecommunications systems |
| US6850606B2 (en) * | 2001-09-25 | 2005-02-01 | Fair Isaac Corporation | Self-learning real-time prioritization of telecommunication fraud control actions |
| US7212620B1 (en) * | 2000-11-06 | 2007-05-01 | Michael Patrick Mastro | System and method for providing an anti-telemarketing feature in a telephony network |
| US8600022B2 (en) * | 2000-11-06 | 2013-12-03 | Michael P. Mastro | System and method for providing an anti-marketing feature in a network |
| US8150013B2 (en) * | 2000-11-10 | 2012-04-03 | Securelogix Corporation | Telephony security system |
| FR2821227B1 (en) * | 2001-02-22 | 2003-05-16 | Schlumberger Systems & Service | SECURE PUBLIC TELEPHONY SYSTEM |
| US6801607B1 (en) | 2001-05-08 | 2004-10-05 | Mci, Inc. | System and method for preventing fraudulent calls using a common billing number |
| US6590967B1 (en) | 2001-05-23 | 2003-07-08 | Worldcom, Inc. | Variable length called number screening |
| US7865427B2 (en) * | 2001-05-30 | 2011-01-04 | Cybersource Corporation | Method and apparatus for evaluating fraud risk in an electronic commerce transaction |
| WO2003010946A1 (en) * | 2001-07-23 | 2003-02-06 | Securelogix Corporation | Encapsulation, compression and encryption of pcm data |
| US7043001B2 (en) * | 2003-10-16 | 2006-05-09 | Tekelec | Methods and systems for detecting and mitigating call routing arbitrage in a telecommunications network |
| US20080152104A1 (en) * | 2006-12-20 | 2008-06-26 | Motorola, Inc. | Intelligent selection of network elements for upgrades |
| EP2446610A1 (en) | 2009-06-25 | 2012-05-02 | PBXwall Limited | Telecommunication fraud prevention system and method |
| DE102011117299B4 (en) * | 2011-11-01 | 2014-09-04 | Deutsche Telekom Ag | Method and system for fraud detection in an IP-based communication network |
| EP2736237A1 (en) | 2012-11-26 | 2014-05-28 | PBXwall Limited | Telecommunication fraud prevention system and method |
| US9160865B2 (en) | 2012-12-04 | 2015-10-13 | Bank Of America Corporation | Mobile platform as a delivery mechanism for security capabilities |
| US10425438B1 (en) * | 2013-09-30 | 2019-09-24 | EMC IP Holding Company LLC | Enriching compromised data using corporate and social network inferred content |
| US9660862B2 (en) | 2014-03-31 | 2017-05-23 | International Business Machines Corporation | Localizing faults in wireless communication networks |
| US9456312B2 (en) | 2014-04-22 | 2016-09-27 | International Business Machines Corporation | Correlating road network information and user mobility information for wireless communication network planning |
| US9350670B2 (en) | 2014-04-22 | 2016-05-24 | International Business Machines Corporation | Network load estimation and prediction for cellular networks |
| US9497648B2 (en) | 2014-04-30 | 2016-11-15 | International Business Machines Corporation | Detecting cellular connectivity issues in a wireless communication network |
| US9674350B2 (en) | 2015-04-27 | 2017-06-06 | Pbxwall Ltd. | Telecommunication fraud prevention system and method |
| US10210520B2 (en) | 2015-07-10 | 2019-02-19 | Mastercard International Incorporated | Co-processing electronic signals for redundancy |
| US10224038B2 (en) | 2015-07-14 | 2019-03-05 | International Business Machines Corporation | Off-device fact-checking of statements made in a call |
| US10230835B2 (en) | 2015-07-14 | 2019-03-12 | International Business Machines Corporation | In-call fact-checking |
| WO2019190438A2 (en) * | 2017-12-29 | 2019-10-03 | Netaş Telekomüni̇kasyon Anoni̇m Şi̇rketi̇ | Ott bypass fraud detection by using call detail record and voice quality analytics |
| US10855666B2 (en) | 2018-06-01 | 2020-12-01 | Bank Of America Corporation | Alternate user communication handling based on user identification |
| US10798126B2 (en) | 2018-06-01 | 2020-10-06 | Bank Of America Corporation | Alternate display generation based on user identification |
| US10972472B2 (en) | 2018-06-01 | 2021-04-06 | Bank Of America Corporation | Alternate user communication routing utilizing a unique user identification |
| US10785220B2 (en) | 2018-06-01 | 2020-09-22 | Bank Of America Corporation | Alternate user communication routing |
| US10785214B2 (en) | 2018-06-01 | 2020-09-22 | Bank Of America Corporation | Alternate user communication routing for a one-time credential |
| CN111565253B (en) * | 2019-12-13 | 2021-07-09 | 成都无糖信息技术有限公司 | Early warning method and system for fraud data of cat pool |
| US11805200B2 (en) | 2022-01-25 | 2023-10-31 | International Business Machines Corporation | Detecting and resolving fraudulent calls |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5220593A (en) * | 1990-10-24 | 1993-06-15 | Gte Mobile Communications Service Corporation | Cellular radiotelephone credit card paystation method |
| US5333183A (en) * | 1992-03-13 | 1994-07-26 | Moscom Corporation | Universal MDR data record collection and reporting system |
| US5438571A (en) * | 1992-11-06 | 1995-08-01 | Hewlett-Packard Company | High speed data transfer over twisted pair cabling |
| US5345595A (en) * | 1992-11-12 | 1994-09-06 | Coral Systems, Inc. | Apparatus and method for detecting fraudulent telecommunication activity |
| TW225623B (en) * | 1993-03-31 | 1994-06-21 | American Telephone & Telegraph | Real-time fraud monitoring system |
| US5590181A (en) * | 1993-10-15 | 1996-12-31 | Link Usa Corporation | Call-processing system and method |
| US5463681A (en) * | 1993-12-29 | 1995-10-31 | At&T Corp. | Security system for terminating fraudulent telephone calls |
| JPH11502982A (en) * | 1995-03-30 | 1999-03-09 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | Detect unauthorized use of communication services |
-
1995
- 1995-12-22 US US08/577,888 patent/US5805686A/en not_active Expired - Lifetime
-
1996
- 1996-12-20 EP EP96944901A patent/EP0868811A1/en not_active Withdrawn
- 1996-12-20 CA CA002241227A patent/CA2241227A1/en not_active Abandoned
- 1996-12-20 WO PCT/US1996/020337 patent/WO1997023085A1/en not_active Application Discontinuation
-
1998
- 1998-06-22 MX MX9805049A patent/MX9805049A/en not_active IP Right Cessation
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107819924A (en) * | 2017-11-06 | 2018-03-20 | 东软集团股份有限公司 | A kind of recognition methods of spam phone number, device and equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| MX9805049A (en) | 1998-10-31 |
| EP0868811A1 (en) | 1998-10-07 |
| US5805686A (en) | 1998-09-08 |
| WO1997023085A1 (en) | 1997-06-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5805686A (en) | Telephone fraud detection system | |
| US8170947B2 (en) | Fraud detection based on call attempt velocity on terminating number | |
| US6643362B2 (en) | Call-processing system and method | |
| US5867566A (en) | Real-time billing system for a call processing system | |
| US5596632A (en) | Message-based interface for phone fraud system | |
| US6279038B1 (en) | Client interface | |
| US9390418B2 (en) | System and method for detecting and managing fraud | |
| US7058166B2 (en) | System and method for real-time fraud detection within a telecommunications system | |
| US6947532B1 (en) | Fraud detection based on call attempt velocity on originating number | |
| US20040151292A1 (en) | Prepaid and postpaid subscriber telephony platform | |
| CA2446732A1 (en) | A system and method for preventing fraudulent calls using a common billing number | |
| US6590967B1 (en) | Variable length called number screening | |
| CA2449703A1 (en) | Isn call interrupt | |
| EP1417827A1 (en) | Method and system for preventing fraud in a telecommunications system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |