The Process Result Object

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

You'll find PROs used throughout the various sections in the KYC results. The follow is a general guide as to how the fields are used.


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


The type of check performed by the service
Will be one or more of the following:

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


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 complete, but only some succeeded. Check the resultNotes (see below) for more information
  • CHECKED_SUCCESS_WITH_NOTES: All checks complete, and more information to give the result context have been provided.
  • CHECKED_SUCCESS_CLEAR: All checks complete, no additional special notes that impact on the result (some may still be provided).
  • CHECKED_FAILED: Checks complete, but failed.


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 your attention, we've detailed those specifically in the various guides.


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


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. Default to 0 rather than 40 if at all in doubt.
  • 41-70 if the results are partial matches. Use your judgement and common sense to come up with a useful number
  • 70-90 for results where there might be a small amount of uncertainty, but we’re pretty confident they’re for the right person/document.
  • 90+ for high levels of confidence.

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


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


Service provider that performed the check.


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


A service provider will usually give us a receipt number / transaction id / check number, or equivalent that gives us a unique id on their side that we can reconcile with.

In the cases where FrankieOne are the ones 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) - we'll use this if we can re-use checks against the same entity or doc later.
  • RequestID (if uniqueness is needed every request)

Did this page help you?