Precise ID Settings

Below is a matrix of your PID settings which will give a little more insight into how Precise ID score and the percentage of correct answers plays into the decisioning. PID score in the first vertical column is a score given based on information provided and the first horizontal row is the percentage of questions answered correctly. ACC will be accept (pass) and REF/DEC will be a refer/decline (fail).

There are also overrides which result in a REF/DEC which automatically fail. 9012 victim alert, FS5, FS13, FS14.

These settings are configurable once in production but these are the recommended settings. If you would like to change your production PID settings you can do so by contacting FSSuppot@experian.com. We have seen a good setting for 9012 is ACC for 70 and above, which means they would have to answer 70% of the questions correct to pass. If you do not want to change your settings, then you would need to alert the user they cannot use your application without first removing the fraud alert. You can direct them to the Experian Fraud center to do so https://www.experian.com/fraud/center.html

PIDScore /KIQ Score	0-9	10-19	20-29	30-39	40-49	50-59	60-69	70-79	80-89	90-99	100-100%
1-299	REF	REF	REF	REF	REF	REF	ACC	ACC	ACC	ACC	ACC
300-364	REF	REF	REF	REF	REF	ACC	ACC	ACC	ACC	ACC	ACC
365-429	REF	REF	REF	REF	ACC	ACC	ACC	ACC	ACC	ACC	ACC
430-489	REF	REF	REF	REF	ACC	ACC	ACC	ACC	ACC	ACC	ACC
490-529	REF	REF	REF	REF	ACC	ACC	ACC	ACC	ACC	ACC	ACC
530-569	REF	REF	REF	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC
570-624	REF	REF	REF	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC
625-679	REF	REF	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC
680-754	REF	REF	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC
755-999	REF	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC	ACC
9012-9012	REF	REF	REF	REF	REF	REF	REF	REF	REF	REF	ACC

Fraud Shield 5 (FS5) – Inquiry SSN recorded as deceased
Fraud Shield 13 (FS13) – High probability SSN belongs to another
Fraud Shield 14 (FS14) – SSN format is invalid

Below is a breakdown of exclusion codes and use limits that will also prevent users from authenticating.

9001

In the case of 9001 the user will not be able to authenticate because the SSN provided was considered deceased. Your application can either alert the user they cannot use your system or ask the user to review their SSN and try to resubmit. Below is what will be returned but I have only included key parts of the response for reference. We do provide test cases to validate this scenario in staging (PENNY S BOYCE - 676 - 9001 DECEASED SSN - BK - COLLACCT - MEDICAL PAYMENT DATA.pdf)

Key take aways: No questions returned and cannot pass authentication

{
  "preciseIDServer": {  <— Precise ID response segment
…………………..
"Summary": {
      "ReviewReferenceID": "3077043",
      "PreciseIDType": "11",
      "PreciseIDScore": "9001",
      "PreciseIDScorecard": "9001 Default        ",
      "ValidationScore": "009001",
      "ValidationScorecard": "9001 Default        ",
      "VerificationScore": "009001",
      "VerificationScorecard": "9001 Default        ",
      "ComplianceIndicator": "",
      "ComplianceDescription": "No Compliance Code  ",
      "FPDScore": "009001",
      "FPDScorecard": "9001 Default  
…………………..
  "Reasons": {
          "Reason1": {
            "value": "Deceased",
            "code": "B502"
          },
…………………..
 "error": {  <— API response segment (ONLY A TRANSLATION: CODE TO THE preciseIDServer RESPONSE)
    "Message": "Consumer reported as deceased",
    "Code": "3901",
    "Status": 402,
    "FieldErrors": null
  },
  "success": false <— Success segment (If false check preciseIDServer segment for details “Summary” and/or “Rules")
}

9013

In the case of 9013 the user will not be able to authenticate because consumer has placed a block or freeze on their credit profile. Your application can either alert the user they cannot use your system and/or alert the user they must remove the block/freeze to use your system. (https://www.experian.com/freeze/center.html) Below is what will be returned but I have only included key parts of the response for reference.

Key take aways: No questions or data returned and cannot pass authentication

{
"preciseIDServer": { <— Precise ID response segment
…………………..
"Summary": {
"ReviewReferenceID": "3077048",
"PreciseIDType": "11",
"PreciseIDScore": "9013",
"PreciseIDScorecard": "",
"ValidationScore": "9013",
"ValidationScorecard": "",
"VerificationScore": "9013",
"VerificationScorecard": "",
"ComplianceIndicator": "",
"ComplianceDescription": "No Compliance Code ",
"FPDScore": "9013",
"FPDScorecard": "",
…………………..
"Reasons": {
"Reason1": {
"value": “Not Supplied",

…………………..
"error": { <— API response segment (ONLY A TRANSLATION: CODE TO THE preciseIDServer RESPONSE)
"Message": "Blocked or Frozen file",
"Code": "3913",
"Status": 402,
"FieldErrors": null
},
"success": false <— Success segment (If false check preciseIDServer segment for details “Summary” and/or “Rules")
}

9012

In STAGING with the case of 9012 the user will not be able to authenticate because default Precise ID settings has a decision override set to REF/DEC (decline). This can be changed in your production environment however if you do not change it users will not be able to pass authentication. Below is a sample matrix(last line item) if a user is a 9012 scenario they must answer 100% of the questions correct to pass authentication since ACC (accept) is set at 100%.

--INSERT MATRIX--

Key take aways: In STAGING the user will always fail authentication due to REF setting, however in your production this can be changed. Questions will be returned in both cases but decision override score will take precedence only in your production environment. In the above example, if a user does not answer 100% correct they will not be issued a token and the response will be a “success": false after submitting the answers.

{
"preciseIDServer": { <— Precise ID response segment
…………………..
"Messages": {
"ConsumerStatement": [
{
"Number": "06",
"Text": "06 12-22-13 3999999 ID FRAUD VICTIM ALERT: FRAUDULENT APPLICATIONS MAY BE SUBMITTED IN MY NAME OR MY IDENTITY MAY HAVE BEEN USED WITHOUT MY CONSENT TO FRAUDULENTLY OBTAIN GOODS OR SERVICES. DO NOT EXTEND CREDIT WITHOUT FIRST CONTACTING ME PERSONALLY AND VERIFYING ALL APPLICATION INFORMATION AT DAY 555-555-5555 OR EVENING 555-555-5555. THIS VICTIM ALERT WILL BE MAINTAINED FOR SEVEN YEARS BEGINNING 09-22-13."
}
],
"Message": {
"Number": "57",
"Text": "015000 0200",
"AddrMismatch": "N"
}
},
"Summary": {
"ReviewReferenceID": "3077050",
"PreciseIDType": "11",
"PreciseIDScore": "9012",
"PreciseIDScorecard": "9012 Default ",
"ValidationScore": "009012",
"ValidationScorecard": "9012 Default ",
"VerificationScore": "009012",
"VerificationScorecard": "9012 Default ",
"ComplianceIndicator": "",
"ComplianceDescription": "No Compliance Code ",
"FPDScore": "009012",
"FPDScorecard": "9012 Default ",
"UtilityFunction": "00007030",
"InitialResults": {
"AuthenticationIndex": "0005",
"MostLikelyFraudType": {
"value": "Exclusion",
"code": "EXC"
},
"Reasons": {
"Reason1": {
"value": "Victim Statement found on file",
"code": "B503"
},
…………………..
"QuestionSet": [
{
"QuestionType": 26,
"QuestionText": "Which of the following is the highest level of education you have completed? If there is not a matched educational level, please select 'NONE OF THE ABOVE'.",
"QuestionSelect": {
"QuestionChoice": [
"HIGH SCHOOL DIPLOMA",
"SOME COLLEGE",
"BACHELOR DEGREE",
"GRADUATE DEGREE",
"NONE OF THE ABOVE/DOES NOT APPLY"
]
}
},
…………………..
"authSession": "ODdjZmViYWUtMjJkNi00OTk4LWEwOTQtOWU0ZGYzZTJkM2I5",
"error": null,
"success": true
}

---

USE LIMITS

Experian will not block attempts to authenticate at anytime. This is up to your application to block the user from re-trying authentication once they become locked due to failed attempts or based on whatever business rules you have in place. As a fraud measure Precise ID does allow you to have settings to lock users out from being able to pass authentication but DOES NOT BLOCK THE REQUEST.

This means if a user has exceeded use limits then questions will not be returned. In STAGING the defaults are removed to avoid blocking test cases however, when you first went into production your default settings were 3 failed attempts in a 72 hour time frame would result in a lock and that user would have to wait for 72 hours to try to authenticate again. If your application allowed the user to re-submit before the 72 hour period passed the clock would start over again.

DEFAULT RECOMMENDED SETTINGS

Client Use Limit (PIN Based) - Period (hrs)

72 = Time period for failed and attempts and lock out period

Client Use Limit (PIN Based) - Count

3 = Number of failed attempts then locked

In the JSON response after submitting the answers to the questions, the KBAScore segment is where details of the attempts will be returned. In the sample below this would be if the default settings were in place and the user exceeded use limits.

……………..
"KBAScore": {
"General": {
"KBAResultCode": 2,
"KBAResultCodeDescription": "No questions returned due to excessive use",
"PriorUsage": {
"ExceededUseLimitCode": “Y”,<— “Y" means yes they have exceeded use limits, block the user from retrying
"ConsumerTotal": “3",<— Is the number of failed attempts already attempted
"ClientUseLimitPeriod": 72,<— Is how long they need to wait in hours before retrying
"ClientUseLimitCount": 3,
"TotalUseLimitPeriod": 72,
"TotalUseLimitCount": 0,
"ConsumerSSNTotal": "0",
"ClientSSNUseLimitPeriod": 720,
"ClientSSNUseLimitCount": 99,
"TotalSSNUseLimitPeriod": 720,
"TotalSSNUseLimitCount": 0,
"ConcurrentPINTotal": 0,
"ClientConcurrentPINLimitCount": "0",
"CompanyConcurrentPINLimitCount": "0",
"GlobalConcurrentPINLimitCount": "0"
}
………………

One caveat to be aware of is that any request to the /ECP2P/api/user end-point that successfully reached PID will count towards the ConsumerTotal. This means if the user abandons the sessions (typical when they do not know the answers right away) it will count towards the total failed attempts. Since the session was abandoned a count will not be returned so it may be a good idea to keep track of abandonments.