Calculating risk

Castle's methodology and signal analysis for risk score calculation


Castle’s /authenticate endpoint returns a numerical risk score between zero and one. Low-risk events are scored at or near zero, and high-risk events are scored at or near one.

When producing this risk score, many properties are evaluated. These properties include:

  • whether the event is pre- or post-authentication
  • any history of the device performing the event
  • the real-time IP and ISP reputation
  • suspicious behavior, such as high entropy in user or device traits
  • historical data for any relevant users

Risk factors

Castle determines a set of risk factors that are evaluated based on the contextual data provided for an event. Summaries are provided here for evaluations of IP characteristics, device characteristics, bot behavior, location, and suspicious behavior. This is a small sample of the total number of risk factors that Castle evaluates when determining the risk score - it should not be considered a comprehensive list.

Castle allows configuration of policies to block or label events that exhibit certain risk factors. This allows an infinite amount of customization for your own Castle integration - you can block events, get webhook notifications, and create follow-up workflows based on very specific policies, looking at very specific risk factors, and applied to any number of events that you choose.

IP and ISP characteristics

Castle maintains a database of IP characteristics. Some examples include:

  • proxy
  • datacenter
  • TOR exit node

Based on the labels above in combination with activity that we observe, Castle maintains a concept of an IP and ISP reputation that changes over time. Since IP addresses get reassigned, these reputations are not static. IP and ISP reputations change in real time. Castle has seen more and more attacks originate from residential network ISP’s, and we tune our product to block bad activity while still allowing “good” users to access their accounts.

Device characteristics

Castle parses the User-Agent string and compares device fingerprint details to extract device characteristics. With these two pieces of information, Castle is able to reliably determine the kinds of devices, as well as individual pieces of hardware that users are using. Castle can tell when a device is trying to spoof its' true platform or browser.

Bot behavior

Castle evaluates fingerprint characteristics for telltale signs of bots. The behaviors we look for include things like straight vector mouse movements, time patterns between interactions, and some other mechanisms that we like to keep as closely-held secrets. To get an idea of what our Data Science team works on when it comes to effective detection capabilities, including our ability to spot B├ęzier curves, read our Blog post on Bot Mouse Movement Detection.


Castle maintains an updated data store of IP locations. Castle keeps track of locations around the world where a user and device has been “seen”. This means that risk factors such as “New Country” and “Fast Travel” will be evaluated and feed into risk calculation for a user. Castle also compares new locations against “expected” locations where users travel, and factors likelihood of the users being in that location when determining risk score.

Suspicious behavior

Castle looks at a variety of behavioral traits of devices, ISP’s, and individual IP traffic to determine suspicious circumstances. These traits include, among many others, the ratio of failed-to-successful events, as well as observations of multiple-account access attempts. As with our other models, we tune our product to be extremely fast in detecting suspicious behavior, and we label such behavior in real time.