Designer Reference Guide...Designer Reference Guide | illion Decisioning 2 Private and Confidential The contents of this document are copyrighted and contain confidential information

Designer Reference Guide | illion Decisioning 1

DESIGNER REFERENCE GUIDE

illion Decisioning

Version 3.6, February 2020


Private and Confidential The contents of this document are copyrighted and contain confidential information with is the property of illion Australia & New Zealand Pty Ltd. No part of this document may be copied, reproduced, transmitted, stored in a retrieval system or divulged to any other party without prior written permission from illion Australia & New Zealand Pty Ltd. © illion Pty Ltd

Table of Contents


TABLE OF

CONTENTS illion Decisioning .......................................................................... 1

Table of Contents ....................................................................... 3

Overview ..................................................................................... 8

Flows as a Concept ................................................................... 8

Administration ........................................................................... 9 Required Privileges ...................................................................... 9 Timeout Information ..................................................................... 9

Linking Flows and Screens ....................................................... 9 Assigning a Flow to a Credit Product ........................................... 9

Flow List Page .......................................................................... 10 Flow Details............................................................................ 10 Creating a Flow ...................................................................... 10 Copying a Flow ...................................................................... 10 DIfferent Flow List Options ..................................................... 11

Accessing a Flow ....................................................................... 11 Pending Changes ...................................................................... 12

Importing Pending Changes ................................................... 12 Ignore & Work Solo ................................................................ 12 Removing Pending Changes .................................................. 12 Exiting Pending Pages Page .................................................. 12

Flow Refresh Page ................................................................... 13 Refreshing a Flow ...................................................................... 13

Flow Migration ......................................................................... 14 Flow Migration Page .................................................................. 14 Download Migration File ............................................................. 14 Upload Migration File ................................................................. 15 Direct Migration .......................................................................... 16

Establishing Connection ......................................................... 17

‘What If?' Testing Setup .......................................................... 18

Environment Setup .................................................................. 19 Adding an Environment .............................................................. 19

Screen Layout .......................................................................... 20 Diagram Layout.......................................................................... 20 Table Layout .............................................................................. 20

Header ................................................................................... 20 Toolbar ................................................................................... 20 Toolbar – Tools Menu ............................................................ 21 Mapping ................................................................................. 22 Group List .............................................................................. 22

Simultaneous Edit .................................................................... 23 Locking Mapping ........................................................................ 23

Unlocking mapping ................................................................. 23 Locking Objects ......................................................................... 23

Unlocking Objects .................................................................. 23 View Currently Editing ................................................................ 24

Currently editing popup .......................................................... 24

Search ....................................................................................... 25 Searching by Name ................................................................... 25 Searching by XPath ................................................................... 25 Searching by SQL ...................................................................... 25 Searching by Type ..................................................................... 25 Searching other flows ................................................................ 26 Quick Find .................................................................................. 26

Using the Quick Find Bar ........................................................ 26

Flow Mapping ........................................................................... 28 Locking Mapping .................................................................... 28

Reordering Objects .................................................................... 28 Creating Mappings ..................................................................... 28

Adding an object to the mapping ............................................ 28 Outcomes .................................................................................. 29

Making an Object Mapping Active or Inactive ......................... 31 Removing an Object Mapping ................................................ 31

Statuses .................................................................................... 32

Table of Contents


Managing Statuses .................................................................... 32

Alerts ........................................................................................ 34 Managing Alerts ......................................................................... 34

Rules ......................................................................................... 35 Creating Rules ........................................................................... 35 Editing Existing Rules ................................................................ 35

Editing Existing Rules from the Search Bar ............................ 35 Editing existing rules from an object ....................................... 36

Rule Editor Popup ...................................................................... 36 Description Tab ...................................................................... 36 Options Tab............................................................................ 36 Mapping Tab .......................................................................... 37 Other Functions ...................................................................... 38 System True ........................................................................... 38

Items ......................................................................................... 39 Creating Items ........................................................................... 39

Creating Items from the Search Bar ....................................... 39 Creating Items from a rule or Object ....................................... 39

Editing Existing Items ................................................................. 39 Editing Existing Items from the Search Bar ............................ 40 Editing existing items from a rule ............................................ 40

Item Editor Popup ...................................................................... 40 Description ............................................................................. 40 Options ................................................................................... 40 Mapping ................................................................................. 41 Other Functions ...................................................................... 46

System Items ............................................................................. 46

Data Bins .................................................................................. 48 Creating Data Bins ..................................................................... 48

Creating Data Bins from the Search Bar ................................. 48 Creating Data Bins from a Rule or Object ............................... 48

Editing Existing Data Bins .......................................................... 48 Editing Existing Data Bins from the Search Bar ...................... 48 Editing Existing Data Bins from a rule..................................... 49

Data Bin Editor Popup ............................................................... 49 Description ............................................................................. 49

Options ................................................................................... 49 Mapping ................................................................................. 50

Objects ..................................................................................... 53 Creating an Object ..................................................................... 53

Flow Mapping ......................................................................... 53 Modifying Objects ...................................................................... 53

Modifying Objects from the Flow Mapping .............................. 53 Modifying objects from search menu ...................................... 53

Object Types .............................................................................. 54 Global Objects ........................................................................... 55

Referencing an Object as a Global Object .............................. 55 Using Global objects .............................................................. 55

Object Editor Popup ................................................................... 55 Description Tab ...................................................................... 55 Mapping Tab .......................................................................... 56 Outcomes ............................................................................... 57 Other Functions ...................................................................... 57

Analyser Object ........................................................................ 58 Description ............................................................................. 58 Mapping ................................................................................. 59 Outcomes ............................................................................... 67

Application Comparison Object .............................................. 68 Mapping ................................................................................. 68 Outcomes ............................................................................... 69

Application Merge Object ........................................................ 70 Description ............................................................................. 70 Mapping ................................................................................. 70 Outcomes ............................................................................... 71

Appwriter Object ...................................................................... 72 Description ............................................................................. 72 Mapping ................................................................................. 72 Outcomes ............................................................................... 74

Bureau Enquiry Objects .......................................................... 75 Description ............................................................................. 75 Mapping ................................................................................. 75

Table of Contents


Outcomes ............................................................................... 84

Calculator Object ..................................................................... 85 Description ............................................................................. 85 Mapping ................................................................................. 85 Outcomes ............................................................................... 87

Checklist Object ....................................................................... 88 Description ............................................................................. 88 Mapping ................................................................................. 89 Outcomes ............................................................................... 91

Communication Object ............................................................ 92 Description ............................................................................. 92 Mapping ................................................................................. 93 Outcomes ............................................................................... 95

Director Object ......................................................................... 96 Description ............................................................................. 96 Mapping ................................................................................. 96 Outcomes ............................................................................... 98

Docusign Object ...................................................................... 99 Description ............................................................................. 99 Mapping ................................................................................. 99 Outcomes ............................................................................. 102

Flow Change Object .............................................................. 104 Description ........................................................................... 104 Mapping ............................................................................... 104 Outcomes ............................................................................. 105

GreenID Object ....................................................................... 106 Description ........................................................................... 106 Mapping ............................................................................... 106 Outcomes ............................................................................. 109

Group Object .......................................................................... 110 Description ........................................................................... 110 Outcomes ............................................................................. 110 Managing Groups ................................................................. 111

Internet Monitor Object .......................................................... 112 Description ........................................................................... 112

Mapping ............................................................................... 113 Parameters........................................................................... 114 Outcomes ............................................................................. 114

Loan Calculator Object .......................................................... 115 Description ........................................................................... 115 Settings ................................................................................ 115 Date Settings ........................................................................ 116 Interest Rate Settings ........................................................... 116 Principal Adjustments ........................................................... 117 Additional Fees .................................................................... 118 Loan Variations .................................................................... 119 Snapshots ............................................................................ 120 Outcomes ............................................................................. 121

Loan Conditions Object ......................................................... 122 Description ........................................................................... 122 Mapping ............................................................................... 122 Outcomes ............................................................................. 124

Matrix Object .......................................................................... 125 Description ........................................................................... 125 Mapping ............................................................................... 126 Outcomes ............................................................................. 127

OCR Labs Object ................................................................... 128 Description ........................................................................... 128 Mapping ............................................................................... 129 Outcomes ............................................................................. 130

Outcome Tree Object ............................................................. 131 Description ........................................................................... 131 Mapping ............................................................................... 132

Ownership Object .................................................................. 135 Description ........................................................................... 135

PPSR Object ........................................................................... 137 Description ........................................................................... 137 Mapping ............................................................................... 137 Outcomes ............................................................................. 139

Printing Object ....................................................................... 140

Table of Contents


Description ........................................................................... 140 Mapping ............................................................................... 140 Outcomes ............................................................................. 141

Product Variant Selector Object ........................................... 142 Description ........................................................................... 142 Mapping ............................................................................... 142 Outcomes ............................................................................. 143

Queue Object ......................................................................... 144 Description ........................................................................... 144 Actions ................................................................................. 144 Options & Escalation ............................................................ 148 Assignment .......................................................................... 149 Check-In & Follow-Up .......................................................... 150

Raw Editor Object .................................................................. 152

Resubmit Object .................................................................... 153 Description ........................................................................... 153 Outcomes ............................................................................. 154

Ruleset Object ........................................................................ 155 Description ........................................................................... 155 Mapping ............................................................................... 155 Outcomes ............................................................................. 156

Scorecard Object ................................................................... 157 Description ........................................................................... 157 Mapping ............................................................................... 158 Outcomes ............................................................................. 158

Simple KYC Object ................................................................ 159 Description ........................................................................... 159 Mapping ............................................................................... 159 Outcomes ............................................................................. 162

Suspect Register Object ........................................................ 163 Description ........................................................................... 163 Mapping ............................................................................... 163 Outcomes ............................................................................. 171

Variable Object ....................................................................... 172 Description ........................................................................... 172

Mapping ............................................................................... 172 Outcomes ............................................................................. 173

Webservice Object ................................................................. 174 Description ........................................................................... 174 Mapping ............................................................................... 174 Outcomes ............................................................................. 178

XML Object ............................................................................. 179 Description ........................................................................... 179 Mapping ............................................................................... 179 Outcomes ............................................................................. 181

Custom Objects ..................................................................... 182 Configuring Custom Objects .................................................... 182


Object Testing ........................................................................ 184 Performing a Test ................................................................. 184 Reviewing Test Results ........................................................ 184

Final Actions .......................................................................... 185 Configuring a Final Action .................................................... 185

Status Change Events ........................................................... 186 Status Change Mapping ....................................................... 186

Flow Details ............................................................................ 188 Flow Description and Activation ............................................ 188 Start Object & Status Details Section ................................... 189 Schemas & Stylesheets........................................................ 189 Sub flow details .................................................................... 190

Defining Linked Documents ..................................................... 191

Reason List Setup .................................................................. 194 Defining a Reason List ............................................................. 194

DLA Configuration ................................................................. 195 DLA Mapping ........................................................................... 195

'What If?' & Object Testing ................................................... 197

Object Import ......................................................................... 198 Importing Objects ..................................................................... 198

Table of Contents


Select Environment .............................................................. 198 Select Flow .......................................................................... 198 Select Objects ...................................................................... 199 Select Rules ......................................................................... 199 Select Items ......................................................................... 199

Change History ...................................................................... 200 Migration Tab ....................................................................... 200

Orphaned Items...................................................................... 200

Flow Documenter ................................................................... 201

Obsolete Functionality .......................................................... 202 External Accounts Object (Obsolete) ....................................... 202


Appendix A: Reference Data ................................................ 204 XPath Qualifiers ....................................................................... 204

Appendix B: Loan Calculator Excel Spreadsheet ............... 205

Appendix C: GreenID Match Logic XPaths .......................... 206

Appendix D: Document History ........................................... 211 Version History ........................................................................ 211

Administration / Linking Flows and Screens


OVERVIEW illion Decisioning is an automated credit decisioning and loan origination product.. illion Decisioning is extremely versatile and offers multiple configurations and customisation options to fully meet the needs of small and large businesses alike.

illion Decisioning encompasses several different application modules. The back-end “brains” behind the credit process is the flow, which is managed through Designer.

FLOWS AS A CONCEPT Flows are the backbone of Designer and illion Decisioning in general. Applications are sent to the flow for processing, either through the illion Decisioning screens or by a direct API call. Flows consist of a set of ‘objects’, which are configured to perform particular processing tasks over an application. Bureau objects will make an external call to a bureau, while a ruleset will perform checks and validation against an application. A full list of objects and how they behave is listed later in the document. As objects process applications ‘alerts’ are triggered. These alerts are displayed to operators via the Result screen, and provide context for the actions taken in processing an application. When triggered, alerts can assign a new status to an application: an alert may change an application ‘In Progress’ to a ‘Decline’ status if the alert is triggered by disqualification by a credit policy. Once an object has completed processing the status of the application is considered to be the ‘outcome’ of the object, and is used to determine where a flow should continue processing.

Administration / Linking Flows and Screens


ADMINISTRATION The Designer Tools administration menu can be accessed through by selecting ‘Administration’ from the top-right hand dropdown, and then selecting ‘Designer Tools’. Access to the Designer Tools page and the pages within the menu are controlled through privileges assigned to a user’s privilege group.

Required Privileges Access to Designer and its constituent components are controlled through a combination of privileges and access groups.

Timeout Information By default, users will not "time out" when using Designer. This can be modified through the customisation of "Time Out Length" in the illion Decisioning Security Settings. Given the tasks completed in Designer can take some time, and the unexpected loss of data would be detrimental to the operation of Designer. It is recommended that any time out length provide sufficient leeway for users to complete complex tasks in Designer.

LINKING FLOWS AND SCREENS The link between a screen set and a flow is created via the Credit Product configuration.

Assigning a Flow to a Credit Product Flows can be assigned to credit products via the Credit Product Details screen, accessible via the Security administration menu for users with appropriate privileges. Each Credit Product is configured with a ‘Flow Selection’, which determines the flow to use when processing applications with the credit product. Changes to the credit product configuration only take effect on the next log in to illion Decisioning.

Administration | Flow List Page


FLOW LIST PAGE The Flow List Page can be accessed through the ‘Flow Designer’ link on the Designer Tools page.

FLOW DETAILS A flow is defined by the fields below.

Flow ID A unique ID for the Flow.

Description A human-friendly text description of the flow.

Version A system-maintained version number of the flow. Each time changes to the flow are committed to the database, the version number is incremented.

Save Date The date the listed version of the flow was saved.

Active Flows can be either active or inactive. An inactive flow will not be used for credit decisioning, and cannot be associated with a credit product.

CREATING A FLOW A new flow can be created by selecting the ‘Create New Flow’ button. A ‘New Flow Details’ popup will be displayed, allowing the user to enter the Flow ID and a brief textual description of the flow to be created.

From there, users will be taken to the Flow Mapping screen to begin the development of their flow.

COPYING A FLOW An existing flow can be copied and used to create a new flow, with a new ID and description. A flow can be copied by selecting the ‘Copy’ button. The ‘New Flow Details’ popup will be displayed, allowing the user to enter the Flow ID and a brief textual description of the flow to be created. From there, users will be taken to the Flow Mapping screen to begin the development of their flow, with the entirety of the copied flow included as a base point.



Deactivating a Flow The ‘Flow List Page’ allows authorised users to deactivate flows, marking them as inactive. A flow can be deactivated by selecting the ‘Deactivate’ button.

Once selected, the flow will be marked as inactive.

DIFFERENT FLOW LIST OPTIONS By default, the Flow List screen will display a list of the currently active flows. The filter can be used to show different views of the corpus of flows on the system.

‘Active Flows’ Filter The ‘Active Flows’ filter will display a list of all active flow versions. If there are flows without an active version, they will not be displayed in the list.

‘Latest’ Filter The ‘Latest’ filter will display a list of the latest version of all unique flows that have been created for the company, regardless of if the flow is active or inactive.

‘All’ Filter The ‘All’ Filter will display a list of all versions of all flows that have been created for the company.

Flow Specific Filter Each unique flow ID will be displayed in the filter dropdown. Using the Flow ID as a filter will show all versions of that flow, regardless of if the version is active or inactive.

Accessing a Flow The contents of a flow can be accessed by selecting the flow ID from the list of flows.



Pending Changes When accessing a flow, if there have been changes made to a flow that haven’t been saved to the database, the user will be directed to the ‘Pending Changes’ screen.

Each change that has not been saved is listed in the table to the user, in order to assist users determining whether to import or remove changes that are pending. It is recommended that if a user encounters the Pending Changes screen unexpectedly they should refrain from continuing until they have spoken to the user making the change.

IMPORTING PENDING CHANGES If a user chooses to import pending changes, the changes will be loaded into their session of Designer.

When the user next saves to the database, they will be including the imported changes in that save.

IGNORE & WORK SOLO If a user chooses to ignore and work solo, the changes that were pending are not included. If changes are then made to the flow and saved, the pending changes are overwritten by the solo work.

REMOVING PENDING CHANGES If a user chooses to remove pending changes, the changes that were pending are removed.

Once removed, pending changes cannot be retrieved, so caution should be taken before taking this course of action.

EXITING PENDING PAGES PAGE A user can choose to neither import or remove pending changes by selecting the ‘Return Home’ button

When this option is chosen, the pending changes will remain pending until a user chooses to import or remove them.

Administration | Flow Refresh Page


FLOW REFRESH PAGE In order to speed up the processing time of applications, every flow is stored within the memory of the illion Decisioning Engine. When a flow has been changed, the version stored in the engine has to be “refreshed” before it will be used by new applications.

The Flow Refresh Page can be accessed through the ‘Flow Refresh’ link on the Designer Tools page.

Refreshing a Flow To refresh a flow, first select the Inteport URL of the environment where the flow is to be refreshed. Selecting ‘Local’ will refresh the flow on the environment currently being used.

Then, select 'Refresh Flows'. A popup will appear confirming that the flows on the environment were refreshed successfully.

Administration | Flow Migration Page


FLOW MIGRATION Due to the nature of flows, it is not suitable to be directly editing and making significant alterations for a flow that is currently being used. Flow development generally takes place on separate development environments and is then tested on test environments to confirm its desired behaviour, well before any changes are made to a flow in a production environment. The Flow Migration functionality enables this development process, by allowing flows to be moved between environments and companies. The Flow Migration Page can be accessed through the ‘Flow Migration’ link on the Designer Tools page.

Flow Migration Page The ‘Flow Migration’ page allows for three different actions to be performed in order to migrate a flow.

Download Migration File Downloading a migration file allows for a portable and distributable version of the flow to be downloaded from any environment.

The ‘Download’ button will take the user to the Download Migration File page.

Flows that have been configured for a company will appear in a table, with filters directly matching that offered on the Flow List page (for more information on filtering, see the Flow List section of this document).

All details of a flow can be downloaded by selecting the download icon on the right of the table.

An .xml file containing the definition of the flow will then be downloaded. This file can be used in release packages or provided to others to perform the migration.



Upload Migration File Uploading a migration file allows for flows to be imported into an environment directly from a previously downloaded flow migration file. The ‘Upload’ button will take the user to the Upload Migration File page.

Flows that have already been configured for a company will appear in a table, with filters directly matching that offered on the Flow List page (for more information on filtering, see the Flow List section of this document). The Upload Migration File page features several different input fields.

External File The migration file from which the flow is to be imported.

Active Determines whether to set the flow migrated into the environment as an active flow. When unchecked, the imported flow will be inactive. When checked, the flow will be able and appear in the list of active flows.

Active Date & Time (HH: mm) Allows for a migrated flow to be initially marked as inactive, but to have a date and time scheduled for when it is to be made active.

Upload The upload button will begin the upload of the migration file to the destination environment.

As part of the migration process, the configured access groups, privilege groups and other configuration settings from the migration file and destination environment/company are compared.

Configuration Mismatch Where there is configured groups or settings that do not exist in the destination environment/company, an additional section will appear allowing the user to map between the existing configurations and the settings from the migration file.



Successful Migration After a successful flow migration, a confirmation popup will appear to the user.

Refresh Flows The 'Refresh Flows' button allows for the flows saved in memory on the engine to be refreshed.

For more information about Flow Refreshing, see the ‘Flow Refresh’ section of this document.

Direct Migration In some circumstances, it may be appropriate to directly connect to a different environment and migrate a flow without downloading and uploading a migration file. This method is not considered best practice, as it cannot be audited or managed as rigorously as migration using the file method. The ‘Migrate’ button will take the user to the Migrate page.

Environment Information A connection to an environment must first be established before a direct migration can take place. There are a set of fields that allow the connection to be established.

Environment A list of environments that are available for connection. For more information about how this list is configured, see the ‘Environment Setup’ section of this document.

Company The company to which the flow will be migrated.

Merchant The merchant to use when connecting to the destination environment.

Operator The operator to use when connecting to the destination environment.



Password The password to use when connecting to the destination environment.

ESTABLISHING CONNECTION When all necessary login information has been entered, the ‘Connect’ button will allow for the connection to the destination environment to be established. Once a connection has been established, a list of flows on the current environment will be displayed and made available for direct migration.

The functionality of the direct migration from this point is nearly identical to the ‘Upload Migration’ process. The only difference is that in place of the ‘External File’ input field, the flow to be migrated must be selected from the list of flows.

Administration | 'What If?' Testing Setup


‘WHAT IF?' TESTING SETUP 'What If' Testing is scheduled for future development. This document will be updated when the redesign is complete.

Administration | Environment Setup


ENVIRONMENT SETUP For each environment on which illion Decisioning is installed, there may be multiple development, testing, or other internal environments that relate to it. Processes are commonly built on migrating data between those environments, and in order to aid the interaction between environments, each environment can be defined on the Environment Setup page.

The Environment Setup Page can be accessed through the ‘Flow Refresh’ link on the Designer Tools page.

Adding an Environment External environments can be added by selecting the ‘Add Environment’ button on the Environment Setup page.

An environment is defined by three fields.

ID A code that uniquely identifies the environment on the system.

Name A human-friendly name of the environment. The name of an environment will be used to populate dropdowns where an environment is to be selected.

Inteport URL A URL to Inteport on the environment. Inteport URLs generally end with “/inteport/decisiongateway.asmx”, although the exact URL is dependent on the server configuration.

Designer | Screen Layout


SCREEN LAYOUT The Flow Mapping screen is the main screen in Designer and is the first screen that is accessed by selecting the flow from the Flow List page. It consists of several different components, each providing a unique function.

Diagram Layout The diagram layout is scheduled for a redesign. This document will be updated when the design is complete.

Table Layout

HEADER The header sits at the top of all screens in Designer.

Search Bar The search bar can search all objects, rules and items configured in the flow. For more information, see the ‘Search Bar’ section of this document.

Save The floppy disk ‘Save’ icon allows all the changes made to the flow to be committed to the database.

Refresh The circular arrow ‘Refresh’ icon allows users to perform a flow refresh. For more information on refreshing flows, see the ‘Flow Refresh Page’ section of this document.

Exit Designer The cross ‘Exit Designer’ icon allows users to exit designer without saving their changes. Upon exiting designer the user will be taken to the Flow List page.

TOOLBAR The toolbar sits above the mapping view, providing quick access to the most commonly used objects and functions in Designer.



Object Pane The object pane lists each type of object available in the flow. For more information on how to use the Object Pane, see the ‘Objects’ section of this document.

Alerts The warning ‘Alerts’ icon allows users to view and manage the alerts configured in the flow. For more information, see the ‘Alerts’ section of this document.

Statuses The light bulb ‘Statuses’ icon allows users to view and manage the statuses configured in the flow. For more information, see the ‘Statuses’ section of this document.

Status Change Events The light bulb with an arrow ‘Status Change Events’ icon allows users to view and manage status change events configured in the flow. For more information, see the ‘Status Change Events’ section of this document.

Tools Menu The Tools icon allows users to open the tools popup.

Quick Find Bar The Quick Find tollbar will highlight all objects in the mapping which contain the search query, and automatically scroll to the first item in the list. For more information, see the 'Search' section of this document.

Currently Editing Device The 'Currently Editing' device allows users to see how many other users are simultaneously editing the flow. For more information, see the 'Simultaneous Edit' section of this document.

TOOLBAR – TOOLS MENU

Flow Details Displays the Flow Details tab. For more information, see the ‘Flow Details’ section of this document.

Linked Document Setup Allows users to view and configure linked documents. For more information, see the ‘Flow Documenter’ section of this document.

Reason Lists Setup Allows users to view and configure reason lists. For more information, see the ‘Reason Lists’ section of this document.

Designated Lending Authority (DLA) The shield ‘DLA’ icon allows users to view and manage the DLA levels configured in the flow. For more information, see the ‘DLA’ section of this document.



Object Import Allows users to import objects from other flows. For more information, see the ‘Object Import’ section of this document.

Change History Provides users with a chronological list of changes that have been made to the flow. For more information, see the ‘Change History’ section of this document.

Orphaned Items Provides users with a list of items, objects and rules that are not referenced in the flow. For more information, see the ‘Orphaned Items’ section of this document.

Flow Documenter Allows users to export a PDF summary of all flow logic for audit purposes. For more information, see the ‘Flow Documenter’ section of this document.

MAPPING The mapping section the contents of the flow: the objects, the groups and the general structure of the flow.

For more information, see the ‘Managing Flow Mapping’ section of this document.

GROUP LIST The Group List to the left of the mapping section provides a quick anchor to groups in the flow. When a group is selected the screen will scroll down to the start of the group.

Designer | Simultaneous Editing


SIMULTANEOUS EDIT Designer allows for multiple users to edit a flow simultaneously, provided that they are editing separate sections. In order to achieve this, a locking and unlocking system is used to ensure that changes are made to separate parts of the flow and that no user has their changes overwritten unknowingly.

Locking Mapping A flow’s mapping must be manually locked in order for the mapping to be modified. This can be achieved through pressing the ‘Lock Mapping’ button in the top right of the ‘Mapping’ screen.

Object Restrictions Objects can only be created or reordered by the user who has locked the flow mapping. Other users will only be able to view the mapping but will remain able to edit objects within it.

UNLOCKING MAPPING A flow’s mapping can be unlocked by selecting the ‘Unlock Mapping’ button.

Locking Objects When a user opens an object it will be locked to them automatically, provided it is not already locked.

Opening an already locked object When opening an object that is already locked a warning message will be displayed informing the user of the lock, and the name of the user who has locked the item.

The user who opened the locked object will still be able to view the contents of the object, however, the ‘Save’ and ‘Delete’ options will not be available.

The user who has locked the item will not receive a notification that the object has been opened by another user.

UNLOCKING OBJECTS An object is unlocked when the user who locked it closes the object by saving the object, deleting the object, or exiting the object popup. Minimising an object does not cause the object to unlock.

Designer | Simultaneous Editing


View Currently Editing The 'Currently Editing' device next to the lock/unlock buttons indicates the number of users that are concurrently editing a flow.

Selecting this icon will display the "Currently Editing" popup.

CURRENTLY EDITING POPUP The "Currently Editing" popup lists every user currently "polling" designer. These polls are routine checks run every thirty seconds to determine if a user is still active. The last change made by the user, and objects locked to them and their IP is listed.

Designer | Search


SEARCH The search bar can be used to find any objects, rules, items or data bins that have been configured in the flow.

Searching by Name Objects, rules and items can be searched by name simply by entering your desired text into the search box.

A list of results will appear below the search box. Objects will be sorted by object type, and items and rules will be sorted in a stand-alone section.

From the drop-down, users will also be able to create new rules and items. Selecting either the ‘Create Rule’ or ‘Create Item’ will present the user with the standard menus: for more information see the ‘Items’ or ‘Rules’ sections of this document.

Searching by XPath Items can also be searched by XPath. Searching by XPath allows users the ability to see if items already exist to capture their desired information from the application XML. To search by XPath, the search query needs to be prepended

with 'XML':

All items that contain the text in the XML definition will be displayed as a result.

Searching by SQL Items can also be searched by SQL query. Searching by query allows users the ability to see if items already exist to capture their desired information from the database.

To search by SQL query, the search query needs to be prepended with 'SQL':

All items that contain the text in the SQL query will be displayed

as a result.

Searching by Type

Designer | Search


Objects, rules and items can also be searched by type. Searching by type allows users the ability to see a list of objects of a specific type, all rules, or all items, even if the name is not known. To search by type, the search query needs to be prepended with 'TYPE':

All objects of the matching object type will be displayed. If the type provided is 'Rule', 'Item' or 'Data Bin' all elements of that type will be displayed.

Searching other flows The search bar also allows for searching in other flows.

The 'Other Flows' section will display a list of flows configured in the system. Selecting a flow will then show the results of the search query made against that other flow.

Quick Find The 'Quick Find Bar' allows for items in the mapping to be quickly found regardless of their position. The 'Quick Find Bar' is located next to the tools icon in the Toolbar.

USING THE QUICK FIND BAR Selecting the quick find bar will cause it to expand, allowing the entry of the name of an object that is to be located in the mapping.

Designer | Search


As a search term is being entered, each row in the mapping will be highlighted if the term can be found in the name of the object. The mapping will also scroll to the first instance of that object within the flow.

Using the Quick Find Bar will cause all sections with a matching

term to be uncollapsed.

Designer | Flow Mapping


FLOW MAPPING The mapping section shows the contents of the flow: the objects, the groups and the general structure of the flow.

Each object in the flow is listed as a row, and each group is represented as a collapsible section. The object icon and description can be used to identify the type of object being used and the possible outcomes of the object.

The full list of object icons is listed in the Object section of this document.

LOCKING MAPPING Before mapping can be edited, the mapping must be locked to the user making the edits. For more information, see the ‘Simultaneous Flow Editing’ section of this document.

Reordering Objects The reorder icon ( ) can be used to drag and drop objects within the mapping flow.

Reordering the flow visually doesn’t have any functional effect; however, a well-ordered flow aids readability and readability of the process.

Creating Mappings

ADDING AN OBJECT TO THE MAPPING An object can be created by dragging an object from the object list into the desired location in the flow.



The user will have the ability to either create a new object of the chosen object type or to select an existing object that hasn't already been mapped. To cancel the addition of a new item, a user can select the 'bin' right to the right of the 'Choose Unmapped Object' link.

Outcomes Once an object has completed processing, the flow needs to determine the next object in the flow to process. This is driven through the configuration of outcomes. The outcome of an object is the status of the application after it has been processed.

Outcome Status The icon relating to the outcome status. Applications which, after being processed by the object, have this status will be moved to the ‘next object’ relating to the outcome status. The outcome status icon can also be one of several ‘special’ outcome statuses. These statuses may match several statuses and can be used to cover unique scenarios. The special statuses, their icons, and the applications that they match are listed below.

Custom Outcomes The textbox indicates the custom outcome that will be matched. Custom Outcomes are defined on the Outcome tab of each object.

ICON DESCRIPTION WILL MATCH

All

All applications, regardless of their status. Should only be used as the only outcome

path for an object.

Other Any applications which do not

have a specific outcome which relates to their status.

Custom

Will match an application which has been assigned a ‘Custom Outcome’ matching that in the additional text box.

Custom outcomes are free text strings that can be

configured within specific types of objects.

Unknown

Indicated that there is no icon to display for this outcome. This can be caused by two

scenarios: there is no selection of the status in the

outcome (which will cause an error), or the status has not

been configured with an icon in the Status List.



Status Overrides The grey arrow indicates which object will be used as the ‘next object’ when an application matches the outcome status. There are two types of arrows that will be displayed.

ICON OPERATION

The application will be sent to the object indicated, with no further action

The status of the application will be overridden by a different status.

A status override can be configured by selecting the arrow and choosing from the list of statuses.

Next Object The icon and name of the objects to which the applications will be sent are listed to the right of the arrows.

The object can be changed by selecting the text of the object listed and selecting a new option from the list that appears. There are two ‘Next Objects’ that feature unique behaviour, unlike that of a normal outcome.

ICON NAME OPERATION

END

Stop processing the application through the flow. Once an application reaches the ‘END’ outcome, it will be removed from a queue, and

any final actions (documented below) will be performed.

[LAST:Object Type]

The application will be sent the object of the selected object type which with the application was previously

processed.

For example, consider an application which is currently

in a queue called “XYZ”.

Following processing, the application next reaches an object with a [LAST: Queue]

outcome. The application will be sent

back to the “XYZ” queue, as it is the most recently used

object of the selected object type.



MAKING AN OBJECT MAPPING ACTIVE OR INACTIVE The ‘Active’ checkbox allows objects to be flagged as either inactive or active

Inactive mappings are not removed from the flow when made inactive, and may still be referenced in other objects as the next step in processing. Care is therefore needed to ensure that deactivating a mapping does not result in a “broken” chain in the flow.

REMOVING AN OBJECT MAPPING The ‘Remove Mapping’ “garbage bin” icon allows the deletion of a mapping from the flow.

Objects are not deleted from the flow when a mapping is deleted, and may still be referenced in other objects as the next step in processing. Care is needed to ensure that deleting a mapping does not result in a “broken” chain in the flow.

Statuses


STATUSES Statuses determine the current state of an application as it progresses through a flow. Statuses are generally used to determine the credit decision of an application or the current place in the decision process.

Managing Statuses To manage statuses, select the “light-bulb” status icon from the main toolbar.

An ‘Edit Statuses’ popup will appear, containing a list of all configured statuses in the flow.

Each status is defined by the fields listed below.

ID The code assigned to the Status.

Priority Is used to determine whether to overwrite the existing status when a new status is assigned.

For example, consider an application with a status of ‘Refer’, which has a configured priority of ‘3’.

If the application goes through a ruleset which assigns a status of ‘Assess’ with a configured priority of ‘7’, the application will remain as ‘Refer’, as '3’ > ‘7’.

However, if that application were to be assigned a status of ‘Withdraw’ with a configured priority of ‘1’, the application will be changed and assigned to ‘Withdraw’, as ‘1’ > ‘3’.

Count in DLA Is used to determine whether an application with the status is included when calculating whether an underwriter has reached their capacity for managing applications, within the DLA structure.

Pending Status A pending status indicates that the status is not intended to be the final credit decision of the application. Pending statuses are often used to signal internally at what stage of the process the application sits.

Statuses


Rate Recalculation When checked, an application which has been assigned this status will run a rate recalculation.

Image The icon that is used to represent the status on the dashboard, and flow mapping screen. The list of images available is below; the image will be recoloured according to the selection of the colour.

Colour The colour of the icon, and used to represent the status in dashboard graphs and charts. A well-defined set of statuses should have similar statuses assigned similar colours, in order to aid association between colour and status meaning.

Description A description of the status; generally a human-friendly, verbose description of the application which can be used in application screens or communications to customers.

Alerts


ALERTS Alerts are flags that are triggered as applications process through a flow. Alerts are used as both a method for flagging information that needs to be followed up with assessors and as the primary way of triggering a change in an application’s status.

Managing Alerts To manage alerts, select the “warning sign” alert icon from the main toolbar.

An “Edit Alerts” popup will appear, containing a list of all configured alerts in the flow.

Each alert is defined by the fields listed below.

ID The code assigned to the Alert.

Status The status that will be assigned to the status when the alert is triggered. The actual status of the application will take into account the status priority (as documented in the Status section above). If an alert is functioning simply as an information notice, normal practice is to assign a status with the lowest priority to ensure that the status is not changed.

Page Link The name of the page to which the alert should provide a link.

Category An alert category, used to grouping similar alerts. When at least one category has been supplied, the display in the screens will automatically categorise triggered alerts.

Description A description of the alert. The description is displayed to operators on the result screen and should provide the full context of the alert what it represents.

Rules


RULES Rules are logic tests and checks that are configured and used in objects to validate, sort, direct, and generally manage applications that are being processed.

Creating Rules Rules can be created in two different ways.

Creating Rules from the Search Bar Rules can be created from the search bar following the completion of a search.

In the search results section an option ‘Create Rule’ is available. Selecting ‘Create Rule’ will cause a new rule editor popup to appear.

Creating Rules from an object Rules can be created when configuring an object in which rules are required.

When selecting from the list of all rules an option ‘Create Rule’ is available. Selecting this rule will cause a new rule editor popup to appear.

Editing Existing Rules Existing rules can be edited in two different ways in the same manner as creating rules.

EDITING EXISTING RULES FROM THE SEARCH BAR Existing rules can be edited from the search bar following the completion of a search.

Rules


Within the ‘Rules’ subgroup of the search results, selecting an existing rule will cause the rule editor popup to appear.

EDITING EXISTING RULES FROM AN OBJECT Existing rules can be edited when configuring an object for which rules are required.

The ellipses button to the right of the rule selection box will open the rule editor popup for the rule.

Rule Editor Popup The Rule Editor popup consists of three tabs.

DESCRIPTION TAB The Description tab of the rule editor popup contains general information relating to the rule.

Rule Name The name of the rule. The Rule Name Is used to uniquely identify the rule in Designer and is only editable when creating a new rule.

Rule Description A textual description of the rule. Intended to be a more human-friendly description of the rule and its function.

Version The version number of the rule. When an object is being newly created the field will simply read ‘New Rule’.

OPTIONS TAB The options tab of the rule editor contains information relating to the group and the calculation method of the rule.

Group The group to which the rule belongs. This is mainly for categorisation purposes and to ease navigation.

Calculation Method The calculation method field allows historical flows to use a now deprecated method of calculating the result of a rule; provided only for backwards-compatibility purposes.

Rules


MAPPING TAB The Mapping Tab of the Rule Editor contains the definition of the rule.

Rules can be written in plain text simply by entering an equation.

The values of items and data bins can be included by selecting the {ITEM} or {DATABIN} buttons at above the text area and choosing the desired item from the resulting popup.

Supported logic operators can be added by selection from the top menus, or by typing the value of the operator.

SUPPORTED OPERATORS

DESCRIPTION

AND Logical AND

OR Logical OR

< Less than

<= Less than or equal to

> Greater than

>= Greater than or equal to

= Equal to

<> Not Equal to

Parentheses can also be used to perform more complex logical structures.

IN and NOT IN The IN and NOT IN operators allow for comparisons between individual values and sets.

SET OPERATORS DESCRIPTION

IN Exists within

NOT IN Does not exist within.

Sets are defined by a pipe separated list of raw values, which can be either the value of an item within the rule or raw input.

Rules


Escape Characters

Raw input must be contained within single apostrophes. When the

input itself contains an apostrophe, it needs to be ‘escaped’ using

another single apostrophe, for example, ‘O’’Donnell’.

Saving Changes

The floppy disk ‘Save’ icon in the top right of the popup will save

the changes to the rule being edited.

OTHER FUNCTIONS

A set of additional functions can be accessed via the icon panel

in the top right of the rule editor.

Save Rule

Selecting the floppy disk ‘Save’ icon will save a new version of the

rule. Once a rule is saved, the changes are propagated to other

users who are modifying the flow in Designer.

Delete Rule

Selecting the garbage can ‘Delete’ icon will delete the rule from

the flow and mapping.

Copy Rule

Selecting the two-window ‘Copy’ icon will open a popup to create a

new rule. This new rule will be prefilled with all the data from the

copied rule.

Test Rule

Selecting the test checklist ‘Test’ is icon will open a popup to test

the rule against an application. For more information see the

Object Testing section of this document.

Where is this Used?

Selecting the magnifying glass ‘Where is this Used?’ icon will

display a list of objects that use the rule as part of its operation.

The object can be opened by selecting the name of the object.

SYSTEM TRUE System True is a special rule that can be used in place of a user defined rule. The definition of System True cannot be changed, and the rule will always return a result of ‘TRUE’.

Items


ITEMS Items are individual data elements that are used throughout designer. Items are configured with an XPATH, an SQL query or simply a constant value.

Creating Items Items can be created in two different ways.

CREATING ITEMS FROM THE SEARCH BAR Items can be created from the search bar following the completion of a search.

In the search results section an option ‘Create Item’ is available. Selecting ‘Create Item’ will cause a new item editor popup to appear.

CREATING ITEMS FROM A RULE OR OBJECT Items can be created when configuring rules, or when configuring certain objects.

When in the ‘Mapping’ tab of the Rule Editor popup, the item picker will allow for a new item to be created.

Editing Existing Items Existing items can be edited in two different ways in the same manner as creating items.

Items


EDITING EXISTING ITEMS FROM THE SEARCH BAR Existing items can be edited from the search bar following the completion of a search.

Within the ‘Items’ subgroup of the search results, selecting an existing item will cause the item editor popup to appear.

EDITING EXISTING ITEMS FROM A RULE Items can be created when configuring rules, or when configuring certain objects.

When in the ‘Mapping’ tab of the Rule Editor popup, items can be edited by either selecting an existing item from the item picker or by double-clicking an item in the rule.

Item Editor Popup The Item Editor popup consists of three tabs.

DESCRIPTION The Description tab of the item editor popup contains general information relating to the item.

Item Name The name of the item. The Item Name is used to uniquely identify the item in Designer and is only editable when creating a new item.

Item Description A textual description of the item. Intended to be a more human-friendly description of the item and its function.

Version The version number of the item. When an item is being newly created the field will simply read ‘New Item’.

OPTIONS The options tab of the item editor contains information relating to the calculation method and the logging of items.

Items


Item Output Type The data type of the item. Is used to confirm the validity of items and their use in rules.

ITEM OUTPUT TYPE

FORMAT

Date yyyy-MM-dd

(e.g 2017-04-10)

Date Time yyyy-MM-dd HH:mm:ss

(eg 2017-04-10 19:50:40)

Integer As described

Text As described

Decimal As described

Item Group The group to which the item belongs. This is mainly for categorisation purposes and to ease navigation.

Recalculate Determines whether the item should be recalculated on each use. This is used in situations where an item is used in multiple objects at different stages of the flow. When checked, following the first reference to the item each subsequent use will recalculate the value. When unchecked, each subsequent use uses the first calculation of the item’s value.

Forbid Logging Determines whether the calculation of the item should be recorded in the processing node of the XML of the application. This is used in situations where the value of the item is sensitive and should not be stored. When checked, the item does not appear in the processing log for the application. When unchecked, the item is included in the processing node as normal.

Quote in Query Determines whether database queries containing this item should be enclosed with quotes. This setting should always be checked unless the item specifically includes quotes that should not be escaped in the database query.

Default Value Determines a default value for the item if there is an error generated by calculating the item value. An error will be generated when the calculation fails: an XPath returns no data, or incompatible data types are used. When checked, the Default Value of the item will be used as the value in place of the error in the application XML. When unchecked, the error will be written into the application XML.

MAPPING The Mapping Tab of the Item Editor contains the definition of the item. The final result of an item is the value of each mapping combined with the actions.

Items


Within each mapping, there are several configuration fields. These fields define the final value of each mapping within the item, which the combine action then uses to calculate the final value of the item itself.

Type Defines the type of mapping. The type of an item should always be considered when using the mapping in a rule, to confirm compatibility with the action being used on it.

The type dictates the subsequent fields that are available, and the type of data that is required in the definition as a result.

ITEM MAPPING

TYPE

FIELDS AVAILABLE

DEFINES

Constant Output Type and

Definition. Any static string

or integer.

Database Function, Output Type

and Definition. An SQL database query.

Item Output Type and

Definition. A name of an item that

exists in the current flow.

Data Bin Output Type and

Definition A name of a data bin that exists in the current flow.

System Output Type and

Definition. The name of a System

Item. (See Below).

XML Function, Qualifier, Output Type and

Definition.

An XPath relating to the Application XML.

Functions An enhanced function to perform to the value defined in the mapping definition. These functions allow for data to manipulated in a more specific manner than a regular item mapping would allow.

A function is used in conjunction with function parameters. These function parameters dictate how the function behaves. Function Parameters must be provided in a comma-separated list.A list of mapping functions and their corresponding parameters are listed on the next page.

XML Functions For XML functions, the Mapping Definition must resolve to an XPath to an application XML location.

Items


MAPPING FUNCTION PARAMETERS DESCRIPTION

Count N/A Duplicates the functionality of the XPath 1.0 count function. EXAMPLE XML: {Qualifer}/count({XPath})

First N/A Duplicates an XPath selector for the first child node of an

element. EXAMPLE XML: {Qualifer}/{XPath}[position()=’1’]

Last N/A Duplicates an XPath selector for the last child node of an

element. EXAMPLE XML: {Qualifer}/{XPath}[position()=last()]

Position Requires a whole value, representing the position of the desired

node amongst its siblings.

Duplicates an XPath selector for a chosen child node of an element. EXAMPLE XML:

{Qualifer}/{XPath}[position()=’{Parameter}’]

Round N/A Duplicates the functionality of the XPath 1.0 round function. EXAMPLE XML: {Qualifer}/round({XPath})

Round Up N/A Duplicates the functionality of the XPath 1.0 ceiling function. EXAMPLE XML: {Qualifer}/ceiling({XPath})

Substring Requires two comma–separated integers. The first number

represents the start position within the string, and the second number represents the length of the substring required.

Duplicates the functionality of the XPath 1.0 substring function. EXAMPLE XML:

{Qualifer}/substring({XPath},{Parameter})

Sum N/A Duplicates the functionality of the XPath 1.0 sum

function. EXAMPLE XML: {Qualifer}/sum({XPath})

The calculated value from the Mapping Definition is represented above by ‘{XPath}’. The XPath relating to the Qualifier selected is represented in the examples above by ‘{Qualifier}’.

Items


Database Functions One Database function is available that allows for a specific operation to be performed on the result of a database query.

MAPPING FUNCTION

PARAMETERS DESCRIPTION

Decrypt N/A

Decrypts a value from the database using the

illion Decisioning decryption method.

Database and XML Functions One joint function is available that allows for an operation on either a node-set or a single column of data returned as a result of a database query.

MAPPING FUNCTION

PARAMETERS DESCRIPTION

Join Values

A string that will be used as a separator

in the combined string

Concatenates all values in the node-set or database column into a single string, using the

parameter as a separator

Min N/A Returns the lowest value of all

values in the node-set or database column.

Max N/A Returns the highest value of all values in the node-set or

database column.

Average N/A

Returns the mean average of all values in the node-set or

database column. Will return an item error if

used on a string.

Base64 Encode

N/A Returns a string of the value in

base64 encoded text.

Qualifier The XPath qualifier that is to be prepended to the XPath provided by an ‘XML’ type mapping. For more information about the definition of XPath Qualifiers, see Appendix A of this document.

Output Type Defines the type of data that will be returned by the mapping. The

output type of the final value of the item must match the output type

defined in the Options tab.

ITEM OUTPUT TYPE

FORMAT

Date yyyy-MM-dd

(e.g 2017-05-01)

Date Time yyyy-MM-dd HH:mm:ss

(eg 2017-05-01 22:53:53)

Integer As described

Text As described

Decimal As described

Date To Months Date to Months is a specific Combine Action which is only available for the first mapping in an item. When the checkbox is selected, the final value of the mapping will be the date represented as a number of months.

FORMULA

Year*12 + Month + (Day/100)

For example, a date of 2017-06-15 would be 24210.15 after the ‘Date to Months’ conversion.

Mapping Definition The Mapping Definition text area allows for the content of an item mapping to be defined. The text area functionally identical to the Rule Editor; for more information, see the Rule Editor Popup section of this document.

Items


The Mapping Definition can contain any combination of Items and static values, provided that the end result matches the definition required (see the type table of this section), and resolves to data matching the selected output type.

Combine Actions Combine Actions allows for multiple different mappings to be calculated together to return a final value for a given item. Each combine action, compatible output types, and behaviour is listed below.

COMBINE ACTION COMPATIBLE W/ OUTPUT TYPES DESCRIPTION RESULTS

+ Decimal or Integer Simple addition value 1 + value 2

- Decimal or Integer Simple subtraction value 1 - value 2

/ Decimal or Integer Simple division value 1 / value 2

* Decimal or Integer Simple multiplication value 1 * value 2

Add Days First Mapping: Date or Date Time

Second Mapping: Decimal or Integer Adds the number of days defines

in the second mapping value to the

DateTime in the first mapping

value.

A single Date or DateTime of value 1,

offset by the number of days in value 2

Days Between Date or Date Time Calculates the number of days

between the two date mapping values.

An integer representing the number of days between.

Date To Months Date or Date Time Converts the date into a decimal

number reflecting the number of months

Year*12 + Month + (Day/100) (rounded

to 2 decimal places)

Months Between Date or Date Time Calculates the number of months

between the two date mapping values.

An integer representing the number

of months between.

String Concatenate TEXT Concatenates the two text mapping values. String - the concatenated text A string representing the match strength.

String Match

Strength

TEXT Performs an SQL SOUNDEX comparison

between the two text mapping values.

STRENGTH VALUES EXACT

STRONG MEDIUM WEAK NONE

String to Uppercase TEXT Capitalises a single text mapping value.

Cannot be used to combine two strings.

String - the first string capitalised.

Items


OTHER FUNCTIONS A set of additional functions can be accessed via the icon panel in the top right of the item editor.

Save Item Selecting the floppy disk ‘Save’ icon will save a new version of the item. Once an item is saved, the changes are propagated to other users who are modifying the flow in Designer.

Delete Item Selecting the garbage can ‘Delete’ icon will delete the item from the flow and mapping.

Copy Item Selecting the two-window ‘Copy’ icon will open a popup to create a new item. This new item will be prefilled with all the data from the copied rule.

Test Item Selecting the test checklist ‘Test’ is icon will open a popup to test the item against an application. For more information see the Object Testing section of this document.

Where is this Used? Selecting the magnifying glass ‘Where is this Used?’ icon will display a list of rules and items that use the item as part of its operation.

The item or rule can be opened by selecting the name.

System Items System Items are hard coded to return useful processing or application information. They can be referenced by selecting the “System” type in the Item Mapping (see the previous section of this document).

Items


Below is a list of system items that can be referenced in the Item Mapping.

CODE DATA TYPE

DESCRIPTION

TODAY Date Time The current system date and time.

LOOP_INDEX Integer Returns the loop index (ie, the number of iterations) where the Loop XPath is iterating over a mapping.

OPERATOR String The username of the operator currently logged in.

LEVEL String The Application Level being used to process the item.

GUID String The GUID of the current session of the user

processing the application.

APPROVAL_CODE

String A randomly generated “approval code”.

Data Bins


DATA BINS Data bins are individual flow elements that allow for the sorting and categorisation of applications into statistical bins. Data bins are configured with an XPATH definition, and a set of configurable outcomes.

Creating Data Bins Data Bins can be created in two different ways.

CREATING DATA BINS FROM THE SEARCH BAR Data bins can be created from the search bar following the completion of a search.

In the search results section an option 'Create Data Bin' is available. Selecting 'Create Data Bin' will cause a new data bin editor popup to appear.

CREATING DATA BINS FROM A RULE OR OBJECT Data bins can be created when configuring rules, or when configuring certain objects.

When in the 'Mapping' tab of the Rule Editor popup, the data bin picker will allow for a new data bin to be created.

Editing Existing Data Bins Existing data bins can be edited in two different ways in the same manner as creating data bins.

EDITING EXISTING DATA BINS FROM THE SEARCH BAR Existing data bins can be edited from the search bar following the completion of a search.

Data Bins


EDITING EXISTING DATA BINS FROM A RULE Data bins can be created when configuring rules, or when configuring certain objects.

When in the 'Mapping' tab of the Rule Editor popup, data bins can be edited by either selecting an existing data bin from the data bin picker or by double-clicking a data bin in the rule.

Data Bin Editor Popup The Data Bin Editor popup consists of three tabs.

DESCRIPTION The Description tab of the data bin editor popup contains general information relating to the data bin.

Data Bin Name The name of the data bin. The data bin name is used to uniquely identify a data bin in Designer, and is only editable when creating a new data bin.

Data Bin Description A textual description of the data bin. Intended to be a more human-friendly description of the data bin and its function.

Version The version number of the data bin. When a data bin is being newly created the field will simply read 'New Data Bin'.

OPTIONS The options tab of the data bin editor contains information relating to the defaults and recalculation of data bins.

Recalculate Determines whether the data bin should be recalculated on each use. This is used in situations where a data bin is used in multiple objects at different stages of the flow. When checked, following the first reference to the data bin each subsequent use will recalculate the value. When unchecked, each subsequent use uses the first calculation of the data bin's values.

Use Default Determines if there should be a default value configurable for situations in which a data bin cannot be calculated. When checked, a default field will be configurable on the mapping tab. When unchecked, the data bin will return a data bin error if the data bin cannot be calculated.

Data Bins


MAPPING The Mapping Tab of the Data Bin Editor contains the definition of the data bin. The final result of a data bin is last sequential data bin mapping that has been calculated.

Within each mapping, there are several configuration fields. These fields define the final bin value of the data bin mapping.

Type Defines the type of mapping. The type of the data bin determines the method by which the bin values are configured, and the validation that is utilised.

DATA BIN TYPE DESCRIPTION

Numeric—Continuous Allows for the definition of an

indefinite number of contiguous, disjoint numerical bands

Numeric—Discrete Allows for the definition of an

infinite number of disjoint, but not contiguous, numerical bands.

Enumeration Allows for the definition of a set of

enumerated data bin values.

Percentage Allows for the definition of a set of bands, with the assignment driven

by a weighted percentage.

Numeric—Continuous When Numeric—Continuous is selected, the following fields are displayed.

Name Determines the name of the mapping value.

Rule Determines whether a data bin mapping row should be calculated.

Mode & XPath/Item Determines the value used to use in the band calculation. The value at the XPath specified or the value of the item selected is used to compare against the data bin bands.

Qualifier Determines the application level at which the result of the data bin should be applied.

Band Mapping The bands are configured at the bottom of the mapping section.

Each bin is listed with the maximum and minimum values. The value in the adjoining text box is the assigned as the data bin value. The mapping enforces validation to ensure that no bands can overlap, and that there are no missing values.

Data Bins


Numeric—Discrete When Numeric—Discrete is selected, the following fields are displayed.



Mode & XPath/Item Determines the value used to use in the range calculation. The value at the XPath specified or the value of the item selected is used to compare against the data bin ranges.

Qualifier Determines the application level at which the result of the data bin should be applied.

Range Mapping The ranges are configured at the bottom of the mapping section.

Each range is listed with the discrete, numeric values that will be used to match the value provided. Hyphens can be used to specify ranges, and commas are used to separate the values. The value on the adjoining text box determines the data bin value. The mapping enforces validation to ensure that no ranges have overlapping values, but will not force a tier to be provided for all values.

Enumeration When Enumeration is selected, the following fields are displayed.



Schema Determines the schema to be used to load a list of enumerations.

Enumeration Type Determines the application level at which the result of the data bin should be applied.

Mode & XPath/Item Determines the value used to use in the range calculation. The value at the XPath specified or the value of the item selected is used to compare against the data bin ranges.

Value Mapping The values are configured at the bottom of the mapping section.

Each value in the enumeration file loaded is populated as data bin value fields. Additional options can be added, and the data bin values can be changed accordingly.

Data Bins


Percentage When Percentage is selected, the following fields are displayed.



Keep on resubmit Determines whether the value should be reassigned in resubmitted applications. This is useful if the goal of the resubmit is to ensure it is categorised in the same way.

Value Mapping The values are configured at the bottom of the mapping section.

Each application is randomly assigned a value based purely on the percentages given. In the example above, an application would have an 80% chance of being assigned a bin value of "Champion", and a 20% chance of being assigned "Challenger". This is technically different from having applications assigned outcomes based on the amount of other applications assigned that outcome, but over a long period of time the difference is statistically insignificant. The mapping enforces validation to ensure that the total "percentage points" exactly equals 100%.

Objects


OBJECTS Objects are the tools with which applications are processed, analysed and generally actioned throughout the flow. They are the core of the Designer: as an application progresses through a flow it gets passed through several objects. Inside those objects, rules and items determine what specific action is performed on the application, before it is sent to the next object. There are many different types of objects, each with their own function and purpose. With objects, applications can be analysed, calculations can be made, bureau reports can be retrieved and third-party services can be integrated.

Creating an Object Objects can be created through two different methods.

FLOW MAPPING When the flow mapping is locked to the current user, objects can be created through the flow mapping. For more information on how to create objects with the Flow Mapping, see the ‘Managing Flow Mappings’ section of this document.

Object Pane An object can also be created via the object pane when the user does not have the flow mapping locked to them. Selecting an object icon from the object pane will display the create object popup.

Modifying Objects

Objects can be modified by accessing the Object Editor popup. This can be achieved several ways.

MODIFYING OBJECTS FROM THE FLOW MAPPING The Object Editor popup will be displayed after selecting an object from the flow mapping screen.

MODIFYING OBJECTS FROM SEARCH MENU The Object Editor popup will be displayed after selecting an object from the search results list.

Objects


Object Types There are numerous types of objects, each with their own functionality and configuration requirements. Each object is described in greater detail further in the document. Every object type and icons relating to them is listed below.

Analyser

Application Comparison

Application Merge

AppWriter

Bureau (illion (formerly D&B))

Bureau (Equifax (fka. Veda))

Bureau (Experian)

Bureau (Centrix)

Calculator

Checklist

Communication

Director

Docusign

External Account

Flow Change

GreenID

Group

Internet Monitor

Loan Calculator

Loan Condition

Matrix

Outcome Tree

Ownership

PPSR

Printing

Product Variant Selector

Queue

Raw Editor

Resubmit

Ruleset

Scorecard

Suspect Register

Variable

Webservice

XML

Objects


Global Objects Global Objects are objects that are referenced across multiple flows, negating the need for identical objects to be maintained in multiple flows.

REFERENCING AN OBJECT AS A GLOBAL OBJECT A global object can be referenced simply by selecting the “global object” checkbox on the object’s ‘Description’ tab. Once checked, a new ‘Global Object Mapping’ tab will become visible, in place of the regular ‘Mapping Tab’ .

This Global Object Mapping tab consists of a drop-down listing each credit product, and an object dropdown. When a credit product is selected in the credit product drop-down, the flow linked to that product is loaded, and a list of objects is returned.

USING GLOBAL OBJECTS An object which references a global object behaves as any other object when placed in the flow, only the internal definition of the object is used. For example, the outcomes in the mapping are specific to flow in which the object is used.

Object Editor Popup

The object editor popup will vary for each type of object being edited; however, all objects feature the same base level functions.

DESCRIPTION TAB The description tab of each object contains basic information about each object. Some objects will have additional fields displayed on the description tab.

For more information see the individual section for each object in this document.

Object Name The name of the object. The Object Name Is used to uniquely identify the rule in Designer and is only editable when creating a new object.

Object Description A textual description of the object. Intended to be a more human-friendly description of the object and its function.

Version The version number of the object. When an object is being newly created the field will simply read ‘New Object’.

Global Objects Designates the object as a reference to a global object. For more information, see the ‘Global Objects’ section of this document.

Objects


MAPPING TAB The mapping tab is used to determine how the object performs its function. A mapping represents a single action performed by the object.

Often, objects are configured with multiple mappings, as the action taken on an application will vary according to how it meets certain criteria (configured via rules). Other objects may perform the same action of different parts of an application, such as different applicants. A mapping can be moved by clicking and dragging the four-arrow move handle icon on the left, allowing you to update the order in which mappings will occur during processing. A mapping can be deleted by selecting the garbage can icon on the right.

ID The ID of a mapping is used to uniquely identify the mapping amongst others in the object. As an object processes an application, each mapping is written into the application XML’s processing tab for debugging and verification purposes. Having unique and meaningful mappings significantly increases the

readability of the processing tab, allowing for quicker debugging and troubleshooting.

Rule Rules are used within mappings to generally determine if a mapping is to be actioned. The rule used to perform this check can be chosen by selecting the input field and choosing from the list of rules.

The rule selected can also be edited by selecting the ellipsis button inside the input field. For more information about rules and how to configure them, see the ‘Rules’ section of this document.

The icon to the right of the input field determines what result of the rule triggers the mapping.

ICON DESCRIPTION

The mapping will execute when the rule evaluates to

‘TRUE’

The mapping will execute when the rule evaluates to

‘FALSE’

Levels Levels refer discrete segments on an application, such as “Principal”, “CoBorrower1” or “Guarantor5”. Levels are used to manipulate objects to both store data under a specific node in an application XML or to restrict an action only to an application level relevant to the call. For example, bureau calls are most commonly performed at an individual applicant level, and the bureau objects can be configured to perform enquiries for CoBorrowers, but not Guarantors. The list of levels available is dependent on the enumeration of Applicant Types in the schema.

Objects


Wildcard Levels

Applicant enumerations which contain an asterisk indicate that they are a “wildcard” applicant type. For example, an object with a configured level of “CoBorrower*” will match all applicants which have an applicant type beginning with “CoBorrower”.

Continue Objects configured with continue options allow for a “break” to be introduced into the object processing. When continue is checked for a mapping, the object will move to the next mapping in the list after processing. When continue is unchecked, the object will not process any more mappings in the object, even if they would otherwise be executed.

Loop XPath The Loop XPath defines the number of times a mapping should be performed, based on the number of elements which exist at the Loop XPath location.

Parameters A list of key-value pairs that are used when processing the mapping.

OUTCOMES The outcomes tab of an object allows for a manipulation of the outcomes following processing an object. It can only be edited when the flow mapping is locked to the user.

The Outcomes tab is functionally identical to manipulating the mapping via the Flow Mapping Screen. For more information, see the 'Managing Flow Mapping' section of this document.

OTHER FUNCTIONS A set of additional functions can be accessed via the icon panel in the top right of the object editor.

Save Object Selecting this icon will save a new version of the object. Once an object is saved, the changes are propagated to other users who are modifying the flow in Designer.

Delete Object Selecting this icon will delete the object from the flow and mapping. The delete icon will only display if the user has the mapping locked.

Copy Object Selecting this icon will open a popup to create a new object. This new object will be prefilled with all the data from the copied object.

Test Object Selecting this icon will open a popup to test the object against an application. For more information see the Object Testing section of this document.

Objects | Analyser Object


ANALYSER OBJECT

The Analyser object is used to examine applications and search for applications with duplicate information.

The Analyser object is most commonly used to identify duplicate applications or previous applications submitted on the system by the same applicants.

DESCRIPTION The Description tab of the Analyser object features two fields in addition to the standard object description tab.

Consolidate Matches The ‘Consolidate Matches’ flag determines how the Analyser Object handles previous applications which match the current application in more than one way.

For example, the name and address of a previous applicant match the current application, causing two matches to be made. Or, an Analyser object with the same rule has been run in the flow multiple times.

Add Applicant Data The Add Applicant Data checkbox determines how the Analyser Object stores information relating to the matched application. This is mainly useful when application data has matched with non-individual data, such as phone number or email addresses.

When checked, the applicant details from the application that has been matched are included in the duplicate checks node of the application XML. When unchecked, only the details that matched the rule used to find duplicates are included.



MAPPING The Mapping tab lists each separate action for the Analyser object to execute. Each mapping row contains several configuration fields.

Levels Determines the Application Level used when processing the mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document. The Level selected for a Duplicate Analyser mapping should align with the RuleID selected. For example, for RuleID “[Individual] Duplicate Identification 1.0”, the mapping needs to be run on an “Individual” applicant Level.

Rule

The rule indicates whether or not to execute a given mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

RuleID The preconfigured Analyser rule that is to be used to compare the current application to previous applications. Each rule analyses different application data, and uses different ‘strengths’ parameters to determine what a match is.

[Company] Duplicate ABN ACN 1.0 The Duplicate ABN ACN 1.0 Rule is used to identify potential duplicate applications based on the ABN or ACN of each company applicant.

STRENGTH

DESCRIPTION

Exact

ABN/ACN Match Strong

Average

Weak

PARAM. CODE

DESCRIPTION

CD_STATUS

The value must be a comma-separated list of

statuses. When the parameter is provided, the

Analyser object will only analyse applications

with a status that exists in the provided list.

NO_MONTHS

The value must be a whole number. When the

parameter is provided, the Analyser object will

only analyse applications submitted in the last

n months.



[Company] Duplicate Company Number 1.0 The Duplicate Company Number 1.0 Rule is used to identify potential duplicate applications based on the New Zealand Company Number of each company applicant.

STRENGT

H

DESCRIPTION

Exact

New Zealand Company Number Match

Strong

Average

Weak

PARAM. CODE DESCRIPTION

CD_STATUS

The value must be a comma-separated list of statuses. When the parameter is provided, the Analyser object will only analyse applications with a status that exists in the provided list.

NO_MONTHS

The value must be a whole number. When the parameter is provided, the Analyser object will only analyse applications submitted in the last

n months.

[Company] Duplicate CompanyName 1.0 The Duplicate CompanyName 1.0 Rule is used to identify duplicate applications based on the legal name or the trading name of each company applicant.

STRENGTH

DESCRIPTION

Exact

The legal name in the current application matches the legal or trading name of a previous

application. OR

The trading name in the current application matches the legal or trading name of a previous

application

Strong

The legal name in the current application is similar to the legal or trading name of a previous

application. OR

The trading name in the current application is similar to the legal or trading name of a previous

application.

Average Not used.

Weak

* The test used to determine if a name is “similar” uses the SOUNDEX and DIFFERENCE SQL functions. For more information about how these SQL functions work, refer to Microsoft’s SQL documentation.

PARAM. CODE

DESCRIPTION

CD_STATUS







NO_MONTHS




n months.

[DnB] Bureau DnBCCBMatch 1.0 The Bureau DnBCCBMatch 1.0 rule is used to compare the data provided on an application to the data returned by bureau reports. The alert triggered by this rule indicates that the application data matches the bureau data. The rule works by calculating a "strength score". The strength score is a cumulative score indicating how much data differs and the relative significance of that mismatching data. The score initialises at 0, and each piece of mismatching data increments the strength score by the value listed.

MISMATCHING

DATA

INCREMEN

T

First Name +10

Surname +10

Driver Licence +15

Current Street No +4

Current Street Name +2

Current State +5

Current Postcode +2

DOB Year +10

DOB Month +10

DOB Day +10

STRENGTH

DESCRIPTION

Exact Strength Score is exactly 0

Strong Strength Score is between 1 and 9, inclusive.

Average Strength Score is between 10 and 14,

inclusive.

Weak Strength Score is greater than 14.

PARAM. CODE

DESCRIPTION

ID_BUREAU

The ID of the bureau to be used to match

applications. The ID is used to load all bureau

reports at the XPATH

“result/bureau_list/bureau[@id={ID_BUREAU}]

”

[DnB] Bureau DnBDirectMatch 1.0 The Bureau DnBDirectMatch 1.0 rule is used to compare the data provided on an application to the data returned by commercial bureau reports. The alert triggered by this rule indicates that the application data matches the bureau data. The rule works by calculating a “soundex score”. The soundex score for this case uses the SOUNDEX and DIFFERENCE SQL Functions to determine the relative similarity of the company name on the application.

STRENGTH

DESCRIPTION

Exact Soundex Score is exactly 0.

Strong Soundex Score is either 1 or 2.

Average Soundex Score is exactly 3

Weak Soundex Score is greater than 3.

PARAM. CODE

DESCRIPTION

ID_BUREAU

The ID of the bureau to be used to match applications. The ID is used to load all bureau

reports at the XPATH “result/bureau_list/bureau[@id={ID_BUREAU}]”



[Everyone] Custom Duplicate 1.0 The Custom Duplicate 1.0 rule is used to perform a custom duplicate query.

STRENGTH

DESCRIPTION

Exact

Data exists in the result of the custom query. The query must return the id_request of the

application as the first column, and the status as the second column.

Strong

Not used. Average

Weak

PARAM. CODE

DESCRIPTION

SQL QUERY

The SQL query that is to be run to find duplicates. The parameter accepts placeholders that will be replaced before the query is executed. Custom

Parameters can be referenced using these parameters; {1}, {2}, {3}, etc, representing the

order of the parameters in the mapping.

MATCH_TEXT The text that is displayed to the user on the result

screen when a match is found.

[Everyone] Duplicate Address 1.0 The Duplicate Address 1.0 Rule is used to identify duplicate applications based on the address of applicants.

STRENGTH

DESCRIPTION

Exact The address, including any unit number, matches exactly.

Strong The address, excluding any unit number, matches exactly.

Average Not Used.

Weak

PARAM. CODE

DESCRIPTION

CD_STATUS


NO_MONTHS

The value must be a whole number. When the parameter is provided, the Analyser object will

only analyse applications submitted in the last n months.

CD_TYPE

The value must be a comma-separated list of address types. When the parameter is provided, the Analyser object will only analyse addresses

with a type that exists in the provided list.



[Everyone] Duplicate Application Address 1.0 The Duplicate Application Address 1.0 Rule is used to identify duplicate applications based on addresses that exist on an application.

STRENGT

H

DESCRIPTION

Exact The number of addresses exactly matching the

application address is at least the number required

by the NO_ALLOWED_COUNT parameter.

OR

There were no addresses matched and the FG_

ALERT_NOT_FOUND parameter is 1.

Strong

Average

Weak

PARAM. CODE DESCRIPTION

FG_ALERT_NOT_FOUND

The value must be either 0 or 1.

When the value is 1, the rule will trigger an

alert if there are no duplicates found. When the

value is 0, the rule will trigger an alert if the

required

number of duplicates (see below) is found

NO_ALLOWED

_ COUNT

The number of duplicate addresses that must be

identified before an alert is triggered.

CD_TYPE_WITH

The address types to be used to find duplicate

addresses.

CD_TYPE_

AGAINST

The address types to be compared against the

“with” addresses and considered as duplicates.

[Everyone] Duplicate Email 1.0 The Duplicate Email 1.0 Rule is used to identify duplicate applications based on email addresses.

STRENGTH

DESCRIPTION

Exact The email address matches exactly.

Strong

Not Used. Average

Weak

PARAM. CODE

DESCRIPTION

CD_STATUS


NO_MONTHS

The value must be a whole number. When the parameter is provided, the Analyser object will only analyse applications submitted in the last

n months.



[Everyone] Duplicate PhoneNumbers 1.0 The Duplicate PhoneNumbers 1.0 Rule is used to identify duplicate applications based on the phone numbers of applicants.

STRENGTH

DESCRIPTION

Exact The home phone of the current application matches the home phone of a previous application.

OR The work phone of the current application matches

the work phone of a previous application. OR

An ‘Other’ phone number of the current application matches an ‘other’ phone number of the same type

on a previous application.

Strong

Average

Weak

PARAM. CODE

DESCRIPTION

CD_STATUS

The value must be a comma-separated list of statuses. When the parameter is provided, the

Analyser object will only analyse applications with a status that exists in the provided list.

NO_MONTHS



PHONE_TYPE

The value must be a comma-separated list of phone types. When the parameter is provided,

the Analyser object will only analyse phone numbers with a type that exists in the provided

list.

[Individual] Duplicate Identification 1.0 The Duplicate Identification 1.0 Rule is used to identify duplicate applications based on the identification numbers provided.

STRENGTH

DESCRIPTION

Exact The driver licence number of the current application

matches the driver licence number of a previous application.

OR The passport number of the current application

matches the passport number of a previous application.

OR An ‘Other’ identification number of the current

application matches an ‘other’ identification number of the same type on a previous application.

Strong

Average

Weak

PARAM. CODE

DESCRIPTION

CD_STATUS

The value must be a comma-separated list of statuses. When the parameter is provided, the

Analyser object will only analyse applications with a status that exists in the provided list.

NO_MONTHS



IDENTIFICATION_TYPE

The value must be a comma-separated list of identification types. When the parameter is

provided, the Analyser object will only analyse identifications with a type that exists in the

provided list.



[Individual] Duplicate Individual 1.0 The Duplicate Individual 1.0 Rule is used to identify duplicate applications based on the personal details of individual applicants.

STRENGTH

DESCRIPTION

Exact

The first name, surname and date of birth

of a current applicant match an applicant


Strong

The surname of a current applicant matches the

first name, the first name matches the surname,

and the date of birth matches that of an applicant


OR

The first name of a current applicant matches

the middle name, and the middle name

matches the first name, and the surname and

dates of birth match that of an applicant on a

previous application.

OR

The driver licence number and date of birth of a

current applicant matches that of an application


Average

The surname and date of birth of a current

applicant match an applicant on a

previous application.

Weak Not used.

PARAM. CODE

DESCRIPTION

CD_STATUS





NO_MONTHS




n months.

[Individual] Duplicate Name 1.0 The Duplicate Name 1.0 Rule is used to identify duplicate applications based on the names of previous individual applicants.

STRENGT

H

DESCRIPTION

Exact The surname, date of birth and the postcode of the

current address of a current applicant match that of

an application on a previous application.

Strong

The first name, surname and date of birth of a current applicant match an applicant on a previous

application.

Average The first name and surname of a current applicant

match an applicant on a previous application.

Weak

The first name, the first letter of the middle

name, and surname of a current applicant match

an applicant on a previous application.



PARAM. CODE

DESCRIPTION

CD_STATUS





NO_MONTHS




n months.

[Veda] Bureau VedaCompMatch 1.0 The Bureau VedaCompMatch 1.0 rule is used to compare the data provided on an application to the data returned by bureau reports. The alert triggered by this rule indicates that the application data matches the bureau data. The rule works by calculating a “strength score”. The strength score is a cumulative score indicating how much data differs and the relative significance of that mismatching data. The score initialises at 0, and each piece of mismatching data increments the strength score by the value listed.

MISMATCHING

DATA

INCREMEN

T

First Name +10

Surname +10

Driver Licence +15

Current Street No +4

Current Street Name +2

Current State +5

Current Postcode +2

DOB Year +10

DOB Month +10

DOB Day +10

STRENGTH

DESCRIPTION

Exact Strength Score is exactly 0

Strong Strength Score is between 1 and 9, inclusive.

Average Strength Score is between 10 and 14, inclusive.

Weak Strength Score is greater than 14.

PARAM. CODE

DESCRIPTION

ID_BUREAU

The ID of the bureau to be used to match

applications. The ID is used to load all bureau

reports at the XPATH

“result/bureau_list/bureau[@id={ID_BUREAU}]

”



Duplicate Request Translation Specifies an XSLT that is to be used to process the duplicate application. The result of the transformation is then included within the duplicate list node of the application XML for display in the Duplicate control.

Min Strength Determines the minimum strength bracket to be used when considering a "match".

Max Strength Determines the maximum strength bracket to be used when considering a "match".

Alert The alert to be triggered if the rule finds at least one match.

Continue on Alert Determines the behaviour of the Analyser object once a match has been found. When checked, the object will continue processing the remaining mappings as normal. When unchecked, the object will move directly to the outcomes if a match has been found.

Custom Outcome The Custom Outcome to be used if the Analyser object finds a match.

Application Message Determines the Application Message that is included in the Application XML when a match is found. The Application Message can be displayed on multiple different pages of the application.

Parameters A list of parameters that will be passed to the Analyser object when processing the matching rules. The parameters used by each rule vary and are detailed above.

OUTCOMES The Outcomes tab of the Analyser object does not differ from the standard object outcome tab.

Objects | Application Comparison Object


APPLICATION COMPARISON OBJECT The Application Comparison object is used to compare two different application XMLs and see the differences in data between them. The application comparison will write a list of differences to the application XML for further inspection. This is most commonly used in two scenarios: to compare a previous version of an application with the current version, and to compare one application to an entirely different (but often related) application.

DESCRIPTION

The Description tab of the Application Comparison Object object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each separate comparison for the Application Comparison object to execute. Each mapping row contains several configuration fields.

Objects | Application Comparison Object


ID The ID of the Mapping row; used to uniquely identify the mapping in the list. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Rule The rule indicates whether or not to execute a given mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Transformation File An XSLT that is to be run over the application XML for both the “Be- fore” application and the “After” application. Designed to be used to compare only relevant sections of the application XML.

Before Application ID The Application ID of the first application to compare. This must be an application that exists in the current environment and company. If the Application ID field is blank, the ID of the application being processed will be used.

Before Sequence No The Sequence No of the first application to compare. If the sequence number field is blank, then the sequence number of the application being processed will be used.

After Application ID The Application ID of the second application to compare. If the Application ID field is blank, the ID of the application being processed will be used.

After Sequence No The Sequence No of the second application to compare. If the sequence number field is blank, then the sequence number of the application being processed will be used.

OUTCOMES The Outcomes tab of the application comparison object does not differ from the standard object outcome tab.

Objects | Application Merge Object


APPLICATION MERGE OBJECT The Application Merge object is used to merge application data from another application into the application undergoing processing. This is useful in situations where previously cleared data needs to be reincorporated into the current version of an application.

DESCRIPTION The Description tab of the Application Merge object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each separate merge action for the Application Merge object to execute. Each mapping row contains several configuration fields.

Objects | Application Merge Object



Levels Determines the Application Level used when processing the mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.


Transformation File An XSLT that is used to return the merged application XML. The Application Merge object will combine the full application data from both the “Previous” application and the application being processed into a temporary “merged” XML.

PREVIOUS APPLICATION

CURRENT APPLICATION

TEMPORARY “MERGED” XML

<inteflow> … application 1

</inteflow >

<inteflow>

… application 2

</inteflow >

<merge> <previous> <inteflow> … application 1 </inteflow > </previous> <current> <inteflow> … application 2 </inteflow> </current> </merge>

The Transformation XSLT will be used to pass over the temporary XML, and the output will be saved as the new application XML for the application. By necessity, the XSLT will need to store a complete and valid application XML. Following the merge, the information node of the Application XML will be updated with the previous application and sequence.

Previous Application ID The Application ID of the previous application to merge. If the Application ID field is blank, the ID of the application being processed will be used.

Previous Application Sequence The Sequence No of the previous application to merge. If the sequence number field is blank, then the sequence number of the application being processed will be used.

Continue Determines whether to continue processing the other rows of the object after processing the current row. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Parameters A list of parameters that will be passed to the XSLT. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

OUTCOMES The Outcomes tab of the Application Merge object does not differ from the standard object outcome tab.

Objects | AppWriter Object


APPWRITER OBJECT The AppWriter object is used to directly modify the XML of an application. The AppWriter object is most commonly used to prefill information into the application XML, outside of the normal capture process. For example, existing customer information from a core banking system call, or bank statement information from a third-party financial verification service.

DESCRIPTION The Description tab of the AppWriter object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each separate action for the AppWriter object to execute. Each mapping row contains several configuration fields.




Mode Either ‘XSLT’ or ‘XPATH’. Determines the method of execution for the AppWriter.

XSLT Mode When using XSLT mode, the AppWriter control will pass the entire application through the XSLT-defined in the ‘Transform’ field.

Transform The filename of the XSLT that is used to perform the AppWriter. The XSLT will be required to return the entire application XML with the desired changes included.

XPath Mode When using XPath mode, the AppWriter control will simply write the result of the ‘Value’ field into the XPath defined by the ‘Qualifier’ and the ‘XPath’ fields.



Qualifier An XPath qualifier. The XPath of the qualifier is prepended to the XPath provided in the XPath field.

XPath The XPath of the node that is to have the value written in by the AppWriter. The XPath entered is appended to the XPath relating to the Qualifier.

Value The value that is to be written into the node indicated by the Qualifier and XPATH. Can either be a constant or an item.

Append The Append check box determines how the AppWriter will write to the XPath described by the Qualifier and XPath fields. When checked, the AppWriter control will add a new instance of a node if the node described already contains data. When unchecked, the AppWriter will override the existing node.



EXISTING XML OUTPUT - UNCHECKED

OUTPUT - CHECKED

<example_element>

<target_element> “ABC”

</target_element>

</example_element>

<example_element>

<target_element> “New Value”

</target_element>

</example_element>

<example_element> <target_element> “ABC” </target_element> <target_element> “New Value” </target_element>

</example_element>

Remove Blank The Remove Blank check box determines how the AppWriter will behave if the Value provided to write in is empty. This would most likely be the result of an item with a conditional value. When checked, the AppWriter control will remove a node if there are no contents to write in.

EXISTING XML OUTPUT -

UNCHECKED OUTPUT - CHECKED

<example_element>

<target_element> “ABC”

</target_element>

</example_element>

<example_element>

<target_element>

</target_element>

</example_element>

<example_element> </example_element>

Fix Node Order The Fix Node Order checkbox determines whether the AppWriter object will attempt to align the application XML after modification to the schema. When checked, the AppWriter object will reorder every application XML node in an attempt to match the order of the nodes to the core schema.

Continue if written Determines whether to continue processing the other rows of the object after processing the current row. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Loop XPath Determines whether to loop over an application element. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.


OUTCOMES The Outcomes tab of the AppWriter object does not differ from the standard object outcome tab.

Objects | Bureau Enquiry Objects


BUREAU ENQUIRY OBJECTS Bureau enquiry objects are used to make a credit enquiry to a credit bureau for a given application. There are three tabs used to configure the Bureau Objects.

DESCRIPTION The Description tab of the bureau objects do not differ from the standard object description tab.

MAPPING The Mapping tab lists each separate bureau call for the bureau object to execute. Each mapping row contains several configuration fields. Each bureau object is identical, with the exception of the security settings.

illion (formerly D&B)

Experian

Equifax (formerly Veda)

Centrix




Bureau Product The Product Code of the product being ordered from the bureau. For more information about bureau product codes, refer to the technical specification for each bureau. A list of fully supported bureau products is displayed within the drop down list. However, any bureau report can be ordered by selecting the 'Define product manually' dropdown.




Alert on failure Determines the alert triggered when the call to the bureau fails.



Retries Determines the number of times the Bureau object shall attempt to retry a bureau enquiry once a timeout has been received.

Delay Determines the length of time, in seconds, that the Bureau object should wait before attempting to retry a bureau enquiry.

Adhoc Dictates whether the enquiry is available exclusively for ad-hoc bureau requests through the Bureau Tree screen control.

Loop Xpath Determines whether to loop over an application element. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Schema – Request Specifies an XSLT that will be used to transform the application XML into the required format of the bureau enquiry. It is highly recommended that only XSLTs produced and maintained as part of the illion Decisioning solution are used.

Schema – Response Specifies an XSLT that will be used to transform the result of the bureau enquiry before it is stored in the application XML.

Schema – Display Transform Specifies an XSLT that will be used to transform the bureau enquiry prior to the Display transformation being applied.

Schema – Display Specifies an XSLT that will be used to display the result of the bureau enquiry to the user. The user is able to view the result of all bureau enquiries through the BureauTree screen control.

Schema – Display Output

If option un-checked (default), the display stylesheet will be embedded into the bureau display page in Integate. If option checked, the display stylesheet display in an iFrame on the bureau display page in Integate.

Schema – Content Type Specifies the data type of the contents of the request being sent to the bureau. When not stated, the value will default to 'text/XML'.

Schema – Attach Display The 'Attach Display' setting determines whether the bureau object should store the translated bureau reports within the application XML. When 'HTML - CDATA' is selected, the bureau report will be stored in raw HTML within a "CDATA" tag. When HTML - Base64' is selected ,the bureau report will be stored in base-64 encoded HTML.

Schema – Service Code Determines the service code to use when performing the bureau enquiry. For more information, refer to the technical documentation of the bureau.

Schema – Service Version Determines the service version to use when performing the bureau enquiry. For more information, refer to the technical documentation of the bureau.



Security - illion (formerly D&B) For more information regarding these fields, refer to the illion Technical Information Packs or subscriber information.

Subscriber The illion subscriber code of the company performing the enquiry.

Password The illion subscriber password.

User ID The subscriber User ID of the company to be used when performing the enquiry.

Request URL The URL endpoint to use to make the bureau enquiry.

Request Version The version of the request used to make the bureau enquiry.

Request Mode The mode of the request used to make the bureau enquiry.

Timeout Determines the length of time, in seconds, beyond which illion Bureau object will consider the enquiry to have timed out.

Account Type The illion account type code used to perform the bureau enquiry.

DIT Enquiry The DIT Enquiry Type to be used when performing the bureau enquiry.

DIT Soap Action The DIT Soap Action to be used when performing the bureau enquiry.

Use Service Layer Determines whether the bureau call should be executed via the Service Layer. For more information, contact the illion Decisioning Support Team via the JIRA Service Desk:

https://servicedesk.illion.com.au

https://servicedesk.illion.com.au/



Security - Equifax (Formerly Veda) For more information regarding these fields, refer to the Equifax Technical Guide or subscriber information.

Member Code The Equifax subscriber code of the company performing the enquiry.

Security The Equifax subscriber security code of the company performing the enquiry.

SSL Password The SSL Access Password to use when performing the enquiry.

SSL Access The SSL Access Code to use when performing the enquiry.


Request Version The version of the request used to make the bureau enquiry.


Timeout Determines the length of time, in seconds, beyond which the Equifax Bureau object will consider the enquiry to have timed out.

Account Type The Equifax account type code used to perform the bureau enquiry.



Security - Experian For more information regarding these fields, refer to the Experian Technical Guides or subscriber information.

Password The Experian subscriber password of the company performing the enquiry.

Username The Experian subscriber username of the company performing the enquiry.


Domain The Domain used to perform the bureau enquiry.


Timeout Determines the length of time, in seconds, beyond which the Experian Bureau object will consider the enquiry to have timed out.

Account Type The Experian account type code used to perform the bureau enquiry.



Security - Centrix For more information regarding these fields, refer to the Centrix Technical Information Resources or subscriber information.

Subscriber The Centrix subscriber code of the company performing the bureau enquiry.

Password The Centrix subscriber password of the company performing the bureau enquiry.

User ID The User ID to be used when performing the bureau enquiry.

Request URL The URL endpoint to use to perform the bureau enquiry.

Enquiry Reason The Enquiry Reason code to use when performing the bureau enquiry.

Request Mode The mode of the request used to perform the bureau enquiry.

Timeout Determines the length of time, in seconds, beyond which the Centrix Bureau object will consider the enquiry to have timed out.

Account Type The Centrix account type code used to perform the bureau enquiry.

Soap Action The SOAP Action to use to perform the bureau enquiry.

HTTP Username The HTTP Username to use to perform the bureau enquiry.

HTTP Password The HTTP Password to use to perform the bureau enquiry.



Reuse Logic – Past Enquiries The Past Enquiries option within the Reuse Logic section determines the behaviour of the Bureau object when looking for matching enquiries. When selected, the object will look for applications within the contents of the application being processed for existing bureau reports, to ensure that no unnecessary, duplicate calls are made to the bureau.

Conditions

The following fields are the same value in the application XML:

INDIVIDUAL COMPANY

First Name Entity Type

Middle Name ABN

Surname ACN

Date of Birth NCN

Gender DUNS

Current Address Legal Name

Drivers License Trading Address

AND

The age of the existing report is less than the number of days specified in the "Use Enquiries within last field" (see below).

AND

The conditions selected in the "Match Using" and "Bureau Errors" settings match. (see below).

If all the conditions have been met, the object will reuse the bureau report and a new bureau enquiry will not be performed.

Use enquiries within last Dictates, in days, how the long in the past Bureau object will look for enquiries to reuse existing enquiries on an application. The value is fed into the logic that searches for a duplicate enquiry (see below).

Bureau Errors Determines whether the Bureau object should reuse enquiries which were identified as containing an error,

Append Determines how the Bureau object will write store bureau enquiries if there is already an enquiry in the application XML.

When "Append" is selected, the Bureau object will add the new bureau call to the bottom of the list of bureau reports in the application XML. When "Replace" is selected, the Bureau object will replace the existing bureau report with the new one.

Match Using Determines the matching method used by the Bureau object. When "Enquiry ID & Product" is selected the Bureau Object ID, bureau product and service code must all match the duplicate enquiry. When "Product Only" is selected only the bureau product and service code are used.



Other Applications The Past Enquiries option within the Reuse Logic section determines the behaviour of the Bureau object when looking for matching enquiries. When selected, the object will look for applications within the contents of the application being processed for existing bureau reports, to ensure that no unnecessary, duplicate calls are made to the bureau. The logic of this setting is completely independent from that of the "Past Enquiries" setting. As a consequence, it is possible to configure the Bureau object so that it looks only at other applications, ignoring enquiries on the application being processed. The side effect of this is that it is possible for bureau enquiries to be updated after being processed by post-bureau rule sets. It is recommended that if only using the "Other Application" matching that the application is reprocessed by any post-bureau rules. The Past Enquiries setting does, however, take precedence over the Other Applications logic; when a valid, matching enquiry is found on the same application, no search is made on external enquiries. When selected, the bureau object will reuse a bureau enquiry from

the most recent application which matches the following criteria.

Conditions

The bureau enquiry type matches the type requested in the current application.

AND

There was no error received when making the bureau enquiry.

AND

The conditions selected in the "Match Using" and "Only use enquiries with matching" settings match. (see below).

AND

The following fields of the current application match that of the bureau enquiry.

INDIVIDUAL

OR

COMPANY

First Name ABN

Surname ACN

Date of Birth NCN

EITHER DUNS

Street No.

Street

Name

Postcode

Drivers Licence or

Passport, provided

there is not another

form of identification

on the new

application.

AND

The age of the existing report is less than the number of days specified in the "Use Enquiries within last field" (see below).



Use enquiries within last Dictates, in days, how the Bureau object will reuse existing enquiries on an application. The value is fed into the logic that searches for a duplicate enquiry (see below).

Only use enquiries with matching Restricts the matching logic used to only use applications which have been submitted by an operator under the same merchant as the current application.

Match Using Determines the matching method used by the Bureau object. When "Enquiry ID & Product" is selected the Bureau Object ID, bureau product and service code must all match the duplicate enquiry. When "Product Only" is selected only the bureau product and service code are used.

Parameters A list of parameters that will be passed to the bureau when performing the bureau enquiry, and which transformation into which they will be passed.

Auto Enquiries Automatic Enquiries are used to automatically order bureau reports for entities returned in a primary bureau report. For example, a director or parent company identified as part of the bureau reports on an initial entity.

Auto Enquiries – Parent Enquiry The ID of the bureau report containing the entities for which a bureau enquiry will automatically be performed.

Auto Enquiries – XPath An XPATH within the bureau enquiry containing the details entity to be used for the new bureau enquiry.

Auto Enquiries – Relationship The relationship between the entity in the parent bureau enquiry and the automatic bureau enquiry.

AVAILABLE

RELATIONSHIP

TYPES

Director

Directorship

Director Boards

Indv. Proprietor

Org. Proprietor

Proprietorship

Possible Match

Cross Reference

Search Match

Auto Enquiries – Maximum The Maximum number of automated bureau enquiries to be ordered for entities within the parent enquiry.

Post Bureau Ruleset This setting determines the object that will be run following the bureau enquiry. Any outcomes of the object will not be used following processing; the application will continue to be processed any other bureau enquiries.

OUTCOMES The Outcomes tab of the Bureau objects do not differ from the standard object outcome tab.

Objects | Calculator Object


CALCULATOR OBJECT The Calculator object passes application XML to a Microsoft Excel file, then reads input from that Excel back into the Application XML. The Calculator object is one of the most commonly used objects in Designer, and is used to leverage the potential of Excel to perform complex loan repayment calculations, compounding interest, commissions or any other type of mathematical function. There are three tabs used to configure a Calculator object.

DESCRIPTION The Description tab of the Calculator object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each separate calculation for the Calculator object to execute. Each mapping row contains several configuration fields.





Transformation File An XSLT that is used to generate the input for the Excel Calculator. The XSLT will be ran across the entirety of the application, and must be in a quasi-HTML table format.

APPLICATION XML REQUIRED XSLT OUTPUT /

EXCEL INPUT FORMAT

<application>

…

<income>

<am_amount> 500

</am_amount> <cd_type> Salary </cd_type>

</income>

…

</application>

<table>

<row>

<cell>

Income - Salary

</cell>

<cell> 500

</cell>

</row>

</table>

The table defined by the XSLT output will be used to replace the contents of the Input sheet of the Excel spreadsheet.

Excel Files An .xls file that uses the output from the transformation file and returns a list of XPaths and values to be written back into the application by the Calculator object.

File Type + Format The file must be of type .xls in order to be read by the Calculator object, contain at least two sheets: a sheet named ‘Input’ and a sheet named ‘Output’. Any number of additional sheets can be used for calculation.

Input The Input sheet will be populated as per the output of the Transformation File as described in the previous section.

Intermediate Sheets The values from the input sheet can then be manipulated and used in various calculations to meet any given requirements. All Excel functions used must be supported by NPOI .NET Version 2.



Output The output sheet will be read by the Calculator object and used to manually write and change values in the application XML. The output sheet must adhere to the format detailed to the left.

Loop Xpath Determines whether to loop over an application element. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.


OUTCOMES The Outcomes tab of the Calculator object does not differ from the standard object outcome tab.

A Write TRUE/FALSE Dictates whether the data in the row is to be written to the

application XML.

B Xpath XPath An XPATH to the application node into which the value

should be written.

C Level See Xpath Qualifiers

in Appendix

An application Level. Prepends the XPath of the level to XPath in the Xpath column.

D Append TRUE/FALSE

Dictates whether to replace an existing node or append a new node to it.

EXISTING XML TRU

E FALS

E

<example>

<target> “ABC” </target>

</example>

<example>

<target> “New Value” </target>

</example>

<example> <target> “ABC” </target> <target> “New Value” </target>

</example>

E Value Anything

The value to be written into the node indicated. Even though there is no restriction on the data that will be read

in by the Calculator object, there application XML must still pass schema validation.

Objects | Checklist Object


CHECKLIST OBJECT The checklist object is used in conjunction with a screen control to restrict the progress of an application until items in a checklist have been manually checked. The checklist object populates the checklist options node in the application XML. This node is used by the control display to the user on the screen, and the state of the checkbox is updated in the XML when an option is checked/unchecked.

After submission, a checklist object is used again (either the same or a different object) to verify the required options have been checked, add additional options or prevent the application from continuing processing. This is most commonly used to forcibly guarantee human interaction in the credit process, either as an additional prompt for action or as a manner of tracking the users actioning applications.

DESCRIPTION The Description tab of the Checklist object features four fields in addition to the standard object description tab.



Hide Existing Items The Hide Existing Items objects flag determines how the Checklist object will handle checklist options that already exist in the application XML. For example, an application passes through a checklist object for the second time or passes through more than one checklist while being processed. When checked, all checklist options that currently exist on an application will be marked as “hidden”, regardless of whether their checked/unchecked status or the specific checklist object that added it.

APPLICATION BEFORE PROCESSING

HIDE EXISTING ITEMS CHECKED

HIDE EXISTING ITEMS UNCHECKED

<checklist_options>

<option>

… <fg_shown> 1

</fg_shown>

</option>

<option>

… <fg_shown> 0

</fg_shown>

</option>

</checklist_options>

<checklist_options>

<option>

… <fg_shown> 0

</fg_shown>

</option>

<option>

… <fg_shown> 0

</fg_shown>

</option>


<checklist_options>

<option>

… <fg_shown> 1

</fg_shown>

</option>

<option>

… <fg_shown> 0

</fg_shown>

</option>


Evaluate Options The Evaluation Options Checkboxes determines whether the checklist object should validate whether checklist options have been marked as checked. When checked, the Checklist object will iterate over each checklist object in the application XML to verify that the option has been checked. If the Checklist object finds an unchecked option, it will return a custom outcome of “FAIL”, which can then be used on the ‘Outcomes’ tab to control any future processing.

Check Only This Checklist The second checkbox determines the scope of validation for the Checklist object. When it is checked, the Checklist object will only attempt to validate whether the checklist options for this individual object have been checked.

Fail Application Message The “Fail Application Message” text box defines text that is displayed to the user when they attempt to progress an application without having the required options checked. The message will be used by the Action List control after an action which cannot be completed has been selected.

MAPPING The Mapping tab lists each separate checklist option for the Checklist object to execute. Each mapping row contains several configuration fields.



ID

The ID of the Mapping row; used to uniquely identify the mapping in the list. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Rule Level Determines the Application Level used when processing the mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.


Store Level Allows the application level at which the checklist options are stored to vary from the level of the rule. When the ‘Use rule level to store checklist option’ checkbox has been selected, the Rule level will be used to determine where the checklist data is stored in the application XML. When unchecked, the store level dropdown will be used.

Store XPath Determines the exact XPath to the location at which the checklist options will be stored. The XPath in this field will be concatenated with the XPATH from the Rule Level/Store Level.

Add Option When Rule Determines when the Checklist Object will add a checklist option to the application XML. When the option is set to ‘FALSE’, the checklist option will be added when the rule evaluates to ‘FALSE’. When the option is set to ‘TRUE’, the checklist option will only be added when the rule evaluates to ‘TRUE’.

Hide Option Determines when the Checklist object will remove a checklist option from the application XML. When checked, the Checklist object will remove a checklist option if the rule outcome did not meet the outcome set in the ‘Add Option When Rule’ setting.



RULE RESULT

ADD OPTION WHEN

HIDE OPTION

OUTCOME

TRUE TRUE FALSE Checklist Option Added TRUE TRUE TRUE

TRUE FALSE

FALSE No Action

TRUE FALSE

TRUE Checklist Option Hidden

FALSE TRUE FALSE No Action

FALSE TRUE TRUE Checklist Option Hidden

FALSE FALSE

FALSE Checklist Option Added

FALSE FALSE

TRUE

Option ID The ID of the checklist option; used to uniquely identify the checklist option in the application XML. There can be multiple options sharing the same Option ID, however, checklist options with the same Option ID will cause data issues if stored at the same application level.

Option Text The text of the checklist option. The text will be displayed to the end user next to the checkbox.

Options A configurable list of selections for each option in the checklist.

The check/cross icon to the right of the field determines whether the selection of the option is considered “Acceptance” of the checklist option.


Section Determines the “section” of the checklist option. The section is used by the checklist screens control to break the full list of checklist options into manageable sections.

Parameters – Rule A rule that determines whether the to set the checked value. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Checked Value to Set Determines whether the Checklist object should mark a checklist option as checked, based on the outcome of the rule.

OUTCOMES The Outcomes tab of the Checklist object does not differ from the standard object outcome tab.

Objects | Communication Object


COMMUNICATION OBJECT The communication object is used to send email communications as part of the credit process. The contents of the email can vary and use application XML data to provide more specific or personalised messaging.

DESCRIPTION The Description tab of the Checklist object features five fields in addition to the standard object description tab.

Email Server The address of the SMTP server to be used to send emails. Managed environments are configured with an email server at localhost.

Port Number The port number of the SMTP server to be used.

User Name The username the Communications Object should use to log in to the SMTP server.

Password The password of the user used to log in to the SMTP server.

Domain The domain of the SMTP server.



Enable SSL Dictates whether the Communications object should use SSL to log in to the SMTP server.

MAPPING The Mapping tab lists each separate email for the Communication object to execute. Each mapping row contains several configuration fields.

ID The ID of the Mapping row; used to uniquely identify the mapping in the list. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.




Register Document The Register Document checkbox determines how the Communications object will interact with the Document Register of illion Decisioning. The Document Register is a page which lists uploaded documents and applicable communications for an application on a single page. When checked, the contents of the email being sent by the communications object will be included and made visible in the document register.




From The email address that will be used as the sender of the email. Generally, this would be a ‘no reply’ email belonging to the customer’s domain, in order to prevent errant replies being sent to automatic messages.

To The recipient(s) of the email that is being sent. If the field contains more than one email address, the email addresses must be listed in a comma-separated list.

CC The carbon copy (CC) recipient(s) of the email that is being sent. If the field contains more than one email address, the email addresses must be listed in a comma-separated list.

BCC The blind carbon copy (BCC) recipient(s) of the email that is being sent. If the field contains more than one email address, the email addresses must be listed in a comma-separated list.

Subject The subject of the email that is being sent.

Contents – Rule The Rule to indicate whether or not to add the content. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Contents – Content Name

The name of the content being added to the email. Must include the file extension (e.g. a STATIC Content Type being used to send a PDF file will have a Content Name value that ends in “.pdf”).

Contents – Object The type of content that is being added to the application: either “Body” or “Attachment”.

Contents - Pre-Transformation An XSLT that is used to prepare the content of the email or attachment prior to the 'Transformation' file being applied.

Contents – Transformation An XSLT that is used to generate the content of the email or attachment. The Communication object will attempt to use the transformation file assuming it matches the output type from the ‘Type’ field.

Contents – Type The type of content output. When the content is of type “Body”, the type is required to be “HTML”. The multiple output PDF types are used to map the exact type of PDF to the format specified in the transformation XSLT.

CONTENT OUTPUT TYPES

PDF

PDF – 0.94

PDF – 1.1

HTML

STATIC

HTML To PDF

Plain File



Plain output types will output files of the file type specified in the filename field, allowing for the generation of .CSV or .TXT files.

Contents - Password A free-text field that can be used to password-protect PDF documents. When blank, the file has no protection. When set, the PDF generated will only open after the user provides the text entered in the field as the password.

Parameters – Rule The Rule to indicate whether or not to include the parameters when using transformation XSLT. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Parameters – Content Name The name of the content to which the parameter relates. The content will use the parameters relating to it in the transformation XSLT.

When the content is of type ‘Body’, the Content Name should be “Body”.

Parameter Name, Value and Type A name and value of the parameter that will be passed to the XSLT. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Uploads The Upload fields attach files that have been uploaded to an application to emails.

There are two different types of uploaded documents: upload and upload2. The type of uploads used is determined by the selection of user control on the screen.

Upload Control ID The Upload Control ID dictates either:

The ID of the user control that was used to upload the document to the application.

the Category ID of the file (Upload2).

Filename The filename field will restrict the list of files attached to the email by filename.

When a filename is provided, only files that match an SQL LIKE comparison of the format "{Filename}%" will be attached. The file extension can be used to further specify the file required.

Sequence ID The sequence ID determines which version of the uploaded file to use when gathering the list of uploads.

This can be either: “All”, which will return every file ever uploaded to the application; “First” which will load the initial upload, and “Last” which would return only the latest upload.

OUTCOMES The Outcomes tab of the Communication object does not differ from the standard object outcome tab.

Objects | Director Object


DIRECTOR OBJECT The Director object uses data from commercial bureau reports to populate the application XML with information the commercial entity. Most often used to add the listed directors of a company as co-borrowers on an application, the Director object can also be used to populate other data about a company such as registered and trading addresses. The Director object currently only supports Dun and Bradstreet Commercial Enquiries, and the Equifax Commercial Apply v3.2 product.

DESCRIPTION The Description tab of the Director object features five fields in addition to the standard object description tab.

MAPPING The Mapping tab lists each separate mapping for the Director object to execute. Each mapping row contains several configuration fields.





Bureau ID The ID of the bureau report to be loaded by the Director Object for processing. The ID of a bureau report needs to match the ID set in the bureau object that is to be used for population. For more information on the bureau ID, see the ‘Bureau Enquiry Objects’ section of this document. The Director will attempt to load the bureau report data from the XPath below in the application XML.

applicant[@cd_type = 'Principal']/result/bureau_list/bureau[@id = '"

+ BureauId + "']/tx_data_bureau/

The Bureau ID is also used by the Director Object to determine which bureau report schema to use when decoding the director data from the report.

Applicant Code The applicant code determines the applicant types used for directors to the application.

The Director object will first iterate over all applicants whose type contains the Applicant Code listed and compare them to the directors on the credit report. For example, an Applicant Code of “CoBorrower” will cause the Director object to analyse applicants ‘CoBorrower1’, ‘CoBorrower2’,

‘CoBorrower3’.

Once the Director object finds a “match” for the director in the list of applicants, it will move to the next director on the report. If the Director Object cannot find an applicant which matches a director on the report, it will add the director as a new applicant on the application. This new applicant will be of type “ApplicantCoden”, where n is the number of existing applicants whose type contains the Applicant Code. In the example above, a fourth direct which was not matched against an applicant would be added as ‘CoBorrower4’.

Populate Company Determines how the Director object will handle directors from the bureau report who are companies. When checked, the Director object will use the details of company type directors from the bureau report to populate a new applicant. When Unchecked, the Director object will ignore directors on the bureau report if they are a company.

Principal Registered Address Determine whether the Director object should write the Registered Address from the bureau report into the company’s details in the application XML. When checked, the object will write the registered address from the bureau report into the application MXL. When unchecked, the object will not write the address.



Principal Trading Address Determine whether the Director object should write the Trading Address from the bureau report into the company’s details in the application XML.

When checked, the object will write the trading address from the bureau report into the application XML. When unchecked, the object will not write the address.

Restrict Directors by address country Restricts the Director object from adding the details of directors which are based outside of the desired country.

OPTION SELECTED ACTION

Australia Only

Only directors who—according to their address in the bureau report — are based in Australia will be added as additional applicants.

New Zealand Only

Only directors who — according to their address in the bureau report — are based in New Zealand will be added as additional applicants.

Australia or New Zealand Only

Only directors who — according to their address in the bureau report — are based in either Australia or New Zealand will be added as additional applicants.

Store international addresses unformatted Determines whether international (i.e., neither Australian nor New Zealand) addresses as an unformatted address in the application XML.

Applicant Count The maximum number of additional applicants that can be added to the application. The Director Object will continue adding directors as additional applicants until the number of additional applicants meets this count. When not entered, the object will assume a placeholder limit of 999 additional directors. This would be most useful to restrict schema errors, as each sequential type of applicant needs to be accounted for in the application schema. However, as the order and number of directors in a bureau report cannot be known beforehand, arbitrarily restricting the number of additional applicants may result in crucial information not being added to the application.

OUTCOMES The Outcomes tab of the Director object does not differ from the standard object outcome tab.

Objects | Docusign Object


DOCUSIGN OBJECT The Docusign object allows for the application to integrate with the digital signature service from Docusign. The configuration required for the Docusign object is dependent on the method of integration with Docusign. Docusign uses “Templates” to manage documents, and these templates can be configured either by Docusign or by the illion Decisioning project team.

Docusign has an “Audit” process that needs to be undertaken before the customer can move to production with a new Integration key, which is not covered in this document. For more information about Docusign, visit www.docusign.com.au

DESCRIPTION The Description tab of the Docusign object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each separate mapping for the Docusign object to execute. Each mapping row contains several configuration fields.

http://www.docusign.com.au/






Retain Recipient Data Determines how the Docusign object should manage additional recipient data in the request envelope. When checked, additional recipient data is preserved within the request. When unchecked, the recipient list is rebuilt by the object during the call.

Retain Email Data Determines whether the Docusign object should use the subject and message defined in the template. When unchecked, the object will use the default email subject and message to send to the customer.



SUBJECT

Your Finance application approval

confirmation, reference {0}

BODY Please proceed to DocuSign and

sign this document.

* {0} is a placeholder for the Application ID.

Application ID Defines the application ID. Generally, an item that loads the application ID from the application XML.

Action ID Defines the ID of the action required to be executed when the signed document is received from Docusign.

Document Name Defines the customer-facing name of the signed document returned by Docusign.

Account ID The Docusign account ID of the company performing the enquiry.

Template The ID of the Docusign template.

User The username of the DocuSign user to use when performing the Docusign call.

Password The password of the DocuSign user to use when performing the Docusign call.

Integrator Key The Docusign IntegratorKey of the company performing the enquiry.

Return URL The base URL of the location where the user will be sent after they have signed a document on the DocuSign service.

Brand ID The Docusign Brand ID to use when signing the document.

Recipient The recipient section allows for the definition of the recipients that will receive an email generated through the DocuSign Template. Even if the recipients configured in the template are to be used, the details of the recipients still need to be defined in the Docusign object.

Recipient ID The ID of the recipient row; used to uniquely identify the recipient in the list. This needs to match the order number of the recipient in the template.



Role The role of the recipient. This needs to match the Role defined in the template.

Email The email address of the recipient.

Name The name of the recipient.

Send Email Determines the behaviour of the Docusign object when it is preparing to send emails to the recipients. When checked, all recipients will receive an email distributed by the DocuSign service. When unchecked, no recipients will receive an email and the URL relating to each applicant is stored in the Application XML. These URLs can then be used in a separate email managed by the communication object managed in the flow.

Documents The documents section allows for the definition of documents that will be either attached to the email distributed by Docusign or stored for future use in the application XML. If Docusign is being used to manage the documents, then this tab needs to be blank.

Document ID The ID of the document row; used to uniquely identify the document in the list. This needs to match the order number of the document in the template.

Name The customer-facing name of the document.

Type Defines the type of file provided in the PDF/XSLT field. When set to ‘Static PDF’, the file referenced in the PDF/XSLT field will be sent as-is to Docusign to be distributed.

Generated PDF/Static PDF When set to ‘Generated PDF’, the XSLT file referenced will be used to generate the PDF to be sent to Docusign.

Uploaded Document When set to 'Uploaded Document', the object will attach any file which matches the category, filename and sequence provided.

PDF/XSLT The file path of the PDF/XSLT file to be used to send PDFs to Docusign.

Tabs Tabs are parameters that replicate the Docusign tab functionality. They are functionally identical to parameters in other objects in that they are used when processing the document, however, they will be used by the DocuSign service.

OUTCOMES The Outcomes tab of the Docusign object does not differ from the standard object outcome tab.

Objects | External Accounts Object


Objects | Flow Change Object


FLOW CHANGE OBJECT The Flow Change object allows applications to change the flow that is being used to process the object.

DESCRIPTION The Description tab of the Flow Change object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each separate flow change for the Flow Change object to execute. Each mapping row contains several configuration fields.


Level Determines the Application Level used when processing the

Objects | Flow Change Object


mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Credit Product The ID of the Credit Product the Flow Change Object will use to load the new flow. For more information about how credit products are assigned flows, see the ‘Assigning a flow to a credit product’ section of this document.

Starting Object The ID of the object from which the new flow should begin processing.

OUTCOMES The Outcomes tab of the Flow Change object does not differ from the standard object outcome tab.

Objects | GreenID Object


GREENID OBJECT The GreenID object allows for the application to integrate with the identity verification service from Edentiti. For more information about GreenID, visit:

www.vixverify.com/greenid-services/#verification-of-identity

DESCRIPTION The Description tab of the GreenID object does not differ from the standard object description tab.

MAPPING

The Mapping tab lists each separate verification service for the GreenID object to execute. Each mapping row contains several configuration fields.

http://www.vixverify.com/greenid-services/#verification-of-identity







Reuse Matching Enquiry The 'Reuse Matching Enquiry' checkbox allows for previously submitted GreenID requests to be reused in subsequent uses of the object. This is beneficial in situations where an application may have been resubmitted, in order to minimise the cost of making enquiries. When unchecked, the GreenID object will perform the webservice call each time the application passes through it, regardless of whether a matching call has already been made.



When checked, the GreenID object will not perform another call if a "matching" GreenID result exists in the application XML. The definition of a matching GreenID request is configured through additional settings.

Reuse Match Object The 'Reuse Match Object' setting determines whether the matching logic should only consider requests made by an object with the same object, and with the same Mapping ID.

No of days Existing Check The 'No of days Existing Check' setting determines how recent a GreenID call can be in order to be reused. Only GreenID requests made in the last n days will be considered as part of the matching logic.

Check all Applicants Determines how detailed the GreenID object should be when performing its existing check logic. When checked, the object will perform the existing check logic against all applicants on an application to try and find duplicate reports.

A Green ID request is considered a "match" if:

GREENID MATCHING LOGIC

All GreenID Match XPaths are identical. (see Appendix C for a list of XPaths)

AND

The request was made in the previous number of days defined in the 'No of days Existing Check' field.

AND

If 'Reuse Match Object' is checked, both the Object ID and Mapping ID used to make the request match

AND

If 'Check all Applicants' is not checked, the applicant being validated matches.


Force Enquiry Dictates to the GreenID object whether to bypass the existing check logic and perform the GreenID object call. When checked, the GreenID will bypass the existing check logic if the Force Rule restriction is met.

Force Rule The Force Rule to indicate whether or not to force an enquiry. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Force Enquiry on Error Data Source Dictates to the GreenID object whether to bypass the existing check logic if the previous GreenID call contained an error.



Request Specifies an XSLT that will be used to transform the application XML into the required format of the GreenID call. The resulting XML is the body of the request sent to GreenID.

Response Specifies an XSLT that will be used to transform the result of the GreenID call before it is stored in the application XML.

Transformation Specifies an XSLT that will be used to transform the entire application XML after the GreenID response has been added.

Display Schema Specified an XSLT that will be used to display the result of the GreenID call to the user. The user is able to view the result of all GreenID calls through the Web Service screen control.

URL The URL to query when making the GreenID call.

Transport Method The HTTP transportation method used to the make the GreenID request.

SUPPORTED HTTP METHODS

GET

PUT

POST

SSL Determines whether the GreenID object needs to use an SSL connection to connect to the web service.

Certificate The filename of a client certificate to use when connecting to GreenID. The certificate must first be installed on the server running

illion Decisioning; for more information please contact the illion Decisioning Support Team:


Password The client certificate password of the client certificate used to connect to GreenID.

Timeout Determines the length of time, in seconds, beyond which the GreenID object will consider the GreenID call to have timed out.

Retries Determines the number of times the GreenID object shall attempt to retry a GreenID call once a timeout has been received.

Delay Determines the length of time, in seconds, that the GreenID object should wait before attempting to retry a GreenID call.

Parameters A list of parameters that will be passed to GreenID when performing the GreenID call.

Post Bureau Ruleset The object that will be run following the GreenID call. Any outcomes of the object will not be used following processing; the application will continue to be processed any other GreenID mappings.

OUTCOMES The Outcomes tab of the GreenID object does not differ from the standard object outcome tab.


Objects | Group Object


GROUP OBJECT The Group object is used to create groups for organising other objects in the flow.

DESCRIPTION The Description tab of the Group object does not differ from the standard object description tab.

Mapping As the group object does not perform any actions, there is no mapping tab for the Group object.

OUTCOMES The Outcome tab of the Group object does not differ from the standard object description tab.

Objects | Group Object


MANAGING GROUPS Groups and their contents are managed via the flow mapping view.

Any objects which sit below a group object in the flow mapping are considered to part of that group. When the contents of the group are collapsed, the objects sitting below the group objects will be hidden.

The left-hand groups list allows users to quickly navigate to the group selected.

Objects | Internet Monitor Object


INTERNET MONITOR OBJECT The Internet Monitor Object is used to add a monitoring request with the illion monitoring service, allowing for organisations to be proactively updated of significant changes to an applicant’s credit report.

DESCRIPTION The Description tab of the Internet Monitor object contains one option in addition to the standard object Description tab.

Monitoring via B2B This checkbox determines whether the monitoring method should take place via the B2B service. This setting only works for entities with a DUNS number, and required additional configuration outside illion Decisioning. For more information, contact the illion Decisioning Support Team:


mailto:[email protected]




MAPPING The Mapping tab lists each separate monitoring check for the Internet Monitor object to execute. Each mapping row contains several configuration fields.


External Reference This setting dictates if there is an external reference for the Internet Monitor. It exists for backwards compatibility only, and should not be turned on without consulting the illion Decisioning Support Team.



Collections Specifies if a notification should be sent if the collections section on the report for an applicant changes. When set to '1', the bureau will notify the email address of the change.

Court Actions Specifies if a notification should be sent if the court action section on the report for an applicant changes. When set to '1', the bureau will notify the email address of the change.

DDS Movement Specifies if a notification should be sent if DDS movement on the report for an applicant is detected. When set to '1', the bureau will notify the email address of the change.

DDS Unit Specifies if a notification should be sent if the DDS unit section on the report for an applicant changes. When set to '1', the bureau will notify the email address of the change.

DRS Movement



Specifies if a notification should be sent if DRS movement on the report for an applicant is detected. When set to '1', the bureau will notify the email address of the change.

DRS Unit Specifies if a notification should be sent if the DRS unit section on the report for an applicant changes. When set to '1', the bureau will notify the email address of the change.

New Report Specifies if a notification should be sent if the report requested is a new report. When set to '1', the bureau will notify the email address.

Registered Charges Specifies if a notification should be sent if the registered charges section on the report for an applicant changes. When set to '1', the bureau will notify the email address of the change.

Status Change Specifies if a notification should be sent if the status changes on the report for an applicant. When set to '1', the bureau will notify the email address of the change.

Company Name Specifies the Company name for the entity whose bureau report the monitoring service is being requested to monitor.

DUNS Specifies the DUNS for the entity whose bureau report the monitoring service is being requested to monitor.

ACN Specifies the ACN for the entity whose bureau report the monitoring service is being requested to monitor.

Service Level Specifies the service level being requested for the notification service. For more information, contact the illion Decisioning Support Team:


Email The email to which the notifications from the illion monitoring service should be sent.

Frequency The frequency by which the notifications from the illion monitoring service should be sent For more information, contact the illion Decisioning Support Team:


PARAMETERS A list of parameters that will be passed to the illion monitoring service. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

OUTCOMES The Outcomes tab of the Internet Monitor object does not differ from the standard object outcome tab.




Objects | Loan Calculator Object


LOAN CALCULATOR OBJECT The Loan Calculator Object allows for the calculation of complex loan details such as repayments, rate changes and other defining financial features. Due to the complexity and variability of Loan Calculator settings, an Excel spreadsheet that documents and recreates the calculations of the code is available; see Appendix B.

DESCRIPTION The Description tab of the Flow Change object does not differ from the standard object description tab.

SETTINGS The Settings tab of the Loan Calculator object is used to define how the interest rate and repayments would be calculated.



Calculator Mode Determines the mode of the loan calculator. Selecting 'Core' will use the prebuilt illion Decisioning loan calculator. A selection of 'Custom' allows for a reference to a custom built loan calculator. Custom loan calculators involve intensive custom development work and are not recommended.

Instalments The instalment settings allow for the definition of the number of payment installations occur within a year for each instalment frequency. These values must be whole numbers. The recommended settings for each of the periods is below.

FREQUENCY NO. OF PAYMENTS PER

YEAR

Week 52

Fortnight 26

Four Weeks 13

Month 12

Quarter 4

Half Year 2

Year 1

DATE SETTINGS

First Repayment Date The date of the first loan repayment. This value is used to back- calculate the funding start date, which is then used to calculate the final payment date. When not provided, the funding start date is assumed to be the current date.

Grace Period The Grace Period defines a period of time, in days, in which each version of the product is provided a 'grace period'. If a new version of a product is created, existing applications using the old version of the product will maintain this version, if the grace period has not expired from when the newer version became active. A flag is available in the product setup to suppress this grace period if the new version needs to apply immediately to existing applications.

INTEREST RATE SETTINGS

Interest Rate Adjustment The Interest Rate Adjustment fields allow for the interest rate to be modified by a value. The multiply/addition buttons determine the type of adjustment. The interest rate assigned to the product will either be multiplied by the value of the adjustment, or added with the percentage points entered.

Rate Recalculation Object The rate recalculation object determines the behaviour of the Loan Calculator object when an existing application is processed through the flow. When checked, the object will be used to recalculate interest rates automatically when the application is returned to the flow.



Customer Rate The Customer Rate check box determines the behaviour of the Loan Calculator object when managing interest rates adjustments that increase the interest rate. When checked, loan calculator will not use any adjustment that would cause the interest rate to increase. However, the loan calculator will continue to process any adjustments that decrease the interest rate.

Use Best Rate The 'Use Base Rate' checkbox determines the behaviour of the loan calculator when it has calculated many different possible values of the interest rate.

When checked, the calculator will use the lowest rate of either the default rate, the rate after any overrides, or the locked rate. When unchecked, it will use the rate that applies to the loan based on all other configuration factors.

PRINCIPAL ADJUSTMENTS The Principal Adjustments tab allows for the configuration of adjustments to the principal loan amount. Each mapping row represents a potential adjustment to be made to the principal amount.


Text A textual description of the adjustment being made to the principal loan amount.



Value The amount to be added or subtracted to the principal loan amount.



ADDITIONAL FEES The Additional Fees tab of the Loan Calculator object allows for fees to be conditionally assigned to a loan. While fees are generally added through the product configuration screens, this tab allows for fees to be added (or even removed) on a more granular level.

ID The ID of the Mapping row. This will also be the unique ID of the fee when it is added to the application XML.

Text The customer facing name of the fee being added to the loan.



Remove Determines the behaviour of the Loan Calculator object when the rule fails, and a fee with the same ID is found on the application. When unchecked, the existing fee will remain assigned to the loan. When checked, the fee will be removed from the loan.

Value The value of the fee being added to the loan.

Reference An external reference code that relates to the fee. The reference code will be included with the rest of the fee information within the application XML.

Occurrence Determines the occurrence of the fee; must be either: ‘Initial’, ‘Ongoing’ or ‘Annual’.



Capitalised Determines the capitalisation method of the fee. Must be either: ‘Capitalised’, ‘Upfront’ or ‘Deducted’.


LOAN VARIATIONS The Loan Variation mapping allows for certain aspects of a loan to be conditionally modified. The section predates the Product Variant configuration and is provided for backwards compatibility only.



Alterations Alterations a predefined list of options that allow for complex manipulation of the loan details. Each mapping may have multiple alterations which are processed in the order they are configured.

The Loan Calculator object will attempt to modify the loan amount, repayment amount or interest rate in order to match the alteration provided. If the values provided in the application make the alteration infeasible, the loan calculation will return an outcome of 'Error'.

Alteration Name The name of the alteration; used to uniquely identify the alteration.

Alteration Type The type of alteration to be made to the loan. Each alteration type behaves uniquely.



Add to Principal Amount (in $) This alteration will increase the principal loan amount by the amount provided in the Alteration Value field.

Add to Repayment Amount (in $) This alteration will increase the repayment amount by the amount provided in the Alteration Value field.

Add to Variable Rates (in %) This alteration will increase the variable rate of a loan by the percentage points provided in the Alteration Value field.

Specify Term (in months) This alteration will modify the loan term of the application to match the length defined by the Alteration Value field. The repayment amounts will then be recalculated using the new term.

Specify Repayment Frequency This alteration will modify the repayment frequency of the application to match the length defined by the Alteration Value field. The repayments will then be recalculated using the new frequency.

Extend to Maximum Term (No value required) This alteration will modify the loan term to the maximum length allows in the product configuration. The repayment amounts will then be recalculated using the new term.

Maximum Repayment: Reduce Principal This alteration will attempt to reduce the principal amount of the loan in order to reduce the maximum repayment amount to the value defined in the Alteration Value field.

Maximum Repayment: Extend Term This alteration will attempt to extend the loan term to the maximum term allowed in order to reduce the maximum repayment amount to the value defined in the Alteration Value field.

Minimum Principal: Set Fail This alteration will cause the loan calculator to fail if the calculated principal loan amount is less that the value defined in the Alteration Value field. Is intended to be used in conjunction with other alterations, in order to enforce a minimum loan amount.

Alteration Value The value to be used by the Alteration Type (see above).

SNAPSHOTS Product Snapshots are used in order to capture a complete picture of the state of the loan schedule at a given point. This is often used to compare a previously approved loan with a newly recalculated loan. Snapshots are taken after all calculations in the object have been completed, and store the result of the snapshot in the application XML.





Append Determines how the Loan Calculator object should behave when there is an existing product snapshot on an application. When unchecked, all existing snapshots will be replaced with the new snapshot. When checked, the new snapshot will be appended at the end of a list of snapshots within the application XML.

Exclude Rates Indicates whether rates should be excluded from the product snapshot included in the Application XML.

Exclude Fees Indicates whether fees should be excluded from the product snapshot included in the Application XML.

Exclude Calculations Indicates whether calculation breakdowns should be excluded from the product snapshot included in the Application XML.

Exclude Variations Indicates whether variations should be excluded from the product snapshot included in the Application XML.

Exclude Disbursements Indicates whether disbursements should be excluded from the product snapshot included in the Application XML.

OUTCOMES The Outcomes tab of the Loan Calculator object does not differ from the standard object outcome tab.

Objects | Loan Conditions Object


LOAN CONDITIONS OBJECT The Loan Condition Object is used to add conditions to an application that will prevent it from leaving a queue. These conditions are generally something a customer (or another party) must do in order for the loan to be approved. Loan conditions are shown based on access group, and unlike checklists which can be grouped into sections and displayed across multiple pages, loan conditions can be displayed on any page but cannot be separated into sections.

The enforcement of progress on an application is controlled by the screens, but the adding of loan conditions to an application is driven through the flow.

DESCRIPTION The Description tab of the Loan Condition object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each mapping for the Loan Condition object to execute. Each mapping row contains several configuration fields.



Condition ID The ID of the loan condition. Will be used to uniquely identify each loan condition within the screens XML of the application.

Condition Name The customer-facing name of the loan condition. Should be a concise and human-friendly description of the condition.

Condition Description The customer-facing description of the loan condition. Should provide a human-friendly description of the condition and clearly convey the requirements of the condition.

Condition Category The category of the loan condition. The category will be used by the Loan Conditions control within the data entry screens to group conditions into separate sections. Multiple condition categories can be provided for a single mapping using comma separated values.

Condition Value The value of the condition. The condition value will be written in the application XML alongside the other Loan Condition Information.






Hide loan condition Determines when the Checklist object will remove a checklist option from the application XML. When checked, the Checklist object will remove a checklist option if the rule outcome did not meet the outcome set in the ‘Add Option When Rule’ setting.

Allow Custom Description Determines whether the Loan Conditions control should allow the description of the loan condition to be overwritten by authorised users.

Edit Custom Description Determines whether the Loan Conditions control should allow custom descriptions that have been added to loan conditions to be modified by authorised users.

Edit Condition Value Determines whether the Loan Conditions control should allow the value of the loan condition to be modified by authorised users.

Manual Condition Determines whether the Loan Conditions control should allow this condition to be manually added to an application by authorised users.

Maximum Occurrences Determines the maximum number of times the loan condition can be added to a single application.

Access Group A list of access groups, the members of which will be able to view the loan condition and mark the condition as being met in the Loan Conditions control.

OUTCOMES

The Outcomes tab of the Loan Condition object does not differ from the standard object outcome tab.

Objects | Matrix Object


MATRIX OBJECT The matrix object is a unique object that allows for the definition of a matrix to determine the path of an application through the flow. The Matrix object accepts two axes of information, which can be either a rule, data bin or another, nested matrix. When an application is process using the Matrix object, the values of the axes are used to determine the overall "Matrix Result", which is then pre-populated as the object outcomes. Through this object, the need for complex Ruleset Objects involving permutations of rules is negated and replaced with a graphical representation of the possible outcomes for an application.

DESCRIPTION The Description Tab of the Matrix Object features one additional field in addition to the standard object description tab.

Level This defines the default application level used when processing rules and data bins in the matrix. This level will override any rule or data bin that does not have its level set, but will also prevent processing of rules and data bins where the rule does not match.



MAPPING


Levels Determines the Application Level used when processing the mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.


Value 1 & Value 2 The two value fields are used to define the x and y axes of the matrix. The 'Levels' determine the application levels that are used to calculate the result of the rule or data bin. The Matrix object will retrieve a list of possible outcomes from the selected element, and display them as either columns or rows within the matrix arrangement.

Results The results section dictates the list of possible outcomes for the matrix. The Results configured will be automatically populated as the only possible outcomes of the Matrix object when used in the mapping. Each cell within the matrix can be assigned a "Matrix Result", but the result does not need to be unique. This allows for multiple cells within a matrix to be directed to the same outcome on the mapping.

Result - Name The name of the result. Used on the Outcome tab to identify the outcome.



Result - Code The code to be stored alongside the result within the application XML. Can be used to integrate with external systems or be used as a reference for other objects.

Result - Value The value to be stored alongside the result within the application XML. Can be used to integrate with external systems or be used as a reference for other objects.

Result - Colour & Shape The colour and shape to be used to identify the result within the graphical representation of the matrix. For people who are visually impaired, it is recommended that each outcome be given a different shape.

Arrangement The arrangement of the matrix dictates the mapping of possible values to matrix results. The axes represent the possible results from the values entered in the mapping tab. Each cell represents the union of the two possible values when calculating the value elements. For example:

OUTCOMES The Outcomes tab of the Matrix object differs from the standard Object Outcome tab, as it does not allow for outcomes to be added.

Instead, all outcomes are pre-populated from the list of matrix results defined on the 'Mapping' tab.



OCR LABS OBJECT The OCR Labs object allows for the application to integrate with OCR Labs for the purpose of obtaining and verifying details from identification documents, and comparing the face of the person providing the document to the face on the document. For more information about OCR Labs, visit: https://ocrlabs.com/ The OCR Labs process requires two API calls to be configured. The first will take the user’s mobile number and send an SMS with a link to the verification process. The second will get the status and results of the verification process. A notification event also exists which will, if configured, let the Decisioning system know that the verification process is complete so the second call can be delayed until completed.

DESCRIPTION The Description tab of OCR Labs object does not differ from the standard object description tab.

https://ocrlabs.com/



MAPPING The Mapping tab lists each API call for the OCR Labs object to execute. Each mapping row contains several configuration fields.

ID The ID of the Mapping row; used to uniquely identify the mapping in the list. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document. If creating multiple OCR Labs objects with various ‘Send SMS’ calls, ensure each one is given a unique ID.




API Details The OCR Labs API details need to be configured in the “Third Party Administration” screens within Integate. There you will be able to configure the following details:

API URL

Notification URL

Client ID

Client Secret

Action (optional) The API URL, Client ID and Client Secret will be provided by OCR Labs. There are further details on how to configure each field within the administration screen.



Method Determines the method that will be used for this OCR Labs Mapping. Options are “Send SMS” or “Get Results” selectable from a list. The selected method will affect which fields are displayed.

Fields Displayed for “Send SMS” Method

Phone Number The mobile number to send an SMS to. This is expected to be in the format a user would dial from inside the country (for example: 0400123456 for Australia).

Phone Code The country code for the phone number. This is expected to be in the “+XX” format (for example: +61 for Australia).

Name The name of the person you are sending the SMS to. OCR labs will use this in their message template.

Fields Displayed for “Get Results” Method

SMS Call Mapping ID This is a reference to the Mapping ID of the “Send SMS” method. This is used to match the “Get Results” call with the correct transaction ID, which is generated as part of the “Send SMS” call.

Post OCR Labs Ruleset The object that will be run following the OCR Labs call. Any outcomes of the object will not be used following processing; the application will continue to be processed through any other OCR Labs mappings.

OUTCOMES The Outcomes tab of the OCR Labs object does not differ from the standard object outcome tab.

Objects | Outcome Tree Object


OUTCOME TREE OBJECT The Outcome Tree is a unique object that uses rules, data bins and matrices to build a set of outcome paths analogous to a decision tree. The Outcome Tree starts at a single "root" node which can be a rule, data bin or a matrix. Each potential outcome of those nodes forms a branch to a new child node which, in turn, can have additional outcomes. Applications being process will pass from node to node after evaluating each node result until eventually reaching a "leaf" node - a node with no branches. These leaf nodes are then categorised and correlated to outcomes for the Outcome Tree Object itself, wherein the application continues processing.

DESCRIPTION The Description tab of the Outcome Tree object does not differ from the standard object description tab.



MAPPING The Mapping tab of the Outcome Tree object contains three distinct sections.

Tree Section The tree section contains a graphical representation of the outcome tree being configured. Each box represents a node and each line connecting them represents a possible path of an application. Nodes can be configured by selecting the box within the tree. When selected, the node will have a shadow colour matching the brand colour, and the details displayed below in the Node Details section.

The node is displayed alongside the name of its rule, data bin or matrix. An icon in the top left denotes the type of node.

ICON NODE TYPE

Rule

Data Bin

Matrix

Leaf Node (no children)

Leaf nodes are coloured in to match the colour assigned to the selected tree result, making it easier to identify leaves that return the same result

Minimising and Maximising The arrow at the bottom of the node box allows for the showing and hiding of children nodes. When selected, all children of a given node will be collapsed, making it easier to navigate large trees.

Route Finder The "Connected Nodes" icon in the top right of the node highlights



the path that would lead to a node.

This can be used to help back trace how an application reached a particular outcome.

Mid Tree Addition In addition to adding branches at the bottom of the tree (see below), branches can be added in the middle of the tree by selecting the "+" symbol in the top right of a node. A "Mid Tree" popup will appear allowing for the new node to be defined before the branch is created.

After "Save Mid Tree" is selected, the existing children of the node are moved to become children of each possible outcome of the newly added "mid-tree" node, ensuring there is no loss of configuration. The children can then be configured as normal.

Node Details Section The Node Details section shows all information relating to the

selected node. For branch nodes (that is, a node with branches to children), the Node Details section defines the rule, data bin or matrix to be used when processing applications. The Node Details section will also allow for the branch to be removed, which deletes all children. For leaf nodes (nodes without children), the node details section allows for the selection of the Tree Result.

Tree Results Section The Tree Results section dictates the list of possible outcomes for the Outcome Tree. The Results configured will be automatically populated as the only possible outcomes of the Outcome Tree object when used in the mapping. Each leaf node within the tree can be assigned a "Tree Result", but the result does not need to be unique. This allows for multiple leaf nodes within an outcome tree to be directed to the same outcome on the mapping.

Deleting Tree Results When a tree result is deleted, a popup will appear to allow existing leaf nodes to be remapped to a new tree result.



Default and Failure Tree Results The Default and Failure Tree Results cannot be deleted, and are reserved for use in a specific set of situations. If, in the process of moving an application through a tree, the object cannot find a matching branch to move to, the application will "fall through" to the default outcome. This is most commonly due to a new matrix or data bin result being added after the configuration of the outcome tree. The Failure outcome is used if there any failure occurs when processing the object, whatever the cause may be.

Outcomes The Outcomes tab of the Outcome Tree object differs from the standard Object Outcome tab, as it does not allow for outcomes to be added.

Instead, all outcomes are pre-populated from the list of tree results defined on the 'Mapping' tab.

Objects | Ownership Object


OWNERSHIP OBJECT The Ownership object uses the information provided by a commercial bureau report to produce and create bureau reports for entities within a multi-level corporate ownership structure. This is done by using the illion bureau ‘CANS’ product which looks for CAN information for a provided company name. If, for any reason, the ‘CANS’ product fails, the object will then attempt to retrieve ownership information from the Australian Business Register (ABR). If that also fails, the object will lastly attempt to retrieve the information from the Australian Securities and Investments Commission (ASIC) website.

DESCRIPTION The Description tab of the Ownership object contains ten fields in addition to the standard object description tab.

Use Version 2 Dictates the version of the object to use when processing. This should always be checked unless required for backwards compatibility.

Version 2 Bureau ID Start Specifies the ID of the bureau to use to identify entities.

Objects | Ownership Object


Version 2 ABR GUID The GUID to be used to connect to the Australian Business Register (ABR) in the event that the illion ‘CANS’ call fails.

illion Search URL Determines what URL to call out to in order to retrieve the illion ‘CANS’ enquiry.

illion Subscriber Determines what Subscriber code to use for the illion ‘CANS’ enquiry.

illion User Determines what User ID to use for the illion ‘CANS’ enquiry.

illion Password Determines what Password to use for the illion ‘CANS’ enquiry.

illion Environment Determines what Environment (e.g. ‘T’ or ‘P’) to use for the illion ‘CANS’ enquiry.

Enable Reset Determines the behaviour of the Ownership object when there is already data in the application XML. When checked, the Ownership object will erase the data populated through previous iterations of the Ownership object and replace it with the new data.


Outcomes The Outcomes tab of the Ownership object does not differ from the standard object outcome tab.

Objects | PPSR Object


PPSR OBJECT The PPSR object is used to register assets listed as a security on an application with the Australian Personal Property Securities Register (PPSR).

DESCRIPTION The Description tab of the PPSR object does not differ from the standard object description tab.

MAPPING Contrasting with other Objects, the Mapping tab of the PPSR object dictates individual grantors within a single PPSR call. Items within the PPSR object will only be read at the "Application" level, however results will be stored against each applicant.


Levels Determines the Application Level used when processing the mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.





Existing Check Determines the behaviour of the PPSR object when there is an existing result in the application XML. When checked, the PPSR object will not perform another call if the results of the call exist in the application XML. When unchecked, the PPSR object will perform the webservice call each time the application passes through it, regardless of whether the call has already been made.

Request Schema Specifies an XSLT that will be used to transform the application XML into the required for PPSR calls. The resulting XML is the body of the request sent to the PPSR.

Response Schema Specifies an XSLT that will be used to transform the result of the PPSR call before it is stored in the application XML.

Display Schema Specified an XSLT that will be used to display the result of the PPSR call to the user. The user is able to view the result of all PPSR calls through the Web Service screen control.



Request Type The PPSR Request Type to be performed. Currently, this only supports Creating a PPSR Registration

Provider Determines the provider of the PPSR Registration webservice. Currently, only GlobalX and ESIS are supported; for more information refer to the API Connectivity Guide of those services.

URL The URL to be used as the endpoint for the PPSR call.

Timeout Determines the length of time, in seconds, beyond which the PPSR object will consider the PPSR web service to have timed out.

Username The username of the company to be used to connect to the PPSR web service.

Password The password of the company to be used to connect to the PPSR web service.

Sec. Group Party Determines the security group be used when performing the PPSR call. For more information, refer to the provider’s technical documentation.

Contract Type Determines the contract be used when performing the PPSR call. For more information, refer to the provider’s technical documentation.

Parameters A list of parameters that will be passed to the PPSR web service when performing the PPSR call.

Post Bureau Ruleset The object that will be run following the PPSR call. Any outcomes of the object will not be used following processing; the application will continue to be processed any other PPSR mappings.

OUTCOMES The Outcomes tab of the PPSR object does not differ from the standard object outcome tab. Due to specific requirements surrounding the use of Australian Company Numbers (ACNs) within PPSR calls, the PPSR object is hardcoded to return a custom outcome in specific scenarios. The PPSR Object will output a custom outcome of "NO_ACN" when no ACN has been found on an application, and the ABN supplied does not exist in the response from the Australian Business Register.

Objects | Printing Object


PRINTING OBJECT The Printing object is used to define documents that can be generated and attached to an application. The object works in conjunction with the Printing screen control: while the documents that apply to an application are assigned by the Printing object, the Printing control displays the list of documents to the user on a data entry screen. When the user selects a document from that control, the control then generates the actual document provided to the user using the stylesheets and output types provided.

DESCRIPTION The Description tab of the Printing object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each mapping for the Printing object to execute. Each mapping row contains several configuration fields.

Objects | Printing Object



Display Text The customer-facing name of the document, as it will be displayed within the Printing object.




Stylesheet An XSLT that is used to generate the content of the email/attachment. The Printing object will attempt to use the transformation file assuming it matches the output type from the ‘Type’ field.

Output Type The type of content output. The multiple output PDF types are used to map the exact type of PDF to the format specified in the transformation XSLT. Plain output types will output files of the filetype specified in the filename field, allowing for the generation of .CSV or .TXT files.

Printing Image The file path to the custom image that is to be used to display the document in the Printing control. When blank, the default icon is used.

Privileges A list of access groups, the members of which will be able to view and generate the document from the Printing object.

Parameters A name and value of the parameter that will be passed to the XSLT. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

OUTCOMES The Outcomes tab of the Printing object does not differ from the standard object outcome tab.


PDF

PDF - 0.94

PDF - 1.1

HTML

STATIC

HTML to PDF

Plain File

Objects | Product Variant Selector Object


PRODUCT VARIANT SELECTOR OBJECT The Product Variant Selector is used to determine which variant of a product is to be used for a given application, based on application characteristics. The available characteristics are dependent on the configuration in the product module. For more information, please see the documentation relating to the product module. The value of all the characters from the mapping tab is then used to select the correct product variant from the preconfigured variant matrix.

DESCRIPTION The Description tab of the Product Variant Selector object contains one field in addition to the standard object description tab.

Grace Period The Grace Period defines a period of time, in days, in which each version of the product is provided a ‘grace period’. If a new version of a product is created, existing applications using the old version of the product will maintain this version, if the grace period has not expired from when the newer version became active. A flag is available in the product setup to suppress this grace period if the new version needs to apply immediately to existing applications.

MAPPING The Mapping tab lists each mapping for the Product Variant Selector object to execute. Each mapping row contains several configuration fields.

Objects | Product Variant Selector Object


Characteristic

The characteristic that is to be included in the variant calculation. The field will present a list of the preconfigured characteristics from the product module.

Rule


Value

The value of the characteristic to be used in the variant calculation. The value will be used to fit into a preconfigured characteristic band from the product module.

Levels

Determines the Application Level used when processing the mapping. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

OUTCOMES

The Outcomes tab of the Product Variant Selector object does not differ from the standard object outcome tab.

Objects | Queue Object


QUEUE OBJECT The Queue object allows for the definition of a holding queue, within which applications will be held for further manual processing or analysis.

When a flow reaches a queue it will stop processing. The application can be continued by selecting an action from the result screen, or through actions configured in the Screen Mapping.

The Queue object forms an integral part of a flow, as they can be used to both categorise applications and provide a breakpoint in a flow.

DESCRIPTION The Description tab of the Queue object does not differ from the standard object description tab.

ACTIONS The Actions tab is used to configure the actions that can be used to progress the application from the queue.

Actions appear in the ActionGroup control, but can also be referenced directly by other elements in the data entry screens.



Access Permission Defines a list of access groups, the members of which will have the ability to view applications sitting in the queue. If a user is not a member of an access group list in the access permission list, they will not be able to see the application on the dashboard, action the application via an interface or open the application.

Action The name of the action. This name is included in the application XML in addition to being displayed on the Result page. It is recommended that the name of the action is unambiguous, and clearly describes the action that is to take performed on the application.


Must meet loan conditions Determines the behaviour of the queue when used in conjunction with the loan conditions object and control. When checked, the queue will prevent the action from being performed unless the loan conditions added to the application have been marked as satisfied.

Loan Condition Category The Loan Condition category field is displayed when the "must meet loan conditions setting" is checked, and is used to restrict the loan conditions that are required to perform the action. When provided, the queue object will only restrict the action from being performed if the loan conditions belonging to the loan condition category have been met.



Auto Check-in Determines whether to use this action when the object is performing an Auto Check-in. Check-ins are configured via the 'Check-in & Follow-up' tab, and the first action with this option selected that passes all other restrictions will be used to perform the Auto Check-in.

DLA Constraint Determines the behaviour of the queue when used in conjunction with the DLA configuration. When set to 'No Selection' DLA configuration is not considered when evaluating which actions are available. When set to 'Meets DLA', the action will only be available if the DLA restrictions of the application are met by the operator's DLA access level. When set to 'Does not meet DLA', the action will only be available if the DLA restrictions of the application are not met by the operator's DLA access level. For example, if an operator was responsible for reviewing applications and has the required DLA level they would be able to 'Approve' an application, whereas an operator without the required DLA level would be only able to 'Escalate for Approval'. For more information about configuring DLAs, see the 'DLA Configuration' section of this document.

Must accept app. changes Determines the behaviour of the queue when used in conjunction with the application accepted changed functionality. When checked, the action will only be available if all application changes have been accepted on the application changes administration screen. If there are unaccepted application changes that have caused an action to be hidden, the Action List screen control will display a warning message to the user. For more information about Application Changes Administration,

see the Application Changes documentation.

Must accept alerts Determines the behaviour of the queue when used in conjunction with the Alerts screen control. When checked, the queue will prevent the action from being processed unless all alerts have been accepted within the Alerts control. For more information about Alerts, see the 'Alerts' section of this document, or the documentation for the Alerts screen control.

Confirmation Required and Confirmation Message Allows for a double-dare confirmation prompt to be displayed to the user when an action is selected from the list of actions in the Action List control.

When checked, the user will be presented with a popup confirming that they intended to perform the action. The popup will be using the wording provided in the Confirmation Message field. When no confirmation message has been provided, the default text "Are you sure?” will be displayed instead. The user will then be able to either proceed with or cancel the action from the confirmation popup.

Where both a confirmation message and a reason list has been configured for an action, the reason list will be displayed after a positive confirmation on the confirmation popup.



Reason List Determines the behaviour of the Queue object when used in conjunction with reason lists. When a Reason List has been assigned to an action, an additional popup box will appear after that action has been selected in the Action List control. The popup box will contain a list of the preconfigured reasons of the reason list and require a selection to be made before the action will be performed. For more information about how to configure a reason list, see the 'Reason Lists Setup' section of this document.

Re-evaluate action on click

Determines the behaviour of the Queue object when an action is selected from the Action List screen control. The action list control determines the actions to which a user has access when the application is loaded using a combination of DLA and alert acceptance checks. When the 'Re-evaluate action on click option' checked, the Queue object will re-evaluate whether an action is valid when an action is selected from the Action List control. This is used to identify changes to the application that have been made since the application was loaded by the user which mean a restriction on an action is no longer met. When unchecked, the Queue object will perform the action as normal.

Hide Action Determines how the Action List control displays the action. When checked, the action will not appear in the list of available actions on the Action List control, even if all requirements have been met. The action can still be performed by actions built into the screen mapping. This is generally used to hide back-end actions which shouldn't be provided as an option to the end user.

Next Process

Determines the next object in the flow when an action is performed in the queue. The flow will resume processing from the chosen object until it reaches the next queue or the end of the flow.

Status Determines the status assigned to the application after the action has been performed. The status will be assigned to the application in the same priority as all other status assignments; for more information about Status priority and configuring statuses, see the 'Statuses' section of this document.

Application Message A customer-facing message to be assigned to the application XML after the action has been performed. The message will be displayed on the result page of the application and can be included in external communication emails or used for analysis.

Privileges Defines a list of access groups, the members of which will have the ability perform the given action if all other requirements have been met.



If a user is not a member of an access group list in the access permission list, they will not be able to see the action within the Action List control or perform an action via an interface.

OPTIONS & ESCALATION The 'Options & Escalation' tab allows for configuration of business hours and escalation options for applications within a queue.

Rate Recalculation Determines the behaviour of the Queue object when used in conjunction with a ‘Rate Re-Calculation’ scheduled task. Scheduled tasks are configured through the Scheduler administration page, and the ‘Rate Re-Calculation’ scheduled task iterates through all applications on an environment and attempts to recalculate the interest rates of the loan products. When the checkbox is checked, the Queue object will allow applications within it to have their interest rate recalculated by the scheduled task.

Business Hours Business Hours are used to both control the Queue object’s calculation of how much time has elapsed for follow-up purposes, and to determine when applications can be assigned to underwriters automatically. Business Hours Lists are configured through the Business Hours administration page. When not set, the Queue object will not make any restriction or accommodation for business hours (functionally identical to having business hours of 24 hours a day). When set, the follow-up and assignment logic will take the time of day into account.

Queue Colour Determines the colour used to represent the queue. The queue colour is used in places such as the dashboard and in visualisations.

Escalations Escalations allow for applications to be flagged as requiring particular attention based on the amount of time it has been in a queue. The amount of time elapsed is calculated taking into account the configured business hours selection. When an escalation point has been reached, the application will be displayed with a special flag in the colour defined by the escalation.

Escalation - Name The Name of the Escalation flag to be triggered.

Escalation - Colour The colour of the indicator displayed on the dashboard for the application.



Escalation - Value & Type The length of time that needs to have elapsed in order for the escalation to be triggered.

ASSIGNMENT

The ‘Assignment’ tab determines the method by which applications are assigned to operators and the functionality that is available for those applications.

Open Locked

Determines whether an application can be locked manually. When checked, users with appropriate privileges will be able to manually assign an application to an operator.

Auto Unassign & Auto Unassign Time

Determines how assignments on applications that have not been actioned will be managed. When the "Always" unassign existing underwriter" checkbox is checked, the underwriter currently assigned to the application will be removed regardless of the existing permissions or status of the application.

When the second checkbox is checked, an application will be unlocked and unassigned if there has been no action in the time period specified in the Auto Unassign Time field.

Assignment Type

Determines the method by which applications are assigned to operators.

ASSIGNMENT METHOD

DESCRIPTION

Workload Applications will be assigned to the operator with the lowest amount of

active applications.

Cycle Applications will be assigned to each user in turn, regardless of the amount

of applications already assigned to them.

Custom Assignment Query

Uses the custom query to assign applications.

Combine Access

Determines the assignment behaviour when there are multiple access groups that have been configured to be assigned applications. When checked, operators will only be assigned applications if they are a member of every access group eligible for an application. When unchecked, operators only need to be a member of at least one eligible access group to be assigned applications.



Count Application

Determines whether applications sitting in the queue are considered to be “active” for the purpose of the Workload calculation (see above).

Unassigned Operator A fallback operator that will be assigned an application if no other operator could be auto-assigned an application.

Custom Assignment Query

The custom assignment query that will be run in place of a core assignment method. Custom Assignment Queries are not recommended due to their unsupported nature.

Assignment The Assignment section is used to define a list of access groups, the members of which will be eligible to be assigned applications if the rule requirements are met.

Assignment - Access Group The Access Group to be made available for auto-assignment of applications.

Assignment - Rule The Rule to indicate whether or not an access group is eligible to be auto-assigned applications. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

CHECK-IN & FOLLOW-UP The ‘Check-in & Follow-up’ tab allows for the definitions of check-in events and reminders.

When to Use Check-ins Check-ins are typically used to automatically move an application through the workflow at a certain stage. Some examples include:

Automate repeatedly sending the application through to a

third party integration Object (e.g. Bureau or Webservice

Object) to poll an asynchronous service.

Automatically action an application after a set amount of

time. For example, automatically withdraw an application

that has been referred for 60 days.



Note: Check-ins update the application XML and application sequence.

When to Use Follow-ups Follow-ups are typically used to send reminder emails to the customer or internal Operators, where the application does not need to automatically progress through any of the workflow. Some examples include:

Reminder emails sent to the customer asking them to

complete their application.

Reminder emails to the credit officer advising that an

application has been referred for X number of days.

Note: Follow-ups do not update the application XML or application sequence.

Check-In Time Defines the amount of time after an application has entered the queue that the check-in event should take place. When the check-in event takes place, the action with the ‘Auto Check-in’ option selected will be used to automatically action the application.

Check-in - Rule The Rule to indicate whether or not to execute a given check-in. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Check-in User The user ID under which the check-in action will be attributed.

Follow-up Name The customer-facing name of the follow-up action. When not set, the operator will remain as the last operator to edit the application.

Follow-up Time Defines the amount of time after an application has entered the queue that the follow-up should take place. When the follow-up

takes place, any processes configured will be actioned. The follow-up time takes into account any business hours that have been configured on the ‘Options & Escalation’ tab.

Follow-up - Rule The Rule to indicate whether or not to execute a given follow-up. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Follow-up User The user ID under which the follow-up action will be attributed. When not set, the operator will remain as the last operator to edit the application.

Repeats The number of times the follow-up process will be actions after the first instance. When set to '0', the Queue object will only perform the follow up process once - when the follow-up time has been reached. When set to any other number, the object will "repeat" the follow-up process n number of times.

Processes The object that is to be executed as part of the follow-up event. Most commonly used to call “reminder” communication objects.

Objects | Raw Editor Object


RAW EDITOR OBJECT The Raw Editor object is used for modifying the XML structure of custom developed object types. Custom developed object types are produced as part of a licensed project; please contact the illion Decisioning Support Team:



Objects | Resubmit Object


RESUBMIT OBJECT The Resubmit object is used to submit a new application using data from the application being processed. New applications created using the Resubmit object are processed by the flow as any other new application would be processed.

DESCRIPTION The Description tab of the Resubmit object contains seven fields in addition to the standard object description tab.

Clearing Data The Resubmit object will submit an application to the engine using the XML of the application being processed. Within the application XML significant amounts of data is generated through flow processing. While some of the information calculated and included in the application XML will still be relevant to the resubmitted application, other data is not relevant and needs to be removed in order for the application to be processed correctly.

Alerts

Determines application levels from which alerts should be removed from the new application’s XML prior to submission.

Objects | Resubmit Object


Scores

Determines application levels from which credit scored should be removed from the new application’s XML prior to submission.

Bureau Reports

Determines application levels from which bureau reports should be removed from the new application’s XML prior to submission.

Web Service Calls

Determines application levels from which web service calls should be removed from the new application’s XML prior to submission.

Result Tags

Determines application levels from which the contents of the ‘result’ tags of the application XML should be removed from the new application’s XML prior to submission.

Rule Processing

Determines application levels from which the rule processing trail should be removed from the new application’s XML prior to submission.

Item Processing

Determines application levels from which the item processing trail should be removed from the new application’s XML prior to submission.

OUTCOMES The Outcomes tab of the Resubmit object does not differ from the standard object outcome tab.

Objects | Ruleset Object


RULESET OBJECT The Ruleset object is used to trigger alerts and generally control the outcomes of application through sets of configured rules.

The Ruleset object is a crucial part of any flow, as it allows for the systematic decisioning of applications and configurations of credit policies.

DESCRIPTION The Description tab of the Ruleset object does not differ from the standard object description tab.

MAPPING

The Mapping tab lists each mapping for the Ruleset object to execute. Each mapping row contains several configuration fields.

Objects | Ruleset Object


Levels


Rule


Continue

Determines whether to continue processing the other rows of the object after processing the current row. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Set Alert Determines the alert that should be triggered by the object when the rule restriction is met. By triggering an alert on an application, the status of the application may also be affected; for more information see the ‘Alerts’ section of this document. When left empty, no alert will be triggered if the rule restriction is met.

Custom Outcome

The Custom Outcome to be assigned to the application when the rule restriction. The Custom Outcome allows for more details control over the outcome of the application following the processing by the Ruleset object. For more information see the ‘Managing Flow Mappings’ section of this document.

Application Message

The Application Message that is to be assigned to the application when the rule restriction is met. The application message is stored in the application XML and is visible through screen controls on the Result page.

Disabled

Allows for a rule to be disabled and made non-functional without deleting it from the mapping. When the disabled checkbox is selected, the rule will be skipped and not executed, and the Ruleset object will continue processing any other rules as normal.

OUTCOMES

The Outcomes tab of the Ruleset object does not differ from the standard object outcome tab.

Objects | Simple KYC Object


SCORECARD OBJECT The Scorecard object is used to calculate a credit score for an applicant, using a configured credit policy. The configuration of each scorecard is highly customised for each individual customer and requires extensive consultation before a meaningful scorecard can be produced.

DESCRIPTION The Description tab of the Scorecard object contains three fields in addition to the standard object description tab.

Start Score

Determines the starting score of every applicant before the scorecard begins to add and subtract points. The starting score of a scorecard is entirely unique and is a key outcome of the scorecard engineering process.

When ‘Constant’ is selected, the value of the start score should be a whole number. When ‘Item’ is selected, the start score will be the calculated value of the selected item.

Score Type

A customer-facing description of the scorecard value. The score type is included in the application XML and is used to distinguish between different scores of the same applicant.



Levels Determines the Application Level used when processing the scorecard. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

MAPPING

The Mapping tab lists each mapping for the Scorecard object to execute. Each mapping row contains several configuration fields.

Characteristic

A textual description of the application characteristic being considered by the scorecard. This description will be included in the application XML and is used to assist debugging the result of a scorecard.

Rule


Increment The amount to be added or subtracted from the scorecard value. The magnitude of the each increment is entirely unique and is a key outcome of the scorecard engineering process. When ‘Constant’ is selected, the value of the start score should be a whole number. When ‘Item’ is selected, the start score will be the calculated value of the selected item.

Disable

Allows for a scorecard increment to be disabled and made non- functional without deleting it from the mapping. When the disabled checkbox is checked, the characteristic will be skipped and not executed, and the scorecard object will continue processing any other changes as normal.

OUTCOMES

The Outcomes tab of the Scorecard object does not differ from the standard object outcome tab.



SIMPLE KYC OBJECT The Simple KYC object allows for the application to integrate with Simple KYC for the purpose of retrieving beneficial ownership data. For more information about Simple KYC, visit: https://simplekyc.com/ The Simple KYC process requires two API calls to be configured. The first, the “Create” call, sends in an ABN, ACN or NZBN to Simple KYC and triggers a new Simple KYC application to be created. As this process can take several minutes for more complex ownership structures, an additional “Retrieve Results” call must run at a later stage in the Flow to return the completed ownership tree, report and data from Simple KYC.

DESCRIPTION The Description tab of the Simple KYC object does not differ from the standard object description tab

MAPPING The Mapping tab lists each API call for the Simple KYC object to execute. Each mapping row contains several configuration fields.

https://simplekyc.com/



ID The ID of the Mapping row; used to uniquely identify the mapping in the list. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document. If creating multiple Simple KYC Objects with various ‘Create’ calls, ensure each one is given a unique ID.




Reuse Matching Enquiry The 'Reuse Matching Enquiry' checkbox allows for previously submitted Simple KYC requests to be reused in subsequent uses of the object. This is beneficial in situations where an application may have been resubmitted, in order to minimise the cost of making enquiries. When re-use is enabled, the applicant’s ABN, ACN or NZBN should not be modified between the Create and Retrieve Results calls occurring to prevent inconsistencies or issues with re-use. When unchecked, the Simple KYC object will perform the API call each time the application passes through it, regardless of whether a matching call has already been made.

When checked, the Simple KYC object will not perform another call if a "matching" Simple KYC result exists in the application XML. The definition of a matching Simple KYC request is configured through additional settings.

No of days Existing Check The 'No of days Existing Check' setting determines how recent a Simple KYC call can be in order to be reused. Only Simple KYC requests made in the last n days will be considered as part of the matching logic.



A Simple KYC request is considered a "match" if:

SIMPLE KYC MATCHING LOGIC

The request was made in the previous number of days defined in the 'No of days Existing Check' field.

AND

The request did not return an error.

AND

The request was made for the same Application ID and Applicant type.

AND

The request was made for the same type (‘Create’ or ‘Retrieve Results’) defined in the ‘Method’ field.

AND

The request lookup value (ABN, ACN or NZBN) matches the lookup value that would be used in the new request (only

applicable for the ‘Create’ method)

AND

The Mapping ID matches (only applicable for the ‘Retrieve Results’ method).


Force Enquiry Dictates to the Simple KYC object whether to bypass the existing check logic and perform the Simple KYC object call. When checked, the Simple KYC will bypass the existing check logic if the Force Rule restriction is met.

Force Rule The Force Rule to indicate whether or not to force an enquiry. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Simple KYC URL The base URL to query when making calls to Simple KYC’s API. This will be provided by Simple KYC during the onboarding process. The URL will typically be in the form of: “https://yourcompany.simplekyc.com”

API Key The API Subscription Key that is used during credential verification in each API call. Provided by Simple KYC.

Username The API username that is used during credential verification in each API call. Provided by Simple KYC.

Password The API password that is used during credential verification in each API call. Provided by Simple KYC.

Method Determines the method that will be used for this Simple KYC Mapping. Options are “Create” or “Retrieve Results” selectable from a list. The selected method will affect which fields are displayed

Fields Displayed for Create Method

Override Lookup Type Determines whether the default lookup type is overridden. By default, the Create method will use the Applicant’s ABN as the lookup type/value. If an ABN is not found in the standard Core schema location, the Applicant’s ACN will be used instead. If neither ABN nor ACN are found, the Applicant’s NZBN will be used. At least one of these identifying values must exist for the call to work.

https://yourcompany.simplekyc.com/



Lookup Type Displayed when Override Lookup Type is checked. Defines whether the custom lookup value will be an ABN, ACN or NZBN.

Lookup Value Displayed when Override Lookup Type is checked. Defines the source of the custom lookup value (typically uses an Xpath Item).

Fields Displayed for Retrieve Results Method

Create Call Mapping ID Used to capture the ID of the Create method Mapping that this Retrieve Results Mapping will be linked with.

Post Simple KYC Ruleset The object that will be run following the Simple KYC call. Any outcomes of the object will not be used following processing; the application will continue to be processed through any other Simple KYC mappings.

OUTCOMES The Outcomes tab of the Simple KYC object does not differ from the standard object outcome tab.

Objects | Suspect Register Object


SUSPECT REGISTER OBJECT The Suspect Register object is used to compare the application being processed to applications submitted by known fraudsters or other “suspect” applicants. Very similar to the Analyser object in its function, the Suspect Register Object relies on a configured list of suspects to be configured in the Suspect List of a company.

DESCRIPTION The Description tab of the Suspect Register object does not differ from the standard object description tab.

MAPPING

The Mapping tab lists each mapping for the Suspect Register object to execute. Each mapping row contains several configuration fields.

Levels





RuleID

The preconfigured Suspect rule that is to be used to compare the current application to suspects from the suspect type list. Each rule analyses different application data, and uses different ‘strengths’ parameters to determine what a match is.

[Company] Company Name ABN ACN 1.0 The Company Name ABN ACN 1.0 Rule is used to identify potentially suspicious applications by matching company data from the application to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact ABN or ACN match exactly.

Strong The legal name in the current application matches

the legal or trading name of an entry in the

suspect list.

OR

The trading name in the current application

matches the legal or trading name of an entry in the

suspect list.

Average Not used.

Weak

PARAM.

CODE DESCRIPTION

N/A There are no parameters available to configure

the behaviour of this rule.



[Company] Company Address 1.0 The Company Address 1.0 Rule is used to identify potentially suspicious applications by matching company and address data from the application to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact The street number, name, suburb and either the

state or city of at least one of the addresses in

the current application matches that of an entry

in the suspect list.

Strong The street number and postcode of at least one

of the addresses in the current application

matches that of an entry in the suspect list.

AND

The street name of the matching address is

similar to an entry in the suspect list.

AND

Either the ABN, ACN, Company Number or DUNS

number of the company in the current application

matches that of an entry in the suspect list.

Average The name of the street of at least one of the

addresses in the current application matches

an entry in the suspect list.

AND

Either the ABN, ACN, Company Number or DUNS

number of the company in the current application

matches an entry in the suspect list.

Weak The postcode of at least one of the addresses in the current application matches an entry in the

suspect list. AND

Either the ABN, ACN, Company Number, or DUNS number of the company in the current application

matches an entry in the suspect list.

* The test used to determine if a name is "similar" uses the

SOUNDEX and DIFFERENCE SQL functions. For more information

about how these SQL functions work, refer to Microsoft's SQL

documentation.

[Company] Company Number Name 1.0 The Company Number Name 1.0 Rule is used to identify potentially suspicious applications by matching company data from the application to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact Company Number matches exactly.

Strong The legal name in the current application matches

the legal or trading name of an entry in the

suspect list.

OR

The trading name in the current application

matches the legal or trading name of an entry in the

suspect list.

Average Not used.

PARAM.

CODE DESCRIPTION





Weak

PARAM.

CODE DESCRIPTION



[Everyone] All PhoneNumbers 1.0 The All PhoneNumbers 1.0 Rule is used to identify potentially suspicious applications by matching phone numbers from the application to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact Home Phone Number matches exactly

AND

Work Phone Number matches exactly.

Strong The home phone of the current application matches

the home phone of an entry in the suspect list.

OR

The work phone of the current application matches

the work phone of an entry in the suspect list.

OR

An ‘Other’ phone number of the current application

matches an ‘other’ phone number of the same type

on an entry in the suspect list.

Average The home phone of the current application matches

any phone number of an entry in the suspect list.

OR

The work phone of the current application matches

any phone number of an entry in the suspect list.

OR

An ‘Other’ phone number of the current application

any phone number of the same type on an entry in

the suspect list.

Weak Not used.

PARAM.

CODE DESCRIPTION



[Everyone] Custom Suspect 1.0 Object The Custom Suspect 1.0 rule is used to perform a custom duplicate query.

STRENGTH

DESCRIPTION

Exact Data exists in the result of the custom query. The

query must return the id_request of the application

as the first column, and the status as the second

column.

Strong

Not used. Average

Weak

PARAM.

CODE DESCRIPTION



SQL QUERY

The SQL query that is to be run to find suspect

matches.

The parameter accepts placeholders that will

be replaced before the query is executed.

Custom Parameters can be referenced using these

parameters; {1}, {2}, {3}, etc, representing the order

of the parameters in the mapping.



[Everyone] Reference Name 1.0 The Reference Name 1.0 Rule is used to identify potentially suspicious applications by matching the name of references on the application to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact The first name, surname and date of birth of

an applicant’s reference match an entry in the

suspect list.

Strong The first name and surname of an applicant's

reference match an entry in the suspect list.

Average The surname of an applicant's reference

matches the first name, and the first name

matches the surname of an entry in the suspect

list.

Weak The surname of an applicant’s reference matches an entry in the suspect list.

PARAM.

CODE DESCRIPTION



[Individual] Individual Address 1.0 The Individual Address 1.0 Rule is used to identify potentially suspicious applications by matching the addresses on an application to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact The street number, name, suburb and either

the state or city of at least one of the addresses in

the current application matches that of an entry in

the suspect list.

Strong The street number and postcode of at least one of

the addresses in the current application matches

that of an entry in the suspect list.

AND

The street name of the matching address is

similar to that of an entry in the suspect list.

AND

The surname of the individual matches that on an

entry in the suspect list.

Average The street name of at least one of the addresses in

the current application matches that of an entry in

the suspect list.

AND

The surname of the individual matches that of a

suspect application.

Weak The postcode of at least one of the addresses in

the current application matches that of an entry

in the suspect list.

AND

The surname of the individual matches that of an

entry in the suspect list.



* The test used to determine if a name is "similar" uses the SOUNDEX and DIFFERENCE SQL functions. For more information about how these SQL functions work, refer to Microsoft's SQL documentation.

PARAM. CODE

DESCRIPTION

N/A There are no parameters available to

configure the behaviour of this rule.

[Individual] Individual Email 1.0 The Individual Email 1.0 Rule is used to identify potentially suspicious applications by matching email addresses from the application to entries in the Suspect List.

STRENGT

H DESCRIPTION

Exact The email address matches exactly.

Strong

Not used. Average

Weak

PARAM. CODE

DESCRIPTION

ID_TYPE The value must be a comma-separated list of

address types. When the parameter is

provided, the Suspect object will only analyse

email addresses with a type that exists in the

provided list.

[Individual] Individual Employer 1.0 The Individual Employer 1.0 Rule is used to identify potentially suspicious applications by matching an applicant’s employer to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact The name of the employer matches a company in the suspect list.

Strong

Not used. Average

Weak

PARAM. CODE

DESCRIPTION





[Individual] Individual Employer Address 1.0 The Individual Employer Address 1.0 Rule is used to identify potentially suspicious applications by matching an applicant’s employer’s address to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact The address of the employer matches that of a

company in the suspect list.

Strong

Not used. Average

Weak

PARAM. CODE

DESCRIPTION



[Individual] Individual Identification 1.0 The Individual Identification 1.0 Rule is used to identify potentially suspicious applications by matching an applicant’s identification details to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact The identification value and identification type

of an applicant match that of an entry in the

suspect list.

Strong The identification value match that of an entry in

the suspect list.

Average Not used.

Weak

PARAM. CODE

DESCRIPTION

ID_TYPE The value must be a comma-separated list of identification types. When the parameter is

provided, the Suspect object will only analyse identification with a type that exists in the provided

list.

[Individual] Individual Name 1.0 The Individual Name 1.0 Rule is used to identify potentially suspicious applications by matching an applicant’s details to entries in the Suspect List.

STRENGTH

DESCRIPTION

Exact The first name, surname and date of birth of

an applicant match that of an entry in the

suspect list.

Strong The first name and surname of an applicant

match that of an entry in the suspect list.

Average The surname of an applicant matches the

first name, and the first name matches the

surname of an entry in the suspect list.

Weak The surname of an applicant matches that of an entry in the suspect list.

PARAM. CODE

DESCRIPTION





File Type The name of the Suspect file to be used for all comparisons by the Suspect Register Object. Suspect Files are configured through the Fraud Manager administration section.

Min Strength Determines the minimum strength bracket to be used when considering a "match".

Max Strength Determines the maximum strength bracket to be used when considering a "match".

Alert The alert to be triggered if the rule finds at least one match.

Continue on Alert Determines the behaviour of the Suspect Register object once a match has been found. When checked, the object will continue processing the remaining mappings as normal. When unchecked, the object will move directly to the outcomes if a match has been found.

Custom Outcome The Custom Outcome to be used if the Suspect object finds a match.

Application Message Determines the Application Message that is included in the Application XML when a match is found. The Application Message can be displayed on multiple different pages of the application.

Parameters A list of parameters that will be passed to the Suspect Register object when processing the matching rules. The parameters used by each rule vary and are detailed above.

OUTCOMES The Outcomes tab of the Suspect Register object does not differ from the standard object outcome tab.

Objects | Variable Object


VARIABLE OBJECT The Variable object allows for the definition of a variable that can be used in other parts of the flow. Variables can be referenced in the Item editor using special {VARIABLE:} mark up.

DESCRIPTION The Description tab of the Variable object does not differ from the standard object description tab.

MAPPING

The Mapping tab lists each mapping for the Variable object to execute. Each mapping row contains several configuration fields.

Objects | Variable Object


Variable ID

The unique ID of the variable. The Variable ID will be used in other parts of the flow to reference the value of the variable.

Value

Determines the value of the variable.

Levels


Rule


OUTCOMES The Outcomes tab of the Variable object does not differ from the standard object outcome tab.

Objects | Webservice Object


WEBSERVICE OBJECT The Webservice object allows for a flow to be integrated with an external web service. There is a comparatively large amount of use cases for this object. The objects have been used to perform integrations with internal banking systems, third-party validation services or even interacting with illion Decisioning’s own Inteport API. Not every web service can be integrated using the Webservice object. Integrations that cannot be achieved using the Webservice object need to be introduced through additional core development.

DESCRIPTION The Description tab of the Scorecard object contains one field in addition to the standard object description tab.

Attach Uploaded Documents to Application XML

Determines whether documents that have been uploaded as part of the web service call are to be included alongside the application XML.

MAPPING

The Mapping tab lists each mapping for the Variable object to execute. Each mapping row contains several configuration fields.









Existing check

Determines the behaviour of the Webservice object when there is an existing result for the web service in the application XML. When checked, the Webservice object will not perform another call if the results of the call exist in the application XML. When unchecked, the Webservice object will perform the web service call each time the application passes through it, regardless of whether the call has already been made.

Fix node order

Determines the behaviour of the Webservice object when adding the results of a call to the application XML.

When checked, the Webservice object will rearrange the application XML so that the order of the child nodes matches the order required by the application schema. When unchecked, the results of the call will be appended at the bottom of the node dictated by the store path.

Store Path

Determines the XPath of the location where the result of the web service call will be stored.

Loop XPath

Determines whether to loop over an application element. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Request Schema

Specifies an XSLT that will be used to transform the application XML into the required format of the web service call. The resulting XML is the body of the request sent to the web service

Response Schema

Specifies an XSLT that will be used to transform the result of the web service call before it is stored in the application XML. At the most basic level, this can be used to strip unwanted namespace data, however, this can also be used to perform more complex transformations.

Transform Schema

Specifies an XSLT that will be used to transform the entire application XML after the web service response has been added.

This is most commonly used when data returned in a web service call needs to be used in other parts of the application, particularly if it is replacing existing data.

Display Schema

Specifies an XSLT that will be used to display the result of the web service call to the user. The user is able to view the result of all web service calls through the Web Service screen control.



Security - URL

Specifies the URL to query when making the web service call.

Security - Transport Method

The HTTP transportation method used to the make the web service request. The required transport method will vary according to the definition of the web service.

SUPPORTED HTTP METHODS

GET*

PUT

POST

DELETE*

PATCH

*These methods expect the body of the request to be empty

Security - SSL

Determines whether the Webservice object needs to use an SSL connection to connect to the web service.

Security - Certificate

The filename of a client certificate to use when connecting to the web service. The certificate must first be installed on the server running illion Decisioning; for more information contact the illion Decisioning Support Team:


Security - Password

The client certificate password of the client certificate used to connect to the web service.

Security - Timeout Determines the length of time, in seconds, beyond which the Webservice object will consider the web service to have timed out.

Options - Retries

Determines the number of times the web service object shall attempt to retry a web service call once a timeout has been received.

Options - Delay

Determines the length of time, in seconds, that the Webservice object should wait before attempting to retry a web service call.

Options - Store location

Provides a one time choice of whether to continue using older inconsistent storage approach on existing mappings. For context, before around mid-2018, there was no fixed storage location for web service results. This means that if a change was made later to display the data, the storage location would have changed and caused confusion. Since this inconsistency is now fixed this option will not be available for new objects and mappings.

Parameters

A list of parameters that will be passed to the web service when performing the web service call.

Post Webservice Object - Ruleset The object that will be run following the web service call. Any outcomes of the object will not be used following processing; the application will continue to be processed any other web service mappings.

Documents

Determines the behaviour of the Webservice object when receiving a document as part of a web service call. Any documents that are returned can be captured and stored alongside the application XML when configured by the Webservice object.




Documents - ID


Documents - Name

The customer-facing name of the document being attached to the application. This name should include the file extension.

Documents - Location

The location of the document within the XML of the web service response. The entire contents of the node provided will be considered to be the contents of the file.

Documents - Category

The category of the document uploaded to the application. Categories are used by the Upload2 screen control to sort documents into different sections before they are displayed to the end user.

Documents - Document Type The type of the document uploaded to the application. Types are used by the Upload2 screen control to sort documents into different sections before they are displayed to the end user.

Documents to Send

The Upload settings allow for a base64 encoded file to be transmitted as part of the web service call to the web service.

Documents to Send - ID Specifies a unique ID for the file being sent.

Documents to Send - Filename Specifies an XSLT that will be used to produce the base64 encoded file.

Documents to Send - Type The type of content output. The multiple output PDF types are used to map the exact type of PDF to the format specified in the transformation XSLT.


PDF

PDF - 0.94

PDF - 1.1

HTML

STATIC

HTML to PDF

Documents to Send - Password A free-text field that can be used to password-protect PDF documents. When blank, the file has no protection. When set, the PDF generated will only open after the user provides the text entered in the field as the password.

Documents to Send - Rule

The rule indicates whether or not to include the file as part of the web service call. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

OUTCOMES

The Outcomes tab of the Webservice object does not differ from the standard object outcome tab.

Objects | XML Object


XML OBJECT The XML object allows for an application to be converted to a different XML structure and stored as a file.

DESCRIPTION

The Description tab of the XML object does not differ from the standard object description tab.

MAPPING The Mapping tab lists each mapping for the XML object to execute. Each mapping row contains several configuration fields.




Levels


Rule


Append Data

This setting is deprecated and exists for backwards compatibility only.

Continue

Determines whether to continue processing the other rows of the object after processing the current row. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Request Specifies an XSLT that will be run over the application XML to generate the file to be stored.

Method

The type of content output. The multiple output PDF types are used to map the exact type of PDF to the format specified in the transformation XSLT.


XML

PDF

PDF - 0.94

PDF - 1.1

Text

Store Method Determines the method by which the generated output would be stored: either 'File Location', 'FTP', 'SFTP'. The selection of store method determines the storage fields that are then shown.

File Location When 'File Location' is the selected Store Method, the following fields are displayed.

URL or File Location The URL or File Location field is displayed when "File Location" is the selected storage method. The URL or File Location determines the file path where the resulting file should be stored.

FTP When 'FTP' is the selected Store Method, the following fields are displayed.

Server Determines the location of the file server.

Port Determines the port to use when connecting to the server.



Path Determines the file path where the resulting file should be stored.

Username and Password The log in credentials to be used when connecting to the FTP server.

Passive Mode Determines the connection mode to be used when connecting to the FTP server.

SFTP When 'SFTP' is the selected Store Method, the following fields are displayed.

File Name Determines the name of the file stored. When not set, a unique, generated name is used instead,

Server Determines the location of the file server.

Host Key Fingerprint Verifies that a particular client is connecting to the correct host and is generally provided by SSH server administrator to the clients.

Port Determines the port to use when connecting to the server.

Path Determines the file path where the resulting file should be stored.

Authentication Method Either 'Certificate' or 'Password'; determines the method for authenticating a connection to the SFTP server.

Parameters

A list of parameters that will be passed into the Request XSLT when generating the file.

OUTCOMES The Outcomes tab of the Webservice object does not differ from the standard object outcome tab.

Objects | Custom Objects


CUSTOM OBJECTS Custom Objects are customer-specific objects which have been developed using a common set of Custom Object functionality. Custom Objects cannot be fully configured without a project implementation. For more information, contact the illion Decisioning Support Team:


Configuring Custom Objects Once the custom object code has been deployed, the object can be configured in the same way as any other object.

DESCRIPTION

The Description tab of Custom objects contains one field in addition to the standard object description tab.

Object Type

Specifies the custom object type to use when processing the object. The type must match the name of the object in the custom object code.

MAPPING The Mapping tab lists each mapping for the Custom object to execute. Each mapping row contains several configuration fields.


Objects | Custom Objects


ID


Levels


Rule


Append Data

The Append check box allows the Custom object to determine how it will write to the XPath defined inside the custom object. The exact implementation of this setting will vary for each custom object

Parameters Defines a list of parameters that will be passed to the custom object. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

OUTCOMES

The Outcomes tab of the Custom object does not differ from the standard object outcome tab.

Objects | Object Testing


OBJECT TESTING Objects, Rules and Items can all be tested via the testing checklist 'Save & Test' icon in the top right of the respective editor popups.

PERFORMING A TEST When the Icon is selected, a popup appears.

Once an Application ID has been entered, the value of the object, rule or item can be tested by selecting the ‘Test’ button. The last application ID used to test an object will be prefilled in the Application ID box for future tests by an operator during a designer session.

Testing an application involved processing the application provided through the object, and returning the values calculated.

REVIEWING TEST RESULTS

The test results will appear at the top of the editor popup. Each object, item and rule simulated in the test will be displayed and available for analysis. In addition, the resulting application XML for the application is returned.

The Object testing functionality allows for quick troubleshooting of changes to rules, objects and items without requiring a new application to be submitted.

Designer Tools | Final Actions


FINAL ACTIONS A flow will continue processing from object to object, passing through queues until it reaches an ‘END’ object. The ‘END’ object is a placeholder object indicating that the flow has completed processing, removing the application from the queue. The last stage of processing is to execute any ‘Final Actions’. Final Actions are simply steps of processing that have configured to occur at the end of processing. Final Actions can be configured by selecting the Final Object row at the bottom of the flow mapping.

CONFIGURING A FINAL ACTION

From the Final Actions popup, multiple final actions can be configured. The Final Actions popup consists of one tab.

Action ID


Status From

The status of the application when it reached the end of Flow processing, used in conjunction with the Rule field to determine if the Final Action is enabled and accessible to Operators. When not selected, the status will be considered to match any status.

Status To The status that will be given to the application when the Final Action is selected. When not selected, the status will not change when the Final Action is selected.

Rule

The rule to determine if the Final Action is enabled and accessible to Operators. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Object The object that will be run as part of the final action. The object will be executed when both the rule is met and the ‘from’ and ‘to’ statuses match that of the application. Any outcomes of the object will not be used following processing; the application will continue to be processed by the other final actions.

Privileges A list of access groups, the members of which will have access to perform this action on an application that has completed processing.

Designer Tools | Status Change Events


STATUS CHANGE EVENTS Status Change Events are used to trigger objects outside of the normal flow mapping. Status Change Events are most commonly used for running Repayment Calculations when the details of an application have changed or triggering communication emails.

The Status Change Events popup can be accessed by selecting the ‘Status with Arrow’ icon from the Toolbar.

STATUS CHANGE MAPPING The Status Change Events popup consists of a single mapping tab.

Object The object that will be run as part of the status change event. The object will be executed when both the rule is met and the ‘from’ and ‘to’ statuses match that of the application. Any outcomes of the object will not be used following processing; the application will continue to be processed by the other status change objects.

Status From

The status of the application prior to being processed. When not selected, the status will be considered to match any status.

Designer Tools | Status Change Events


Status To

The status of the application after being processed. When not selected, the status will be considered to match any status.

Rule

The rule to determine if the status change event should be processed. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

On Change Determines when to run the status change object, either before or after an application is processed through a flow. An application will reach the end of processing when it reaches an “End” object or is kept in a queue.

On Start Allows status change events to run after an object has changed the status of an application, rather than waiting until the end of the current processing. When checked, the status change events will be run as soon as an object changes the application status. When unchecked, the events will only occur once processing has been completed.

Designer Tools | Flow Details


FLOW DETAILS The Flow Details tab contains overarching information about the flow and how it operates. It can be accessed by selecting ‘Flow Details’ from the Tools Menu.

The Flow Details screen is also displayed as the first Designer screen after a flow has been created.

The Flow Details screen consists of four sections: Flow Description and Activation, Start Object & Status Details, Schemas & Stylesheets, and Sub Flow Details.

FLOW DESCRIPTION AND ACTIVATION

Flow Description

The flow description can be modified through the Flow Description multiline text field.

The Flow Description is displayed on the Flow List screen and is generally used to provide a human-friendly description of the flow and the purpose it serves.



Activating a Flow

A flow can be activated from the Flow Details popup by selecting the “Activate this flow” button.

Making a flow active will set the currently active version of the flow to inactive.

START OBJECT & STATUS DETAILS SECTION The Start Object & Status Details section of the Flow Details popup allows users to define the behaviour and the start and end of processing an application through a flow.

The section consists of three fields.

Starting Object The starting object determines the first object that is used when an application is sent to the flow. This is the first object that the flow uses, and from it, the flow will navigate through subsequent objects.

Initial Status

The initial status determines the status that is assigned to the application before objects begin processing it as part of the flow.

Final Status

The final status determines the status that is assigned to the application once the application reaches an ‘END’ object in the flow. The status will be assigned to the application in the same manner as any other status assignment; the priority of the status will be the determining factor as to whether the final status is kept by the application. For more information about status priorities, see the ‘Statuses’ section of this document.

SCHEMAS & STYLESHEETS The Schemas & Stylesheets section of the Flow Details popup allows users to define the schema and translation stylesheets used to process applications.

Request Schema

The request schema is used by the engine to validate the application XML, load enumeration files and generally dictates the data standard with which applications are stored.

The engine will attempt to load the schema from the file location “…/Inteflow Engine/schema/”, using the filename given in the text field. This file must be an XSD file.

Request Translation

The request translation can be used to perform alterations to an application’s XML with an XSLT file before it is validated. The engine will attempt to load the stylesheet from the file location “…/



Inteflow Engine/schema/”, using the filename given in the text field.

Retrieve Schema

The retrieve schema defines a schema that will be used to validate the application when retrieving an application from the engine. The engine will attempt to load the schema from the file location “.../Inteflow Engine/schema/”, using the filename given in the text field. This file must be an XSD file.

Response Translation

The response translation can be used to perform alterations to an application’s XML with an XSLT file before it is returned to the screens to be used. The engine will attempt to load the schema from the file location “…/Inteflow Engine/schema/”, using the filename given in the text field.

Application Translation

The application translation can be used to alter the application XML when an application is loaded from the database. This can be used to convert existing applications to use a new set of enumerations, for example. The engine will attempt to load the stylesheet from the file location “…/Inteflow Engine/schema/”, using the filename given in the text field.

SUB FLOW DETAILS

The Sub Flow Details sections allow for the definition of a sub-flow.

Sub Flow

The sub-flow drop down will offer a list of flows that have been configured in the system for a company.

Sub Flow Rule

The sub-flow rule determines whether an application is to be sent through the sub flow. An application must pass the rule before it will be sent to use the sub flow.

Sub Flow Level The sub-flow level field determines the application level of the data that will be sent to the sub flow.

Application Volume (%) The application volume field can be used to indicate how many applications which pass the sub-flow rule should be sent to the sub flow. This would most commonly be used if the rule was “SYSTEM TRUE” and the intent was to compare the performance of two flows against each other.

Designer Tools | Linked Documents Setup


LINKED DOCUMENTS SETUP As part of the credit decisioning process, third-party verification or validation calls may be integrated with a flow. The method by which these third-party services return response data varies greatly, with some services offering only asynchronous responses to requests. Further, the size of the data returned could be many times larger than the application XML itself.

In order to allow for the seamless integration between illion Decisioning and third-party services, linked documents can be configured to store and preserve supplemental data relating to an application. The contents of linked documents are included in the application for the purposes of flow processing but excluded when managing the application from data entry screen to screen. Linked Documents must be configured through the Linked Documents Setup menu. It can be accessed by selecting 'Linked Documents Setup' from the Tools Menu.

Defining Linked Documents From the Linked Documents Setup popup, multiple different Linked Documents can be configured. The Linked Document Setup consists of one tab.

Type Specifies the type of the Linked Document call being returned. Is used to categorise the document in the Linked Document screen control.

Name Specifies the customer-facing name of the Linked Document being returned.



XML Post Param Determines the behaviour of the Linked Document when the contents of the document are stored as an XML file in a POST Parameter to Inteport.

The document will be retrieved from the named parameter in the POST call to Inteport.

XML Param Encoding Specifies the encoding of the XML file being returned in the POST call.

SUPPORTED ENCODING

TYPES

Plain Text

Base64 Encoded

HTML Encoded

HTML POST Param Determines the behaviour of the Linked Document when the contents of the document are stored as HTML in a POST Parameter to Inteport.

The document will be retrieved from the named parameter in the POST call to Inteport.

HTML Param Encoding Specifies the encoding of the HTML file being returned in the POST call.

SUPPORTED ENCODING

TYPES

Plain Text

Base64 Encoded

HTML Encoded

Display Method Determines the behaviour of the Linked Documents screen control when displaying the linked document to the end user.

When set to ‘HTML’, the control will return the HTML code returned in the POST parameter. When set to ‘Stylesheet’, the control will use the Display Transform file to transform the XML data returned in the POST parameter.

Display Transform Specifies an XSLT that will be used to display the result of the linked document call to the user. The user is able to view the result of all linked documents calls through the Linked Documents control.



Display Type Determines the data displayed in the Linked Documents control. When ‘Latest’ is selected, the control will display only the results of the most recent iteration of the Linked Document call of the same type and name. When ‘All’ is selected, the control will display the results of all linked document call with the same type and name.

Request Transform Specifies an XSLT that will be used to transform the request to Inteport before the linked document is stored. At the most basic level, this can be used to strip unwanted namespace data, however, this can also be used to perform more complex transformations. Note: The XSLT file must be stored within the Inteport\schema folder.

Designer Tools | Reason List Setup


REASON LIST SETUP Reason Lists allows for enhanced options and functionality when processing applications through queues. Through the Reason Lists Setup tab, lists of reasons are offered to a user when an action is selected from a queue. The reason selection is then stored in the application XML and made available for further processing.

The Reason List Setup page can be accessed by selecting 'Reason Lists Setup' from the Tools Menu.

Defining a Reason List From the Reason Lists Setup popup, multiple different lists of reason lists can be defined. The Reason List Setup consists of one tab.

Reason List ID The ID of the Reason List row; used to uniquely identify the reason list. The ID is the code that will appear in any dropdown wherein reason lists need to be selected.

Reasons A list of plain text ‘reasons’ that will offer to the user for selection.

Reason The customer-facing text of the reason.

Comments Required Determines whether an additional ‘comments’ field will be made visible to the user upon selecting the reason.

Designer Tools | DLA Configuration


DLA CONFIGURATION The credit policies of some organisations dictate that different business processes need to be followed for different applications according to the level of exposure. For example, junior credit operators may only have the ability to approve applications where the total loan funds do not exceed $1,000,000, whereas senior credit operators may be authorised to approve applications for loans of up to $5,000,000. This difference in authority is enabled through the Designated Lending

Authority (DLA) configuration. Configuring DLAs is a multi-step process: first, the DLA settings need to be defined in the DLA Configuration section, then the authority groups need to be created in the Designated Lending Authority administration screens. The DLA Configuration popup can be accessed by selecting the 'DLA shield' icon from the Tools Menu

DLA Mapping The DLA Mapping popup consists of a single mapping tab.

Setting Name The ID of the Mapping row; used to uniquely identify the DLA setting in the list.

Designer Tools | DLA Configuration


Rule The Rule to indicate whether or not to include a given DLA setting in the consideration of whether the DLA restrictions are met. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.

Comparison The logical operator used to compare the setting value configured in an operator’s DLA access group in the Designation Lending Authority Administration screens to the value in the DLA mapping.

Value The value used to compare to the setting configured in an operator’s DLA access group in the Designation Lending Authority Administration screens.

Designer Tools | 'What If?' & Object Testing


'WHAT IF?' & OBJECT TESTING ‘What If’ Testing is scheduled for a redesign.

This document will be updated when the redesign is complete.

Designer Tools | Object Import


OBJECT IMPORT The Object Import tab allows for objects to be imported from flows on other companies and environments. It can be accessed by selecting ‘Object Import’ from the Tools Menu.

Importing Objects There are three stages required to import an object.

SELECT ENVIRONMENT The first stage of importing objects is to enter the details of the environment from which the object should be imported.

Company The company code of the company with the configured flow and objects.

Merchant The merchant code of the merchant to be used.

Operator The operator to be used to log into the company and merchant.

Password The password of the operator.

Inteport URL The URL to the desired environment. The Inteport URL field features two options in the dropdown.

Default The current environment. This selection should be made if importing objects from a different company in the same environment.

Other An URL to the DecisionGateway. Should take the form of {URL}/Inteport/decisiongateway.asmx

Connect In order to proceed with importing objects, the user is required to connect to an environment by selecting the ‘Connect’ button.

SELECT FLOW The second stage of the object import process is to select the flow from which the objects will be imported.

Designer Tools | Object Import


By default, this tab will display a list of all currently active flows on the destination environment to which the user used to log into the company and merchant has access. The Filter dropdown can be used to select inactive and previous versions of flows from the destination environment.

SELECT OBJECTS Once a flow has been selected, objects can be imported by selecting them from a list of all objects on the ‘Select Objects’ tab.

Any object with the ‘Import’ checkbox checked will be imported into the destination environment once the ‘Save’ icon has been selected.

SELECT RULES Once a flow has been selected, rules can be imported by selecting them from a list of all rules on the ‘Select Rules’ tab.

Any rule with the ‘Import’ checkbox checked will be imported into the

destination environment once the ‘Save’ icon has been selected.

SELECT ITEMS Once a flow has been selected, items can be imported by selecting them from a list of all items on the ‘Select Items’ tab

Any item with the ‘Import’ checkbox checked will be imported into the destination environment once the ‘Save’ icon has been selected.

Designer Tools | Change History / Orphaned Items


CHANGE HISTORY The Change History contains a list of all changes that have been made to the flow. It can be accessed by selecting ‘Change History’ on the Tools Menu.

The Change History popup consists of one section.

Each change that is saved to the database is automatically assigned a new version number and is added the Change History page.

MIGRATION TAB The Migration tab shows the history of flow migrations performed with the flow. For more information about Flow Migrations, see the 'Flow Migrations' section of this document.

ORPHANED ITEMS Orphaned Items contains a list of all items, objects and rules that are not referenced anywhere in the flow. It can be accessed by selecting ‘Orphaned Items’ from the tools menu.

The Orphaned Items list is designed to aid the cleanup of unnecessary or superfluous items in the flow.

Designer Tools | Flow Documenter


FLOW DOCUMENTER The Flow Documenter exports a summary of the flow to a PDF format. It can be accessed by selecting ‘Flow Documenter’ from the tools menu.

The Flow Documenter is most commonly used to provide a hard-copy document of the flow to an auditor or external agency.

The PDF contains a textual description of the flow mapping and item details.



OBSOLETE FUNCTIONALITY

External Accounts Object (Obsolete) The functionality that follows is now obsolete. The details are provided are for maintenance of existing solutions only, as this functionality is no longer being updated.

The External Accounts object allows Designer to search and retrieve application details against an ICBS core banking system. Configuring an External Accounts object requires a very specific set of instructions to be provided by the customer.

DESCRIPTION The Description tab of the External Accounts object contains four fields in addition to the standard object description tab.

ICBS Server The location of the ICBS system.

ICBS Port Number The port number to use to connect to the ICBS system.

ICBS Temp File Location The Temporary File Location to use for ICBS data.

ICBS FTP Command The FTP Command to use on the ICBS system.

MAPPING The Mapping tab lists each separate external call for the External Account object to execute. Each mapping row contains several configuration fields.



ID The ID of the Mapping row; used to uniquely identify the mapping in the list. For more information see the ‘Mapping Tab’ subsection of the ‘Object’ section of this document.'




Run Command Determines whether the FTP commands entered in the ICBS FTP Command field should be run.

FTP Determines whether to transfer the file to the set FTP site.

File The name of the file that contains the request message.

Parameters Parameters to be passed into the logic for an External Account call.

OUTCOMES The Outcomes tab of the External Account object does not differ from the standard object outcome tab.

Appendices | Reference Data


APPENDIX A: REFERENCE DATA XPath Qualifiers

NAM

E

XPAT

H

Application /inteflow/service/application/

Applicant /inteflow/service/application/applicant/

Product /inteflow/service/application/product/

Loan Product List /inteflow/service/application/loan_product_list/

Finance /inteflow/service/application/finance/

Insurance /inteflow/service/application/insurance/

Result /inteflow/service/application/result/

Bureau List /inteflow/service/application/applicant/result/

bureau_list/

Alert List /inteflow/service/application/applicant/result/

alert_list/

Baycorp Response /inteflow/service/application/applicant/result/

bureau_list/bureau/tx_data_bureau/BCAmessage/

BCAservices/BCAservice/BCAservicedata/respon

se/

NAM

E

XPAT

H

Baycorp Org Id

Response

/inteflow/service/application/applicant/result/



se/org-id-result/

Baycorp Credit

Report




se/enquiry-report/

DnB Individual

Response /inteflow/service/application/applicant/result/

bureau_list/bureau/tx_data_bureau/Response/

Product/

DnB Commercial

Bureau Enquiry



CommercialBureauEnquiry/Product/

DnB Commercial

Payment Predictor

Enquiry



PaymentPredictor/Product/

Appendices | Loan Calculator


APPENDIX B: LOAN CALCULATOR EXCEL SPREADSHEET For the most recent version of the Loan Calculator Excel Spreadsheet, please contact the illion Decisioning Support Team:



Appendices | GreenID Match Logic XPaths


APPENDIX C: GREENID MATCH LOGIC XPATHS

APPLICATION PATH GREENID REPORT XPATH

individual/nm_firstname name/givenName input[name=’greenid_passportdvs_givenname’]/value input[name=’greenid_aec_givenname’]/value

individual/nm_middlename name/middleNames input[name=’greenid_passportdvs_middlename’]/value input[name=’greenid_citizenshipcertificatedvs_middlename’]/value

input[name=’greenid_nzcitizenship_middlename’]/value input[name=’greenid_nzpassport_middlename’]/value

input[name=’greenid_nztadriverslicence_middlename’]/value

individual/nm_surname name/surname input[name=’greenid_passportdvs_surname’]/value input[name=’greenid_citizenshipcertificatedvs_surname’]/value

input[name=’greenid_medibank_surname’]/value input[name=’greenid_aec_surname’]/value input[name=’greenid_wp_surname’]/value input[name=’greenid_nzaa_surname’]/value

input[name=’greenid_nzbirthcertificate_surname’]/value input[name=’greenid_nzcitizenship_surname’]/value input[name=’greenid_nzpassport_surname’]/value

input[name=’greenid_nztadriverslicence_surname’]/value input[name=’greenid_nzwp_surname’]/value



individual/dt_dob dob input[name=’greenid_passportdvs_dob’]/value input[name=’greenid_citizenshipcertificatedvs_dob’]/value

input[name=’greenid_medibank_dob’]/value input[name=’greenid_nzaa_dob’]/value input[name=’greenid_nzbirthcertificate_dob’]/value input[name=’greenid_nzcitizenship_dob’]/value

input[name=’greenid_nzpassport_dob’]/value input[name=’greenid_nztadriverslicence_dob’]/value

individual/cd_title honorific

individual/cd_gender extraData[name =’passportGenderCode’]/value input[name=’greenid_passportdvs_gender’]/value

address/current_address/cd_country currentResidentialAddress/country

address/current_address/cd_postcode currentResidentialAddress/postcode

address/current_address/cd_state currentResidentialAddress/state

address/current_address/nm_street currentResidentialAddress/streetName input[name=’greenid_aec_streetname’]/value input[name=’greenid_wp_streetname’]/value input[name=’greenid_nzaa_streetname’]/value

input[name=’greenid_nzwp_streetname’]/value

address/current_address/tx_no_unit input[name=’greenid_wp_flatnumber’]/value input[name=’greenid_nzaa_flatnumber’]/value input[name=’greenid_nzwp_flatnumber’]/value

address/current_address/tx_no_street currentResidentialAddress/streetNumber input[name=’greenid_aec_streetnumber’]/value input[name=’greenid_wp_streetnumber’]/value input[name=’greenid_nzaa_streetnumber’]/value

input[name=’greenid_nzwp_streetnumber’]/value



address/current_address/cd_type_street currentResidentialAddress/streetType input[name=’greenid_aec_streettype’]/value input[name=’greenid_wp_streettype’]/value input[name=’greenid_nzaa_streettype’]/value

input[name=’greenid_nzwp_streettype’]/value

address/current_address/nm_suburb currentResidentialAddress/suburb input[name=’greenid_aec_suburb’]/value input[name=’greenid_wp_suburb’]/value input[name=’greenid_nzaa_suburb’]/value

input[name=’greenid_nzwp_suburb’]/value

address/previous_address/cd_country previousResidentialAddress/country

address/previous_address/cd_postcode previousResidentialAddress/postcode

address/previous_address/cd_state previousResidentialAddress/state

address/previous_address/nm_street previousResidentialAddress/streetName

address/previous_address/tx_no_unit previousResidentialAddress/flatNumber

address/previous_address/tx_no_street previousResidentialAddress/streetNumber

address/previous_address/cd_type_street previousResidentialAddress/streetType

address/previous_address/nm_suburb previousResidentialAddress/suburb

contact/home_phone/tx_area|contact/home_ phone/tx_number

homePhone

contact/work_phone/tx_area|contact/work_ phone/tx_number

workPhone

contact/Other[@cd_type=’Mobile’]/tx_number

mobile

contact/email/tx_address email

identification/drivers_license/id_number extraData[name = ‘driversLicenceNumber’ ]/value



address/current_address/cd_type_street currentResidentialAddress/streetType input[name=’greenid_aec_streettype’]/value input[name=’greenid_wp_streettype’]/value input[name=’greenid_nzaa_streettype’]/value

input[name=’greenid_nzwp_streettype’]/value

address/current_address/nm_suburb currentResidentialAddress/suburb input[name=’greenid_aec_suburb’]/value input[name=’greenid_wp_suburb’]/value input[name=’greenid_nzaa_suburb’]/value

input[name=’greenid_nzwp_suburb’]/value

address/previous_address/cd_country previousResidentialAddress/country

address/previous_address/cd_postcode previousResidentialAddress/postcode

address/previous_address/cd_state previousResidentialAddress/state

address/previous_address/nm_street previousResidentialAddress/streetName

address/previous_address/tx_no_unit previousResidentialAddress/flatNumber

address/previous_address/tx_no_street previousResidentialAddress/streetNumber

address/previous_address/cd_type_street previousResidentialAddress/streetType

address/previous_address/nm_suburb previousResidentialAddress/suburb

contact/home_phone/tx_area|contact/home_ phone/tx_number

homePhone

contact/work_phone/tx_area|contact/work_ phone/tx_number

workPhone

contact/Other[@cd_type=’Mobile’]/tx_number

mobile

contact/email/tx_address email

identification/drivers_license/id_number extraData[name = ‘driversLicenceNumber’ ]/value

identification/drivers_license/cd_state extraData[name = ‘driversLicenceState’]/value

identification/drivers_license/dt_expiry extraData[name = ‘driversLicenceExpiryDate’]/value



identification/drivers_license/no_version extraData[name = ‘driversLicenceRTANumber’]/value

identification/other[cd_type = ‘Medicare’ or cd_type = ‘MEDICARE’]/id_number

extraData[name =’medicareCardNumber’]/value

identification/other[cd_type = ‘Medicare’ or cd_type = ‘MEDICARE’]/tx_fullname

extraData[name =’medicareNameOnCard’]/value

identification/other[cd_type = ‘Medicare’ or cd_type = ‘MEDICARE’]/cd_colour

extraData[name =’medicareCardColour’]/value

identification/other[cd_type = ‘Medicare’ or cd_type = ‘MEDICARE’]/dt_expiry

extraData[name =’medicareCardExpiryDate’]/value

identification/passport/id_number extraData[name =’passportNumber’]/value extraData[name =’visaPassportNumber’]/value input[name=’greenid_passportdvs_number’]/value input[name=’greenid_nzpassport_number’]/value

input[name=’greenid_visadvs_passport_number’]/value

identification/passport/cd_country extraData[name =’visaCountryOfIssue’]/value

identification/passport/nm_firstname input[name=’greenid_passportdvs_givenname’]/value

identification/passport/nm_middlename input[name=’greenid_passportdvs_middlename’]/value

identification/passport/nm_surname input[name=’greenid_passportdvs_surname’]/value

Appendices | Document History


APPENDIX D: DOCUMENT HISTORY This document is maintained by the illion Decisioning Product Team: [email protected]

Version History

DATE DESCRIPTION NAME ALIGNED TO INTEFLOW/ ILLION DECISIONING VERSION

DOCUMENT VERSION

3 May 17 Initial Document M CHASE 5.0.0.10 -

10 May 17 Patch 11 Updates: N/A Patch 12 Updates: PPSR Object

M CHASE 5.0.0.12 Patch 12

19 May 17 Section Break Cleanup Table of Contents Fixes Patch 13 Updates:

PDR-1968

PDR-71

PDR-2061

PDR-2094


16 Jun 17 Patch 17 Updates:

PDR-2223

PDR-2225

PDR-2054


28 Jun 17 Formatting Update Patch 18 Updates:

(N/A)


30 Jun 17 Patch 19 Updates:

PDR-2284

PDR-2337






DOCUMENT VERSION

14 Jul 17 Patch 20 Updates:

PDR-2379

PDR-2357

PDR-2378

PDR-2182

PDR-2290


18 Jul 17 Corrections:

Queue - Assignment - "Cycle"

Updated Queue - Actions Screenshot


28 Jul 17 Patch 21 & 22 Updates:

PDR-179

PDR-2373


11 Aug 17 Patch 23, 24 & 25 Updates:

PDR-2500

PDR-2406

PDR-2646


25 Aug 17 Patch 26 Updates:

PDR-2597

PDR-2595

PDR-2599

PDR-2285 Corrections:

XML Object- Method - Output Types


28 Aug 17 Corrections:

Suspect Object - Individual Identification Rule


30 Aug 17 Patch 27 Updates:

PDR-2354


6 Oct 17 Patch 28, 29 & 30 Updates:

PDR-2805

PDR-2701





DOCUMENT VERSION

PDR-2829 Corrections:

Bureau Object - Reuse Logic

10 Oct 17 Patch 31 Updates:

PDR-2871


20 Oct 17 Patch 32–36 Updates:

PDR-2410

PDR-2878

PDR-2845

PDR-2865 Dun & Bradstreet Rebrand:

All Decision Intellect references replaced with illion.


27 Oct 17 Patch 37-38 Updates:

PDR-2957

PDR-2851


1 Nov 17 Patch 39, 40, 41 & 42 Updates:

PDR-2985

PDR-2948

PDR-3011

PDR-2959

PDR-2496

PDR-3009


13 Nov 17 Patch 43, 44 & 45 Updates:

PDR-2898 Amendments

Queue Object - 'Repeat: Clarification of behaviour.


17 Nov 17 Patch 46 & 47 Updates:

(N/A)





DOCUMENT VERSION

Amendment:

PDR-2955 from Patch 44

29 Nov 17 Patch 48, 49 & 50 Updates:

PDR-3140


6 Dec 17 Patch 51 Updates:

PDR-3022


15 Dec 17 Patch 52, 53 & 54 Updates:

PDR-2490


22 Dec 17 Patch 55 & 56 Updates:

PDR-3364


29 Jan 18 V 5.0.1, Patch 1 - 8 Updates:

PDR-3369

PDR-2906

PDR-3416 Amendments

Application Merge Object - Clarification of Merged XML structure

M CHASE 5.0.1.8 v5.0.1 Patch 8

31 Jan 18 Patch 8 Updates:

N/A Formatting Update

M CHASE 5.0.1.9 v5.0.1 Patch 8

15 May 18 PDR-4074 Amendment

Ownership Object

F MAHER 5.0.1.29 May 2018

31 May 18 PDR-3737 – Display output on bureau object F MAHER 5.0.1.21 May 2018

1 Jun 18 PDR-3388 – Updated Supported HTTP methods F MAHER 5.0.1.21 June 2018

7 Sep 18 Updated wording around suspect register matches F MAHER 5.0.1.29 Sep 2018




DOCUMENT VERSION

11 Oct 18 Updated wording on Duplicate Identification Check R DWYER 5.0.1.29 Oct 2018

28 Dec 18 Added clarity to several definitions in Final Actions and Communication Objects

R DWYER 5.0.1.29 Dec 2018

9 Jan 19 Added extra information on Duplicate Analyser Levels R DWYER 5.0.1.29 Jan 2018

22 Feb 19 Added clarity on XSLT file location in Linked Documents setup

R DWYER 5.0.1.29 Feb 2019

26 Feb 19 Added details around moving and deleting Object mappings

R DWYER 5.0.1.29 Feb 2019

01 Mar 19 Updated product name from Inteflow to illion Decisioning F MAHER - 3.0

16 Mar 19 Added Simple KYC Object R DWYER 5.1.0.18 3.1

16 May 19 Add further information on Auto check-in and follow-up R DWYER 5.1.0.18 3.2

31 May 19 Obsolete the External Accounts object L CROFT 5.2.0.1 3.3

7 Nov 19 Add NZBN details to the Simple KYC Object R DWYER 5.2.0.15 3.4

12 Nov 19 In SFTP Store Method of the XML object: (a) Added missing information on Host Key Fingerprint; (b) Corrected File Name being termed as Server. In Webservice Object: Added new option ‘Store Location’

N SANDHU

5.2.0.1 3.5

5 Feb 20 Add OCR Labs Object B SAWYER 5.2.0.20 3.6