...
Overall Outcome States
State Name | Meaning | Alternative from Data Structures Page | Human Readable Name | |
|---|---|---|---|---|
| VERIFIED | The user individual has been verified against the given specified rule set. | the person has been verified against the specified ruleset. | Verified | |
| VERIFIED_ADMIN | The user individual was manually verified by an administrator through the admin panel. | the person was manually verified by an administrative user, viathe admin panel. | Verified (by admin) | |
| VERIFIED_WITH_CHANGES | The user individual was verified against the given specified rule set, however some minor changes were made to the data in order to get the result. These changes are included in the rule set as acceptable changes. | the person was verified against the specified ruleset, but with some acceptable changes to their data. | Verified with changes | |
| IN_PROGRESS | The user individual has not yet been verified, as but further checks may be attempted. As GreenID allows further checks to be performed at any time this can be considered as not yet meeting the rule set requirements for verification. | the person has not yet been verified, but further checks may be attempted. | In progress | |
| PENDING | The user individual has been verified against the rule set, but to do so they changed data in a way that is not considered acceptable without further action. | the person has been verified against the ruleset, but some changes were made to their data that require manual inspection before they can be verified. | Pending review | |
| LOCKED_OUT | The user individual has been locked out completely. This will occur depending on the customer lock out rules. By default there are no lock out rules. | the person has been lockedout | completely; this is dependent upon the customer’s lockoutrules. | Locked out |
Possible Modes
Mode name | Meaning | Alternative from Data Structures Page | Human readable name |
|---|---|---|---|
POSTOFFICE | The user was verified by filling out a Post Office form and visiting a post office with documentary evidence. | the person was verified by completing a Post Office form and visiting a branch of Australia Post, where their identity documents were manually inspected. | Post Office |
ASSISTED | The user was verified by an administrator loggin into the admin panel and entering the data on behalf of the user. This method still contacts the third party data sources to confirm the entered data. | the person was verified by an administrative user. | Admin assisted |
EXTERNAL | This mode is used to indicate that verification was carried out outside of the GreenID system. | the person was verified outside of greenID, and the results have been loaded in to greenID. | Externally Verified |
Individual Source States
State name | Meaning | Other possible value from Data Structure Page | Human readable name |
|---|---|---|---|
VERIFIED | The users data has been verified against this source | the check against the data source has succeeded | Verified |
VERIFIED_ADMIN | The details for this source were manually verified by an administrator through the admin panel. | an administrative user has marked the check as successful, after manual inspection of the results. This mostly applies to checks that were previously “Pending review” (see below). | Verified (by admin) |
VERIFIED_WITH_CHANGES | The user was verified against this source, however some minor changes were made to the data in order to get the result. These changes are included in the rule set as acceptable changes. | the check against the data source passed, but the person made some changes to their details in order to pass. If the changes are acceptable according to the customer’s rules, then this state is applied; otherwise the status may remain as “PENDING”. | Verified with changes |
PASSED | This state is specific to the watchlist checks. If a problem was NOT found on a watchlist check then they are considered to have PASSED the watchlist. | this status applies to the device/fraud watchlist source, and indicates a non-suspicious result. | Passed |
FAILED | This state is specific to the watchlist checks. If a problem was found on a watchlist check then they are considered to have FAILED the watchlist. | this status applies to a source when the check has been unsuccessful - ether the data has not matched or (in the case of some interactive checks) the user has changed some data violating the the requirements of the rules. | Failed |
AUTOFAIL | This state is specific to non-consent or “BG” checks it indicates that the automatic check did not become verified. | applies to background checks, and indicates that a check that was attempted automatically has failed, i.e. the check against the data source was not successful. | Autofail |
IN_PROGRESS | When a user centric “UC” check has not yet reached a verified state it is considered in progress. | the check is currently in progress, i.e. the check has been started, but not enough data has been gathered to allow the check to be completed. | In progress |
PENDING | The user has been verified this source, but to do so they changed data in a way that is not considered acceptable without further action. | the check against the data source passed, but the person made some changes to their details in order to pass, and manual intervention is required to assess the changes. | Pending review |
LOCKED_OUT | This individual source has been locked out. Either by customer specific rules, or at the source end. Only some sources force a lockout after a number of attempts. | some data sources have a limited number of attempts associated with them, and if that threshold is exceeded, then the person is prevented from trying again. | Locked out |
ERROR | The individual source could not be queried because of an error. The user may retry at a later date if necessary. | an error was experienced during the check, for example, the data source was unavailable. | Error |
| NOT_FOUND_ON_LIST | this status applies watchlist style checks. | ||
| FOUND_ON_LIST | this status also applies to watchlist style checks. | ||
| EMPTY | indicates this check has not been used. |
Method Names
Method name | Meaning | Human readable name |
|---|---|---|
| DB | This check was a “Data Base” check that was automatically carried out with no user input. This is also referred to as a “Non Consent check” as no explicit consent is needed from the user. | Data Base OR Non Consent |
| UC | The check was a “User Centric” check that required either input or explicit consent from the user or both. | User Centric |
| PP | This check was carried out as a “Person Present” or face to face check. The main example of this type of check is a Post Office verification where the user physically presented themselves and their verification information at a Post Office. | Person Present |
| A category that does not fall into the above will have a blank or null method name. | None |
Field Status
Status name | Meaning | Human readable name |
|---|---|---|
| CONFIRMED | This field was matched to this source exactly | Field confirmed. |
| CHANGED | This field was changed in order to get a valid match on this source | Field changed. |
| ADDITION | This was an additional field that was added by the user in order to get a valid verification. This is a specialised field that is only available to certain customers. By default a customer will never receive this. | Additional field. |
| NO_MATCH | This is a status returned by “DB” or non consent checks and indicates that a match was not able to found on the source. | No exact match found. |
| MISSING | This is a status returned by a “DB” or non consent source and indicates that this field was not available to be compared on the source, for example in the phone book check the givenName is most often MISSING, whereas the firstInitial is present. | Field missing on source. |
...