Use Case

This guide helps companies identify suspicious logins and protect users from having their account hijacked, thus preventing loss of funds, content abuse, and other types of fraud caused by account takeover.

Sending data to Sift

Send user activity

• JavaScript
• Mobile SDKs

Send key user events

• $login
• $security_notification
• $verification
• $create_account
• $update_account

User attempts a login

When there is a login attempt – whether successful or failed – send a $login event. Here are guidelines for sending the $login event:

• $user_id : send when the email/username exists in your system
• $ip : always send when you have it
• $session_id : always send
• $browser : send for all non-native-mobile-app login requests
• $app : send for all native mobile app login requests
• $login_status : this defines whether the username + password combination was correct. It does not define whether or not the attempt failed or succeeded any other internal checks you may perform

User asked to verify a login attempt or other account activity

Verification is a blocking event: once sent, the respective activity (login or another) cannot proceed until with the verification is successfully completed. When a user is asked to verify a login attempt or account activity (e.g., initiating a transaction), send one $verification event when the verification is sent with a $pending status and one more $verification event the final status (i.e., $success or $failure).

User is notified of a login attempt or other account activity

A security notification is an informative, rather than blocking, event: the account can be used as usual after a notification is sent, unless the user follows up to mark the account as compromised. When a user is notified of a login attempt or account activity (e.g., initiating a transaction), send one $security_notification event when the notification is sent with a $sent status and one more $security_notification event the final status (i.e., $safe or $compromised).

User creates an account

When a user creates an account, send a $create_account event. You can include custom fields to capture any additional fields collected on signup.

User updates account information

When a user updates their account information send an $update_account event. The $update_account call captures changes such as password changes, payment and billing changes, and changes to name or email. You only need to send what information has changed.

Send use-case specific user events

Send additional events in order 1) capture known fraud patterns specific to your business or 2) create policies at points outside of a login. Here are some examples:

User content & messages

If users can create content – e.g. listings, profiles, postings, rentals, etc. – or send messages to other users, send the following events:

• $create_content
• $update_content
• $flag_content

Orders

If users can purchase items or services, send the following events:

• $create_order when a user buys an item or service
• $transaction for a payment gateway interaction

Deposits / Transfers / Withdrawls

If users can deposit, send, or withdraw funds or points, send the following events:

• $transaction

Send business decisions

You will need to inform Sift which accounts and sessions have been identified as compromised through Decisions. Decisions can be applied manually via the Sift Console or programmatically through the Decisions API. ATO Decisions need to be applied at both the user and session level.

When manually reviewing for ATO, fraud analysts should mark incidents of account takeover in the Sift Console using a “Compromised Account” Decision and flag the compromised login(s). Once the account is restored apply an “Account Recovered” Decision. You can connect Decisions made in the Sift to your backend by following this tutorial.

Get started with Sift Scores

One of the key strengths of the Sift Trust Platform is that it consistently learns as you send more data to it. You will see an increase in score accuracy during the first weeks as you send more Decisions and user events. During this stage, you should assess your Sift Scores in the Sift Console and determine which actions to take for different score thresholds. Since all businesses are different, finding a score threshold that achieves your business goals is key. The two metrics we recommend analyzing for score thresholds are 1) Fraud caught and 2) Verification rate.

Build your business logic with Sift Scores

Now that you are sending both user events and business decisions to Sift, you’re ready to start using Sift Scores in your business logic. Higher Sift Scores correlate to higher risk. Based on the Sift Score, you’ll set up different outcomes within your application (e.g., user with low score is allowed to proceed).

To build this logic, you'll want to evaluate a user's Sift Score at the key events where bad users can hurt your business or good users should have a more frictionless experience. Note: currently ATO Scores can only be returned in response to a $login event.

For higher risk logins, you may want to do one or more of the following:

• Send an email notification to the user that there is a login from a new device or location. These emails should include a means for your user to let you know it was not them.
• Send a one time passcode via SMS, email, or app that a user must enter after login to verify themselves.
• Restrict access to sensitive information (e.g. bank info, user details) or limit account actions in the same session (e.g. changing payment information, changing shipping address, withdrawing money, etc) until the user verifies the login.

When you send a login event for a successful login, Sift will return the Sift Score in the response. There are two ways to receive Sift Scores:

Create a Sift Workflow (recommended): Workflows allow you to automate your Decisions without putting business logic in your code. With Workflows a business manager can use the Console and set up criteria to evaluate when a specified event occurs. These criteria route users to different outcomes based on Sift Score and other attributes of the user (e.g. User is from Canada and Sift Score is greater than 80). With Sift Workflows, the response will specify what Decision to take. A user can also be put into a Sift Review Queue for investigation. To learn more, see our Workflows tutorial.

Build logic in your application:You can synchronously request the Sift Score of a user. To receive a score in the response of a login event, append "return_score=true" to the endpoint of the $login API call. Here’s a link to more information on receiving risk scores synchronously with events. Upon receiving the Sift Score, you can decide what further action is required.

Any questions? Contact our support engineers. We're happy to talk it through!