Interpreting Workflows

The start step signifies the successful initiation of the workflow. To confirm that the workflow started without issues, check if the execution result includes a start step with a result of COMPLETE. Typically, no processResults are expected for this step.

The decision step serves as a pivotal point in the workflow, determining its final status—PASS, FAIL, or REVIEW. This decision is based on the outcomes of the preceding steps. For example, if all prior steps were executed successfully and all checks were cleared, the workflow is typically marked as PASS. Conversely, if any step encountered an issue, such as a failed verification, the workflow is likely marked as FAIL. It is important to note that these statuses can be customized within the workflow builder.

The risk step in the workflow is a mandatory checkpoint for risk assessment. It doesn’t result in a pass or fail status. Instead, it’s simply marked as “COMPLETED” once a risk evaluation has been conducted. This step ensures that risks are always considered in the process, without directly affecting the workflow’s status. While the risk assessment itself doesn’t change the workflow, the information gathered may be useful for later steps.

The finish step indicates whether the workflow has completed successfully. This means all results have been collected and stored, ready for further analysis. To verify that the workflow finished without issues, look for a result of COMPLETE. Note that this only confirms the workflow’s completion, not the success of individual checks or the absence of errors. Typically, no processResults are generated for this step.

Process Result Objects (PROs) encapsulate the outcomes of specific processes (check, comparison, verification etc.). They play a crucial role in evaluating the overall outcome of relevant workflow steps.

Let’s break down the following KYC process result:

• The class is “KYC” which indicates the process is in relation to a KYC database verification check.
• The address of the entity has been successfully verified against the Australian Electoral Roll:
  • Based on the objectType we can see that the specific element checked was an “ADDRESS”
  • The providerResult array contains the details of the service provider that the entity was checked against:
    • The service provider is the Document Verification Service as indicated by the name field (“dvs”)
    • The specific data source that was checked is the Australian Electoral Roll as indicated by the source (“au-elec-roll”) and sourceNormalized (“au-elec-roll”) fields
  • The result is “MATCH” indicating that the address was successfully matched.
• The check was completed successfully (state is “COMPLETED”) and hasn’t yet been invalidated in any way (systemStatus is “VALID”), therefore it’s safe to determine that the process ran to completion and was indeed used in determining the successful result.
• There has been no manual status applied to the process (due to the absence of a manualStatus field)

1
"processResults": [
2
{
3
	"class": "KYC",
4
	"createdAt": "2024-07-11T23:57:08.197185Z",
5
	"entityId": "{entityId}",
6
	"groupId": "{groupId}",
7
	"notes": {...},
8
	"objectId": "{objectId}",
9
	"objectType": "ADDRESS",
10
	"processResultId": "{processResultId}",
11
	"providerResult": {
12
		"confidence": "100",
13
		"name": "dvs",
14
		"reference": "{referenceId",
15
		"source": "au-elec-roll",
16
		"sourceNormalized": "au-elec-roll"
17
	},
18
	"supplementaryData": {
19
		"matchStrengths": {
20
			"fullAddress": 100,
21
			"streetNumber": 100,
22
			"streetName": 100
23
			"streetType": 100,
24
			"locality": 100,
25
			"district": 100,
26
			"subdivision": 100,
27
			"postalCode": 100,
28
			"country": 100,
29
		},
30
		"fuzziness": {
31
			"normalized": 0,
32
			"actual": 0
33
		},
34
		"wasNameMatchStrongEnough": true
35
	},
36
	"requestId": "{requestId}",
37
	"result": "MATCH",
38
	"schemaVersion": 2,
39
	"state": "COMPLETED",
40
	"stepName": "KYC",
41
	"systemStatus": "VALID",
42
	"updatedAt": "2024-07-11T23:57:08.197185Z"
43
}

Similar to Process Results (PROs) for KYC database verification matches, process results that result in no match will be generated during step execution and will provide insights into why the data source could NOT be matched.

Let’s break down the following KYC process result:

• The class is “KYC” which indicates the process is in relation to a KYC database verification check.
• The address of the entity has been checked but wasn’t verified against the Australian Electoral Roll:
  • Based on the objectType we can see that the specific element checked was an “NAME”
  • The providerResult array contains the details of the service provider that the entity was checked against:
    • The service provider is the Document Verification Service as indicated by the name field (“dvs”)
    • The specific data source that was checked is the Australian Electoral Roll as indicated by the source (“au-elec-roll”) and sourceNormalized (“au-elec-roll”) fields
  • The result is “MATCH” indicating that the address was successfully matched.
• The matchStrengths within supplementaryData shows that no part of the name matched at all.
• The fuzziness within supplementaryData shows that an exact match (normalized as “0”) was required, potentially restricting any passable partial matching (“Sarah”, “Sara”).
• The check was completed successfully (state is “COMPLETED”) and hasn’t yet been invalidated in any way (systemStatus is “VALID”), therefore it’s safe to determine that the process ran to completion and was indeed used in determining the successful result.
• There has been no manual status applied to the process (due to the absence of a manualStatus field).

1
"processResults": [
2
{
3
	"class": "KYC",
4
	"createdAt": "2024-07-11T23:57:08.197185Z",
5
	"entityId": "{entityId}",
6
	"groupId": "{groupId}",
7
	"notes": {...},
8
	"objectId": "{objectId}",
9
	"objectType": "NAME",
10
	"processResultId": "{processResultId}",
11
	"providerResult": {
12
		"confidence": "0",
13
		"name": "dvs",
14
		"reference": "{referenceId}",
15
		"source": "au-elec-roll",
16
		"sourceNormalized": "au-elec-roll"
17
	},
18
	"supplementaryData": {
19
		"matchStrengths": {
20
			"fullname": 0,
21
			"familyName": 0,
22
			"givenName": 0,
23
			"otherNames": 0,
24
			"firstInitialFamilyName": 0
25
		},
26
		"fuzziness": {
27
			"normalized": 0,
28
			"actual": 0
29
		}
30
	}
31
	"requestId": "{requestId}",
32
	"result": "NO_MATCH",
33
	"schemaVersion": 2,
34
	"state": "COMPLETED",
35
	"stepName": "KYC",
36
	"systemStatus": "VALID",
37
	"updatedAt": "2024-07-11T23:57:08.197185Z"
38
}

AML screening results are reflected in the result field, which clearly indicates the steps outcome. This field summarizes the steps result, taking into account all the processed data. For instance, if an individual’s details such as name show up on any AML screening lists like PEP or Sanctions lists, the result will be HIT. If not, the result will be CLEAR.

1
{
2
    "workflowResult": {
3
        "workflowStepResults": [
4
            {
5
                "endedAt": "2024-05-14T04:04:12.66319Z",
6
                "objectId": "{objectId}",
7
                "objectType": "INDIVIDUAL",
8
                "processResults": [...],
9
                "requestId": "{requestId}",
10
                "result": "CLEAR",
11
                "serviceProviders": [
12
                    {
13
                        "endedAt": "2024-05-14T04:04:12.663187286Z",
14
                        "provider": "complyadvantage",
15
                        "result": "CLEAR",
16
                        "startedAt": "2024-05-14T04:04:11.849152Z"
17
                    }
18
                ],
19
                "startedAt": "2024-05-14T04:04:11.849152Z",
20
                "stepData": {...},
21
                "stepName": "aml",
22
                "stepResultId": "{stepResultId}",
23
                "workflowExecutionId": "{workflowExecutionId}"
24
            },
25
        ]
26
    }
27
}

processResults exist under the workflow step results for steps that require verification or some sort of checks to be run and differ based on the context of what the check is trying to accomplish. For checks against external data sources, the processResults will aim to capture what exactly has matched against what source. Steps typically return an array of all the individual process results that were used in determining that step’s result.

Take for instance the following example:

1
"processResults": [
2
	{
3
		"class": "AML",
4
		"createdAt": "2024-05-14T04:04:12.566065Z",
5
		"entityId": "{entityId}",
6
		"notes": {...},
7
		"objectId": "{objectId}",
8
		"objectType": "name",
9
		"processResultId": "{processResultId}",
10
		"providerResult": {
11
			"confidence": "100",
12
			"name": "complyadvantage",
13
			"reference": "{referenceId}",
14
			"riskScore": 0
15
		},
16
		"result": "HIT",
17
		"state": "COMPLETED",
18
		"stepName": "pep",
19
		"supplementaryData": {...},
20
		"systemStatus": "VALID",
21
		"updatedAt": "2024-05-14T04:04:12.566065Z"
22
	}

Let’s break down the following match result:

• name, dob and address were checked as they’re listed under matchTypes
• Based on the matchCount we can determine how many data sources we were able to match against for each element:
• name matched against the Australian Electoral Roll (“au-elec-roll”) and Equifax Public Credit Data Header (“au-efax-cdh-pub”)
• address matched against the Australian Electoral Roll (“au-elec-roll”) only
• dateOfBirth matched against the Equifax Public Credit Data Header (“au-efax-cdh-pub”)
• matchCount equals the matchCountRequired which means we were able to find enough matches for a positive result
• requiredSourcesMatched indicates that the Australian Electoral Roll (“au-elec-roll”) was a source that was required to be matched against, which it was (name, address)
• isVerified indicates that the match requirements were satisfied based on the rule criteria

1
"summary": {
2
"matchedRules": [
3
{
4
    "ruleName": "SafeHarbour2x2",
5
    "ruleOrder": 1,
6
    "ruleMatches": [
7
    {
8
        "matchTypes": {
9
        "name": {
10
            "objectId": "{objectId}",
11
            "matchCount": 2,
12
            "matchSources": ["au-elec-roll", "au-efax-cdh-pub"],
13
            "nonMatchSources": ["au-efax-cdh-consumer"],
14
            "isChecked": true,
15
            "isVerified": true
16
        },
17
        "address": {
18
            "objectId": "{objectId}",
19
            "matchCount": 1,
20
            "matchSources": ["au-elec-roll"],
21
            "nonMatchSources": ["au-efax-cdh-pub", "au-efax-cdh-consumer"],
22
            "isChecked": true,
23
            "isVerified": true
24
        },
25
        "dateOfBirth": {
26
            "objectId": "{objectId}",
27
            "matchCount": 1,
28
            "matchSources": ["au-efax-cdh-pub"],
29
            "nonMatchSources": ["au-elec-roll", "au-efax-cdh-consumer"],
30
            "isChecked": true,
31
            "isVerified": true
32
        }
33
        },
34
        "matchCount": 2,
35
        "matchCountRequired": 2,
36
        "hasAllRequiredSourcesMatched": true,
37
        "requiredSourcesMatched": ["au-elec-roll"],
38
        "isVerified": true
39
    }
40
    ]
41
}
42
],

Similarly to the matchedRules, the unmatchedRules contains a singular ruleMatches entry detailing the outcome of a particular rule established in the workflow that hasn’t been met.

Let’s break down the following non matched result:

• name, dob and address were checked as they’re listed under matchTypes
• Based on the matchCount we can see no matchSources present which tells us that there were no matches.
• The nonMatchSources lists the sources that were checked against but without a successful match result
• name didn’t match against the Australian Electoral Roll (“au-elec-roll”) and Equifax Public Credit Data Header (“au-efax-cdh-pub”) or Equifax Consumer Credit Data Header (“au-efax-cdh-consumer”)
• address didn’t match against the Australian Electoral Roll (“au-elec-roll”) and Equifax Public Credit Data Header (“au-efax-cdh-pub”) or Equifax Consumer Credit Data Header (“au-efax-cdh-consumer”)
• dateOfBirth didn’t match against the Australian Electoral Roll (“au-elec-roll”) and Equifax Public Credit Data Header (“au-efax-cdh-pub”) or Equifax Consumer Credit Data Header (“au-efax-cdh-consumer”)
• matchCount doesn’t equal the matchCountRequired which means we weren’t able to find enough matches for a positive result
• requiredSourcesMatched indicates that the Australian Electoral Roll (“au-elec-roll”) was also a source that was required to be matched against, which wasn’t
• isVerified indicates that the match requirements weren’t satisfied based on the rule criteria

1
"summary": {
2
  "unmatchedRules": [
3
	{
4
	  "ruleName": "SafeHarbour2x2",
5
	  "ruleOrder": 1,
6
	  "ruleMatches": [
7
		{
8
		  "matchTypes": {
9
				"name": {
10
			  	"matchCount": 0,
11
			  	"nonMatchSources": ["au-elec-roll", "au-efax-cdh-pub", "au-efax-cdh-consumer"],
12
			  	"isChecked": true,
13
			  	"isVerified": false
14
			},
15
 			"address": {
16
			  "matchCount": 0,
17
			  "nonMatchSources": ["au-elec-roll", "au-efax-cdh-pub", "au-efax-cdh-consumer"],
18
			  "isChecked": true,
19
			  "isVerified": false
20
			},
21
 			"dateOfBirth": {
22
			  "matchCount": 0,
23
			  "nonMatchSources": ["au-elec-roll", "au-efax-cdh-pub" "au-efax-cdh-consumer"],
24
			  "isChecked": true,
25
			  "isVerified": false
26
			}
27
		  },
28
		  "matchCount": 0,
29
		  "matchCountRequired": 2,
30
		  "hasAllRequiredSourcesMatched": false,
31
		  "requiredSourcesNotMatched": ["au-elec-roll"],
32
		  "isVerified": false
33
		}
34
	  ]
35
	}
36
  ]