Identity Proofing in Kount 360 uses a collection of data and verification methods, like real-time policy configuration, case management, and business intelligence analytics, that can be organized into custom workflows to identify fraud and verify consumer identities during any part of the user journey.
With Identity Proofing, you have the ability to configure strategies that organize active and passive verification checks, apply fraud and business information, and branch workflows to achieve desired outcomes during different stages.
Before you can integrate with Identity Proofing, you must have:
-
A Kount 360 organization ID (provided by your Customer Success Manager)
-
A client ID
-
Admin permissions
-
Strategy templates (these are created internally by Equifax)
A successful integration with Identity Proofing requires the following:
To integrate Identity Proofing into your systems, you will need to configure several components within Kount 360. Some settings are required — like strategies — while others are optional and help tailor the integration to your needs. This section outlines what is what is essential to get started.
Strategies
Strategies define the verification checks and step-up methods used in Identity Proofing workflows. At least one strategy template must be created internally before you can configure a strategy. The strategy name is referenced in the Assessment API to determine which workflow to apply. For more information, go to Strategies in Identity Proofing.
Rejection Codes
Rejection codes are used when an agent or an update API closes a case that is in Review or Challenge. When sending an Update API with rejection codes, they are validated against the Rejection Code not the Rejection Code Name.
-
Color
You can open the color selection menu and select a color for each rejection code. This color is visible when a rejection code is selected.
-
Rejection Code
An assigned alphanumeric code. This code is used when the Update API is invoked and a rejection code is included. The rejection code cannot be edited after creation.
-
Rejection Code Name
This is the title for the rejection code. The character limit is 255 and can be edited.
-
Sort Order
You can sort the rejection codes by dragging and dropping them. The sort order is the order rejection codes will display in the selection menus when a fraud agent wants to choose a rejection code.
For more information, go to Rejection Codes in Identity Proofing.
Queue Manager
Queues can be created to segment cases in Case Management. Cases can be assigned to a queue by:
-
Creating a trigger to auto-assign the case based on policy logic. For more information, go to Creating, Editing, and Deleting Triggers in the Queue Manager.
-
Manually assigning the case in Case Details. For more information, go to Manually Reviewing a Case.
-
Assigning the case to a queue with the Update API.
When a case is updated with the Update API and the queue is passed in the request body, it is validated against the queues created in the Queue Manager.
The Device Data Collector gathers information from a customer’s device by running client-side scripts and then sending that data to Kount. 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 been invited to an organization and your client is initialized, you can generate API keys to securely send data to Kount. You must have an initialized client before you can create an API key.
Note
Only users with the Owner role permissions can generate, delete, or edit API keys.
-
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.
-
Select Admin, then Product Configuration.
-
In System Settings, select API Keys.
All initialized clients display.
-
For the client you want to create an API key for, 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 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 the compromised one.
-
Enter a description, 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 they were created.
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 and client ID in an HTTP POST to a specific login.kount.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.kount.com/oauth2/ausdppkujzCPQuIrY357/v1/token?grant_type=client_credentials&scope=k1_integration_api
API Service Host:
https://api-sandbox.kount.com
Production
Auth Server URL:
https://login.kount.com/oauth2/ausdppksgrbyM0abp357/v1/token?grant_type=client_credentials&scope=k1_integration_api
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.kount.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.
Examples of retrieving and using the bearer token in popular programming languages:
This is the API endpoint required to integrate with Identity Proofing in order to submit new inquiries for assessment and to create cases. The Assessment API request requires a strategy, which is created in Admin > Identity Proofing > Strategies.
Note
The strategy used in the strategy field in the API request must match the name of the strategy created in Kount 360.
The authenticationId is passed in the body of the response and is used to reference any subsequent updates to this event. The response body can be verbose or non-verbose. This mode is set internally at the time of template creation.
The inquiryId is a value passed in the body of the response and should be a unique identifier. Both the inquiryId and authenticationId are required for the Update API.
For more information, go to Assessment API help.
Sandbox:
https://api-sandbox.kount.com/business/identity-proofing/v1/assess
Production:
https://api.kount.com/business/identity-proofing/v1/assess
When an end user completes a step-up notification and step-ups are being processed customer-side, call this API to update the case status. The authenticationId is passed in the response body of the original Assessment API call. The authenticationId and inquiryId is used to identify which case to update.
The Update API can be used to update cases when any process outside of Kount 360 requires a case update. Some examples might include:
-
Customers working with a call center and Customer Relationship Management (CRM) to update a case
-
Third-party integrations to manage a case
-
Making a call to Kount 360 to update a case
For more information, go to Update API help.
Sandbox:
https://api-sandbox.kount.com/business/identity-proofing/v1/update
Production:
https://api.kount.com/business/identity-proofing/v1/update
A webhook is a callback function that securely enables your workflows to receive events as they occur over HTTP. When an event happens in Kount 360, for example the fraud assessment status of an order is updated, we provide your webhook registration with a payload containing information about the event.
To implement a webhook, you must:
-
Create a webhook by providing the URL to the API endpoint and selecting the events you want to be notified about. Refer to Managing Webhooks.
-
Get the public key provided in the Kount 360 portal to verify the authenticity of the events received. Kount creates an RSA 4096 key pair. The private key is used by Kount to sign the message and the public key is available to you for verifying the signature of events that your server receives.
When a fraud agent changes the decision of a Identity Proofing case to Allow, Deny, or opens a case that is closed and webhooks are implemented, a webhook is sent to the customer to update the case status.