Interpreting Workflow Results

AML

Anti-Money Laundering Screening

After a workflow has been executed, various elements require examination to determine the final outcome.

Interpreting Workflow Results

Legend:

Icon	Description
‼️	Results that deem whether the entity has passed or failed or the workflow was unable to execute to completion.
⚠	Context on why the entity may have passed or failed.
ℹ️	Information-only, no contribution to whether the entity has passed or failed

Use the legend above to better understand the following table.

Field name	Description	Importance
status	The ultimate assessment of whether the individual passed all workflow requirements lies in the `status`, which provides a conclusive recommendation based on the checks run. It accounts for whether all verification checks were successful or if there were failures. The status also captures manual intervention such as any action of overriding the result directly outside the context of a workflow. • `UNCHECKED` - Workflow has not yet been executed or the workflow result was not updated successfully as part of the workflow execution. • `IN_PROGRESS` - Workflow is currently running and awaiting completion. • `PASS` - Workflow completed successfully and the entity passed all checks required. Alternatively, the status was applied manually proceeding with workflow execution. • `FAIL` - Workflow completed successfully, however the entity did not pass all checks required. Alternatively, the status was applied manually proceeding with workflow execution. Note: the `statusOverrideAt` field can be used to determine if the status was manually overridden.	‼️
statusOverrideAt	The UTC of when the `status` was manually overridden outside the workflow execution.	ℹ️
statusOverrideRequestId	The unique `requestId` of the request that manually overrode the `status` outside the workflow execution.	ℹ️
statusOverrideBy	The `X-Frankie-Username` header value in the request that manually overrode the status outside of the workflow execution.	ℹ️
result	The `result` is the original workflow outcome that was determined after the workflow. In the case of manual override, this will differ from the `status`. • `UNCHECKED` - Workflow has not yet been executed or the workflow result was not updated successfully as part of the workflow execution. •`IN_PROGRESS` - Workflow is currently running and awaiting completion. • `PASS` - Workflow completed successfully and the entity passed all checks required. • `FAIL` - Workflow completed successfully, however the entity did not pass all checks required.	⚠
workflowExecutionState	The `workflowExecutionState` is an indicator of whether the workflow was able to execute to completeness. The `workflowExecutionState` should always be in a state of “COMPLETED” otherwise it is telling that the workflow execution did not finish executing and that the result should be taken with that context in mind.	‼️
workflowStepResults	The `workflowStepResults` is a detailed list of all the steps that were executed as part of the workflow and their individual outcomes.	⚠
riskAssessment	The `riskAssessment` is a summary of all the risk factors that were encountered during the execution of the workflow and the accumulated risk level of the entity as a result of those factors.	⚠
issues	`issues` is a summary of all the issues that were encountered during the execution of the workflow that may have affected the outcome such as errors, insufficient data, or simply a failed verification. Typically `issues` will only be present if any checks have failed.	⚠
workflowExecutionId	The unique identifier of the workflow execution. Generated on triggering the workflow execution.	ℹ️
serviceProfileId	The unique identifier of the service profile in which the workflow was executed. Set based on the `serviceName` in the path of the workflow execution request API.	ℹ️
workflowId	The ID of the workflow that was executed. Set based on the `workflowName` in the path of the workflow execution request API.	ℹ️
workflowName	The name of the workflow that was executed. Set based on the `workflowName` in the path of the workflow execution request API.	ℹ️
steps	The steps that were executed as part of this workflow execution: `order` - order in which the steps were executed `passed` - steps that passed or were successful in execution `failed` - steps that failed or were unsuccessful in execution `incomplete` - steps that did not execute or did not execute to completion `notApplicable` - steps that did not run because they were deemed unnecessary	ℹ️
entityType	The type of entity in which the workflow was executed. `INDIVIDUAL` or `ORGANIZATION`.	ℹ️
errors	Any errors that were encountered as part of the workflow execution	⚠
requestId	The `requestId` is the unique identifier of the request that triggered this workflow execution.	ℹ️
entityId	The `entityId` of the individual/organization in which the workflow was executed.	ℹ️
startedAt	`startedAt` refers to when the workflow started executing.	ℹ️
endedAt	`endedAt` refers to when the workflow finished executing.	ℹ️
createdAt	`createdAt` refers to when the process result was created.	ℹ️
updatedAt	`updatedAt` refers to when the process result was last updated.	ℹ️
updatedBy	`updatedBy` refers to who last updated the workflow execution. This will be the value of the `X-Frankie-Username` header of the request that executed the workflow or overrode the workflow result.	ℹ️
schemaVersion	Refers to the version of the schema returned. There will always be 2 in the FrankieOne v2.x API.	ℹ️
notes	Any additional `notes` that were captured during the process.	ℹ️

Example 1: Pass

"workflowResult": {
    "createdAt": "2024-07-08T06:37:22.520433Z",
    "endedAt": "2024-07-08T06:37:27.697016Z",
    "entityType": "INDIVIDUAL",
    "issues": [...],
    "workflowExecutionId": "{workflowExecutionId}",
    "requestId": "{requestId}",
    "entityId": "{entityId}",
    "startedAt": "2024-01-15T02:18:11.365Z",
    "endedAt": "2024-01-15T02:18:11.365Z",
    "workflowId": "{workflowId}",
    "workflowName": "onboarding",
    "steps": "[KYC]",
    "result": "PASS",
    "status": "PASS",
    "workflowExecutionState": "COMPLETED",
    "schemaVersion": 2,
    "serviceProfileId": "{serviceProfileId}",
    "updatedAt": "2024-07-08T06:37:27.769601Z",
    "updatedBy": "system:frankieone",
    "riskAssessment": [...],
    "workflowStepResults": [...]
},
"requestId": "{requestId}"

Example 2: Fail

"workflowResult": {
    "createdAt": "2024-07-08T06:37:22.520433Z",
    "endedAt": "2024-07-08T06:37:27.697016Z",
    "entityType": "INDIVIDUAL",
    "issues": [...],
    "workflowExecutionId": "{workflowExecutionId}",
      "requestId": "{requestId}",
    "entityId": "{entityId}",
    "startedAt": "2024-01-15T02:18:11.365Z",
    "endedAt": "2024-01-15T02:18:11.365Z",
    "workflowId": "{workflowId}",
    "workflowName": "onboarding",
    "steps": "[KYC]",
    "result": "FAIL",
    "status": "FAIL",
    "workflowExecutionState": "COMPLETED",
    "schemaVersion": 2,
    "serviceProfileId": "{serviceProfileId}",
    "updatedAt": "2024-07-08T06:37:27.769601Z",
    "updatedBy": "system:frankieone",
    "riskAssessment": [...],
    "workflowStepResults": [...]
},
"requestId": "{requestId}"

Example 3: Workflow failed but status was overridden to be passed

"workflowResult": {
    "createdAt": "2024-07-08T06:37:22.520433Z",
    "endedAt": "2024-07-08T06:37:27.697016Z",
    "entityType": "INDIVIDUAL",
    "issues": [...],
    "workflowExecutionId": "{workflowExecutionId}",
    "requestId": "{requestId}",
    "entityId": "{entityId}",
    "startedAt": "2024-01-15T02:18:11.365Z",
    "endedAt": "2024-01-15T02:18:11.365Z",
    "workflowId": "{workflowId}",
    "workflowName": "onboarding",
    "steps": "[KYC]",
    "result": "FAIL",
    "status": "PASS",
    "workflowExecutionState": "COMPLETED",
    "schemaVersion": 2,
    "serviceProfileId": "{serviceProfileId}",
    "updatedAt": "2024-07-08T06:37:27.769601Z",
    "updatedBy": "system:frankieone",
    "riskAssessment": [...],
    "workflowStepResults": [...]
},
"requestId": "{requestId}"

Interpreting Workflow Step Results

Workflow outcomes will include various individual step outcomes. Each outcome will document findings from specific verification processes. Key steps include data verification, Know Your Customer (KYC) checks, Anti-Money Laundering (AML) screenings, Identity Verification (IDV), and risk evaluations.

To streamline reporting, outcomes are consolidated by category. This ensures that identical steps are aggregated and presented as a single outcome. For example, KYC procedures may be performed multiple times with different service providers. However, only one step outcome will be generated, summarizing all assessments conducted.

Each step follows a consistent format. Significant variations arise from the stepData and processResults elements. These elements are unique to each step type, providing tailored insights specific to each step's function.

Know Your Customer (KYC) Database Verification

The KYC workflow step takes into account all the processed data and indicates the outcome in the result field.

Result	Description
`UNCHECKED`	KYC was not attempted due to a failure in a previous step
`MISSING_DATA`	KYC was not attempted as not enough data was available
`MATCH`	KYC was attempted successfully, and the entity was verified against the required number of data sources
`NO_MATCH`	KYC was attempted, however, the entity was not verified against any data sources
`PARTIAL`	KYC was attempted, however the entity was not verified against the required number of data sources if more than 1 was required
`ERROR`	KYC was attempted, however, an error was encountered during the process. See errors for more information.

Sample workflow step results

{
    "workflowResult": {
        "workflowStepResults": [
            {
                "endedAt": "2024-05-14T04:04:12.66319Z",
                "objectId": "{objectId}",
                "objectType": "INDIVIDUAL",
                "processResults": [...],
                "requestId": "{requestId}",
                "result": "MATCH",
                "serviceProviders": [...],
                "startedAt": "2024-05-14T04:04:11.849152Z",
                "stepData": {...},
                "stepName": "kyc",
                "stepResultId": "{stepResultId}",
                "workflowExecutionId": "{workflowExecutionId}"
            },
        ]
    }
}

🚧
Service Provider Result

The KYC workflow step indicates the service provider overall outcome as the serviceProviders.result

{
    "workflowResult": {
        "workflowStepResults": [
            {
                "endedAt": "2024-05-14T04:04:12.66319Z",
                "objectId": "{objectId}",
                "objectType": "INDIVIDUAL",
                "processResults": [...],
                "requestId": "{requestId}",
                "result": "MATCH",
                "serviceProviders": [
                    {
                        "endedAt": "2024-05-14T04:04:12.663187286Z",
                        "provider": "dvs",
                          "result": "MATCH",
                        "startedAt": "2024-05-14T04:04:11.849152Z"
                    }
                ],
                "startedAt": "2024-05-14T04:04:11.849152Z",
                "stepData": {...},
                "stepName": "kyc",
                "stepResultId": "{stepResultId}",
                "workflowExecutionId": "{workflowExecutionId}"
            },
        ]
    }
}

KYC Step Summary

To gain insight into which personal information matched against specific sources, please refer to the matchedRules. Commonly, you’ll find a singular ruleMatches entry detailing the outcome of a particular rule established in the workflow. For example, a rule might stipulate that both a name and a date of birth or address be verified against two independent data sources. matchTypes will reveal the exact element verified, while matchSources will specify the data sources used for confirmation. Any data sources consulted but yielding no matches will be listed as nonMatchSources.

After a KYC step has been executed, various elements require examination to determine the final outcome.

Legend:

Icon	Description
‼️	Results that deem whether the entity has passed or failed or the workflow failed to execute to completion.
⚠	Context on why the entity may have passed or failed.
ℹ️	Information-only, no contribution to whether the entity has passed or failed.

Matched and Unmatched Rules

The matchedRules and unmatchedRules that exist within the KYC workflow step summary are identical in structure and differ only in whether the ruleset was matched against successfully (matchedRules) or not (unmatchedRules).

Field name	Description	Importance
matchedRules	List of all the KYC rulesets that matched and the summary of those matches. See Matched and Unmatched Rules.	⚠
unmatchedRules	List of all the KYC rulesets that did not match and the summary of those matches. See Matched and Unmatched Rules.	⚠

Rulesets

The requirements rulesets are defined within the KYC workflow step configuration and are used to determine whether the number of data source matches have been met for each entity element (for example, name, date of birth, address and others) for the verification to be considered a match.

Field name	Description	Importance
ruleName	Name of the ruleset Default: `default`	ℹ️
ruleOrder	Order in which we attempted to match the results against the requirements defined in the ruleset. Example: 1	ℹ️
ruleMatches	List of matches that made up this ruleset. See Rule Matches.	⚠

Ruleset Match Details

The specific matching details of each rule that was matched or not matched.

Field name	Description	Importance
matchTypes	The match types that this overall count and results refer to	⚠
matchCount	Number of matches found for this ruleset	⚠
matchCountRequired	Number of matches required for this ruleset to be satisfied	⚠
hasAllRequiredSourcesMatched	Determines whether a match has been found for all required data sources defined in the ruleset. Note: Optional. This is only evaluated if 1 or more data sources have been set as mandatory within the KYC workflow step configuration.	⚠
requiredSourcesMatched	List of the required sources that the entity has been matched against. Note: Optional. This is only evaluated if 1 or more data sources have been set as mandatory within the KYC workflow step configuration.	⚠
requiredSourcesNotMatched	List of the required sources that the entity has not been matched against. Note: Optional. This is only evaluated if 1 or more data sources have been set as mandatory within the KYC workflow step configuration.	⚠
isVerified	Determines whether the matches required have been satisfied, indicating a successfully matched ruleset. Based on whether matchCount >= matchCountRequired true/false	‼️

Ruleset Matched Types

The specific matching details of each element (for example, name, dateOfBirth, and others) that was matched or not matched.

Field name	Description	Importance
objectId	The unique identifier of the object (for example: name, address, date of birth) that was verified	ℹ️
objectType	The type of the object that was verified (for example: name, address, date of birth)	ℹ️
matchCount	Number of matches found for this object type	⚠
matchSources	List of all the data sources that the entity was matched against. Example: “au-elec-roll”	⚠
nonMatchSources	List of all the data sources that the entity was not matched against. Example: “au-elec-roll”	⚠
isChecked	Determines whether an attempt was made to verify the entity’s personal information as identified by the `objectId` and `objectType` (for example: name, date of birth, address)	⚠
isVerified	Determines whether the entity’s personal information as identified by the `objectId` and `objectType` (for example: name, date of birth, address) was able to be verified by at least 1 data source.	‼️

Example 1: Successful KYC Database Verification

Let’s break down the following match result:

Field	Description
`name`, `dob`, `address`	Were checked as they are listed under `matchTypes`.
`matchCount`	Indicates how many data sources were matched 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 `matchCountRequired`, indicating enough matches were found for a positive result.
`requiredSourcesMatched`	Indicates that the Australian Electoral Roll (“au-elec-roll”) was a required source that was matched (name, address).
`isVerified`	Indicates that the match requirements were satisfied based on the rule criteria.

"summary": {
  "matchedRules": [
	{
	  "ruleName": "SafeHarbour2x2",
	  "ruleOrder": 1,
	  "ruleMatches": [
		{
		  "matchTypes": {
			"name": {
			  "objectId": "{objectId}",
			  "matchCount": 2,
			  "matchSources": ["au-elec-roll", "au-efax-cdh-pub"],
			  "nonMatchSources": ["au-efax-cdh-consumer"],
			  "isChecked": true,
			  "isVerified": true
			},
 			"address": {
			  "objectId": "{objectId}",
			  "matchCount": 1,
			  "matchSources": ["au-elec-roll"],
			  "nonMatchSources": ["au-efax-cdh-pub", "au-efax-cdh-consumer"],
			  "isChecked": true,
			  "isVerified": true
			},
 			"dateOfBirth": {
			  "objectId": "{objectId}",
			  "matchCount": 1,
			  "matchSources": [""au-efax-cdh-pub""],
			  "nonMatchSources": ["au-elec-roll", "au-efax-cdh-consumer"],
			  "isChecked": true,
			  "isVerified": true
			}
		  },
		  "matchCount": 2,
		  "matchCountRequired": 2,
		  "hasAllRequiredSourcesMatched": true,
		  "requiredSourcesMatched": ["au-elec-roll"],
		  "isVerified": true
		}
	  ]
	}
  ],
...

Example 2: Unsuccessful KYC Database Verification

The unmatchedRules contains a ruleMatches entry. This entry details a rule in the workflow that was not met.

Let’s analyze the non-matched result:

Field	Description
`name`, `dob`, `address`	Were checked as listed under `matchTypes`.
`matchCount`	Shows no `matchSources`, indicating no matches were found.
`nonMatchSources`	Lists sources checked without successful matches:
	- `name` did not match the Australian Electoral Roll (“au-elec-roll”), Equifax Public Credit Data Header (“au-efax-cdh-pub”), or Equifax Consumer Credit Data Header (“au-efax-cdh-consumer”).
	- `address` did not match the Australian Electoral Roll (“au-elec-roll”), Equifax Public Credit Data Header (“au-efax-cdh-pub”), or Equifax Consumer Credit Data Header (“au-efax-cdh-consumer”).
	- `dateOfBirth` did not match the Australian Electoral Roll (“au-elec-roll”), Equifax Public Credit Data Header (“au-efax-cdh-pub”), or Equifax Consumer Credit Data Header (“au-efax-cdh-consumer”).
`matchCount`	Is less than `matchCountRequired`, indicating insufficient matches for a positive result.
`requiredSourcesMatched`	Shows that the Australian Electoral Roll (“au-elec-roll”) was a required source that did not match.
`isVerified`	Indicates that the match requirements were not satisfied based on the rule criteria.

"summary": {
  "unmatchedRules": [
	{
	  "ruleName": "SafeHarbour2x2",
	  "ruleOrder": 1,
	  "ruleMatches": [
		{
		  "matchTypes": {
				"name": {
			  	"matchCount": 0,
			  	"nonMatchSources": ["au-elec-roll", "au-efax-cdh-pub", "au-efax-cdh-consumer"],
			  	"isChecked": true,
			  	"isVerified": false
			},
 			"address": {
			  "matchCount": 0,
			  "nonMatchSources": ["au-elec-roll", "au-efax-cdh-pub", "au-efax-cdh-consumer"],
			  "isChecked": true,
			  "isVerified": false
			},
 			"dateOfBirth": {
			  "matchCount": 0,
			  "nonMatchSources": ["au-elec-roll", "au-efax-cdh-pub" "au-efax-cdh-consumer"],
			  "isChecked": true,
			  "isVerified": false
			}
		  },
		  "matchCount": 0,
		  "matchCountRequired": 2,
		  "hasAllRequiredSourcesMatched": false,
		  "requiredSourcesNotMatched": ["au-elec-roll"],
		  "isVerified": false
		}
	  ]
	}
  ]

KYC Process Results

KYC match details are represented as processResults, found within the workflow step results. These results apply to steps requiring verification or checks, varying by the context of the check.

For checks against external data sources, processResults captures what matched against each source. Steps typically return an array of individual process results used to determine the step’s overall result.

After executing a KYC step, various elements must be examined to determine the final outcome.

Legend:

Icon	Description
‼️	Results that deem whether the entity has passed or failed or the workflow failed to execute to completion.
⚠	Context on why the entity may have passed or failed.
ℹ️	Information-only, no contribution to whether the entity has passed or failed.

Field name	Description	Importance
processResultId	The `processResultId` represents the unique identifier of the process result	ℹ️
class	The `class` reflects the type of process result (for example KYC, AML)	ℹ️
result	The `result` is the overall outcome of the process (for example MATCH, NO_MATCH, PARTIAL)	‼️
state	The `state` reflects whether the process was completed successfully or whether an error of some kind was encountered during the process	⚠
stepName	The `stepName` indicates the workflow step that triggered the process and thus generated the process result	ℹ️
stepType	The `stepType` indicates whether there was a subtype for the step. Generally used in non-KYC step process results.	ℹ️
groupId	The `groupId` is generated to tie related process results together. In the context of KYC, a single `groupId` will be generated and added to each process result per data source that is checked.	ℹ️
systemStatus	The `systemStatus` indicates that the result is valid and was used in determining the overall step result (typically only VALID results will be returned unless specifically requested).	⚠
manualStatus	The manualStatus indicates whether the result has been manually classified by an operator outside of FrankieOne (for example: via API or Portal). This is set most commonly in AML classifications where an operator has registered whether a potential match is a true positive or false positive.	⚠
providerResult	• The providerResult.confidence refers to the confidence rating that was returned by the provider. Defaults to 0/100 if confidence is not explicit. • `providerResult.name` refers to the name of the provider • Any unique identifier on the data provider side will be returned as `providerResult.reference` The `providerResult.source` indicates the raw source that was checked against The `providerResult.sourceNormalized` indicates the normalized source that was checked against. Note: Same sources checked by different providers will have the same `sourceNormalized` value but different source values.	⚠
riskFactors	Any risk factors returned by the service provider will be present as `riskFactors` and potentially utilized in FrankieOne’s own risk engine, depending on your risk configuration.	⚠
objectId	The `objectId` indicates the exact element that was checked.	ℹ️
objectType	The `objectType` indicates the specific type of element that was checked.	ℹ️
entityId	The `entityId` of the individual that was checked	ℹ️
createdAt	`createdAt` refers to when the process result was created.	ℹ️
updatedAt	`updatedAt` refers to when the process result was last updated.	ℹ️
updatedBy	`updatedBy` refers to who last updated the process result. Generally, this will be FrankieOne unless a manual override is triggered.	ℹ️
schemaVersion	Refers to the version of the schema returned. There will always be 2 in the FrankieOne v2.x API.	ℹ️
requestId	The unique identifier of the request that generated this process result	ℹ️
notes	Any additional `notes` that were captured during the process. May contain extra information about how the result was determined.	⚠
errors	Any `errors` that were encountered as part of the process.	⚠

Example: 1: KYC Data Source Match Details

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:

Field	Description
`class`	Is “KYC,” indicating the process is about a KYC database verification check.
Address Verification	The address of the entity has been successfully verified against the Australian Electoral Roll:
	- Based on the `objectType`, the specific element checked was an “ADDRESS.”
	- The `providerResult` array contains 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 checked is the Australian Electoral Roll as indicated by the `source` (“au-elec-roll”) and `sourceNormalized` (“au-elec-roll”) fields.
Result	The result is “MATCH,” indicating that the address was successfully matched.
Check Status	The check was completed successfully (`state` is “COMPLETED”) and has not yet been invalidated (`systemStatus` is “VALID”).
	Therefore, it is safe to determine that the process ran to completion and was used in determining the successful `result`.
Manual Status	There has been no manual status applied to the process (due to the absence of a `manualStatus` field).

"processResults": [
{
	"class": "KYC",
	"createdAt": "2024-07-11T23:57:08.197185Z",
	"entityId": "{entityId}",
	"groupId": "{groupId}",
	"notes": {...},
	"objectId": "{objectId}",
	"objectType": "ADDRESS",
	"processResultId": "{processResultId}",
	"providerResult": {
		"confidence": "100",
		"name": "dvs",
		"reference": "{referenceId",
		"source": "au-elec-roll",
		"sourceNormalized": "au-elec-roll"
	},
	"supplementaryData": {
		"matchStrengths": {
			"fullAddress": 100,
			"streetNumber": 100,
			"streetName": 100
			"streetType": 100,
			"locality": 100,
			"district": 100,
			"subdivision": 100,
			"postalCode": 100,
			"country": 100,
		},
		"fuzziness": {
			"normalized": 0,
			"actual": 0
		},
		"wasNameMatchStrongEnough": true
	},
	"requestId": "{requestId}",
	"result": "MATCH",
	"schemaVersion": 2,
	"state": "COMPLETED",
	"stepName": "KYC",
	"systemStatus": "VALID",
	"updatedAt": "2024-07-11T23:57:08.197185Z"
}

Example: 2: KYC Data Source Non-Match Details

Similar to Process Results (PROs) for KYC database verification matches, the 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:

Field	Description
`class`	“KYC,” indicating the process is about a KYC database verification check.
Address Verification	The address of the entity has been successfully verified against the Australian Electoral Roll:
	- Based on the `objectType`, the specific element checked was an “ADDRESS.”
	- The `providerResult` array contains 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 checked is the Australian Electoral Roll as indicated by the `source` (“au-elec-roll”) and `sourceNormalized` (“au-elec-roll”) fields.
Result	The result is “MATCH,” indicating that the address was successfully matched.
Check Status	The check was completed successfully (`state` is “COMPLETED”) and has not yet been invalidated (`systemStatus` is “VALID”).
	Therefore, it is safe to determine that the process ran to completion and was used in determining the successful `result`.
Manual Status	There has been no manual status applied to the process (due to the absence of a `manualStatus` field).

"processResults": [
{
	"class": "KYC",
	"createdAt": "2024-07-11T23:57:08.197185Z",
	"entityId": "{entityId}",
	"groupId": "{groupId}",
	"notes": {...},
	"objectId": "{objectId}",
	"objectType": "NAME",
	"processResultId": "{processResultId}",
	"providerResult": {
		"confidence": "0",
		"name": "dvs",
		"reference": "{referenceId}",
		"source": "au-elec-roll",
		"sourceNormalized": "au-elec-roll"
	},
	"supplementaryData": {
		"matchStrengths": {
			"fullname": 0,
			"familyName": 0,
			"givenName": 0,
			"otherNames": 0,
			"firstInitialFamilyName": 0
		},
		"fuzziness": {
			"normalized": 0,
			"actual": 0
		}
	}
	"requestId": "{requestId}",
	"result": "NO_MATCH",
	"schemaVersion": 2,
	"state": "COMPLETED",
	"stepName": "KYC",
	"systemStatus": "VALID",
	"updatedAt": "2024-07-11T23:57:08.197185Z"
}

Anti-Money Laundering (AML) Screening

The result field reflects AML screening results, clearly indicating the step’s outcome. This field summarizes the step’s result, accounting for all the processed data.

Result	Description
HIT	The individual’s name has shown up in screening and needs to be evaluated.
CLEAR	The individual’s name did not show up during screening
CLEARED	The individual’s name showed up during the initial screening however it has since been resolved as a false positive or accepted.


   "workflowResult": {  
        "workflowStepResults": \[  
            {  
                "endedAt": "2024-05-14T04:04:12.66319Z",  
                "objectId": "97039d38-5d2c-411a-afad-236d61558d7b",  
                "objectType": "INDIVIDUAL",  
                "processResults": [...],  
                "requestId": "01HXTMBBBBBBZM2YAARMZB4GPR",  
               "result": "CLEAR",
                "serviceProviders": [  
                    {  
                        "endedAt": "2024-05-14T04:04:12.663187286Z",  
                        "provider": "complyadvantage",  
                        "result": "CLEAR",  
                        "startedAt": "2024-05-14T04:04:11.849152Z"  
                    }  
                ],  
                "startedAt": "2024-05-14T04:04:11.849152Z",  
                "stepData": {...},  
                "stepName": "AML",  
                "stepResultId": "01HXTMBBEERQ53021A2FGND7N7",  
                "workflowExecutionId": "01HXTMBAT8AEM3E8RZXD9QTGN4"  
            },  
        ]  
    }  
}

The processResults and summary has been omitted for brevity.

🚧
Service Provider Result

The AML workflow step indicates the service provider overall outcome as the serviceProviders.result

{
    "workflowResult": {
        "workflowStepResults": [
            {
                "endedAt": "2024-05-14T04:04:12.66319Z",
                "objectId": "97039d38-5d2c-411a-afad-236d61558d7b",
                "objectType": "INDIVIDUAL",
                "processResults": [...],
                "requestId": "01HXTMBBBBBBZM2YAARMZB4GPR",
                "result": "CLEAR",
                "serviceProviders": [
                    {
                        "endedAt": "2024-05-14T04:04:12.663187286Z",
                        "provider": "complyadvantage",
                        "result": "CLEAR",
                        "startedAt": "2024-05-14T04:04:11.849152Z"
                    }
                ],
                "startedAt": "2024-05-14T04:04:11.849152Z",
                "stepData": {...},
                "stepName": "AML",
                "stepResultId": "01HXTMBBEERQ53021A2FGND7N7",
                "workflowExecutionId": "01HXTMBAT8AEM3E8RZXD9QTGN4"
            },
        ]
    }
}

AML Step Summary

Refer to the summary to understand the potential matches found during AML screening. Here you will find the number of matches that have been found for the given entity and what classification of hit it is. After an AML step has been run, various elements require examination to determine the outcome.

Use the table below to better understand the following section.

Icon	Description
‼️	Results that deem whether the entity has passed or failed, or the workflow failed to execute to completion.
⚠	Context on why the entity may have passed or failed.
ℹ️	Information-only, no contribution to whether the entity has passed or failed.

The AML workflow step summary details the types of matches that were found during AML screening and whether they have since been classified or are still in need of resolution.

Field name	Description	Importance
`numUnresolvedAdverseMedia`	Number of matched entities with Adverse Media that have not been classified as true positive, false positive or unknown.	‼️
`numUnresolvedPEP`	Number of matched entities that are PEPs that have not been classified as true positive, false positive or unknown.	‼️
`numUnresolvedSanctions`	Number of matched entities that are Sanctioned that have not been classified as true positive, false positive or unknown.	‼️
`numUnresolvedWatchlist`	Number of matched entities on Watchlists that have not been classified as true positive, false positive or unknown.	‼️
`providerSummaries`	See the `providerSummaries` table.	⚠
`stepName`	The name of the step executed to produce this result.	ℹ️
`totalFalsePositives`	Number of matched entities that have been classified as false positives.	⚠
`totalHits`	Number of matched entities.	⚠
`totalTruePositives`	Number of matched entities that have been classified as true positives.	⚠
`totalUnknowns`	Number of matched entities that have been classified as unknown.	⚠
`totalUnresolved`	Number of matched entities that have not yet been classified.	‼️

AML Step Summary - Provider Summaries

The providerSummaries that exist within the AML workflow step summary, provides additional context as to which matches were discovered by each provider. This will be identical to the summary numbers if only a single AML provider is configured within the workflow.

Field name	Description	Importance
`name`	Name of the service provider that screened this entity.	ℹ️
`lastRetrievedAt`	The datetime of the last result that was retrieved from the service provider.	ℹ️
`adverseMediaCountries`	Countries where matched entities with adverse media were reported.	ℹ️
`pepCountries`	Countries where matched entities that are PEPs were reported.	ℹ️
`sanctionCountries`	Countries where matched entities that are sanctioned were reported.	ℹ️
`watchlistCountries`	Countries where matched entities on watchlists were reported.	ℹ️
`numUnresolvedAdverseMedia`	Relevant to this provider (based on the provider `name`), the number of matched entities with Adverse Media that have not been classified as true positive, false positive or unknown.	ℹ️
`numUnresolvedPEP`	Relevant to this provider (based on the provider `name`), the number of matched entities that are PEPs that have not been classified as true positive, false positive or unknown.	ℹ️
`numUnresolvedSanctions`	Relevant to this provider (based on the provider `name`), the number of matched entities that are Sanctioned that have not been classified as true positive, false positive or unknown.	ℹ️
`numUnresolvedWatchlist`	Relevant to this provider (based on the provider `name`), the number of matched entities on Watchlists that have not been classified as true positive, false positive or unknown.	ℹ️
`totalFalsePositives`	Relevant to this provider (based on the provider `name`), the number of matched entities that have been classified as false positives.	ℹ️
`totalHits`	Relevant to this provider (based on the provider `name`), the number of matched entities.	ℹ️
`totalTruePositives`	Relevant to this provider (based on the provider `name`), the number of matched entities that have been classified as true positives.	ℹ️
`totalUnknowns`	Relevant to this provider (based on the provider `name`), the number of matched entities that have been classified as unknown.	ℹ️
`totalUnresolved`	Relevant to this provider (based on the provider `name`), the number of matched entities that have not yet been classified.	ℹ️

Example 1: Successful AML screening with many matches

Let’s break down the following result:

Field	Description
`numUnresolved`	Indicates how many matches were found of the specified type. There is currently 1 unresolved match with Adverse Media, 3 unresolved matches are potential PEPs, 1 unresolved match is on a sanction list, and 1 unresolved match is on a watchlist. These matches are not mutually exclusive.
`providerSummaries`	Breakdown of the AML screening results for Refinitiv (as presented by the `name`).
	- `name` Refinitiv is the service provider that provided the screening results.
	- `searchQuery` The entity details that were used in the screening query.
	- `Countries` Russian Federation is the only country where the matched listings were published.
	- `numUnresolved` Indicates how many matches were found of the specified type with this service provider. As there are results only from a single provider (Refinitiv), the `providerSummaries.numUnresolved` will represent the same number of matches as the `summary.numUnresolved`.
	- `total` Indicates the total number of matches found and their current classification (such as false positive, true positive, unknown, and unresolved) for this service provider. As there are results only from a single provider (Refinitiv), the `providerSummaries.total` will represent the same number of matches as the `summary.total`.
`total`	Indicates the total number of matches found and their current classification (i.e., false positive, true positive, unknown, unresolved). There are 10 matches total, with 7 already resolved as false positives and 3 still unresolved.

  {  
  "workflowStepResults": [  
  	{  
  ...  
  	"summary": {  
  		"numUnresolvedAdverseMedia": 1,  
  		"numUnresolvedPEP": 3,  
  		"numUnresolvedSanction": 1,  
  		"numUnresolvedWatchlist": 1,  
  		"providerSummaries": [  
                          {  
                              "adverseMediaCountries": [],  
                              "lastRetrievedAt": "2024-11-06T00:51:05.778476391Z",  
                              "name": "refinitiv_pep_media",  
                              "numFalsePositives": 7,  
                              "numHits": 10,  
                              "numTruePositives": 0,  
                              "numUnknown": 0,  
                              "numUnresolved": 3,  
                              "numUnresolvedAdverseMedia": 1,  
                              "numUnresolvedPEP": 3,  
                              "numUnresolvedSanction": 1,  
                              "numUnresolvedWatchlist": 1,  
                              "pepCountries": [],  
                              "sanctionCountries": [  
                                  "RUSSIAN FEDERATION",  
                              ],  
                              "searchQuery": {  
                                  "address": "RUS",  
                                  "dateOfBirth": "1972-10-09",  
                                  "gender": "MALE",  
                                  "name": "Iam Arisk"  
                              },  
                              "watchlistCountries": [  
                                  "RUSSIAN FEDERATION"  
                              ]  
                          }  
                      ]  
  ,  
  		"stepName": "AML",  
  		"totalFalsePositives": 7,  
  		"totalHits": 10,  
  		"totalTruePositives": 0,  
  		"totalUnknown": 0,  
  		"totalUnresolved": 0  
  	},  
  ...  
  ]  
  }

Example 2: Successful AML screening with 0 matches

Let’s break down the following result:

Field	Description
`total`	There were 0 matches found during the screening.
`numUnresolved`	There are 0 unresolved matches for review.
`providerSummaries`
	- `name` - Refinitiv is the service provider that provided the screening results.
	- `searchQuery` - The entity details that were used in the screening query.
	- `Countries` - No listings were matched against this search.
	- `numUnresolved` - As there are results only from a single provider (Refinitiv), the `providerSummaries.numUnresolved` will represent the same number of matches as the `summary.numUnresolved`.
	- `total` - As there are results only from a single provider (Refinitiv), the `providerSummaries.total` will represent the same number of matches as the `summary.total`.

  {  
  "workflowStepResults": [  
  	{  
  ...  
  	"summary": {  
  		"numUnresolvedAdverseMedia": 0,  
  		"numUnresolvedPEP": 0,  
  		"numUnresolvedSanction": 0,  
  		"numUnresolvedWatchlist": 0,  
  		"providerSummaries": [  
                          {  
                              "adverseMediaCountries": [],  
                              "lastRetrievedAt": "2024-11-06T00:51:05.778476391Z",  
                              "name": "refinitiv_pep_media",  
                              "numFalsePositives": 0,  
                              "numHits": 0,  
                              "numTruePositives": 0,  
                              "numUnknown": 0,  
                              "numUnresolved": 0,  
                              "numUnresolvedAdverseMedia": 0,  
                              "numUnresolvedPEP": 0,  
                              "numUnresolvedSanction": 0,  
                              "numUnresolvedWatchlist": 0,  
                              "pepCountries": [],  
                              "sanctionCountries": [],  
                              "searchQuery": {  
                                  "address": "RUS",  
                                  "dateOfBirth": "1992-10-10",  
                                  "gender": "MALE",  
                                  "name": "Iam Notarisk"  
                              },  
                              "watchlistCountries": []  
                          }  
                      ]  
  ,  
  		"stepName": "AML",  
  		"totalFalsePositives": 0,  
  		"totalHits": 0,  
  		"totalTruePositives": 0,  
  		"totalUnknown": 0,  
  		"totalUnresolved": 0  
  	},  
  ...  
  ]  
  }

AML Process Results

In the context of AML screening, a single processResult will represent a single matched entity within the service provider's database, generally with all the related PEP, sanctions and media listing details linked to it.

After an AML step has been executed, various elements require examination to determine whether the entity being screened has matched any of the listings searched by the AML provider.

Icon	Description
‼️	Results that deem whether the entity has passed or failed or the workflow failed to execute to completion.
⚠	Context on why the entity may have passed or failed.
ℹ️	Information-only, no contribution to whether the entity has passed or failed.

Field name	Description	Importance
`processResultId`	The `processResultId` represents the unique identifier of the process result	ℹ️
`class`	The `class` reflects the type of process result (such as AML)	ℹ️
`result`	The `result` is the overall outcome of the process (such as CLEAR, HIT)"	‼️
`state`"	The `state` reflects whether the process was completed successfully or whether an error of some kind was encountered during the process	⚠
`stepName`	The `stepName` indicates the workflow step that triggered the process and thus generated the process result	ℹ️
`stepType`	The `stepType` indicates whether there was a subtype for the step.	ℹ️
`groupId`	The `groupId` is generated to tie related process results together. In the context of AML, this is expected to be null	ℹ️
`systemStatus`	The `systemStatus` indicates that the result is valid and was used in determining the overall step result (typically only VALID results will be returned unless specifically requested).	⚠
`manualStatus`	The `manualStatus` indicates whether the result has been manually classified by an operator outside of Frankie (such as via API or Portal). This will store any hit classification where a potential match has been classified as a true positive or false positive.	⚠
`providerResult`	- The `providerResult.confidence` refers to the confidence ratings returned by the provider and how we’ve normalized it. Defaults to 0/100 if confidence is not explicit. - `actual` - the explicit value returned by the service provider - `normalized` - the value we’ve normalized to between 0-100 - `providerResult.name` refers to the name of the provider - Any unique identifier on the data provider side will be returned as `providerResult.reference` - The `providerResult.source` indicates the raw source that was checked against (if applicable). - The `providerResult.sourceNormalized` indicates the normalized source that was checked against (if applicable). Note: The same sources checked by different providers will have the same `sourceNormalized` value but different source values.	⚠
`objectId`	The `objectId` indicates the ID of the exact element that was checked. Only present it objectType is not an entity type such as “INDIVIDUAL”	ℹ️
`objectType`	The `objectType` indicates the specific type of element that was checked.	ℹ️
`entityId`	The `entityId` of the individual/organization that was checked	ℹ️
`createdAt`	`createdAt` refers to when the process result was created.	ℹ️
`updatedAt`	`updatedAt` refers to when the process result was last updated.	ℹ️
`updatedBy`	`updatedBy` refers to who last updated the process result. Generally, this will be FrankieOne unless a manual override is triggered.	ℹ️
`schemaVersion`	Refers to the version of the schema returned. There will always be 2 in the FrankieOne v2.x API.	ℹ️
`requestId`	The unique identifier of the request that generated this process result	ℹ️
`notes`	Any additional notes that were captured during the process. May contain extra information about how the result was determined.	⚠
`errors`	Any errors that were encountered as part of the process.	⚠
`supplementaryData`	See Supplementary Data below.	⚠

Supplementary Workflow Steps

Start Step Results

The start step confirms the successful initiation of the workflow. Check for a “COMPLETE” result in the execution result. This ensures the workflow starts without issues. Typically, this step does not generate processResults.

{
    "requestId": "{requestId}",    
    "individual": {...},
    "workflowResult": {
        "workflowStepResults": [
            {
                "endedAt": "2024-07-22T05:46:07.722933Z",
                "objectId": "{objectId}",
                "objectType": "INDIVIDUAL",
                "requestId": "{requestId}",
                "result": "COMPLETE",
                "risk": {
                    "contributedScore": 150,
                    "factors": [
                        {
                            "factor": "entity_type",
                            "score": 0,
                            "value": "Individual"
                        },
                        {
                            "factor": "country",
                            "score": 50,
                            "value": "Lithuania"
                        },
                        {
                            "factor": "entity_age",
                            "score": 100,
                            "value": "Under 18"
                        }
                    ],
                    "level": "HIGH",
                    "overallScore": 150
                },
                "schemaVersion": 2,
                "startedAt": "2024-07-22T05:46:09.013204Z",
                "stepName": "START",
                "stepResultId": "{stepResultId}",
                "updatedBy": "01J3CFKFJE1HJACPRFZ7F47N5K",
                "workflowExecutionId": "{workflowExecutionId}"
            }
        ]
    }
}

Finish Step Results

The finish step shows whether the workflow is complete. A “COMPLETE” result means all results were collected and stored. This confirms the workflow’s completion but not the success of individual checks or errors. Typically, this step does not generate processResults.

{
    "requestId": "{requestId}",    
    "individual": {...},
    "workflowResult": {
        "workflowStepResults": [
            {
                "endedAt": "2024-07-22T05:46:26.547446Z",
                "objectId": "{objectId}",
                "objectType": "INDIVIDUAL",
                "requestId": "{requestId}",
                "result": "COMPLETE",
                "schemaVersion": 2,
                "startedAt": "2024-07-22T05:46:26.511309Z",
                "stepName": "FINISH",
                "stepResultId": "{stepResultId}",
                "updatedBy": "system:frankieone",
                "workflowExecutionId": "{workflowExecutionId}"
            }
        ]
    }
}

Decision Step Results

The decision step is a critical point that determines the workflow’s status: PASS, FAIL, or REVIEW. This status depends on the actions taken during the workflow. If all previous steps are completed successfully, the workflow is marked as "PASS." If there is an issue, such as a verification problem, it is marked as "FAIL." You can modify these statuses in the workflow builder.

{
"workflowStepResults": [
	{
                "endedAt": "2024-07-22T05:46:25.826735Z",
                "objectId": "{objectId}",
                "objectType": "INDIVIDUAL",
                "processResults": [],
                "requestId": "{requestId}",
                "result": "COMPLETE",
                "schemaVersion": 2,
                "startedAt": "2024-07-22T05:46:25.76572Z",
                "stepName": "DECISION",
                "stepResultId": "{stepResultId}",
                "summary": {
                    "stepName": "DECISION",
                    "workflowExecutionResult": "PASS"
                },
                "updatedBy": "system:frankieone",
                "workflowExecutionId": "{stepResultId}"
            }
    ]
}

Risk Step Results

The risk step is a mandatory checkpoint for assessment. It does not result in a pass or fail. After evaluation, it's marked "COMPLETED." This ensures risks are considered without affecting the workflow. The information gathered may help in later steps.

"workflowStepResults": [
            {
                "endedAt": "2024-07-22T05:46:24.998288Z",
                "objectId": "{objectId}",
                "objectType": "INDIVIDUAL",
                "requestId": "{requestId}",
                "result": "COMPLETE",
                "schemaVersion": 2,
                "startedAt": "2024-07-22T05:46:24.963811Z",
                "stepName": "RISK",
                "stepResultId": "{stepResultId}",
                "updatedBy": "system:frankieone",
                "workflowExecutionId": "{workflowExecutionId}"
            }
	]
    }

KYC

AML