Analysts have more information than ever when direct servicing in Alert Triage
This post discusses Direct Servicing using SAS Alert Triage, including comparing it with Priority Servicing and looking at an example use case. We'll be highlighting and exploring some exciting servicing functionality from the latest release (2025.11), so note that if you are not on the latest version of Alert Triage, your Direct Servicing will look slightly different.
To begin, let's discuss some basics about Alert Triage and Fraud Decisioning. SAS Alert Triage is a lightweight alerts client that is available as part of SAS Fraud Decisioning. Analysts can use it to service alerts that represent potentially suspicious activity in numerous fields including card fraud, payment fraud, application fraud, and more.
An Alert is created for transactions that are flagged for further review by the Decisioning engine. Alerts are grouped into Domains, then into triage types, and finally within triage types, grouped into queues. Routing rules at the queue level determine the destination of alerts, and there is a default queue for alerts that do not meet the requirements for other queues.
Alert Servicing assigns alerts to analysts based on priority, but in slightly different ways depending on type. There are two types of alert servicing: Direct servicing, and priority servicing.
For more information on the two servicing types, check out this post on servicing alerts in Alert Triage.
In this post, we'll look at an example of direct servicing and focus on advantages and applications of this servicing type.
With both types of alert servicing, the user begins by selecting an alert domain from a drop-down menu.
In the Alert Servicing section of the homepage, the Debit Account Fraud domain is selected
from the drop-down menu.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
When a user clicks Start Priority Servicing, they are assigned the highest priority alert within the highest priority triage type and queue in the domain. This is also known as global priority order.
In Direct Servicing, the user selects a triage type from a list of triage types. The list appears in priority order.
Triage types are displayed in priority order. If a triage type contains workable alerts,
it is a clickable link that begins direct servicing.
For example, here are the available triage types in the Debit Account Fraud domain. Three of the listed triage types are hyperlinks. Clicking one of these links begins Direct Servicing, and the highest priority alert from the highest priority queue in the selected triage type is assigned to the user.
For example, let's say an analyst selects Card Not Present. They are assigned an alert from one of the queues in the Card Not Present triage type, even if another alert in a different triage type has higher global priority.
You may wonder why an analyst would choose Direct Servicing at all when Priority Servicing automatically considers the priority of both the queue and the triage type.
While the triage type priorities may be configured to meet the day-to-day needs of an organization, an analyst may need to work in a particular triage type to address emerging fraud trends in areas that may not usually be high priority.
Another advantage of Direct Servicing facilitated by the newly added alert counts is that it allows analysts visibility into the number of workable and non-serviceable alerts in each triage type. This count can give users a more granular understanding of triage type health and help them make decisions.
It is worth noting that whether an alert is workable depends on several things, and an alert can be workable to one user but not workable to another. Users must have the triage.alert.work capability to work alerts, and an alert must not already be locked by another user. It must also have a state of Active, be accessible to the user, and be in a queue the user is associated with.
If an alert is also in a queue with servicing enabled, and a user has the capability triage.alert.direct_servicing (or triage.alert.priority_servicing), an alert is serviceable by the user.
The Workable column contains the count of alerts in that triage type that are workable, while the Non-serviceable column includes the alerts in that triage type that do not meet a criteria of workability or serviceability.
Now, a user can immediately identify which triage types do contain workable alerts by the hyperlink. Triage types that do not require any action because they contain no workable alerts are not hyperlinks, but they do appear in the list for analysts to reference. In our example, these are the Manual Alerts, Account Takeover, and Other triage types.
Hopefully this example helps you better understand Direct Servicing in Alert Triage and especially how newly added information like alert counts can enhance alert servicing.
Looking for more information on Fraud Decisioning?
Read about the key differences between SAS Fraud Decisioning and SAS Fraud Management here.
For more information on the two servicing types, check out this post on servicing alerts in Alert Triage.
This post discusses writing rules in Fraud Decisioning.
For more information on using and configuring Alert Triage, reference the SAS Alert Triage Administrator's and User's Guides.
