Castle supports tracking address information, both on the user and transaction object in the API payload. You're able to send all the common fields like street address, city, region and postal code. When sending this information, Castle computes a fingerprint by normalizing the address information and creating a hash. This makes it super easy to find e.g. multiple users on the same address, or when using the same shipping address for multiple payment methods. Today we're introducing a change in the API which allows you to send your own address fingerprint if you prefer a custom one over the one that Castle computes automatically.

Castle allows you to send rich transaction data such as payment amount, method, fingerprint and much more. With this information available in Castle you're able to search historic transactions, spot fraudulent ones and then write rules to either block them or warn you when these happen.

Today we've launched a powerful new way of visualizing data over time across many entities of the same type, like Users, Devices or IPs. With this feature, you can quickly hone in on suspicious users, and compare their activity over time, to discover patterns indicative of e.g. multi-accounting abuse. By seeing user activity next to each other, you're able to spot clusters of account with similarities in event sequences, such as a signup shortly followed by an invitation.

Today we're proud to release our link analysis feature which empowers you to quickly visualize and discover more fraudulent users. Link analysis is a powerful technique used to identify relationships and connections between entities such as users, devices, addresses, payment methods and more. Finding such connections can reveal fraudulent patterns and anomalies such as:

A while back we launched the ability to filter and group by custom properties. By sending this custom, business specific data, you're able to create even more efficient rules for stopping bad behavior on your platform. Today we're releasing two big updates to how Castle handles these custom properties, that turns them into a first class citizen in Castle

Lists are a powerful concept in Castle, that can be used for a variety of different use-cases, including IP block lists, user allow lists or as a simple review queue. If you haven't started using Lists yet, we highly encourage you to check them out! Today we're shipping a small but significant update: the ability to manually add anything to a list from the Castle Dashboard.

Castle's is built to make fraud investigations quick and efficient by collecting all user activity data in the same place, as well as providing powerful ways of exploring it. An essential part of a fraud investigation is to be able to go back far in time in order to connect the dots, so today we're happy to announce that we'll start offering up to 12 months of data retention. For an additional fee, you can now activate up to 12 months data retention, compared to the standard 3.

Today we're releasing a beta version of our Events API. This API is what's powering the Castle Dashboard under the hood and is used to query individual events as well as create aggregations and groupings. It opens up countless new use-cases e.g. where you can build customer facing on top of it, or use it to augment internal tooling.

We've released a re-designed list widget, to make it easier to both to manage the list state, as well as see the context of why and when an item was added. The goal with the new widget has also been to give you a unified and consisted experience across the Castle dashboard, for everything related to lists.

Policies is the backbone that allows you to define granular rules and corresponding actions to control the behavior on your platform, eg. to put suspicious logins through additional verification or show a CAPTCHA to automated signups. Today, we're launching a new configuration options for policies, where you're able to configure a policy to run at the very top, before all others, regardless of which event. This is particular useful when using lists to configure global block or allow lists, for example to blanket deny abusive IPs.