KYCImplementation Guide

Interpreting Workflows

A developer's guide to parsing the workflowResult object, from the overall status down to the granular details of each check.

Understanding the Workflow Response

After executing a workflow, the API returns a comprehensive workflowResult object. This object is the key to understanding the outcome of every check performed. This guide provides a structured, top-down walkthrough of how to parse this response, explaining each key object from the final verdict down to the granular evidence.

The examples in this guide refer to the following API response for workflow execution 01JZHEX5FQA4DJB0MMJFZR26JS. Click to expand and see the full structure.

1{
2    "individual": {
3        "entityId": "99f16410-2613-4181-8cf1-048625900013",
4        "name": { "displayName": "MARY TESTFOURTEEN", "...": "..." },
5        "...": "..."
6    },
7    "requestId": "01JZHEX0WX2QEM6EY139D5NNP1",
8    "workflowResult": {
9        "workflowExecutionId": "01JZHEX5FQA4DJB0MMJFZR26JS",
10        "workflowExecutionState": "COMPLETED",
11        "status": "PASS",
12        "result": "PASS",
13        "riskAssessment": {
14            "riskLevel": "LOW",
15            "riskScore": 12,
16            "riskFactors": [ { "factor": "entity_type", "value": "INDIVIDUAL", "score": 2 }, { "factor": "entity_age", "value": "62", "score": 10 } ]
17        },
18        "steps": {
19            "passed": [ "START", "MATCHLIST", "KYC", "AML", "DECISION", "FINISH" ],
20            "failed": [ "IDV" ],
21            "order": [ "START", "MATCHLIST", "KYC", "IDV", "AML", "TOGGLE_MONITORING", "DECISION", "FINISH" ],
22            "...": "..."
23        },
24        "issues": [],
25        "workflowStepResults": [
26            {
27                "stepName": "KYC",
28                "result": "MATCH",
29                "processResults": [
30                    {
31                        "processResultId": "01JZ4H0P59KGQR9DZCWZ6JQRY0",
32                        "class": "KYC",
33                        "objectType": "NAME",
34                        "result": "MATCH",
35                        "state": "COMPLETED",
36                        "systemStatus": "VALID",
37                        "providerResult": {
38                            "name": "con_testbed-docs",
39                            "source": "au-govid1-pp"
40                        },
41                        "supplementaryData": {
42                            "type": "KYC_NAME",
43                            "matchStrengths": {
44                                "fullName": 75,
45                                "familyName": 75,
46                                "givenName": 75
47                            }
48                        }
49                    }
50                ],
51                "summary": {
52                    "matchedRules": [
53                        {
54                            "ruleName": "gov_id_only",
55                            "isVerified": true,
56                            "matchDetails": [
57                                {
58                                    "provider": "con_testbed-docs",
59                                    "source": "au-govid1-pp",
60                                    "attributesMatched": [ "dateOfBirth", "govId", "name" ]
61                                }
62                            ]
63                        }
64                    ]
65                },
66                "...": "..."
67            }
68        ]
69    }
70}

Part 1: The Overall Outcome (The Final Verdict)

Start by examining the top-level fields of the workflowResult object. These provide the final, authoritative outcome of the entire workflow execution.

Field NameImportanceDescription
status‼️This is the most important field. It represents the conclusive recommendation and accounts for any manual overrides. Base your primary business logic on this value.
workflowExecutionState‼️This confirms the workflow’s technical status. It must be COMPLETED for the status to be considered final.
result⚠️This field holds the original, automated outcome of the workflow before any manual changes. It is useful for auditing.
issues⚠️An array of problems that may require manual review. If the status is REVIEW, this array will contain the specific reasons why.

Workflow Execution States (workflowExecutionState)

This field tells you if the workflow ran to completion.

StateDescription
COMPLETEDThe workflow executed successfully from start to finish.
IN_PROGRESSThe workflow is still running.
ERRORThe workflow encountered an unrecoverable error and could not finish.
TIMEOUTThe workflow exceeded its maximum execution time.
CANCELEDThe workflow was manually canceled before completion.
TERMINATEDThe workflow was terminated by the system before completion.

Workflow Statuses (status and result)

This is the final recommendation of the workflow.

StatusDescription
PASSThe entity successfully met the workflow’s criteria.
FAILThe entity did not meet the workflow’s criteria.
REVIEWThe workflow produced results that require manual review.
CLEAROften used for monitoring, indicates no negative information was found.
HITOften used for monitoring, indicates negative information (e.g., a watchlist match) was found.
URGENTA critical issue was found (e.g., a sanctions match) that requires immediate attention.
COMPLETE / INCOMPLETEThe workflow finished, but a pass/fail determination was not applicable.

Detecting Manual Overrides

It’s crucial to know if a workflow’s result was changed by a person. When an operator manually changes the status (e.g., from FAIL to PASS), the following fields are populated:

  • statusOverrideRequestId: The unique ID of the override request.
  • statusOverrideBy: The user who performed the override.
  • statusOverrideAt: The timestamp of the override.

To detect an override, check if statusOverrideRequestId exists and is not empty.

Part 2: The Step-by-Step Breakdown (workflowStepResults)

The workflowStepResults array is a log of each individual check, explaining how the overall status was reached. Each object in this array corresponds to a step configured in your workflow (e.g., KYC, AML, IDV).

Field NameDescription
stepNameThe name of the step (e.g., KYC, AML).
resultThe outcome of this specific step. See the table below for all possible values.
summaryA concise, human-readable summary of the step’s outcome. For a KYC step, this includes which matching rules were met.
processResultsAn array of Process Result Objects (PROs) providing the granular evidence for this step’s result.
riskThe risk assessment specific to this step, including the score it contributed to the overall risk.

Workflow Step Results (result)

ResultApplicable StepsDescription
MATCH / NO_MATCH / PARTIALKYC, IDV, VISAThe step produced a successful, unsuccessful, or partially successful match against data sources.
CLEAR / HITAML, MATCHLIST, DUPLICATEThe step checked against a negative list (e.g., AML watchlist) and found no matches (CLEAR) or found a match (HIT).
PASS / FAILDECISION, Manual KYCThe step completed and met (PASS) or did not meet (FAIL) its required binary criteria.
COMPLETE / INCOMPLETESTART, FINISH, RISKThe step finished, but a pass/fail scenario was not applicable.
SKIPPEDAny StepThe step was skipped because it was not required to run.
MISSING_DATAAny StepThe step could not run because it requires additional data.
ERRORAny StepThe step encountered an unrecoverable technical error.

Part 3: The Granular Evidence (processResults)

For the deepest level of detail, look inside a workflowStepResult at its processResults array. A Process Result Object (PRO) is the raw evidence from a single check against a single data source.

Field NameDescription
processResultIdA unique identifier for this specific piece of evidence.
classThe high-level category of the check. See the table below for details.
objectTypeThe specific data element that was checked (e.g., NAME, ADDRESS, DOCUMENT).
resultThe outcome of this specific check (e.g., MATCH, HIT, CLEAR).
providerResultAn object containing details from the downstream data provider, including the source of the data.
systemStatusThe lifecycle status of this PRO (e.g., VALID, STALE, MARKED_INVALID). A STALE status means the underlying entity data has changed since this check was performed.
manualStatusIf an operator has manually reviewed this specific PRO, their conclusion (e.g., TRUE_POSITIVE, FALSE_POSITIVE) is recorded here.
supplementaryDataA rich, context-specific object containing detailed metrics, like match scores or extracted OCR data.

Process Result Classes (class)

ClassDescription
KYCAn electronic Know Your Customer check against a data source.
IDVAn Identity Verification check, typically involving biometrics and document analysis.
AMLAn Anti-Money Laundering screening against watchlists, sanctions, and PEP lists.
MATCHLISTA check against a custom internal or shared blocklist/allowlist.
DUPLICATEA check to see if the entity is a duplicate of an existing entity.
FRAUDA fraud check, often related to device, IP, or behavioral signals.

Best Practices for Integration

  • Check workflowExecutionState first: Always confirm the workflow is COMPLETED before trusting the status.
  • Automate based on status: Use the top-level status field for your primary business logic (e.g., approve account, flag for review).
  • Debug with workflowStepResults: When you get an unexpected FAIL or REVIEW, loop through the workflowStepResults to find which stepName has a non-passing result. The summary and processResults within that step will tell you why.
  • Log the workflowExecutionId: This ID is your key for auditing, support queries, and correlating results.