The Process Result Object

Suggest Edits

The ProcessResultObject (PRO) stores the generic results of a process (check, scan, compare, verify, etc), and contains the fields outlined below.

PROs used throughout the various sections in the KYC results are found here. The following is a general guide as to how the fields are used:

checkId:

This is the Frankie internal identifier for a given check run against an entity

checkType:

The type of check performed by the service, it will be one or more of the following:

  • document
  • entity
  • address
  • name
  • dob
  • gender
  • email
  • mobile
  • device
  • biometric

resultState:

Check state for an individual data point.

  • UNCHECKED: Check has not yet been performed.
  • NOT_SUPPORTED: the requested check type or industry function is not supported by a connector that processed this request
  • CHECKING: Checks are underway. Unlikely to be seen in a final set of results.
  • UNPROCESSABLE: The data supplied was unprocessable. Check the resultNotes (see below) for more information.
  • NO_MATCH: All checks complete, no records found that matched the details supplied.
  • CHECKED_PARTIAL_SUCCESS: All checks are complete, but only some succeeded. Check the resultNotes (see below) for more information
  • CHECKED_SUCCESS_WITH_NOTES: All checks are complete, and more information to give the result context have been provided.
  • CHECKED_SUCCESS_CLEAR: All checks are complete, no additional special notes that impact the result (some may still be provided).
  • CHECKED_FAILED: Checks complete, but failed.

resultNotes:

An array of Key Value Pairs to store notes and details around the result. There can literally be thousands of different combinations of keys, and normally you will not be expected to process these (the FrankieOne service will though).

The KVPs will provide additional information around specific field matches, service response information, or detailed data for a given result.

For those details that require more attention, we've detailed those specifically in the various guides.

checkDate:

The RFC3399 formatted date-timestamp that this check was performed.

confidenceLevel:

Confidence in the result on a scale of 0 (no match) to 100 (strong/identical match). Whole integers only.

  • < 40 if the results are highly ambiguous and probably not a match. Defaults to 0 rather than 40 if at all in doubt.
  • 41-70 if the results are partial matches.
  • 70-90 for results where there might be a small amount of uncertainty.
  • 90+ for high levels of confidence.

NOTE: This score is not perfectly reliable and should not be used out of context.

riskLevel:

Generally supplied in a summary result, although some services will return a score.

In this case a higher score is a bad thing. General rule of thumb:

  • 0 - 35 = Low Risk
  • 35 - 50 = Medium Risk
  • 50 - 70 = High Risk
  • 70+ = Unacceptable Risk

checkPerformedBy:

Service provider that performed the check.

checkSource:

Where possible, the source name of the data. This might be something like “DVS” or “aust_claims_database” or other source.

providerCheckID:

A service provider will usually give a receipt number/transactionId/check number, or equivalent that gives a unique id on their side that cannot be reconciled with.

In the cases where FrankieOne is to supply an identifier, we'll use one of the following, using the most appropriate for the provider in question:

  • Our Check ID
  • Entity ID (or Doc ID) - This would be used if checks against the same entity or doc later can be re-used.
  • RequestID (if uniqueness is needed for every request).

Updated 5 months ago