...

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<FieldResultV5>`	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`	`2310111377PostOfficeDataV5`	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<2310111377NameValuePair>`	Any extra data associated with this check. As an example, an OCR Document may have 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 V2 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>

FieldResultV5

Name	Type	Description
`addressType`	`String`	Either `currentAddress` or `previousAddress`, depending on whether the address was nominated as their current or previous residential address at registration time. This field will only be present for fields that are address related fields.
`name`	`String`	The name of the field. The possible name will depend on the source used. Again which sources used will depend on the individual customer setup, and new sources, with potentially new fields are constantly being added. For a list of possible field names for each source, please refer to the Data Source Reference tables.
`status`	`String`	This member indicates the status of the field. Refer to the Reference Table for Field Status for possible values.
`value`	`String`	This member contains the original data that was supplied the time of registration, or the “master record”. In the case of a status of ADDITION (see the Reference Table of Field Status) then this will hold the added data.
`extraData`	`List<2310111377NameValuePair>`	Any extra data associated with this check.
`format`	`String`	This member indicates the format of the data in this field. This field will only be present for fields that are encrypted, in which case it will have the value `PGPEncrypted`.
`masterRecordValue`	`String`	This member is reserved for use with combination sources. It's use is discussed below.
`changedValue`	`String`	This member will contain changed values. That is, if a value was changed in order to become verified, then this member will contain the value that the data was changed to, and subsequently verified.
`extractedValue`	`String`	This member is reserved for use with combination sources. It's use is discussed below.

Regular data sources will have a list of FieldResultV3 elements that have the following elements populated:

name
status
value - if the value of the field was not changed for use with this data source.
changedValue - if the value of the field was changed for use with this data source, then the value field will not be present. Instead, the changedValue field will be present, and will contain the value that was used with this data source.
masterRecordValue - if the value of the field was changed for use with this data source, then the masterRecordValue is included to explicitly show the change that was made. The masterRecordValue field shows the value of the field from the master record, i.e. the value that was used when registering this verification attempt with greenID.

To illustrate the use of the value, changedValue and masterRecordValue elements, consider an example where the DoB field was not changed with respect to the master record. The DoB field would be represented by the XML snippet below:

Code Block
<fieldResult> <name>dob</name> <status>CONFIRMED</status> <value>1976-04-26</value> </fieldResult>

Now consider that the DoB was changed from 1/1/1980 on the master record to 1/4/1976 when using the data source, then the following XML snippet would be present:

Code Block
<fieldResult> <changedValue>1976-04-01</changedValue> <masterRecordValue>1980-01-01</masterRecordValue> <name>dob</name> <status>CHANGED</status> </fieldResult>

This scheme makes explicit every change that was made between the data used for the data source, and the master record.

The scheme becomes a little more complicated when combination sources are used. For a discussion of when the various elements of a combination source, please refer to the previous section about the 2310111377 CheckResultV5 type. The main thing to note in this section is which elements of the FieldResultV3 type are present in the different components comprising a combination source.

In the data extraction component of a combination source, the value field will be present if the status field has the value CONFIRMED, as in the example below.

Code Block
<fieldResult> <name>surname</name> <status>CONFIRMED</status> <value>Smith</value> </fieldResult>

If the value has been changed, and the status field has the value CHANGED, then the changedValue element will hold the value that the person altered, and the extractedValue element will contain the value that was automatically read from the ID document. For example, the XML below shows the FieldResultV3 element FieldResultV5 element when a person has changed the value that was read from the card from "Smith" to the value "Jones":

Code Block
<fieldResult> <changedValue>Jones</changedValue> <extractedValue>Smith</extractedValue> <name>surname</name> <status>CHANGED</status> </fieldResult>

In the document registration match component of a combination source, the value field will be present if the status field has the value CONFIRMED, as in the example below:

Code Block
<fieldResult> <name>surname</name> <status>CONFIRMED</status> <value>Smith</value> </fieldResult>

If the value has been changed, and the status field has the value CHANGED, then the changedValue element will hold the value value that the person altered, and the masterRecordValue element will contain the value that is associated with the master record. For example, the XML below shows the FieldResultV3 FieldResultV5 element when a person has a master record where their surname is recorded as "Smith", and the combination source has the surname "Jones" (the value could be different because the person used an identity document with the surname "Jones" on it, or changed the value to "Jones" when asked to confirm the data automatically read from the card):

Code Block
<fieldResult> <changedValue>Jones</changedValue> <masterRecordValue>Smith</masterRecordValue> <name>surname</name> <status>CHANGED</status> </fieldResult>

PostOfficeDataV5

The PostOfficeDataV5 complex type and the following members are for the most part exact representations of the fields found in an Australia Post contract. The reader should be aware of the individual Australia Post contract they will be using to ensure that they can match up the fields. These fields are retrieved from a flat file and stored in Strings with no interpretation of the meanings of the fields. Not all implementations of an Australia Post contract will have all the fields detailed below.

Member	Type	Description	Contract
`customerId`	`String`	This parameter is GreenID's identifier for the client application. The value is supplied by GreenID.	Not null. Max 255 chars.
`documents`	`String`	Human readable string that is a comma separated list of all the names of the documents used to verify this user.	Not null.
`header`	`2310111377DetailRecordHeader`	Representation of the header of the flat file received from Australia Post.	Not null.
`poFileName`	`String`	The name of the actual file read from Australia Post.	Not null. Max 255 chars.
`records`	`2310111377DocumentRecord[]`	List of individual representations of the documents used to verify this User	Not null.

DetailRecordHeader

The complex type DetailRecordHeader has the structure described below:

Member	Type	Description	Contract
`amount`	`String`	Unsigned amount in cents.	Max 255 chars.
`channelId`	`String`	0 = default	Max 255 chars.
`date`	`String`	ddmmyy (NOTE: system generated date with no slashes)	Max 255 chars.
`dateOfBirth`	`String`	ddmmyyyy represents the date of birth on the form that was checked.	Max 255 chars.
`filler`	`String`	Often there will be filler, it serves no purpose and should be ignored.	Max 255 chars.
`formVersion`	`String`	A-Z	Max 255 chars.
`givenName`	`String`	16 characters of the given name that was on the form that was checked.	Max 255 chars.
`id`	`Long`	Extra identifier that identifies this record. Not set by Australia Post.
`idWizardRefNo`	`String`		Max 255 chars.
`paymentMethod`	`String`	'00' = Cash/EFTPOS/Direct Debit, '01'-'09' = number of Cheques, '11' = VISA, '12 = MasterCard. Note: This may differ per contract, but in general the above applies.	Max 255 chars.
`phoneNo`	`String`	Phone number as entered on the form that was checked.	Max 255 chars.
`postOfficeName`	`String`	Presumably the name of the Post Office the form was checked at.	Max 255 chars.
`recordNo`	`String`	Seems to be fixed as ‘1’.	Max 255 chars.
`recordType`	`String`	Seems to be fixed as ‘5’.	Max 255 chars.
`referenceNo`	`String`	The reference number used to identify this user. Most often this will be the userId. It must be 16 characters or less.	Max 255 chars.
`surname`	`String`	20 characters of the surname that was on the form that was checked.	Max 255 chars.
`totalNumberOfIdDocument`	`String`	Number of documents used to verify this user.	Max 255 chars.
`typeCode`	`String`		Max 255 chars.
`uniqueReferenceNumber`	`String`	wwwwwwttnnnnn, first 6 digits are AP Work Centre Code.	Max 255 chars.

DocumentRecord

The DocumentRecord complex type has the structure described below:

Member	Type	Description	Contract
`amount`	`String`	Always zero.	Max 255 chars.
`comments`	`String`		Max 255 chars.
`countryOfIssue`	`String`	Name of country from the document if applicable.	Max 255 chars.
`dateOfBirthMatchesaForm`	`String`	Y = Yes, X = not applicable	Max 255 chars.
`documentExpiryDate`	`String`	dd/mm/yyyy; spaces if not applicable NOTE: (manually entered date with slashes)	Max 255 chars.
`documentName`	`String`	This is an automatic lookup to convert the idDocumentType member into a human readable document name.	Max 255 chars.
`documentNumber`	`String`	Alphanumeric, e.g., passport number.	Max 255 chars.
`filler`	`String`	Often there will be filler, it serves no purpose and should be ignored.	Max 255 chars.
`id`	`Long`	Extra identifier that identifies this record. Not set by Australia Post.
`idDocumentType`	`String`	Code number representing the document type. The lookup for the name is done automatically and stored in the documentName member.	Max 255 chars.
`idWizardRefNo`	`String`		Max 255 chars.
`issuedBy`	`String`	This may be present instead of country of Issue, stateOrTerritoryOfIssue, utilityAccountIssuer and utilityAccountType. It may selectively hold this information in a less rigid format.	Max 255 chars.
`issueDate`	`String`	dd/mm/yyyy; spaces if not applicable NOTE: (manually entered date with slashes) May not be present.	Max 255 chars.
`nameMatchesForm`	`String`	Y = Yes, X = not applicable	Max 255 chars.
`photoMatch`	`String`	Y = Yes, X = not applicable	Max 255 chars.
`recordNo`	`String`		Max 255 chars.
`recordType`	`String`		Max 255 chars.
`referenceNo`	`String`		Max 255 chars.
`residentialAddressMatchesForm`	`String`	Y = Yes, X = not applicable	Max 255 chars.
`stateOrTerritoryOfIssue`	`String`	ACT, QLD, NSW, NT, SA, TAS, VIC or WA.	Max 255 chars.
`utilityAccountIssuer`	`String`	If specifically a utility, then the name.	Max 255 chars.
`utilityAccountType`	`String`	01 = electricity, 02 = gas, 03 = water, 04 = telephone	Max 255 chars.

NameValuePair

The NameValuePair complex type has the following structure:

Member

Type

Required?

Description

Contract

name

String

No

This will identify the data that is stored in this pair.

Needs to match an agreed upon value and be unique in the list.

Max 255 chars.

value

String

No

The actual data being passed in this pair.

Max 255 chars.

gbgAlertV5

The gbgAlertV5 type contains the result of the GBG Alert evaluations.

Name	Type	Description
`overallAlertStatus`	`String`	The overall Alert Status for the registration. This is one of: NO_ALERT_RAISED - no configured Alert rules have been raised or there were alerts raised and locked, but an administrator has 'unlocked' them all ALERTS_RAISED - one or more configured Alert rules have been raised NOT_ATTEMPTED - Alert rules have not been checked. ERROR
`score`	`Decimal`	The score is currently a placeholder. The score will be populated as GBG Alert is enhanced.
`raisedAlerts`	`raisedAlertListV5 i.e. a` `List<raisedAlert>`	a list of '`raisedAlert'` elements, each of which describe an individual Alert rule that has been 'raised'
`extraData`	`List<NameValuePair>`	Allows for extra information about the overall alert results to be returned if required in future.

raisedAlertV5

Name	Type
`alertRule`	`String`	The name/code of the Alert rule that was raised/triggered, for example "Rule A2".
`description`	`String`	A text description of the Alert rule. This will be the same description as shown on the admin panel for the rule.
`firstRaised`	`String`	The timestamp of when this Alert rule was first raised. date:ISO8601_DATETIME_FORMAT e.g. 2023-08-16T23:11:51.544+1000
`multipleInstances`	`Boolean`	Indicates whether this rule has been raised more than once for this verification (true/false)
`alertRuleStatus`	`String`	Indicates the status of the Alert rule. Possible values: UNLOCKED - rule was previously raised but has been unlocked by an admin. LOCKED - rule has been raised and currently the verification is in a locked out state. RAISED (this will be used when there is no lock out status since customer not using locking for Alerts)
`extraData`	`List<NameValuePair>`	Allows for extra information about the raised alert (alert rule) to be returned if required in future

NameValuePair (i.e. used in extraData)

Name	Type	Description
`name`	String	The name of the additional information item we want to provide
`value`	String	The content/value of the additional information item

Version	Old Version 21	New Version 22
Changes made by	Sharmeen Hussain	Sharmeen Hussain
Saved on	Feb 04, 2024	Feb 04, 2024

Versions Compared

Key

FieldResultV5

PostOfficeDataV5

DetailRecordHeader

DocumentRecord

NameValuePair

gbgAlertV5

raisedAlertV5

NameValuePair (i.e. used in extraData)

Content Comparison

Versions Compared

Key

FieldResultV5

PostOfficeDataV5

DetailRecordHeader

DocumentRecord

NameValuePair

gbgAlertV5

raisedAlertV5

NameValuePair (i.e. used in extraData)