Interpretation of KBA
Interpreting the results of a standard KBA verification.
Overview
Verification via KBA is represented at the top level by a policy decision (true for all transactions on the AXN). You can confidently engage business logic based on only the policy decision, but understanding the underlying outcomes at the assertion and component levels will enable you to engage in more nuanced business logic and help users troubleshoot.
Recommended Reading
You'll need to understand policy decisions and the process for finding and reviewing an individual transaction before attempting to analyze an individual transaction, which is what's covered here.
Assertions/Components
For standard KBA, the policy uses one component (level 1) which is based on three assertions. All of these assertions must pass for this level 1 component to pass.
| Description | Assertion Name | Component Name (Level 1) | Assertion, Component, Policy |
|---|---|---|---|
| Did the user answer all knowledge-based questions correctly? | test.KnowledgeBasedAuthentication | TEMPLATE: KBA | This assertion is required to Pass for the component to Pass; this component is required to Pass for the policy to Approve; any other outcome results in Deny (or Obligation depending on workflow). |
| Did the user pass velocity checks in terms of number of times questions have been generated and number of times questions have been unsuccessfully attempted? | test.velocity | TEMPLATE: KBA | This assertion is required to Pass for the component to Pass; this component is required to Pass for the policy to Approve; any other outcome results in Deny (or Obligation depending on workflow). |
| Was the user located by the vendor subsequently allowing velocity checks to be conducted and subsequently allowing questions to be generated? | test.discovery | TEMPLATE: KBA | This assertion is required to Pass for the component to Pass; this component is required to Pass for the policy to Approve; any other outcome results in Deny (or Obligation depending on workflow). |
Interpretation
An example of a user incorrectly answering any or all of the knowledge-based questions.
| Result | Explanation | Solution | |
|---|---|---|---|
| test.KnowledgeBasedAuthentication = Pass test.velocity = Pass test.discovery = Pass | The user correctly answered all knowledge-based questions. | N/A | |
| test.KnowledgeBasedAuthentication = Fail test.velocity = Pass test.discovery = Pass | The user incorrectly answered any or all of the knowledge-based questions. | This is indicative of user error or bad behavior; consider taking negative action against the user, allowing the user to retry, or stepping-up the user to another verification method. | |
| test.KnowledgeBasedAuthentication = Unverified test.velocity = Fail test.discovery = Pass | The user did not engage in knowledge-based questions because they could not be generated. The questions could not be generated because the user has either generated questions X times in Y hours or unsuccessfully attempted questions A times in B hours. | This is indicative of a user trying to generate questions they know the answers to and/or guessing when they don't, either out of human error or bad behavior; consider taking negative action against the user or stepping-up the user to another verification method. | |
| test.KnowledgeBasedAuthentication = Unverified test.velocity = Unverified test.discovery = Fail | The user did not engage in knowledge-based questions because they could not be generated. The questions could not be generated because the user could not be located and validated by the vendor. | This is generally related to a gap in data coverage or invalid PII; consider stepping-up the user to another verification method or allowing the user to retry (for the latter, if data can be corrected or a more established home address or phone number can be used). |
Transaction Events highlight each individual action taken during verification. Here you will find LexisNexis transaction IDs, LN specific failure codes, and their reasons.
| Transaction Event | Explanation |
|---|---|
| denial_cumulative_transaction_activity_frequency | User failed Velocity (pass or fail) |
| failed_iauth_questions | User failed Identity Questions |
| individual_not_located | User failed Discovery |
| identity_event | User triggered an Identity Event |
| transaction_expired | Transaction Expired |
| insufficient_info_for_questions | If test.discovery failed as well, then there was not enough information to find a profile for this user. If test.discovery passed, it's possible there were many individuals that match the provided PII and LexisNexis couldn't pick a person to generate questions for. |
| blocked | Too many attempts to generate questions without changing PII that was causing previous errors. |
Notes
A) KBA is unique in that a user must be discovered (test.discovery = Pass) in order to run velocity checks for that user (test.velocity) and both must Pass in order for questions to be generated (test.KnowledgeBasedAuthentication). This reduces the number of potential assertion payloads.
B) Velocity checks utilize a customizable "lookback" period and count function to determine if a user has generated or unsuccessfully attempted knowledge-based questions too many times. Standard KBA is configured in the following way:
- Test.velocity will Fail if a user has unsuccessfully attempted to answer questions more than 3 times in the past 7 days.
- Test.velocity will Fail if a user has generated questions more than 6 times in the past 7 days.
Updated about 1 month ago