Skip to main content

​
Review alerts

Once an activity has been deemed to be alerting, relevant workflows will be triggered and the alerts will be consumed and presented in the workflowResult object. This object is the key to understanding the outcome, the reason for any alerts, and the granular details of the checks performed. Operators will typically review these alerts via the Portal, where issues are flagged for manual review.

​
via API

Get the result of the evaluation by calling the Get Workflow Execution Results endpoint. The workflowResult object in the response will contain the comprehensive details needed to interpret the outcome. 
curl https://api.uat.frankie.one/v2/individuals/{{your_entity_id}}/serviceprofiles/serviceName/workflows/workflowName/executions/workflowExecutionId \
     -H "api_key: X" \
     -H "X-Frankie-CustomerID: {{your_customer_id}}"

​
via Portal

To learn how Fraud and Compliance Officers can review alerts generated via Portal here, review Entity View.

​
Interpreting the results

The workflowResult object provides a structured, top-down view of the evaluation. Here’s how to interpret the key sections, focusing on Transaction and Activity Monitoring:
Overall outcome (workflowResult top-level fields)
APIPortal
workflowExecutionState: This confirms the workflow’s technical status.
It must be COMPLETED for the status to be considered final and for you to reliably review the activity’s details.
Other states like IN_PROGRESS, ERROR, TIMEOUT, CANCELED, or TERMINATED indicate the workflow did not finish successfully.		Not displayed in Portal
status : This represents a conclusive recommendation (configured status in your selected workflow) for the activity after evaluation and accounts for any manual overrides.
For monitoring workflows, common/preferred statuses include
- CLEAR (no negative information found)
- REVIEW (requires manual review due to identified issues)
No issues (CLEAR)


Needs attention (REVIEW)
result: This field holds the original, automated outcome of the workflow before any manual changes.
It is useful for auditing and understanding the system’s initial verdict versus any human intervention.		Not displayed in Portal

​
Issues

This array will contain a list of problems that may require manual review. If the status is REVIEW, this array will provide the specific reasons why the activity needs further investigation. For Transaction and Activity Monitoring, this might include flags of different types for unusual transaction patterns, device anomalies, or AML concerns with issueCategory: ACTIVITY. The Portal will display these as “Activity” as seen in the image below. Entities flagged with issue Activity
Issue TypeDescription
ACTIVITY_AMLAn issue identified during an Anti-Money Laundering (AML) check within the activity monitoring workflow. This could be due to potentially high-risk financial behavior patterns detected during transaction or activity monitoring.
ACTIVITY_FRAUDAn issue identified as potential fraud during the transaction and activity monitoring workflow. This can stem from indicators of fraudulent intent related to financial activities.
ACTIVITY_EVENTAn issue identified as potential fraud during the activity monitoring workflow. This can stem from indicators that are non-transactional or behavioral by nature such as device anomalies, or unusual login patterns or interactions with the device.

​
Workflow step results

The workflowStepResults array is a log of each step in the workflow, explaining how the overall status was reached. Each object in this array corresponds to a step configured in your monitoring workflow (e.g. AML check, device check, transaction velocity check).
API stepName: The name of the specific step that was executed
  • ACTIVITY_AML - a step dedicated to performing AML checks on the activity.
  • ACTIVITY_FRAUD - a step dedicated to performing fraud checks on the activity.
Portal stepName: ACTIVITY_AML is available stepName: ACTIVITY_FRAUD is available
API result: The outcome of this specific step. For monitoring, this can be:
  • CLEAR (step passed): The step completed successfully without identifying any issues.
  • HIT (step identified an issue): The step identified a potential issue or match according to its configured rules.
  • ERROR (technical issue with the step): The step encountered an unrecoverable technical error during its execution. Portal HIT, Expanded view
CLEAR, Expanded view HIT Expanded view
API summary: A concise, human-readable summary of the step’s outcome.
{
    "amlActivityCount": 3,
    "amlActivityTruePositiveCount": 0,
    "eventActivityCount": 0,
    "eventActivityTruePositiveCount": 0,
    "fraudActivityCount": 0,
    "fraudActivityTruePositiveCount": 0,
    "stepName": "ACTIVITY_MONITOR"
}
PortalNot displayed in Portal
API risk: The risk assessment specific to this step, including the score it contributed to the overall workflowRiskScore and workflowRiskLevel.

​
Portal

​
Activity alerts

On evaluations each activity will have activity results but only activity results that are considered “alerting” will represented as Process Result Objects (PROs) that are treated as alerts and considered needs action.
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 (e.g., a specific device fingerprint provider, an AML watchlist provider).
  • processResultId: A unique identifier for this specific piece of evidence.
  • systemStatus: The 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 and it might need re-evaluation. Only the alerts with a systemStatus: VALID will be displayed in Portal.
  • class: The high-level category of the check performed, for Transaction and Activity Monitoring, it’s ACTIVITY.
  • objectType: The specific data element that was checked (e.g., INDIVIDUAL, TRANSACTION, DEVICE).
  • result: The outcome of this specific PRO (e.g., MATCH for a hit, CLEAR for no hit, CREATED for data fetched).
  • manualStatus: If an operator has manually reviewed this specific PRO, their conclusion (e.g., TRUE_POSITIVE, FALSE_POSITIVE, IN_REVIEW) is recorded here. This is directly linked to the statuses described in Section 3.
  • providerResult: An object containing details from the downstream data provider, including the source of the data.
  • supplementaryData: A rich, context-specific object containing detailed metrics or extracted data, like AML hits details or specific device intelligence data. This is where most of the alerts or rows in the table gets its details as seen in the Portal.

​
Next step

Once you have identified any alerts that need attention, update their status and trigger a re-evaluation. Resolve alerts and re-evaluate →