IMPORTANT: greenID has two versions of stubs codes v1 and v2. v1 stubs code has different character positioning for different data sources and can be triggered if customers do not include a 'TWO' or '2-' (where relevant) in front of their stubs data. To ensure that stubs codes are working appropriately customers are advised to always include 'TWO' or '2-' in front of their data when testing using stubs. See 'Using Stubs' for more information.

TESTING GUIDELINE: When testing please use test data that meets field validation. Some data sources may result in failures or errors if the appropriate validation is not met.

It's very important to test your verification rule set using both real live data and 'stubs'. Without doing this, potential problems can go unnoticed until it's too late.

About real data testing

Testing with real data means just that - inputting real people's details into the system. The results that they achieve are the same as they would be if that person was a real customer. Testing with real data means:

you can be sure that all data is being sent to greenID in the correct field and format
you can get a feel for how easy or hard your chosen verification rule set is to pass, and whether you have selected a good range of data sources
you can address these things before going live

GreenID does not provide real data for testing, however, we are happy to purge your test system of all data prior to go live.

About stubs testing

Stubs testing allows various codes to be input that will force different verification results on each data source. Stubs makes it easy to use fake data to force various verification results, removing the need to find real data that can achieve all these results.

However, testing only with stubs (and not doing any real data testing) means that the actual format of the data you are sending to greenID is never tested for errors (most data fields are ignored under stubs testing). You may find too late that you are not sending the address in the correct fields, for example, because only testing with real data would pick this up.

Turning on Stubs

Stubs can be turned on via the Administration Panel. Note that stubs are only available in test they do not work in production. After logging into the Administration Panel, use the "Switch Stubs" menu item to turn stubs on and off. When stubs are "on" they are on for all users of the test site.

Different codes are available for background and interactive checks, as outlined in the following sections. In most rulesets, there is no way to completely pass a verification rule set using background sources alone. A combination of the background and interactive stubs codes must be used to achieve full verification.

Using Stubs

Changes to stubs

The stubs codes for background have changed to reflect the fact that some data sources are no longer available, and some new data sources have become available.

The update to the stubs codes is dubbed "stubs 2" (i.e. version 2) to differentiate it from the original stubs codes.

The original stubs codes are deprecated, and no longer supported.

The main changes have been to the stubs code for background checks, but there have also been changes to the stubs codes for interactive checks.

The original background stubs codes will continue to function, but they are no longer being supported, and so no changes or fixes will be made. If you are creating or updating tests that use stubs for testing background sources, then use stubs 2.

When testing please use test data that meets field validation. Some data sources may results in failures or error if the appropriate validation is not met.

Existing background stubs codes will continue to work, so if you have tests with stubs codes in the middle name, they will continue to work. To use stubs 2 with background sources, a different string is required in the middle name field.

To use stubs 2, the middle name string must being with "2-". This instructs the greenID stubs manager to use stubs 2. All of the subsequent codes and examples will follow this convention.

If your input validation prohibits the use of digits or hyphens in name fields, the alternate prefix "TWO" can be used.

If a source's validation prohibits the use of digits or hyphens in name fields, then 2- will not work and "TWO" should be used. An example of this is the 'Australian Electoral Roll'.

** Please note that the stub codes are NOT case sensitive.

Using stubs for New Zealand data sources

A customer may elect to use stubs codes for New Zealand data sources. These sources use a different stubs mapping scheme. The New Zealand stubs do not require the use of stubs 2. For full details, please refer to the tables below.

Codes for background checks (Australia)

The code for background checks consists of a series of letters, each of which relate to one of the background checks. GreenID interprets this code and sends back the corresponding result. Please note there is no difference between the stubs code for a standard or a cascading background source, the same background stubs code applies.

This series of letters is sent to greenID in the middle name field. The order of these letters is extremely important to ensure the right verification outcome. The order is defined as below:

Position	Data Source	Position	Data Source
1st	Blacklist (OPAC, DFAT)	13th	Victorian Electoral Roll
2nd	Blacklist (OFAC)	14th	illion Credit Header (results in a full name + address + DOB match) *
3rd	Blacklist (PEP)##	16th	greenID fraud check (if configured)
4th	Australian Electoral Roll ^#	17th	Experian Credit Header*
6th	FCS Public Number Directory	18th	Data Co-op Database (only returns a full match)
7th	ASIC Personal Name Search	19th	illion credit header - Australian banking & finance segment (results in a full name + address + DOB match) *
8th	Australian Tenancy File	20th	illion credit header - Australian telecommunications segment (results in a full name + address + DOB match) *
9th	FNS NAD File	21st	illion credit header - Australian utilities segment (results in a full name + address + DOB match) *
10th	Australian Claims Database	22nd	illion credit header - Australian public records segment (results in a full name + address + DOB match) *
11th	Event Member Data	25th	Payroll Data
12th	Western Australian Electoral Roll	26th	Superannuation Data
		27th	GBG Alert (see note below)
		28th	Visa Entitlement Check (see note below)

^# For this source 'TWO' not '2-' must be used for stubs v2 due to validation restrictions

* See below for Credit Header stubs options, including forcing partial matches.

** Please note that the stub codes are NOT case sensitive.

##this code applies to the deprecated "Standard" watchlist only. All other PEP, Sanctions and Adverse Media watchlists can be tested using 'real' data and do not require stubs.

The letters are defined as follows:

"P" = Pass
"F" = Fail
"E" = Error
"TwoError" = Error (for all sources, i.e. the entire registration)
"TwoPass" = pass all sources
"TwoFail" = fail all sources
Any other character = Fail

Note that if a character is missing, then a fail will be given for that source. For example, if the middle name string contains only 12 "P"s, then the 13th and 14th sources will be automatically failed.

So, an example that would trigger a pass on the White Pages and Electoral Roll sources only, and a fail on all others, is as follows:

2-FFFPPFFFFFFFFF

The alternate prefix is used in the same way:

TWOFFFPPFFFFFFFFF

Codes for background checks (New Zealand)

The order is defined as below:

Position	Data Source	Position	Data Source
1st	Blacklist (OPAC, DFAT)	10th	Experian Credit header
2nd	Blacklist (OFAC)	11th	Centrix Credit Header
3rd	Blacklist (PEP)	12th	NZ PPSR
4th	DIA Births	13th	NZ Tenancy (illion)
5th	NZ Companies Office Directors and Shareholders Database	14th	illion credit header - NZ banking & finance segment (results in a full name + address + DOB match) *
6th	DIA Citizenship	15th	illion credit header - NZ telecommunications segment (results in a full name + address + DOB match) *
7th	illion Credit Header (results in a full name + address + DOB match) *	16th	illion credit header - NZ utilities segment (results in a full name + address + DOB match) *
8th	LINZ Property Ownership Database	17th	illion credit header - NZ public records segment (results in a full name + address + DOB match) *
9th	Tenancy Information NZ (TINZ)	18th	Event Member Data

* See below for other illion Credit Header stubs options, including forcing partial matches.

** Please note that the stub codes are NOT case sensitive.

The same letters apply to New Zealand stubs codes as to Australian stubs codes, however the prefix "2-" or "TWO" is not required.

So, an example that would trigger a pass on the illion credit header file only would be

FFFFFFPF

Codes for interactive checks (Australia)

Using the stubs testing approach means the background stubs mentioned in the section above must first be used, after which interactive verification can be attempted. Stubs for interactive checks are accessed via a nominated field per verification method, as defined below.

Whilst performing interactive verification, the tester must enter a code into the nominated field for that data source, which greenID will interpret and then send back a corresponding response. The field in which the stubs code must be entered varies from source to source.

The codes are detailed in the table below. These codes have been defined to take into consideration:

format and size of the fields
check digit restraints

The screens for interactive verification are pre-populated with the individual's details provided at registration; however, the fields should be modified by the tester to include the codes below at the time of interactive testing.

Note: interactive methods not mentioned here do not have stubs at this point in time.

Interactive source	Nominated field for code input	'Verified' result	'Verified With Changes' result	'Pending Review' result	Error (source unavailable)	'Not Contributing' result
Australian Electoral Roll (AML version)	Street No.	1	2	3	4
Australian Passport - DVS	Passport No.	A1111111	A2222222	A3333333	A4444444	A6666666
Australian Visa - DVS	Passport No.	A1111111	A2222222	A3333333	A4444444	A6666666
Employment Visa	Passport No.	A1111111	A2222222	A3333333	A4444444
Medicare	Medicare No.	2111111111		3333333303	4444444404	6666666606
All driver's licences	Licence No.	11111111		33333333	44444444
WA Electoral Roll	Street No.	1	2	3	4
VIC Electoral Roll	Year of birth (any day and month are OK)	1901	1902	1903	1904
Medibank Private	Membership number	11111111	22222222	33333333	44444444
Birth Certificate - DVS	Registration No.	11111111	22222222	33333333	44444444
Australian Citizenship Certificate - DVS	Stock No.	11111111	22222222	33333333	44444444
Citizenship by descent (post-July 2005) - DVS	Client Id.	11111111111	22222222222	33333333333	44444444444
Citizenship by descent (pre-July 2005) - DVS	Register No.	1111	2222	3333	4444
Citizenship by descent (pre-July 2005) - DVS	Entry No.	11111	22222	33333	44444
Marriage Certificate - DVS	Registration No.	11111111	22222222	33333333	44444444
Change of Name Certificate - DVS	Registration No.	11111111	22222222	33333333	44444444
Immi Card - DVS	Registration No.	AAA111111	AAA222222	AAA333333	AAA444444
Registration by Descent Certificate - DVS	Stock No.	11111111	22222222	33333333	44444444
Centrelink card - DVS	CRN	111111111A		333333333A	444444444A	666666666A

** Please note that the stub codes are NOT case sensitive.

Codes for interactive checks (New Zealand)

Using the stubs testing approach means the background stubs mentioned in the New Zealand background stubs must first be used, after which interactive verification can be attempted. Stubs for interactive checks are accessed via a nominated field per verification method, as defined below.

Whilst performing interactive verification, the tester must enter in a code into the nominated field for that data source (14th for illion, which greenID will interpret and then send back a corresponding response. The field in which the stubs code must be entered varies from source to source.

The codes are detailed in the table below. These codes have been defined to take into consideration:

format and size of the fields
check digit restraints

The screens for interactive verification are pre-populated with the individual's details provided at registration; however, the fields should be modified by the tester to include the codes below at the time of interactive testing.

Note: interactive methods not mentioned here do not have stubs at this point in time.

Interactive source	Nominated field for code input	'Verified' result	'Verified With Changes' result	'Pending Review' result	Error (source unavailable)
NZ Transport Authority Driver's Licence	Licence No.	11111111 or AA111111		33333333 or AA333333	44444444 or AA444444
NZ Passport	Passport No.	A1111111	A2222222	A3333333	A4444444
NZ Birth Certificate	Year of birth	1901	1902	1903	1904
NZ Citizenship	Year of birth	1901	1902	1903	1904
Automobile Association Membership	Membership No.	3083261111111111 (name + address + DoB match) 3083261111111112 (name + address match) 3083261111111113 (name + DoB match)	3083262222222222	3083263333333333	3083264444444444
White Pages	Street No.	1	2	3	4

** Please note that the stub codes are NOT case sensitive.

Codes for the Credit Header checks

The illion and Experian Credit Header check behaves differently to other checks. Below is the required input to force the possible results.

Note: The illion Credit Header check does not allow any input via the greenID interactive screen. Therefore, the codes below must be used at the time of customer registration.

First you need to invoke the Credit Header check by placing a 'P' or 'F' in the relevant position in the middle name field (14th for illion credit header and 17th for Experian credit header), as described above for Australia or New Zealand.

Using a 'P' will force a full name + address + DOB 'Verified' result.
Using an 'F' will force a 'Fail' result.

See below on how to trigger a 'Partial Match' for illion or Experian credit header sources.

Full or Partial Data Matches in Stubs

To force the different possible partial or full matches, the following codes can also be used (in conjunction with the 'P' mentioned above.) This method works for any data sources where partial matches can be returned, for example the Australian Claims Database or the Data Co-op Database.

Nominated field for code input	Full name + address + DOB 'Verified' result	Partial name + address 'Verified' result	Partial name + DOB 'Verified' result
Surname	NameAddressDob	NameAddress	NameDob

** Please note that the stub codes are NOT case sensitive.

Testing Lockout Functionality

If lockout functionality has been enabled then if any character other than the codes detailed in the table above is entered 3 times, the tester will achieve a Verification Result of "Lockout". Any incorrect code entered 5 times across any source will result in an overall verification result of "Lockout".

Testing greenID alert Responses

greenID alerts must be configured within your account to enable testing of its outcomes.

Testing uses a combination of the 16th letter of middle name as well as the <deviceIDData> field to control the results. The 16th letter in the middle name drives the overall response and the <deviceIDData> field determines the number of RCF codes that are returned.

Accepted values for 16th letter of the middle name are:

A - for an accept pass (greenID alert specific)

D - for a deny fail (greenID alert specific)
C - for a challenge fail (greenID alert specific)
F - a standard fail, same as any other source
P - a standard pass, same as any other source
E - for error, e.g. greenID can not make the call to redshield

An example of the middle name field which would drive a DENY response is 2-FFFFFFFFFFFFFFFD.

RCF codes indicate the rules that were triggered during the greenID alert check. The number of RCF codes returned for a challenge or deny response is determined by the number in the <deviceIDData> attribute.

Accepted values for <deviceIDData> attribute are:
11111111- a single predetermined RCF code will be returned
22222222 - two predetermined RCF codes will be returned
33333333 - three predetermined RCF codes will be returned
44444444 - four predetermined RCF codes will be returned
55555555 - five predetermined RCF codes will be returned

Testing GBG Trust: Alert (stubs mode)

GBG Trust: Alert must be configured on your GBG Alert account to enable testing this feature. With stubs mode enabled, in the middle name, send a ‘27^th’ character with ‘P’, ‘E’ or ‘F’.

Example data for middle name	Result
TWOPPPPPPPPPPPPPPPPPPPPPPPPPPP	GBG Trust: Alert checked – no rules raised
TWOPPPPPPPPPPPPPPPPPPPPPPPPPPF	GBG Trust: Alert checked – all alert rules raised
TWOPPPPPPPPPPPPPPPPPPPPPPPPPPE	GBG Trust: Alert not checked - error

All configured active rules for the account / ruleID will trigger.

Testing GBG Trust: Alert (non-stubs mode)

GBG Trust: Alert must be configured on your GBG Trust: Alert account to enable testing this feature. Please note:

these rules and a corresponding verification block will only occur if these are configured to your greenID account
Use this as an alternative, if you are unable to stubs mode to test GBG Trust: Alert

The following identities can be used to raise B Rules in Test:

Rule	Given Name	Surname	DOB
B rules (dependent on setup and profile use)	Sam	Anderson	5/12/96
B rules (dependent on setup and profile use)	Blair	Alice Oswald	30/12/66

Please note: This data is used in the Test instance so in addition to the B rules may trigger other configured rules. The intent of this data is just to give customers an overview of what the results look like in greenID admin panel and API.

Visa Entitlement Check

As the visa entitlement check does not contribute to verification outcomes, stubs code will result in the following results:

Stubs Code	Result
P	Details Found
F	Details not Found
E	Error

Browser not supported