Skip to main content

Fraud Attack Guidance

What to do if you’re under a fraud attack!

Configuring Fraud Attack Radar

If Fraud Attack Radar (FAR) is available in your workspace and not enabled on a Workflow yet, get it configured. To turn it on:

  1. Navigate to the Workflow page for the workflow you want FAR to monitor.

  2. Click the ellipses (…) menu and select Fraud Attack Radar.

  3. Toggle FAR on.

  4. Choose which roles receive notifications when a fraud attack is detected. Notifications are sent by email and shown as an in-app banner.

Data requirements and smart configuration: FAR needs 2 months of production data and an average of 10+ evaluations per day on the workflow to train. You can configure FAR on a workflow that doesn’t yet meet these requirements — for example, during implementation. FAR waits until the requirements are met, then starts training automatically and emails you when training begins.

Training time: once training starts, FAR takes about 1 hour to train, so you’ll see scores roughly an hour after toggling it on (if your workflow already meets the data requirements).

I have a CSM

If you received an email that you are under a fraud attack, you can expect your CSM to reach out with an analysis outlining:

  1. Why the alert was triggered

    1. The leading Indicators behind the fraud attack (e.g. IP fraud ring)

  2. Contributing Entities

    1. Entities with shared attributes that contributed to the attack (e.g. these 15 distinct entities shared the same IP address)

    2. Which shared attributes appeared in conjunction with each other (e.g. these 30 entities had the same IP address and phone number)

  3. Near-term and short-term recommendations

    1. Immediate recommendations to stop the bleed e.g. routing applicants through DocV or temporarily tightening IEV on the leading indicator (e.g. in the above example we’d tighten IEV on IP velocity).

      1. Reroute to your safety Journey/Workflow if you have it set up already!

    2. Long-term policy recommendations to prevent this type of attack from impacting your FI in the future

While you wait for your CSM to reach out, you can triage the attack yourself in the Alloy dashboard — see Reviewing a fraud attack in the dashboard below to:

  1. View the leading Indicators of the fraud attack

  2. See the entities that contributed to the attack

  3. Check to make sure you’re decisioning on IEV! This is the lowest hanging fruit for stopping PII velocity based fraud attacks (most common)

I don’t have a CSM

You can triage the attack yourself in the Alloy dashboard (see Reviewing a fraud attack in the dashboard below):

  1. Understand why the alert was triggered

    1. Open the fraud attack and view the leading Indicators, shown in order from highest to lowest

  2. Contributing entities

    1. View the entities that contributed to the attack directly from the attack view, or filter the Application Queue by the fraud attack timeframe + leading indicators to see which entities came in during that period

  3. Check to make sure you’re decisioning on IEV! This is the lowest hanging fruit for stopping PII velocity based fraud attacks (most common)

    1. If you’re not, here’s how we recommend setting up IEV

Reviewing a fraud attack in the dashboard

You no longer need to reconstruct an attack manually from Workflow Analytics — FAR gives you a self-serve triage view.

  1. View all attacks in a time period. Filter by time period to see every fraud attack detected in that window. Each attack has a unique Fraud Attack Radar (FAR) token that identifies it.

  2. See the top indicators per attack. Each attack shows its top contributing indicators (e.g. repeated shared IP address), without any manual graph filtering, so you can immediately see what’s driving it.

  3. Mark the attack status. Set each attack to Under Review, Confirmed Attack, or Not Fraud Attack. Marking a status for every attack matters: your feedback is used to improve the model’s accuracy for your organization.

Finding the entities behind an attack

From an attack, you can see the specific entities that contributed to it:

  1. Open the attack summary to see its top four indicators.

  2. Drill down by the attack’s FAR token to see the contributing entities — the entities whose shared attributes caused the attack indicators to spike.

  3. Use the shared-indicator analysis to see which attributes the entities have in common, and which shared attributes appeared in conjunction with each other (e.g. same IP address and phone number).

Keep in mind that a contributing entity is one that contributed to the attack being detected — it is not automatically confirmed fraud. Prioritize investigating contributing entities that were approved.

Triaging at the evaluation level

You can also work an attack from the Evaluations page:

  1. Filter evaluations by the attack’s FAR token to see every evaluation tied to the attack.

  2. Export the filtered evaluations if you want to analyze or share them outside Alloy.

This complements the entity-level investigation above: use the entity view to understand who is attacking you, and the evaluation view to review and export exactly what came through your workflow during the attack.

How the Model Works

Training Data

The Fraud Attack Radar is trained on the following feature inputs:

  1. Number of entities

  2. Number of denials

  3. Number of Fraud Review tags returned

  4. Fraud Vendor Scores

  5. Email Distribution

    1. Distribution of email domains is abnormal i.e. spike in AOL and Hotmail applications

  6. State Distribution

    1. Distribution of states is abnormal i.e. spike in Virginia applications for a California CU

  7. PII Uniqueness

    1. State

    2. Email

    3. Email Domain

    4. IP Address

    5. Phone Number

    6. SSN

    7. License

FAR is trained on your organization’s own baseline rate for each indicator, so what counts as an abnormal spike is specific to what’s normal for you. Alloy continues to release model accuracy improvements that reduce false-positive alerts (for example, better handling of legitimate applicants who apply twice, seasonality, and volume spikes after quiet periods) without reducing fraud detection coverage.

Output

The model runs every 30 mins and returns the likelihood the client is under a fraud attack with a confidence score from 0-1. We alert of a fraud attack at a confidence of 0.8

Each check looks at the last 24 hours of activity to determine whether a fraud attack occurred in that period. The 0.8 alert threshold is not configurable — it is the point at which Alloy considers an attack confirmed rather than possible.

Things to note

  • FAR is available on eligible Onboarding workflows and must be enabled as an entitlement in your workspace. If you do not have FAR but are interested, contact your CSM or Account Executive..

  • Always mark a status on every attack — this directly improves the model for your organization.

Did this answer your question?