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
Send key user events
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:
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.
Scenario | Recommended Actions |
Account is taken over |
|
Account is restored |
|
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!