Check Results - Summaries
The CheckEntityCheckResultObject has a number of summary sections that are available.
The entityProfileResults section (see above), provides a detailed overview of the results based off the recipe assigned to the entity. This is only present where entity profiles/recipes are in use (strongly recommended for all API users).
A still relevant, but being phased out section, is the checkSummary which is the pre-cursor to the above entityProfileResults. It’s still useful for those API users still running individual checks, rather than recipes.
And lastly, there is a collection of individual check summaries, one for each time the service has run the /entity/verify API endpoint in reverse chronological order.
Understanding CheckSummary results
The individual checkTypes are being phased out
Unless there is a specific reason to not do so, please move to using Entity Profiles, rather than running individual checks..
The following section details how to interpret the results of a /verify check on an entity.
Whenever a check is performed upon an entity, a summary record is returned as part of the response data. This is found in the checkSummary object and represents the sum total of information about this entity and all previous relevant checks.
If you’re just after the results of the latest check, look for the most recent summary record in the `checkSummaries` list.
As part of the primary summary object, there is an array of typed Key-Value Pairs called CheckResults.
In there, we will return any specific flags or data that we think might be useful for the developer to take immediate action on, rather than having to dig through the individual results.
The kvpKey is generally made up of 2 parts: <Level>.<Flag>
<Level> is designed to indicate the level of importance of the flag. Valid values are:
- Info - Flag is purely informational.
- Issue - Flag is highlighting something that’s a potential issue.
- Important - Flag is indicating something we feel is Important and requires potential intervention.
- Action - Flag indicates a recommended action.
- Fail.Reason - Why the entity is currently in a failed state.
- Review.Reason - Why the entity is currently marked as REFER.
<Flag> is the name of the flag and is generally self-explanatory (see notes below).
The kvpType is one of the enumerated KVP types found in our OpenAPI specification. We’ve translated that to a more readable form here.
kvpKey | kvpType | kvpValues | Notes |
|---|---|---|---|
Recommended Disposition | |||
Action.Recommended | String | One of: PASS PASS_MANUAL REFER FAIL FAIL_MANUAL UNCHECKED | Recommended action to take, based on risk, confidence, and all other
data. The _MANUAL suffix on pass/fail indicate that manual intervention
was required to make the entity pass/fail. UNCHECKED means that no checks have been attempted against this
entity as yet. |
Failure / Refer Reason Indicators | |||
Fail.Reason.* | String | The * can include: Risk NoMatch Duplicate Blacklist Partial Sanction PEP Fraud FraudList Device | The * in the kvpKey will give a single word indicator of the primary
failure reason. The kvpValue will give a short note on why. |
Review.Reason.* | The * can include: PEP Media Risk Fraud Device | The * in the kvpKey will give a single word indicator of the primary
referral reason. The kvpValue will give a short note on why. | |
Info.ManualChanges | Integer | 1+ | If there have been manual interventions on this account, indicate
how many |
portal.issue.summary | String | Comma separated list of issues | Issue codes are: 404: No match 500: Service error PTL: Partial match only PEP: PEP match S: Sanctions match WL: AML Watchlist match M: Adverse Media match FRAUD: Fraud list or check match DUP: Duplicate BL: Blacklist ATT: No IDV data ATT-IDV: ID Validation failed ATT-PHT: Photo comparison failed ATT-OCR: OCR scanned document was modified FRAUD: Fraud list match DEVICE: There was a device-fraud related issue |
Biometrics Related Notes | |||
Fail.Reason.AttestationFailed.* | String | The kvpValue will give a short note on why it failed | When any of the Biometrics reports get rejected/ failed, you will
get this KVP in the response which gives you the reasons. The * can
include: MissingDocs: Missing documents PHT: Photo Comparison OCR: OCR Comparison FACE: Facial Duplicate IDV: ID Validation |
Important.AttestationFailed.* | String | true | When any of the Biometrics reports get rejected/ failed, you will
get this KVP in the response which tells you there’s an important
issue. The * can include: MissingDocs: Missing documents PHT: Photo Comparison OCR: OCR Comparison FACE: Facial Duplicate IDV: ID Validation |
Review.Reason.Attestation | String | The kvpValue will give a short reason on why it needs review | When actioned recommended is “REFER”, and there’s a potential issue
about any of the Biometrics reports, you will get this KVP in the
response so that you can review. |
Info.AttestationMessage | String | The kvpValue will give some info on the potential warnings and
issues | When none of the Biometrics reports are rejected, but there’s a
warning or suspicious, you will get this KVP in the response. |
PEP/Sanctions Related Notes | |||
Issue.HasAdverseMedia | Boolean | True/false | Adverse media was picked up during the check. Only included if true |
Issue.IsPEP | Boolean | True/False | Entity appears on at least one PEP list Only included if true |
Important.HasSanctions | Boolean | True/false | Entity appears on at least one sanctions list Only included if true |
Issue.OnWatchlist | Boolean | True/false | Entity appears on at least one watchlist Only included if true |
Confidence Score Related Notes | |||
Important.VERY_LOW_CONFIDENCE | Boolean | True/false | The confidence score is considered to be very low Only included if true |
Issue.LOW_CONFIDENCE | Boolean | True/false | Confidence levels in the result are considered low Only included if true |
Matching Statistics | |||
Info.MissingChecks | String | Comma separated list of checkTypes that haven’t yet completed. | This will indicate which of the checks you requested haven’t
completed successfully. Inclusion of “two_plus” or “one_plus” indicates that
name/DoB/address checks haven’t passed. “id” indicates that no ID checks have passed. “pep” or “pep_media”
indicate that you requested AML check hasn’t been run. |
Info.NameMatchCount | Integer | 0 or more | The number of times we matched the name provided |
Info.AddressMatchCount | Integer | 0 or more | The number of times we matched the address provided |
Info.DoBMatchCount | Integer | 0 or more | The number of times we matched the date of birth provided |
Info.GovIDMatchCount | Integer | 0 or more | The number of supplied documents we succeeded in verifying |
Info.OtherIDMatchCount | Integer | 0 or more | If Other IDs were matched (e.g. email, mobile, etc) then that count
appears here. |
Info.ManualMatchCount | Integer | 1 or more | Only included if Manual KYC process used. Provides the number of
documents used to pass KYC |
Info.ManualKYCMessage | string | Manual KYC details | Lists the matching documents used to pass a manually verified KYC
check |
Important.Blacklisted | Boolean | True/false | Indicates if the entity in question was found on the internal
Blacklist. Only included if true |
Important.Whitelisted | Boolean | True/false | Indicates if the entity in question was found on the internal
Whitelist. Only included if true |
Important.Duplicate | Boolean | True/False | Indicates if the entity in question is potentially a duplicate. |
Important.CreditBureauMatch.XXX | Boolean | True/False | Indicates a match/fail with a credit header source that may require
notification be sent to the customer. If set to true, the match was successful If set to false, the match failed and the customer may need to be
notified of this fact. The XXX would be replaced with the reporting bureau. Valid values
are:
It’s possible for there to be more than one of these, depending on
how your failover/cascade works. |
Risk Score Related Notes | |||
Risk.Level | String | One of:LOW MEDIUM HIGH UNACCEPTABLE | Gives the risk rating for the entity at this time |
Risk.Policy | String | Customer specific, but defaults nclude SDD EDD Fail | The configured risk checking policy that was applied |
Important.VERY_HIGH_RISK | Boolean | True/false | Risk score is considered very high (over 75) Only included if true |
Issue.HIGH_RISK | Boolean | True/false | Risk score is considered High (over 50) Only included if true |
Issue.MEDIUM_RISK | Boolean | True/false | Risk Score is considered Medium (over 30) Only included if true |
Example check summaries
Biometrics
- Biometrics overall FAIL, with OCR and Document report as suspected, but photo comparison rejected:
- Biometrics overall FAIL, with all the reports as suspected:
- Biometrics overall REFER, with OCR report as suspected, but Document report and Photo comparison as clear:
Interpreting CheckSummary results
This method is being phased out
The following section details how to interpret the results of a /verify check on an entity when the checkType details are specified in full (rather than just using the “profile” option).
Unless there is a specific reason to not do so, please move to using Entity Profiles, rather than running individual checks..
Following on from the article about the contents of a checkSummary
The CheckSummary is formerly the main place to look to determine the current state of an entity,
(It still can be used, but a better service exists from the more structured response in the checkEntityResults section of a response.
The summary resultState is the first field to check. Although the API documentation gives an accurate description of the various states, there are a large number of subtleties that can creep in given the vast array of potential check results possible. With that in mind, the following is a guide to reading the response.
Check state for an individual data point
UNCHECKED: Check hasn’t yet been performed.NOT_SUPPORTED: The requested check type or industry function isn’t supported by this connector.CHECKING: Checks are underway.UNPROCESSABLE: The data supplied was unprocessable.NO_MATCH: All checks were complete as far as possible, no records were found that matched the details supplied. No AML checks would have been run.CHECKED_PARTIAL_SUCCESS: Indicates that we were able to partially match an entity, but not all checks completed.CHECKED_SUCCESS_WITH_NOTES: All checks are complete, but there are some notes (e.g. PEP or sanctions).CHECKED_SUCCESS_CLEAR: All checks are complete, enough details were verified and cleared to ensure that this person meets your KYC/AML requirements. No additional action is required.CHECKED_FAILED: Some checks were attempted, but there was a hard failure along the way and we’ve had to stop.
You should always look to the `Action.Recommended` KVP flag for a final recommended disposition, especially for **CHECKED_PARTIAL_SUCCESS** and **CHECKED_SUCCESS_WITH_NOTES**, just to be sure.
If you receive an Action.Recommended of FAIL or FAIL_MANUAL, you should look at the following:
- KVP
Fail.Reason.*- that will give a basic indication as to why the entity failed. - KVP
portal.issue.summary- this gives a quick indicator of issues that need attention. - KVP
Info.*MatchCount- that will tell you how many items matched - use this for partial failures. - KVP
Important.HasSantions- the individual is marked as sanctioned - you should use the portal to verify these results and set to false or true positive. - KVP
Important.Duplicate- the individual has been marked as a duplicate. Use the portal tools to confirm or mark as a false positive. - KVP
Important.Blacklist- the individual has been marked as blacklisted. Use the portal tools to confirm or mark as a false positive.
When the Action.Recommended is “REFER”, you should look at:
- KVP `Review.Reason.* and KVP portal.issue.summary - as above, these give a brief description of the issues that need addressing.
- KVP `Risk.Level - the entity might just be too high a risk.
- KVPs
Issue.IsPEP,Issue.OnWatchlist,Issue.HasMedia- indicates that the entity has potential AML issues that need review via the portal.