Protecting account opening means ensuring a new account was created by an authentic user, for a legitimate purpose. In Account Opening Fraud (AOF), also known as New Account Fraud (NAF), the attacker creates a new account for an online service with a malicious intent, using a stolen or fake identity. For example, they may set up financial accounts in other people's names to get credit or a loan. They could also create fake accounts to redeem "sign up" promotions, to create an email address for sending phishing emails, or to test stolen credit cards using a retail website.
This describes how you can prevent account opening abuse using Transmit Security detection and response services.
Common attack vectors for account opening abuse include:
- bots for mass account creation and attacks requiring a massive scale to succeed (like phishing)
- human click farms to perform actions too nuanced for bots (like testing stolen credit cards)
- social engineering to get personal info needed to impersonate the user when opening the account
- lots of stolen data (typically from a data breach) to combine with real data to forge synthetic identities
- network spoofing to make it appear as if they’re connecting from the right location
- device spoofing to appear like a new device, and hide from a bad device reputation
Account opening abuse includes cases in which the account appears legitimate upon creation. Although the account was created for the sole purpose of malicious activity, it may only begin weeks later. For this reason, it's important to continuously assess risk and trust for all risk moments within the customer journey and not just upon registration.
The first step to protecting account opening is to provide Transmit with the telemetry required to continuously assess risk and trust for the given context, and to identify trusted users. Report sensitive actions as the user requests to perform them during risk moments.
To do this:
- Add the Detection and Response code snippets, ideally on each page of your website. This will automatically provide telemetry to our machine learning engine—such as device, network, and other context data used to continuously assess risk.
actions that are relevant to your use case using the
triggerActionEvent()call. Start by reporting the sign up request using the
registeraction. Since malicious activity may only be detected within the weeks that follow account creation, you should report all the actions that are relevant to your customer's journey. For example, this may include
checkout, and other available actions .
Set the (authenticated) user as soon as possible to add the user context for all subsequent events of the session. This will also be used to create and update a behavioral profile of the user, so we can detect anomalies in the future. The user can either be set using the
initialize()call, or after authentication using the
setAuthenticatedUser()call. In both cases, it should be set only after you've fully authenticated the user (including, for example, any 2FA that was required). Make sure the user identifier you use doesn't contain any personal information.
When a user logs out or a user session expires, make sure you call
clearUser()so they are not associated with future actions.
See Quick starts for integration steps and code snippets. Once you complete this step, you can already see how it works by running your app, requesting to perform a sensitive action that your snippet reports, and then going to the Admin Portal to see the recommendations associated with the action. In the next steps, you'll learn how to fetch recommendations yourself and act on them.
For every action you report, use our Recommendation API to fetch our recommendation. Based on the recommendation, you can determine the risk-level of the action in the given context, choose an appropriate mitigation strategy if needed, and build trust for the user, device, and network. You can also send the recommendations to your analytics systems for further persistancy and offline analytics.
See Quick starts for API integration steps and code snippets.
There are different types of recommendations that you can get (see Recommendation types). If you receive a
deny recommendation for the register action, you should use additional means such as ID verification or even an offline manual review.
See Challenges for our suggested challenges based on your use case.
Each recommendation includes the reasons for the recommendation, which indicate the risk signals that were used to detect suspicious activity (such as bot behavior). For example, for the
DEVICE_SUSPICIOUS_VELOCITY means that this device was already used to create other accounts, whereas
IP_ACTION_VELOCITY means that this network reported numerous
register actions within a short period of time (which may possibly indicate mass account creation). Other reasons may indicate an attempt to disguise the device as a different one, such as
Recommendations not only allow you to mitigate risk, they're also used to reduce friction. If you receive an
allow recommendation, you can proceed with the activity and reduce friction.
The goal is to keep great customer experience, so reduce friction whenever you can in low-risk scenarios.
Detect risk and protect against account takeover (learn more), as well as leverage our authentication and identity management capabilities for account protection scenarios: