Risk score

Castle predicts a risk score for each individual device based on how its activity matches their user's normal behavior. We look at device properties, geographic location, time of day, IP address, and the sequence and rate at which events are triggered. A high risk indicates that the account is more likely to have been compromised.

In contrast to a traditional fraud score where risk scoring is done per-user, Castle predicts a per-device risk to be able to stop a high-risk login while at the same time letting known devices through. The user's risk score is simply the maximum of the device risks.

Risk thresholds

If a device's risk score exceeds a certain threshold, you can use that to trigger additional authentication. If the risk score is too high, the login can be automatically halted.

We recommend using the following thresholds and corresponding actions:

  • Approved (Less than 30): let the user in
  • Elevated (between 30 and 60): notify the user, typically over email, that they should approve the new activity
  • Suspicious (between 60 and 90): trigger higher level of authentication, e.g. using SMS, email or an external app
  • Malicious (More than 90): reject login and lock account

Learning and feedback

There are two ways the risk engine learns what is normal behavior for a user:

  • The more a user is active on a certain device and location, the more Castle considers activity coming from this context as legitimate. This includes behavior like account sharing, VPN access, and navigation habits.
  • When your team or your users approve or deny an authentication request, Castle learns that all past activity from this context is to be considered approved or malicious respectively. If further activity is tracked from the same context, the risk score may adjust again. A denied device will never recover unless you clear the feedback.

Risk reasons

The risk score is calculated by combining the reasons that have are generated from the device. Reasons can be categorized into:

  • Global behavior consistency: e.g. number of IPs per user, time from login to password change
  • Per-user consistency: e.g. browser, operating system, time of day
  • Fraudulent signals: e.g. brute-force login, robotic browsing speed

Training period

There is an initial training period for each user account. During the training period new devices and locations are considered to be lower risk than after the end of the training period. Fraudulent signals will still have impact, e.g. brute-force login or fast travel.

How the risk score updates over time

This is an example on how the score may develop for a user from the initial training period, through new devices being added, feedback collected, and fraudulent signals triggered:

Score