Fraud scores are calculated independently for each evaluation using the data provider’s proprietary risk model. As a result, the same person may receive different scores across applications or transactions when the submitted information or underlying risk signals differ.
For example, workflows can use LexisNexis data to determine address matches and other identity verification metrics, and using Ekata data for address matches and fraud risk scoring. These differences arise due to the unique methodologies of each provider.
Common reasons for score differences
Differences may result from changes in:
Phone number, including how often it has been associated with the individual, phone-number validation, or correlation.
Address information, such as ZIP code or city.
Other identity, device, behavioral, or transaction details included in the evaluation.
The different data available to the provider at the time each evaluation was processed.
Even small changes in submitted information can affect individual risk components and the overall fraud score. Fraud scores, such as Ekata’s identity check score, are often informational and not used for automated decisions by default. However, they can be incorporated into decision logic if a strong correlation with fraud is observed.
When scores return null
Fraud scores may return null in the following scenarios:
Invalid Input PII: The provider requires valid personal identifiable information (PII) like phone, email, or address. If all submitted PII is invalid, scores cannot be calculated.
CCPA/GDPR Deletion Requests: If an individual has requested data deletion under privacy laws, their PII is suppressed, resulting in null scores.
Model Timeouts: Rarely, a timeout during score calculation may occur. Rerunning the request often resolves this issue.
How to investigate score variation
When comparing evaluations:
Compare the input fields submitted for each evaluation.
Review the individual risk components returned by the data provider.
Look for differences in phone validation, phone correlation, and address information.
Review the reason codes returned with each evaluation. Reason codes can help identify the specific factors or signals that contributed to the score.
Use Alloy’s Rule Explainability feature to review the underlying logic for a tag and what contributed to a given tag being set.
Different scores do not necessarily indicate an error. If the evaluations contained different inputs or were processed at different times, score variation may be expected.
Configuring rules based on fraud scores
To tailor fraud detection workflows, you can set up rules based on fraud scores. For instance, if you want to route applications with high Ekata fraud scores to manual review:
Create a tag, such as "Ekata High Score Review."
Configure the rule to apply this tag when the Ekata score exceeds a specific threshold (e.g., 440).
Set the workflow to route applications with this tag to manual review instead of auto-approval or denial. Note: High-risk scores from other providers, like LexisNexis, may already trigger auto-denial. Use separate tags for different outcomes.