Page Comparison

...

Name	Type	Description
`name`	`String`	The name of the check. For example, if a check against the Electoral Roll was attempted, then the name would be “AEC”. As each customer will accept a different set of checks, customers should refer to their individual rules document for the list of names that they can expect. Refer to Data Source Reference for a list of data source names.
`state`	`String`	The state of the individual check. For a list of possible states, please see the Reference Table of Individual Source States.
`method`	`String`	The method via which the check was carried out. This is an enumerated type, for a list of possible values, please see the Reference Table of Method Names.
`mode`	`String`	The verification mode used for this specific check. This shows HOW the check was made. Please see the Reference Table of possible modes. This can be `null` which indicates that no mode was used.
`dateVerified`	`String`	The date that this particular check became verified (or null if the check is not verified). The string will be formatted in the ISO 8601 format. The pattern used to generate this string in Java is `yyyy-MM-dd'T'HH:mm:ss.SSSZ`.
`fieldResult`	`List<60369636>`	Only the fields that were successfully checked, or were changed, are returned. Any field that was not checked is not returned. Note that this may mean the list is empty.
`postOfficeData`	`60369636`	If and only if the name of the `CheckResultV3` is “PostOffice” then this member will be present. Otherwise it will be null. This represents the raw data retrieved from Australia Post.
`extraData`	`List<60369636>`	Any extra data associated with this check. An OCR Document may have an a key value pair named "origin" whose value indicates the channel that the OCR Document was completed on. Possible values include: greenID Mobile V1, greenID Mobile V1 and greenID Web.
`individualResult`	`List<CheckResultV3>`	A list of nested `CheckResultV3` objects, which are used for representing combination sources. A combination source has five nested elements, each of which will have a corresponding `CheckResultV3` object in this list. Those five elements are: document authenticity, data extraction, data source, facial recognition match, and comparison to the master record. These elements are discussed in detail below.
`documentType`	`String`	The category the document belongs to. Common values are: DRIVERS_LICENCE PASSPORT NATIONAL_ID_CARD Extra document types will be used as necessary, and if they apply to you, greenID will provide details about the appropriate values.
`documentRegion`	`String`	The region or country the document is associated with. The ISO alpha2 country designation is used.
`documentSubRegion`	`String`	Some document depend on the state or region within the country that issued them. For example, in Australia, each state issues their own driver's licences, so the state must be included to accurately identify the ID document.
`faceMatchScore`	`String`	A string representation of a number that reflects the confidence score that the selfie matches the image extracted from the ID document. The range of valid numbers is 0 to 100.

Combination sources, as the name suggests, combine multiple things into a single source. Combination sources are used when the greenID Mobile SDK captures an identity document for verification. A combination source will always have the following three components present:

document authenticity - this component represents the outcome of the automated authenticity and integrity checks that are performed on the image of the document to ensure it is an authentic document, and has not been subject to digital tampering.
data extraction - this component represents the data that was automatically extracted from the card, and how it relates to the data that the person confirmed.
document registration match - this component represents the comparison between the details that the person confirmed and the master record.

An example of an XML snippet for the document authenticity component is below, showing an Australian ACT driver's licence that was deemed authentic, indicated by the VERIFIED state:

Code Block

<individualResult>
   <documentRegion>AU</documentRegion>
   <documentSubRegion>ACT</documentSubRegion>
   <documentType>DRIVERS_LICENCE</documentType>
   <method>interactive</method>
   <name>Document Authenticity</name>
   <state>VERIFIED</state>
</individualResult>

Components initially in a pending state have the option of being reviewed; during this process the administrator is required to give a comment on the review. These comments can be returned in the API if configured. The XML captures the comment, the date and time it was made, and the email address of the administrator making the change. An example of the XML that was verified by an administrator is seen below:

Code Block

<individualResult>
    <dateVerified>2018-12-04T10:31:28.440+1000</dateVerified>
    <fieldResult>
        <data>Ive uploaded a picture of a big beer can</data>
        <extraData>
            <name>Date</name>
            <value>2018-12-04 10:31:28.44</value>
        </extraData>
        <extraData>
            <name>AdminEmail</name>
            <value>admin@edentiti.com</value>
        </extraData>
        <name>AdminComment</name>
    </fieldResult>
    <method>interactive</method>
    <name>Telephone Bill</name>
    <state>VERIFIED_ADMIN</state>
</individualResult>

When a document image is captured by the greenID Mobile SDK, the person has the chance to review the data that was automatically extracted from the image to correct any errors that the OCR process might have made. The results of the OCR process and the so-called "confirmed data" are compared to see how well the OCR process performed, and how many changes the person had to make. If no changes were made, then the data extraction component will be in the VERIFIED state, as in the example below:

Code Block

<individualResult>
   <fieldResult>
      <name>GovId</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>documentNumber</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>surname</name>
      <status>CONFIRMED</status>
      <value>Smith</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <method>interactive</method>
   <name>Data Extraction</name>
   <state>VERIFIED</state>
</individualResult>

The comparison between the data that was read during OCR and the confirmed data is subject to the greenID controlled changes process. If the changed made by the person are automatically accepted by the controlled changes process, then the data extraction component can have the VERIFIED_WITH_CHANGES state. If the changes are too large, then the data extraction component can be in the PENDING state, as in the example below where the person changed their surname:

Code Block

<individualResult>
   <fieldResult>
      <name>GovId</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>documentNumber</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <changedValue>Jones</changedValue>
      <extractedValue>Smith</extractedValue>
      <name>surname</name>
      <status>CHANGED</status>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <method>interactive</method>
   <name>Data Extraction</name>
   <state>PENDING</state>
</individualResult>

As with regular data sources in greenID, a comparison is made between the data used to check the data source and the master record. Combination sources are the same in this regard. When a person confirms the details extracted from their ID document, with or without changes, the "confirmed data" is compared to the master record, and the changes are subject to the greenID controlled changes process. (The confirmed data may also be used with an external data source, depending on customer account configuration.) The document registration match component reflects this comparison. The XML snippet below shows a document registration match component where no data was changed by the person during the confirmation step:

Code Block

<individualResult>
   <dateVerified>2017-01-19T11:37:11.796+0000</dateVerified>
   <fieldResult>
      <name>documentScan</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>face</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <fieldResult>
      <name>surname</name>
      <status>CONFIRMED</status>
      <value>Smith</value>
   </fieldResult>
   <method>interactive</method>
   <name>Document Registration Match</name>
   <state>VERIFIED</state>
</individualResult>

Of course, the person may make changes during the confirmation step, and if these changes are too large, the document registration match component can be in the PENDING state, as in the example below where the person changed their surname:

Code Block

<individualResult>
   <fieldResult>
      <name>documentScan</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>face</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <fieldResult>
      <changedValue>Jones</changedValue>
      <masterRecordValue>Smith</masterRecordValue>
      <name>surname</name>
      <status>CHANGED</status>
   </fieldResult>
   <method>interactive</method>
   <name>Document Registration Match</name>
   <state>PENDING</state>
</individualResult>

There are two more components to a combination source that may appear, depending on customer account configuration:

data source - an external data source that can verify the data read from the document, for example, the government department that issues passports.
face comparison - a comparison between the image of a person extracted from an identity document, such as a passport, and a live selfie of the person captured by the greenID Mobile SDK.

If the data source element is present, then the name of the data source and state of the check will be present, for example, the snippet below shows the data source associated with Australian passports was checked and passed:

Code Block
<individualResult> <method>interactive</method> <name>PassportDVS</name> <state>VERIFIED</state> </individualResult>

The face comparison component will only be present if face comparisons are configured on the customer's account. If present, the face match score and the state of the face comparison will be present, for example:

Code Block
<individualResult> <faceMatchScore>55</faceMatchScore> <method>interactive</method> <name>Face Comparison</name> <state>VERIFIED</state> </individualResult>

FieldResultV3

...

Versions Compared

Old Version 34

New Version 35

Key

FieldResultV3