Overview
Notice
The functionality described below is contained in the EngageIP Fraud Module, an add-on which is not included with EngageIP. If you wish to obtain a Fraud Module license please contact sales@logisense.com
LogiSense’s International Fraud reporting [glossary_exclude]service[/glossary_exclude] is designed to detect abnormal amounts of calls made from BroadWorks or Sansay switches to international locations. Only outbound international calls are analyzed to scan for issues and report them via e-mail to pre-defined users. Data is stored in a manner such that future reporting criteria (changes to existing reports or new reports) should be easily added.
Real-Time Fraud Services
There are windows services that need to be running in order to perform real-time fraud processing.
EngageIP Fraud [glossary_exclude]Service[/glossary_exclude]: this [glossary_exclude]service[/glossary_exclude] will rate international calls in real-time. To configure this [glossary_exclude]service[/glossary_exclude] you need to set the property “FraudUDRRatePlanName” to the rate plan name you want loaded in the app.config file.
BroadworksInternationalCallsService: this [glossary_exclude]service[/glossary_exclude] reads UDR records from BroadWorks switches and sends raw records to the real-time rating Fraud [glossary_exclude]Service[/glossary_exclude].
SansayInternationalCallsService: this [glossary_exclude]service[/glossary_exclude] reads UDR records from Sansay switches and sends raw records to the real-time rating Fraud [glossary_exclude]Service[/glossary_exclude].
Fraud Services are completely independent from the Rating Service, however the UDRFeed and UDRDataSourceDetails must have a valid location or the Fraud Services will return an error.
Both collector services need to be configured to read the records from the specified folders where the fraud [glossary_exclude]service[/glossary_exclude] URL is located. Below are the settings which need to be defined in the config file:
Directory – directory where the UDRs will be copied to be processed
PostFraudProcessDirectory – directory where the processed file will be copied for the regular rating engine
Feed – UDR feed name that the real-time fraud [glossary_exclude]service[/glossary_exclude] should use to do the mediation and processing
MinThread – minimum number of threads to load
MaxThread – maximum number of threads to load
ThreadEnable – enable threading
FraudServiceUrl – URL to the listening Fraud [glossary_exclude]Service[/glossary_exclude] [doman:8378/owner name/] ex: http://localhost:8378/Logisense Corporation/
Candidate CDR Records
CDRs that are considered (by the BroadWorks/Sansay rating code) for international fraud detection are records which:
Are Outbound (field 6 = “Originating” for BroadWorks or Host name in the list of Outbound for Sansay
Have a Terminating Identifier that exists in the results of ViewCountryCodes (in EngageIPCollector).
This returns country codes for non-US/Canada locations (including other NANPs).
The lookups are performed by evaluating the starting digits of the terminating identifier (minus “011” if the terminating number starts with it, or with "1" prepended if the terminating number is 10 digits). It searches by the first 4, 3, 2, and 1 digit, and takes the first match (of which there should only ever be one)
Fail country code lookup but are categorized as International
If the country code lookup fails, the CDR will still qualify if it is categorized by BroadWorks as International (field 19 = “internat”) or the terminating number (field 8) starts with “011” (after stripping and leading ‘+’, ‘”‘, ‘@’, ‘*’ characters)
(Note: field numbers above are based on BroadWorks/Sansay CDR fields starting with 1, not 0-based)
InternationalOutboundCallLog Table
After the previous lookups have occurred, the data is then stored in the InternationalOutboundCallLog table. The table is represented in SQL Server as the following:
[ID] [int] IDENTITY(1,1) NOT NULL, [RecordID] [nvarchar](100) NOT NULL, [ServiceProviderID] [varchar](32) NOT NULL, [Group] [nvarchar](32) NOT NULL, [Department] [nvarchar](255) NOT NULL, [UserID] [nvarchar](162) NOT NULL, [UserNumber] [nvarchar](25) NOT NULL, [GroupNumber] [nvarchar](25) NOT NULL, [CallingNumber] [nvarchar](162) NOT NULL, [CalledNumber] [nvarchar](162) NOT NULL, [StartTime] [datetime] NOT NULL, [AnswerTime] [datetime] NOT NULL, [ReleaseTime] [datetime] NOT NULL, [DialedDigits] [nvarchar](162) NOT NULL, [TrunkGroupName] [nvarchar](255) NOT NULL, [RedirectingNumber] [nvarchar](162) NOT NULL, [CallDuration] [real] NOT NULL, [Type] [nvarchar](16) NOT NULL, [OriginalCalledNumber] [nvarchar](162) NOT NULL, [AccountCode] [nvarchar](15) NOT NULL, [AuthorizationCode] [nvarchar](15) NOT NULL, [RedirectionReason] [nvarchar](40) NOT NULL, [TerminatingLocation] [nvarchar](255) NOT NULL, [EngageIPUserName] [nvarchar](255) NOT NULL, [FileName] [nvarchar](255) NULL, [RowNumber] [int] NULL, [AmountRated] [decimal] NULL, [Classification] [nvarchar](255) NULL, [Owner] [nvarchar](255) NULL, [BillingIdentifier] [nvarchar](255) NULL
|
|---|
All of the fields are populated directly from their corresponding collector services BroadWorks or Sansay. EngageIPUserName was chosen to store the EngageIP user instead of EngageIP UserID so that this table can live in any database without dependence on the main EngageIP database for reporting. Rates are checked for the EngageIP “Fraud” rate plan.
In addition to the EngageIP tables, the EnagageIPCollector has its own set of tables:
Country - a list of International countries detailing if they are in the restricted list or not
Country code - this table links countries from the Country table to their country codes to determine the called country
SansayFraudTerminationPrefixesToStrip - provides the possibility to strip the prefixes in this table from the called number
Anti-Fraud Reports
The anti-fraud reports themselves exist as stored procedures in SQL Server. They are scheduled by the SQL Server Agent as jobs and can be configured to run at whatever interval is desired. The stored procedures are also responsible for sending email notifications out, thus SMTP email must be configured in SQL Server (for information on that, please consult SQL Server documentation).
The stored procedures query the InternationalOutboundCallLog table which contains all the needed information. Fraudulent activity is determined by looking at the sum of UDR.Amount values from within a time period. By default, reporting by owner looks for an excess of $100 in calls, and by user looks for an excess of $30.
Note: The threshold for fraudulent activity on users can be overridden by adding the profile question named “Fraud Threshold” to a user – in the event that $30 is too high/low.
Checks for fraudulent calls occur every 10 seconds. During this check the time period considered for candidate calls is 1 hour in the past from the most recent call in the InternationalOutboundCallLog table. If the threshold for either the User/Owner report has been exceeded, then the offending calls will be added to the report. Only calls which have not yet been reported (emailed), will be emailed in the current report. If the email cannot be sent, then it will not treat those calls as reported.
Information on reported activity is saved in the "FraudByCallAmountsHistory" and "FraudByCallAmountsOwnerHistory" tables for User and Owner reporting. These tables contain the EngageIP User/Owner Name, ID of the Last International Outbound CallLog Reported and Reported Time.
User Report Examples
Scenario | Fraud Is Detected | Resulting Report |
User has made no international calls | No | None |
User has made $5 in the past hour of imported calls | No | None |
User has made $500 of international calls in prior days/weeks | No | None |
User makes $30.01 of international calls in the past hour of imported calls | Yes | Report is sent with the offending calls |
User from previous scenario makes $1 worth of more international calls within the same hour. | Yes | Report is sent with the new calls only |
User from previous scenario makes $29 worth of international calls two hours later | No | None |
User from previous scenario then makes another $1.50 in international calls within the same hour as previous calls. | Yes | Report is sent with the calls that totaled $29 and the most recent $1.50 in calls. |
User makes $40 worth of international calls within an hour, but has a “Fraud Threshold” set on the user of 50 | No | None |
Same user as previous scenario makes $51 worth of calls within the hour | Yes | Report is sent with the $51 worth of calls. |
Owner Report Examples
Scenario | Fraud Is Detected | Resulting Report |
There are no international calls within an owner | No | None |
Owners’ users have made $5 in the past hour of imported calls | No | None |
Owners’ users have made $500 of international calls in prior days/weeks | No | None |
Owners’ users (one or many) make $100.01 of international calls in the past hour of imported calls | Yes | Report is sent with the offending calls |
Any user within the owner from previous scenario makes another $1 worth of more international calls within the same hour. | Yes | Report is sent with the new calls only. The user making the calls can be different than the user(s) making the previous calls. |
User from previous scenario makes $99 worth of international calls two hours later | No | None |
User from previous scenario then makes another $1.50 in international calls within the same hour as previous calls. | Yes | Report is sent with the calls that totaled $99 and the most recent $1.50 in calls. |
Two users make $99 worth of international calls each (within the same hour), within different owners. | No | None |
Reported Fields
The following fields are included in the emailed reports by default:
OriginatingIdentifier, TerminatingIdentifier, BillingIdentifier, StartTime, ReleaseTime, AnswerTime, Amount, Country, Owner, User, OriginalCDRID, RedirectingReason, Classification.
Reporting Recipients
The recipients of the reports are stored within the reports’ SQL stored procedures. To modify them, the value assigned to parameter ‘@recipients ‘ (passed into msdb.dbo.sp_send_dbmail) needs to be modified. If you plan on regularly changing the reports’ recipients, it’s advisable to use an email alias, which can be maintained on the email server.