Verkflo is in early access. Book a demo

Fraud alert triage with the context already gathered

When a fraud alert arrives, the agent collects the account, device and transaction context, applies your rules and puts the case in front of an analyst with a recommendation.

Book a demoSee how it runs

Works with

  • Fraud engine · via Custom REST
  • Card processor · via Custom REST
  • Case system · via Custom REST

and any system with an API via Custom REST

What is fraud alert triage?

  • The procedure

    A fraud engine flags a payment, login or account change it scores as risky. Triage decides what happens next: release it, hold it and contact the customer, or treat it as account takeover. Analysts need the device, login and transaction history together, because a held payment affects a real customer.

  • What the agent does

    • Pulls the alert and recent transactions through Custom REST

    • Reads device and login history from your fraud engine

    • Checks the alert against your signal rules, such as a new device or a payee change

    • Queues low-risk alerts for QA sampling with the reason recorded

  • What your team decides

    • Holding or releasing a payment

    • Contacting the customer

    • Treating a case as account takeover

    • Blocking a card or account, per your procedure

Example runs for fraud analysts, operations leads and financial crime teams

Sample data

Fraud Triage Agent

Collects context for each fraud alert and applies your rules.

  • API
  • Google Drive
  • +1

Trigger: Inbound webhook · new fraud alert

From a procedure Fraud triage · v1.1

Tom

Triage the new fraud alert on the Halden Trading card.

Fraud Triage Agent

  1. Pulled the alert and recent transactions through Custom REST
  2. Pulled the device and login history from the fraud engine
  3. The device and location match the account's usual pattern device.known && geo.matches_history
  4. Marked the alert as a likely false positive and queued it for QA sampling

Low risk. The alert matched the account's usual pattern under your rules and was queued for a QA sample.

4 steps · 0 reviews

Fraud Triage Agent

Collects context for each fraud alert and applies your rules.

  • API
  • Google Drive
  • +1

Trigger: Inbound webhook · new fraud alert

From a procedure Fraud triage · v1.1

Priya

Triage the new fraud alert on the Lumen Print account.

Fraud Triage Agent

  1. Pulled the alert and recent transactions through Custom REST
  2. Pulled the device and login history from the fraud engine
  3. New device and a payment above the usual range device.known == false && txn.amount > profile.typical_max
  4. Asked an analyst whether to hold the payment, as your rules require Waiting for a reviewerMarcus: hold the payment, contact the customer
  5. Saved the case summary and the analyst's decision to the case folder

Held for contact. Marcus decided to hold the payment and contact the customer under your procedure.

5 steps · 1 review

Fraud Triage Agent

Collects context for each fraud alert and applies your rules.

  • API
  • Google Drive
  • +1

Trigger: Inbound webhook · new fraud alert

From a procedure Fraud triage · v1.1

Lena

Triage the new fraud alert on the Harbor Lane account.

Fraud Triage Agent

  1. Pulled the alert, logins and recent changes through Custom REST
  2. Found a password reset, a new device and a payee change within one session
  3. Three takeover signals together: paused for an analyst Waiting for a reviewerDiego: treat as takeover, escalate per procedure
  4. Recorded the decision and opened the escalation

Escalated. Diego treated the case as a possible account takeover and escalated it under your procedure. The signals and his decision are logged.

4 steps · 1 review

Setting up the Fraud Triage Agent

Connect your systems

Read alerts, devices and transactions from your fraud engine and card processor through Custom REST, and keep case summaries in Google Drive.

  • Google Drive
  • Sumsub
  • ComplyAdvantage
  • Fraud engine · via Custom REST
  • Card processor · via Custom REST
  • Case system · via Custom REST

Write the rules

Which signals count, and how many together need a person, are CEL rules your team sets and can change.

Sample data
device.known == false && txn.amount > profile.typical_maxAsk an analyst
signals.count >= 3Escalate
device.known && geo.matches_historyQueue for QA sample

Add reviewers where the procedure says

The analyst sees the signals that fired next to the account's usual pattern. Holds and releases are recorded with who decided and why.

Sample data

Review requested: Lumen Print alert

Reason
New device and a payment above the usual range
Rule
device.known == false
Procedure
Fraud triage · v1.1

ReleaseHold and contact customer

Start it from the event

A new fraud alert starts triage by webhook. A schedule every 30 minutes picks up alerts still waiting on context, and another webhook starts a run when the customer replies.

  • Inbound webhook · new fraud alert
  • Every 30 minutes · alerts awaiting context
  • Inbound webhook · customer replied

Version and evaluate

Keep a known-device alert, a large payment from a new device and a takeover pattern as scenarios. Each fraud triage version runs them in the sandbox before it can be published.

Sample data

Fraud triage · v1.1Published

12/12 scenarios passed

Fraud triage · v1.2 Superseded

Fraud triage · v1.1 Superseded

Share with the team

Fraud analysts take the Reviewer role, an operations lead authors the signal rules, and financial crime teams can audit each hold, release and escalation.

  • Admin
  • Author
  • Reviewer
  • Auditor

Questions about fraud alert triage automation

Does the agent hold payments?

No. It recommends, and an analyst decides on any hold or release. The decision is recorded with who made it and why.

Which fraud engines does it work with?

Any fraud engine or card processor with an API, through Custom REST. There is no built-in fraud engine connector.

What counts as a takeover signal?

Whatever your procedure lists. In the example, a password reset, a new device and a payee change in one session met the rule signals.count >= 3.

Are low-risk alerts closed without a person?

In the example they are queued for a QA sample under your rules. Whether any alert closes without review is set by your procedure.

Controls your auditors will ask about

These controls apply to each agent you build. Sample data

Related use cases

See all use cases

Run this procedure as an agent

Book a demo with your own version of this procedure, and we'll show it running with each step logged.

Book a demo