Designing Proactive Fraud Detection Models using Real-Time Behavioral Data Streams

How-To-Articles
1

Designing Proactive Fraud Detection Models using Real-Time Behavioral Data Streams

What This Guide Covers

  • Moving away from legacy authentication (like PINs or Knowledge-Based Authentication questions) which are easily compromised by social engineering.
  • Architecting a real-time fraud detection pipeline that analyzes how a customer behaves in the IVR and Web interface using Genesys Cloud Predictive Engagement and external anomaly detection engines.
  • The end result is a dynamic risk-scoring model that invisibly evaluates every caller, automatically routing high-risk sessions to a specialized Fraud Operations queue before a financial transaction can be executed.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 2 or 3, plus Predictive Engagement (GCPE).
  • Permissions: Predictive Engagement > Action Map > Edit, Architect > Flow > Edit, Integrations > Action > Execute.
  • Infrastructure: AWS EventBridge (or webhooks) for streaming behavioral data, and an external Fraud Risk Engine (e.g., AWS Fraud Detector, Pindrop, or a custom Lambda model).

The Implementation Deep-Dive

1. The Death of KBA (Knowledge-Based Authentication)

Asking a customer “What is your mother’s maiden name?” is no longer a valid security control. This data is widely available on the dark web or easily extracted via phishing.

The Trap:
If you rely solely on KBA or SMS OTPs, a fraudster who has SIM-swapped the customer will easily pass your IVR authentication block. You must adopt Behavioral Authentication. You don’t authenticate who they say they are; you authenticate how they act.

2. Capturing Web Behavioral Telemetry

Before the fraudster even calls the contact center, they usually probe the website.

Implementation Steps (Predictive Engagement):

  1. Deploy the Genesys Cloud Predictive Engagement Tracking Snippet onto your main website and Customer Portal.
  2. Configure Event Tracking for high-risk actions. Examples:
    • Event A: Multiple failed login attempts within 5 minutes.
    • Event B: Password reset triggered from a new, unrecognized IP address.
    • Event C: Navigating directly to the “Add New Payee” or “Wire Transfer” page immediately after login, without viewing the dashboard.
  3. The Segment Trigger: Create a GCPE Segment called High_Risk_Web_Behavior. Configure the condition: If a user triggers Event B AND Event C within 10 minutes, assign them to this segment.

3. Capturing IVR Behavioral Telemetry

Fraudsters navigate IVRs differently than legitimate customers.

Architectural Reasoning:
Legitimate customers calling about a bill typically press 1 for Billing, then enter their account number. Fraudsters often use automated dialers, entering DTMF tones instantly (faster than humanly possible) or “hunting” by repeatedly hanging up and calling back to test different account numbers.

Implementation Steps (Architect & EventBridge):

  1. In your Inbound Call Flow, utilize the Get Participant Data action. If the ANI (Phone Number) has called more than 5 times in the last 2 hours (tracked via an external DynamoDB table dip), flag a custom attribute Flow.IVR_Behavior_Risk = "High".
  2. Stream all IVR navigation events via Amazon EventBridge (v2.detail.events.conversation.{id}.customer.end).
  3. Your external AWS Fraud Detector model ingests the web segment data (from GCPE) and the IVR navigation data.

4. The Real-Time Scoring and Routing Architecture

You have collected the behavioral data. Now, you must score the interaction in real-time before the caller reaches a vulnerable agent.

Implementation Steps:

  1. The Interception Point: In your Architect Inbound Call Flow, immediately after the initial greeting, place a Call Data Action.
  2. The Risk Dip: Call your backend AWS Lambda function (GetFraudRiskScore). Pass the Call.Ani, the Call.ConversationId, and the user’s Web Cookie ID (if available via authenticated voice flow).
  3. The Scoring Logic (Lambda): The Lambda aggregates the data.
    • Did the caller originate from the High_Risk_Web_Behavior segment? (Score +50)
    • Is the ANI VoIP or a known burner range? (Score +30)
    • Did they input DTMF abnormally fast? (Score +10)
  4. The Routing Decision: The Lambda returns a RiskScore from 0 to 100.
  5. In Architect, use a Switch action:
    • If RiskScore < 40: Route to standard Customer Service.
    • If RiskScore >= 40 AND < 80: Route to Customer Service, but display a Screen Pop warning the agent: “Elevated Risk: Require Voice Biometric or Out-of-Band Auth.”
    • If RiskScore >= 80: Bypass standard routing entirely. Route the call directly to the specialized “Fraud Investigations” queue. Play a generic message: “We are transferring you to a specialist to assist with your account.”

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Traveling Executive” False Positive

  • The Failure Condition: The CEO of your company is traveling in a foreign country. They log in from an unknown IP address, fail their password twice due to jet lag, reset it, and immediately try to wire funds. The system flags them with a Risk Score of 95 and routes them to Fraud Investigations, who puts a hard lock on the account. The CEO is furious.
  • The Root Cause: Behavioral models without context generate high false positives.
  • The Solution: The Fraud Lambda must query a “VIP / Known Exception” database. Furthermore, if a score is high, instead of an immediate hard lock, introduce an Automated Step-Up Challenge in the IVR. Play a prompt: “We noticed unusual activity. Please enter the 6-digit code generated by your physical hardware token (YubiKey) or corporate authenticator app.” Give the user a chance to prove identity through a stronger factor before escalating to the Fraud queue.

Edge Case 2: The Latency Block

  • The Failure Condition: Your Call Data Action to the Fraud Risk Engine takes 8 seconds to process because the backend is querying 5 different databases. The caller hears 8 seconds of dead air. Eventually, the Genesys Architect flow times out, drops the data action, and routes the call to a standard agent without any risk warning.
  • The Root Cause: Synchronous API calls in the IVR must be fast. Genesys Cloud Data Actions time out by default.
  • The Solution: Asynchronous Pre-Scoring. Do not wait for the caller to reach the IVR block to calculate the score. When the customer is browsing the web, the backend should be constantly calculating and caching their Risk Score in an ultra-fast Redis cache (ElastiCache). When the Call Data Action fires, it simply performs a 10ms lookup against the Redis cache (GET UserRisk:12345) rather than recalculating the entire model synchronously.

Official References