Resolve alerts and re-evaluate

Resolve alerts

Portal display	API manualStatus	Description
Needs attention	`null`	Indicates that the alert requires review and resolution.
In review	IN_REVIEW	Indicates that the alert is being actively investigated or reviewed.
True positive: Reject	TRUE_POSITIVE_REJECT	Indicates that the activity was confirmed or suspected to be fraudulent or high-risk, and the associated activity was rejected (e.g. transaction blocked).
True positive: Accept	TRUE_POSITIVE_ACCEPT	Indicates that the activity was confirmed or suspected to be fraudulent or high-risk, and the associated activity was accepted (e.g. transaction approved with override).
False positive	FALSE_POSITIVE	Indicates the alert was reviewed, and confirmed or assumed to be genuine or low-risk.

via API

To resolve an alert, update the activity result’s status by calling the Update Activity Results endpoint. For more details around classification (applying tagIds), see Classifying activities and alerts. X-Frankie-Username is optional. If provided, it identifies the actor in the audit log.

curl -X 'PATCH' \
  'https://api.uat.frankie.one:443/v2/individuals/{{your_entity_id}}/results/activity' \
  -H 'accept: application/json' \
  -H 'api_key: X' \
  -H 'X-Frankie-CustomerID: {{your_customer_id}}' \
  -H 'X-Frankie-Username: example@frankieone.com' \
  -H 'Content-Type: application/json' \
  -d '{
  "processResults": [
    "{{processResultId}}"
  ],
   "tagIds": [
        "{{tagId}}",
        "{{tagId}}"
  ],
  "manualStatus": "TRUE_POSITIVE_ACCEPT",
  "comment": {
    "text": "Update after speaking to customer over the phone directly.",
    "entityId": "{{your_entity_id}}",
    "entityType": "{{entityType}}"
  }
}'

Request body

processResults

string[]

required

The IDs of the process results (alerts) to update. A process result is created when an activity is flagged for review. Supply one or more UUIDs; the manualStatus is applied to each.

manualStatus

string

required

The manual outcome to record for the alert. Must be one of:

FALSE_POSITIVE — the result was reviewed and determined to be genuine or low-risk; the activity is within the risk profile to continue.
TRUE_POSITIVE_ACCEPT — the result was determined to be a true positive, and the activity is within the risk profile to continue (for example, the transaction is approved with an override).
TRUE_POSITIVE_REJECT — the result was determined to be a true positive, and the activity is not within the risk profile to continue (for example, the transaction is blocked).
IN_REVIEW — the alert has been picked up and is being actively investigated. “Needs attention” is the unresolved default state of an alert. It corresponds to no manual status being set and is not a value you send through this field.

tagIds

string[]

Optional tags to apply to the alert and its associated activity. Each tag must exist and be accessible to your account (a FrankieOne SYSTEM tag or a CUSTOMER tag your account owns). Duplicate IDs are removed automatically. A request must not mix FALSE_POSITIVE- or IN_REVIEW-category tags with tags of any other category — the intent cannot be reconciled and the request is rejected with 400See Tags and Reasons reference for the full list of available tags.

comment

object

An optional comment recorded in the audit log alongside the status change. Because comments are tied to the manual status action, they form part of the compliance audit trail.

Show comment properties

text

string

The comment text.

entityId

string

The entity the comment relates to, as a UUID.

entityType

string

The entity type — for example, INDIVIDUAL or ORGANIZATION.

via Portal

See Features for more details

Re-evaluate the results

This is crucial for the entity’s overall risk score, which are calculated based on historical activity, and device or customer characteristics.

Once all alerts have been resolved, you must re-run the workflow for the entity.

To update the status: The overall workflowResult.status will only be changed by the system from REVIEW to PASS or CLEAR after the workflow is executed again and the steps included in the monitoring workflow confirms that no unresolved hits remain.
To clear issues: The re-execution will cause the steps to re-evaluate the issues. If all PROs that previously caused an ACTIVITY issue are now classified as FALSE_POSITIVE, the issue will be cleared from the workflow result.

This re-evaluation ensures that your entity’s compliance status is officially updated, reflects the latest risk assessment, and maintains an accurate audit trail.

via API

To trigger a re-evaluation via API, you will execute the workflow again. Refer to the Execute a workflow for the given service profile documentation.

via Portal

The Portal will automatically re-run the workflow for you once all alerts associated with an activity have been resolved (i.e. no alerts with “Needs attention” and “In review” status remain).

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 (for example, 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.

(Optional) Retrieve all activities

Fetch historical information about the transactions to help get context of the user behavior and investigate.

Get Activities request

curl -X 'GET' \  
  'https://api.uat.frankie.one:443/v2/individuals/d2859e0c-1f63-4208-947a-038bcb7b1e5e/activities?sortField=ACTIVITY_AT&sort=ASC&limit=20&page=1' \                           
  -H 'accept: application/json' \
  -H 'api_key: X ' \ 
  -H 'X-Frankie-CustomerID: {{your_customer_id}}' \
  -H 'X-Frankie-Username: {{example@frankieone.com}}'

Classifying activities and alerts — set alert statuses and classify activities via API.
Interpret activity results — read the workflow result and identify the alerts to resolve.

Next step

Your implementation is complete. If you encounter errors at any step, see the full list of error codes and response structures: Error handling

Getting Started

Fraud

Transaction Monitoring

Resolve alerts and re-evaluate

Resolve alerts

via API

via Portal

Re-evaluate the results

via API

via Portal

Detecting manual overrides

(Optional) Retrieve all activities

Next step

​Resolve alerts

​via API

​via Portal

​Re-evaluate the results

​via API

​via Portal

​Detecting manual overrides

​(Optional) Retrieve all activities

​Related pages

​Next step

Resolve alerts

via API

via Portal

Re-evaluate the results

via API

via Portal

Detecting manual overrides

(Optional) Retrieve all activities

Related pages

Next step