Protect account opening

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.

How it happens

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
Note

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.

Step 1: Report data and actions

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:

  1. 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.
  2. Report all actions that are relevant to your use case using the triggerActionEvent() call. Start by reporting the sign up request using the register action. 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 login , checkout , and other available actions .
  3. 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.
  4. When a user logs out or a user session expires, make sure you call clearUser() so they are not associated with future actions.
Details

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.

Step 2: Fetch recommendations

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.

Details

See Quick starts for API integration steps and code snippets.

Step 3: Mitigate risk

There are different types of recommendations that you can get (see Recommendation types). If you receive a challenge or deny recommendation for the register action, you should use additional means such as ID verification or even an offline manual review.

Details

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 register action, 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 DEVICE_EMULATOR and DEVICE_SUSPICIOUS_ATTRIBUTE.

Step 4: Reduce friction

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.

Remember

The goal is to keep great customer experience, so reduce friction whenever you can in low-risk scenarios.

Next steps

Detect risk and protect against account takeover (learn more), as well as leverage our authentication and identity management capabilities for account protection scenarios: