The Castle Explore view makes it easy to find fraudulent activity, going from haystack to needle with a few clicks. It is also a great place to start your daily routine for inspecting new activity. In order to make this routine even easier and more streamlined, we've now launched saved searches which allows you to persist the most interesting behaviors that frequently needs to be inspected. Like "Logins from outside the US" or "Transactions by multi accounters".

Back in July last year, we introduced the Explore view in the Castle Dashboard as a way for you to quickly sift through and hone in on fraudulent behavior on a per event level. Today, we're launching a subtle but big improvement to quickly being able to assess the impact of a search result: the ability to see the distinct users matching it. This is particularly helpful when your search generates a lot of activity which can sometimes make it hard to get an overview of which users that are involved.

We're really excited about this one. Part of our mission here at Castle is to make it super easy for anyone to discover and stop fraud, and our goal is to provide unparalleled visibility that allows you to see every step the fraudsters make.

Today, we're releasing the ability to see information about Caste SDK versions in the event data. You're now able to visualize and filter events based on both client and server SDK name and version in the Explore view. Together with the top list chart feature, this provides a great way to monitor adoption of an SDK version upgrade.

We're excited to announce a refreshed Event Explorer page in the Castle Dashboard. Taking your feedback into account, the focus has been on making it both more visually appealing, but first and foremost to make the data easier to visualize and navigate, to better support your fraud investigations.

In order to make risk analysis more granular around registration, login, and challenge activity, we've introduced the ability to specify the authentication method used by the user.

Sometimes debugging or testing different risk scenarios can be challenging, especially with the new Risk and Filter APIs where a request tokenrequest token - A request token is generated by one of Castle's client-side SDK, and is to be passed to each server-side call to the Risk or Filter APIs. needs to be generated on the client for each request.