SYSTEM ARCHITECTURE FOR FRAUD DETECTION

• US 20200137221A1
• Filed: 10/23/2019
• Published: 04/30/2020
• Est. Priority Date: 10/25/2018
• Status: Active Grant

• Current Assignee: Verint Americas Incorporated (Verint Systems Incorporated)
• Original Assignee: Verint Americas Incorporated (Verint Systems Incorporated)
• Inventors: DelloStritto, James, Gray, Joshua Tindal, Schneider, Ryan Thomas, Ezell, Wade Walker, Pandit, Ajay
• Granted Patent: US 10,887,452 B2
• Time in Patent Office: Days
• CPC Class Codes: G06Q 10/00 Administration; Management
• CPC Class Codes: G06Q 20/4016 involving fraud or risk level assessment in transaction processing
• CPC Class Codes: H04M 3/2281 Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
• CPC Class Codes: H04M 3/42068 where the identifier is used to access a profile
• CPC Class Codes: H04M 3/5191 interacting with the Internet
• CPC Class Codes: H04M 3/5232 Call distribution algorithms

Abstract

An architecture for assessing and identifying fraudulent contact with client contact systems, such as IVR, includes threshold and machine learning scoring and filtering of calls based on these criteria. The criteria may include behavioral, situational and reputational scoring.

Claims

1. A method of detecting fraud in a client contact system, comprising:

receiving a contact from a user, the contact corresponding to event data, the event data including at least one of a channel type and an identifier; and

checking the event data against at least one criteria to determine a risk associated with the event data, wherein at least one of the criteria comprises at least one of behavior criterion, situation criterion and reputation criterion.

2. The method of claim 1, wherein the reputation criterion includes a historical account of how the user has used the client contact system previously.

3. The method of claim 1, further comprising forwarding the event data to a fraud scoring service if the behavior criterion associated with the event data indicates that the user has interacted with the client contact system maliciously previously.

4. The method of claim 1, wherein the situational criterion includes at least one of origination location of the user and the time of day of the contact.

5. The method of claim 4, further comprising forwarding the event data to a fraud scoring service if the origination location of the user is a suspect origin.

6. The method of claim 1, wherein the behavior criterion includes how a user is interacting with the system.

7. The method of claim 1, wherein the behavior criterion for the user is analyzed for a specific period of time.

8. The method of claim 1, wherein the behavior criterion includes count volume associated with the user.

9. The method of claim 1, wherein the behavior criterion includes how many accounts are associated with the identifier.

10. The method of claim 1, wherein the behavior criterion includes a number of times a user has accessed the client contact system over a predetermined time period.

11. The method of claim 1, wherein the behavior criterion is determined by calculating a standard deviation over a predetermined period of time for a typical contact with the client contact system and determining whether the event data falls outside the standard deviation.

12. The method of claim 1, wherein the identifier comprises one of an ANI, an IP address, a SIP address and an email address.

13. The method of claim 1, further comprising publishing suspect events to a series of reporters.

14. The method of claim 1, further comprising forwarding the event data to a fraud scoring service if any of the behavior criterion, the situation criterion and the reputation criterion are satisfied.

15. The method of claim 1, further comprising collecting additional data related to the user or the context of the contact and determining if further analysis steps should be performed based on the collected additional data.

16. The method of claim 1, further comprising checking and adjusting a format of the event data into a standard format if the format of the event data is not in the standard format.

17. The method of claim 1, further comprising partitioning data related to a plurality of contacts using a unique has key generated based on channel type, channel address and data source.

18. The method of claim 1, further comprising sorting event data by date.

19. An architecture for fraud detection in an interactive voice response system, comprising:

a client system that interacts with a user on a channel;

a shared composite API that receives event data from the client system;

a fraud ingestion service ingestion processor that receives the event data from the shared composite API;

a fraud detail record topic that receives the event data from the fraud ingestion service;

a fraud service aggregator that receives the event data from the fraud detail record topic, the fraud service aggregator in communication with a fraud record service for comparing the event data to prior event data for providing to a scoring topic, the scoring topic providing at least one a plurality of checks on the event data to determine if the event data represents a fraud risk.

20. The system of claim 19, wherein the plurality of checks includes at least one of a threshold check and a machine learning process.

21. The system of claim 19, wherein the fraud service ingestion processor is capable of checking data format and adjusting data format to a standard format for receipt by the fraud detail record topic.

22. The system of 19, further comprising a load balance circuit for gating high event volume through the system.