Account Protection on Kount 360 is used to prevent login, new account creation, and takeover fraud. Integrating this service allows you to block fake account sign-ups, prevent customers from abusing promotions, and stop card testing at the zero dollar authorization stage. Account Protection uses the following tools to prevent fraud:
-
Device, email, phone, and address insights
-
AI and machine learning
-
Reporting and analytics
-
Customized policy management
Integrating with Account Protection requires the following:
After integration, you can implement webhook notifications to receive alerts for specific events, like verification status updates.
The Device Data Collector gathers information from a customer’s device by running client-side scripts and then sending that data to Equifax. This passive analysis conceals the Kount 360 interaction with the customer and does not affect the customer’s experience.
The flow for device data collection follows this pattern:
-
Generate Session ID: Generates a session ID and provides it to the Device Data Collector SDK.
-
Device Data Collector SDK collects and sends device data: The Device Data Collector sends the collected device data to Kount 360.
-
Submit event data with session ID to your server: When the event data (the order, login, or new account opening data) gets submitted to your server, include the session ID that was passed to the Device Data Collector.
-
Send event data with session ID to Kount 360: Pass the session ID in the call to Kount 360, along with the rest of the event data.
-
Associate device data and event data by matching the session ID: Kount 360 associates the device data and the event data by using the session ID that was passed to Kount 360.
For detailed instructions, use our guided Device Data Collector Content generator or follow the steps in the Native iOS and Android SDKs article.
Placement and configuration of the browser Device Data Collector is important for gathering information to identify devices, adhere to business policies, and accurately define sign in risk.
Place the Device Data Collector code in the body of the sign-in page. Kount reduces collection from the same session ID when a collection comes within 15 minutes. We recommend that you run a single data collection per session. When multiple collections are run in a single session — if the collection was placed in the header — it is possible the collection events can be mistaken as a DDOS attack, throttling all collections from your site.
The Google Chrome Lazy Load feature defers loading images and iFrames that come below the end of the page. This feature is active when the Chrome Data Saver feature is on and when the loading attribute is set to auto or unset. If you are using the Kount legacy data collector that uses an iFrame, update integration or set the loading attribute to eager, which bypasses lazy loading functionality.
Kount uses both third-party and first-party cookies as well as device data to identify devices. In order to take full advantage of the Device Data Collector, you can make modifications to the Content Security Policy on your site. For more information, go to Content Security Policies (CSP) and the Device Data Collector.
In Kount 360, after you have activated your organization, you can generate API keys to send data securely to Equifax. Only users with the Owner role permissions can generate, delete, or edit API keys.
Caution
You must have an initialized client before you can create an API key.
-
Sign in to Kount 360.
There are two integration environments: sandbox and production. Only integrate into our sandbox environment if you are integrating a pre-production environment without production data for testing.
-
Select Admin, and then Product Configuration.
-
In System Settings, select API Keys.
All initialized clients display.
-
For the client you want to create an API key, select Generate API Key.
The new API key is generated. A prompt displays with the ability to copy the API key and add a description.
-
Copy the API key, and then store it in a secure location.
Note
The API key is not provided again. You must store it in a secure location for future reference. If the API key is compromised or lost, create a new API key and delete the compromised one.
-
Enter a description detailing the store used for the API key, and then select Confirm.
API keys are organized under each client on the API Keys page. Expand the client to view your API keys, the descriptions, and when client details were created.
The login workflow begins with data collection from the browser application or from the mobile SDK.
When the end user logs in with valid credentials, you make a POST to the Login API to get a response with guidance Allow, Block, or Challenge.
Go to Login API help for more information.
https://api.kount.com/login/v2
The Events API is a set of endpoints used to communicate specific outcomes that occur during your end user's authentication process. You must use the Failed Attempt and Challenge Outcome API endpoints to:
-
Report a failed login attempt when a user provides incorrect credentials.
-
Communicate the success or failure outcome of a challenge, such as Multi-factor Authentication (MFA), Step-Up Authentication, or One-Time Passcode (OTP) verification presented to an end user.
The Failed Attempt endpoint is called to report a login attempt that failed when the end user provides incorrect or invalid credentials.
When the end user attempts to log in and provides wrong credentials, you must call the Failed Attempt endpoint to notify Kount 360 that a failed attempt event has occurred as part of your authentication flow.
Refer to Failed Attempt API help for more information.
https://api.kount.com/events/failed-attempt
The challenge outcome endpoint is used to report the result of a guidance challenge, such as Multi-factor Authentication (MFA), Step-Up authentication, or One-Time Passcode (OTP) verification presented to an end user during the login process.
When the end user receives a challenge and completes MFA process, call the Challenge Outcome API to update Kount 360 with the final success or failure outcome of the challenge.
Refer to Challenge Outcome API help for more information.
https://api.kount.com/events/challenge-outcome
A request sent to Kount that creates a trusted device record for the specified user and the device associated with the session.
Go to Trusted Device API help for more information.
https://api.kount.com/trusted-device
When you receive a guidance challenge from the Login Abuse API response for an end user and multi-factor authentication (MFA) request is sent to their phone or email, the Secure MFA endpoint is used to check the status of the MFA sent to the end user.
Go to Secure MFA API help for more information.
https://api.kount.com/secure-mfa
The Account Creation Abuse endpoint uses the session ID created by the customer for the Device Data Collector.
An account creation request sent to the New Account Opening API that triggers an evaluation of customer-defined policies. The API then returns a guidance of Allow, Block, or Challenge based on those policies.
Go to New Account Opening API help for more information.
https://api.kount.com/newaccountopening/v2
The Account Change Protection API is triggered when an end user's account information (email address, first and last name, phone number, billing and shipping address) is changed.
When an end-user changes their personal account information (for example, changes to first and last name, email address, phone number, or billing and shipping address), it can be an indicator of either legitimate updates or potential fraud.
The Account Change endpoint allows users to send both old and new values, triggering our risk evaluation to:
-
Analyze behavioral velocity patterns (how frequently data is changed).
-
Evaluate cross-field affiliation between fields using AI models (does the new phone number align with the new address and name patterns).
Go to Account Change help for API specifications.
https://api.kount.com/accountchange
After you have provisioned your API credentials in the portal, retrieve a temporary bearer token to authenticate calls to the Kount 360 API. Provide the API key in an HTTP POST to a specific login.equifax.com URL.
With a successful exchange, the returned JSON provides a special bearer token, which is the access_token property. The exchange also provides an expiration date, the expires_in property, provided in seconds until expiration. The API to retrieve the bearer token depends on if you are calling the sandbox or production environment.
The values are:
Sandbox
Auth Server URL:
https://login-uat.equifax.com/as/token
API Service Host:
https://api-sandbox.kount.com
Production
Auth Server URL:
https://login.equifax.com/as/token
API Service Host:
https://api.kount.com
After obtaining the bearer token, use it to authenticate requests to the Kount 360 API. Include the token in the Authorization header of your HTTP API request, prefixed with Bearer {bearer token}.
To prevent authentication issues, refresh the token before it expires. Tokens issued by login.equifax.com expire after 20 minutes, but client credentials remain valid unless revoked. Minimize calls to the /token endpoint by implementing token expiration handling in your customer applications. Always check if a token has expired before requesting a new one, as excessive calls to the /token endpoint could result in rate limiting.
The process begins with data collection from the browser application or from the mobile SDK. The Kount browser data collector is a JavaScript SDK downloaded at runtime. Our mobile SDK can be integrated into your mobile application. Only one data collection should be made per session.
After your end user’s sign-in credentials have been posted to your authentication service, there are two ways to respond:
-
Valid Credentials — If your end user presented valid credentials, you POST to the Kount Login API prior to granting access. The response to this API call is Allow, Block, or Challenge. Depending on the response and based on your policies, you can either allow access, deny access, or challenge your end user by using the Kount MFA or your existing step-up authentication.
-
Invalid Credentials — If your end user fails authentication, you decline access and POST to the Failed Attempt API.
The Trusted Device Service might store a trust relationship between a device and a specific user.
Users employ a small handful of devices to sign in, such as a cell phone, work laptop, and home computer. By identifying these devices for specific users, the customer can reduce friction at sign in by using policies to only challenge users with a device that is not already known and trusted.
Example 3. Trusted Device Example
You create a policy to challenge a sign in coming from an end user with a device that is not previously trusted for that end user. Jane signs in using her new cell phone. Because this cell phone is not trusted for her, the response from the Kount Login Event API is Challenge.
You ask Jane to perform a step-up authentication, such as asking her to input a code sent to her from a text message. She succeeds, and is able to sign in to her account. You then send an update to Kount to trust this device for Jane. Kount stores this trust relationship so the next time Jane signs in with this device, she will not be asked for step-up authentication.
There are several purpose-built endpoints available with the Trusted Device Service.
-
Create Trusted Device Record: Used after an end user has met a step-up challenge and you would like to store the trust state of the device for that user.
-
Update Trusted Device Record: Used to alter the trust state between a device and an end user. Options include trusted or banned. Typically, this is to ensure that a specific end user cannot sign in using a specific device.
-
Read Trust States: The option to review information for all users connected to a device, all devices connected to an end user, or the trust state for a specific user/device pair. They can be used to identify an end user before the end user has signed in to the site. They can also be used to display a list of trusted devices specific to the end user.
-
Delete Trusted Device Record: Used to delete the record of a relationship between an end user’s ID and a device. Deletion is used when there is a limited number of devices that can be used for a specific account and the end user wants to replace one device for a new one.
When an end-user changes their personal account information (for example, changes to first and last name, email address, phone number, or billing and shipping address), it can be an indicator of either legitimate updates or potential fraud.
When a user attempts to update their account information—such as their name, address, email, or phone number—our system performs a comprehensive analysis to determine the risk level of the change.
Key features of Account Change include:
-
Advanced affiliation checks: Analyzes the logical relationship between the old and new PII to differentiate low-risk changes (like domain switch) from high-risk, radical changes.
-
Velocity monitoring: Tracks the speed and frequency of changes (both to single fields or multiple fields at once) to identify rapid, automated attack patterns.
-
Device and network checks: Verifies the connection trustworthiness by flagging change attempts made from unfamiliar devices, high-risk IP addresses, or unusual locations.
Example 4. Account Change use case example
If a user attempts to change their shipping address, our system will analyze whether the new address is a known "mail drop" or is associated with other suspicious activities. We can also cross-reference the new information with the user's existing PII to look for logical connections. If there is a disconnect, the system flags the transaction for further review.
With Account Change, you can prevent Account Takeover (ATO) fraud, credit card fraud, new account fraud, and synthetic identity fraud.