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

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:

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

The alternate prefix is used in the same way:

Codes for background checks (New Zealand)

The order is defined as below:

* 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

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.

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