Data Structures V5


API Versions

This documentation relates to Version 5, the current version of the greenID API. Version 5 became available to customers as of .

CurrentStatusV5

The CurrentStatusV5 object is the sole return type of all the web methods in the API.  It is intended to provide information about what has just happened, as well as giving an overview of the person’s current verification status, and the list of data sources that will help the person become fully verified.  Always presenting this information helps to reduce the chattiness between greenID and the customer application.


Name

Type

Description

sourceList

SourceListV5

This member contains a list of SourceV3 objects, each of which corresponds to a data source that is available to the person for the purpose of becoming fully verified.  The setFields web method expects one of these names as the sourceId input parameter.

verificationResult

Data Structures V5#VerificationResultV5

This member contains all of the verification information currently available for a person.  It is a complete record of all checks that have been performed, their results, and an indicator of the person’s overall verification status.

sourceFields

SourceFields

This member contains a list of fields that are required for a particular data source.  This includes the field’s name, type and other pertinent information for displaying and collecting a value for the field.

checkResultLastCheckResultV5This member indicates the outcome of a check against a data source that was performed during a call to the setFields web method.  This member also indicates whether the check is still in progress.
verificationTokenStringThis field is for future features in the API, and can be ignored for now.

LastCheckResultV5

The LastCheckResultV5 object is intended to give a snapshot of the status of a check that has been performed during a call to the setFields web method.


Name

Type

Description

stillWorking

boolean

This member indicates whether the check is still in progress.  This feature is still under development; currently the value is always false.

state

String

This member gives the current state of the check.  Refer to the Reference Table for Individual Source States for valid values.

SourceListV5


Name

Type

Description

sources

List<SourceV5>

Simply a list of SourceV5 objects.

SourceV5

Name

Type

Description

state

String

This member reflects the current state of the source.  The valid values are the same as the state member of the Data Structures V5#CheckResultV5 object.  If a source has not been used, then this member will be “EMPTY”.

passed

boolean

This member indicates whether this source has been passed, i.e. the check is in one of the verified states.

name

String

This member is the name of the data source.  This name is expected to be used to refer to this data source in calls to the setFields web method.

availablebooleanThis member indicates whether this data source is currently available; sometimes a particular data source may not be available.
notRequiredbooleanThis member indicates whether this data source can help a person become fully verified.  If the value is true, then there is no point using this data source because it cannot help the person become fully verified.
oneSourceLeftbooleanThis member indicates whether completing this data source will make a person fully verified.  This member is very valuable because it indicates which sources should be attempted first, thereby shortening the verification process.
orderintThe order in which the source would be displayed if it were being displayed by greenID.  Sources that are more likely to result in the person becoming fully verified are at the top of the list, i.e. their “order” number is lower.
attributes

List<Data Structures V5#NameValuePair>

This member contains a list of HTML attributes that should be applied to any HTML input collecting input from a person.  For example, the HTML attribute “class=’required’” would be represented by a Data Structures V5#NameValuePair with name=”class” and value=”required”.

SourceFieldsV5


Name

Type

Description

fieldList

FieldListV3

This member contains a list of fields that are required for a particular data source.  The members of list represent HTML fields for collecting input from the person.

rawDataStringThis member contains an HTML fragment that, if displayed, will present HTML fields for collecting data from a person in order to perform a check against a data source.  Some customer may prefer this approach rather than generating their own HTML from the data contained in the fieldList member.

FieldListV5


Name

Type

Description

sourceField

List<Data Structures V5#FieldV5>

This member simply contains a list of Data Structures V5#FieldV5 objects.

FieldV5


Name

Type

Description

type

String

The type of HTML input that is required (at least strongly suggested) for collecting the data for this field from the person.  For example, a value of “text” would indicate a simple HTML text input is appropriate.

name

String

The name of the HTML input that would collect data for this field from the person.  The name also indicates what the data field is, for example, the value “aec_givenname” indicates the field holds the given name for the AEC data source.

value

String

This member contains any pre-existing value for the HTML field.  For example, the FieldV3 with the name aec_givenname will be pre-populated with the person’s given name (derived from the person’s master record established during the call to the registerVerification web method) the first time the getFields method is called with the sourceId aec.

labelStringThis member contains label.  Please refer to the section on Labels.
selectItemList<Data Structures V5#NameValuePair> This member contains a list of item names and values for a select item FieldV3.
attributeList<Data Structures V5#NameValuePair>This member contains a list of the names and values of any HTML attributes that this Field has.  For example, the attribute class=”required” would be represented by a Data Structures V5#NameValuePair with name=”class” and value=”required”.

InputFields


Name

Type

Description

input

List<Data Structures V5#NameValuePair>

This member contains a list of names and values that correspond to input parameters to the setFields web method.  The names are expected to be those that have previously been returned from the getFields method for a particular data source.  For example, a visa number will be represented by a Data Structures V5#NameValuePair with name=”visa_number” and value=”11111111”.

DateOfBirth

This type is a convenience type for holding a partial date, especially useful for representing dates of birth.  This type holds just the date part, and does not contain any reference to a time component or timezone; this avoids potential issues with date of birth timestamps arising from different timezones.


Name

Type

Description

day

int

The day component of a date of birth.

month

int

The month component of a date of birth.

year

int

The full year component of a date of birth, for example 1975, i.e. not 75.

RegistrationDetailsV5


NameTypeDescriptionContract
currentResidentialAddressData Structures V5#AddressThe person's current residential address.
dateCreatedStringThe timestamp of when this verification attempt was created. 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.
dobData Structures V5#DateOfBirthThe person's date of birth.
emailStringThe person's email address.May be null. Must be a valid email address following the Standard Hibernate validation and checking Top Level Domain (TLD) is valid. See https://data.iana.org/TLD/tlds-alpha-by-domain.txt
extraDataList<Data Structures V5#NameValuePair> Any extra data elements that were supplied with the original registration. Identifier such as document numbers will not be present in the list, even if they were supplied at registration time.Zero or more elements.
homePhoneString
If present, must be 10 digits only.
mobilePhoneString
If present, must be 10 digits only.
nameData Structures V5#NameThe person's name.
previousResidentialAddressData Structures V5#AddressThe person's previous residential address.
workPhoneString
If present, must be 10 digits only.

Address

The Address object is intended to serve as a container for address information for countries with a variety of different address schemes and formats.  The fields that are present or required will depend on the country that is specified.  Similarly, fields may have different validation rules depending on the country, for example, the field "postcode" must be a four digit string for an Australian address, but it must be a five digit string for a US address.  For requirements for individual countries, please refer to Address Handling or contact greenID.

NameTypeDescriptionContract
alleyString

amalgamatedMunicipalityString

areaString


avenueString


blockString


cantonString


chomeString


cityString


countryString
The country code. This must be the ISO 3166 country code. The country code can be given in either the alpha-2, alpha-3 or numeric format.Please refer to https://www.iso.org/obp/ui/#search for a full (and up to date) list of ISO 3166 country codes.
countyString


deliveryNumberString


departmentString


directionString


dispatchingInformationString


districtString


divisionFiveString


divisionFourString


divisionOneString


divisionThreeString


divisionTwoString


flatNumberString


levelString


localityString


locationString


mailCentreString


municipalityString


neighbourhoodString


organisationString


parishString


personNameString


poBoxString


postcodeString


prefectureString


propertyNameString


provinceString


quarterString


regionString


ruralAreaString


ruralLocalityString


sectorString


sectorNumberString


stateString


streetNameString


streetNumberString


streetTypeString


subdistrictString


subregionString


suburbString


townString


townCityString


townshipString


urbanLocalityString


villageString


Name

The Name complex type has the following structure: 

Member

Type

Required?

Description

Contract

honorific

String

No

The honorific component of a person’s name, e.g., “Mr”, “Miss”, etc.

Max 255 characters. 

givenName

String

Yes

A person’s given name.

Cannot be null. Cannot be the empty string.

Max 255 characters.

middleNames

String

No

A person’s middle names. Note that there can be multiple names.

 Max 255 characters.

surname

String

Yes

A person’s surname or last name.

Cannot be null. Cannot be the empty string.

Max 255 characters.

Regarding Email Addresses

Standard Hibernate validation is used to check email addresses are well formed.  The full regular expression used is:


^[^-^(^)^<^>^@^,^(;^:^^"^.^[^]^s]+(.[^-^(^)^<^>^@^,^(;^:^^"^.^[^]^s]+)*@([^-^(^)^<^>^@^,^(;^:^^"^.^[^]^s]+(.[^-^(^)^<^>^@^,^(;^:^^"^.^[^]^s]+)*|[[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}])$

Or more simply, the following symbols are used:

ATOM = ^[^-^(^)^<^>^@^,^(;^:^^"^.^[^]^s]  
DOMAIN = “(" + ATOM + "+(." + ATOM + "+)*”  
IP_DOMAIN = “[[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}])”


 And the final regular expression is a combination of those symbols:

"^" + ATOM + "+(\\." + ATOM + "+)*@"
 + DOMAIN
 + "|"
 + IP_DOMAIN
 + ")$"

VerificationResultV5

The VerificationResultV5 type describes the person’s verification results to date.  This is always returned so that the caller always has the latest results for that person.


Name

Type

Description

overallVerificationStatus

String

This member indicates the outcome of the entire verification process. Refer to the Reference Table for Overall Outcome States for values.

ruleIdStringThe identifier for the rule that was used to determine the verification outcome.
modeStringThis member indicates the verification mode that was used.  The mode is null, except in the following cases:
  • “POSTOFFICE” – the person was verified by completing a Post Office form and visiting a branch of Australia Post, where their identity documents were manually inspected.
  • “ASSISTED” – the person was verified by an administrative user.
  • “EXTERNAL” – the person was verified outside of greenID, and the results have been loaded in to greenID.
dateVerifiedStringThe date this person became verified (null if they have not yet been verified).
individualResultsList<Data Structures V5#CheckResultV5>This member holds a list of results for the individual checks that have been performed to date.
verificationIDStringThe unique identifier for this verification attempt.
overallVerificationStatusReason StringReason for overall status such as lockout due to GBG Alerts raised. This would specifically be: GBG_ALERT_RAISED

CheckResultV5

The CheckResultV5 type contains all the details of a check against a particular data source.


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.

modeStringThe 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.
dateVerifiedStringThe 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<Data Structures V5#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.

postOfficeDataData Structures V5#PostOfficeDataV5If 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.
extraDataList<Data Structures V5#NameValuePair>

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.

individualResultList<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:

  1. document authenticity,
  2. data extraction,
  3. data source,
  4. facial recognition match, and
  5. comparison to the master record.

These elements are discussed in detail below.

documentTypeString

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.

documentRegionStringThe region or country the document is associated with. The ISO alpha2 country designation is used.
documentSubRegionStringSome 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.
faceMatchScoreStringA 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:

<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:

<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:

<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:

<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:

<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:

<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:

<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:

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

FieldResultV5


Name

Type

Description

addressTypeStringEither 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.

valueStringThis 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.
extraDataList<Data Structures V5#NameValuePair>Any extra data associated with this check.
formatStringThis 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.
masterRecordValueStringThis member is reserved for use with combination sources. It's use is discussed below.
changedValueStringThis 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.
extractedValueStringThis 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 valuechangedValue 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:

<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:

<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 Data Structures V5#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.

<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 FieldResultV5 element when a person has changed the value that was read from the card from "Smith" to the value "Jones":

<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:

 <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 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):

 <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

Data Structures V5#DetailRecordHeader

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

Data Structures V5#DocumentRecord[]

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.

uniqueReferenceNumberStringwwwwwwttnnnnn, 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. 

NameTypeDescription
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
  • ALERT_RAISED - one or more configured Alert rules have been raised 
  • NOT_ATTEMPTED - Alert rules have not been checked.
  • ERROR
scoreDecimal 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. 

Note: The VerificationResult contains the overallVerificationStatusReason which can also indicate if the verification has been locked out due to GBG Alert. See: VerificationResultV5

raisedAlertV5

NameType
alertRuleString 

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

nameStringThe name of the additional information item we want to provide
valueStringThe content/value of the additional information item