Account Reputation

Overview

Account Reputation is an attribute-based evaluation service that helps prevent abuse by tracking how often a user credential (such as an email or user ID) has been observed in transaction attempts. Based on configurable thresholds, the service can enforce denials or additional checks for users who exceed allowed limits, protecting against account enumeration, credential stuffing, and other forms of automated abuse.

Core Functionality

• Credential Monitoring: The service monitors usage of identity credentials across account opening, login, and other transactions.
• Threshold Enforcement: If a credential is used more than a configured number of times within a defined interval, access can be denied or additional authentication enforced.
• Cross-Channel Protection: Activity observed on the web can inform IVR (call center) flows, enhancing multi-channel fraud detection.

Policy Components

To implement Account Reputation in your policy, use the following components:

• ✅ Account Reputation (1 approve)
• ❌ Account Reputation (3 denies)

These components allow you to approve or deny access based on how many times a credential has appeared in past transactions.

Example Policy Logic

This means:

ℹ️

Deny a user only if they’ve failed 3 times or passed once. Otherwise, approve or obligate

Configuration Requirements

1. Add Attribute Provider

Ensure the Account Reputation attribute provider is added to your service configuration.

2. Time Window (historyInterval)

Configure the lookback window for evaluations using the historyInterval setting.

• Location: General > Advanced > General Properties
• Unit: Seconds

This setting defines how far back the system should check for previous decisions involving the same credential.

Credential Mapping

To fully leverage Account Reputation:

• Enable tracking by email address
• Ensure credential-to-email mapping is active

This ensures credentials like usernames or opaque IDs are associated with an identifiable email.

Account Reputation via. API

(POST) https://api.preprod.iddataweb.com/v1/slverify

API Reference: https://docs.iddataweb.com/reference/slverify

Country Selection typically represents the first step in most IDDataWeb workflows. While your specific use case may vary, the general approach remains consistent.

To begin evaluating a user’s account reputation, use the first API key in your workflow to make an /slverify request. This request can check the user's selected country + PII, and assesses whether their credential has been seen more than the allowed number of times—using Account Reputation logic—to determine if the session should proceed

Request

var data = {
	"apikey": "Your API Key",
    "credential": "e.g. : [email protected]", // The user will be denied if '[email protected]' has been seen 3 (deny) or 1 (approve) times.
    "appID":"Your App Name, (e.g. 'Employee Onboarding App')",
    "userAttributes": [
        {
            "attributeType": "Country",
            "values": {
                "country": "US" // accepted values: (country codes) e.g. "US", "MX", "AU" ....
            }
        }
    ]
}

var axios = require('axios')
var token = 'YOUR_BEARER_TOKEN' // -- obtained from step 1 --

var request = async () => {
  var response = await axios({
    url: 'https://api.preprod.iddataweb.com/v1/slverify',
    method: 'post',
    data: data,
    headers: {
      'Content-Type': 'application/json',
      'Cache-Control': 'no-cache',
      Authorization: 'Bearer ' + token,
    }
  })
	console.log(response.data)
}
request();

Response

{
    "errorCode": "",
    "errorDescription": "",
    "transaction_id": "f8e1af39-80b2-4e8a-8cfd-8a7cc0f10b49",
    "userAttributes": null,
    "acquiredAttributes": [
        {
            "provider": "IDDataWeb",
            "serviceOffering": "Account Reputation",
            "attributeType": "TransactionHistory",
            "dateCreated": "02/10/2023 19:56:14",
            "values": {
                "policyApprovalCount": "0",
                "policyNoDecisionCount": "2",
                "policyRejectionCount": "0",
                "policyObligationCount": "0",
                "riskyTransctionCount" : "0"
                "verificationTransactionCount": "2"
                "transactionCount": "2"
            }
        }
    ],
    "userAssertionList": null,
    "mbun": "bfd0e06b-842e-468a-aaa6-6080a030f975",
    "forwardApiKey": "",
    "policyObligation": false,
    "policyDecision": "obligation"

Resulting Behavior

• A credential seen more than N times within the history interval can be denied.
• Because ID DataWeb-issued OIDC links can be reused, Account Reputation can enforce a soft block to prevent repeat abuse.
• Reputation results are available to policy decisioning in real time.

Technical Behavior

Upon each policy invocation:

• The system tallies prior policy outcomes over the configured time window for the credential in question.

Example Use Case: Call Center

• A user credential is flagged due to repeated failed attempts on the web.
• That same credential is then detected in an IVR flow.
• Based on its Account Reputation, the system flags it as under attack, and the user is prompted for extra verification before proceeding.

Summary

For further support or questions, contact your ID DataWeb representative or consult the service configuration documentation.