Understanding Case Management
This topic discusses the basics of the Case Management feature and includes the following sub-topics:
cara
This topic discusses the basics of the Case Management feature and includes the following sub-topics:
2
What Is a Case
The following is a gist of managed cases in RA:
- All transactions (login, wire transfer, or any transaction that your application is evaluating risk for) for a user that result in theDenyorAlertadvice in the RA system are considered acase.In other words, one case can comprise multiple suspicious transactions for a user.
- Every case provides information related to the user, transactions details, and case history.In other words, there is a strict 1:1 mapping between a user and open cases. As a result if a case is already open for the user, then a new suspicious transaction is added to the existing case. A new case isnotcreated if a user already has a case open.
- At any time, a user can only have one open case in the system.
- At any time, a view into the case from Administration Console shows all the transactions within the case that have not been handled by an administrator and, therefore, their Fraud status is still undetermined.
- After a case is created in the system, it is recommended that a Customer Support Representative (CSR) handles all the transactions within a case and then close the case explicitly.
- If a case is closed, then any new warnings or suspect transactions for a given user result in the creation of a new case in the system. All new and future transactions are assigned to this new case.
What Are the Different States a Case can Undergo
During its lifecycle, a case can progress through the following states:
The following figure illustrates how the states of a case change.

New
When a user transaction results in
Alert
or Deny
advice, then a new case is created for the user, if a corresponding case does not already exist.The case remains in the
New
state until a CSR opens it or the case expires.Open
When a CSR opens a new case assigned to them, the case is activated and its state changes to
Open
. When a case is in the Open
state, new transactions or events can be added to the case.Unless the case state is either
On Hold
or Closed
, every case remains in the Open
state.In Progress
While a CSR is working on a case, the case state remains
In Progress
. In other words, when they click the Cancel
button for the current case or click the Go To Next Case
button to move to the next case assigned to them, the currently open case state changes to Open
, or to the state that they explicitly changed the case to.A CSR and Queue Manager can change the status of a case from
On Hold
to In Progress
.On Hold
When a CSR postpones the further investigation of a case by specifying the
Next Action Date
for an In Progress
case, the case state changes to On Hold
.All events that are generated within the time frame of
Next Action Date
are appended to the case.When the specified
Next Action Date
arrives, the case state automatically changes to Open
.Expired
When no CSR works on a
New
case within a pre-defined number of days, the case state changes to Expired
.The time the last transaction was added to the case or was updated is considered as the
Starting Date
for the case. The case Expiration Date
is calculated as the Starting Date + N
days, where N
is a configurable value. The default value for N
is 10 days
.New transactions cannot be added to an expired case. A new case (and therefore a new Case ID) is created, and the new transactions or events are added to this new case.
Closed
When a CSR resolves an
Open
case and explicitly marks it as Closed
, the case state changes to Closed
.What Is Case Management
The
Case Management
feature of Risk Analytics provides your User Administrators (UAs) and Fraud Analysts (FAs) a single unified view of the data related to cases. This enables them to analyze the data more efficiently and take faster, better-informed decisions towards resolving the cases. In addition, analysts can also constantly track the status and progress of their cases and maintain complete case histories with instant access to all related information.This feature enables you to:
- Efficiently manage customer service and support
- Manage large numbers of cases and investigations
- Create actions and tasks with due dates
- Assign actions with due dates
- Record investigation notes and the resolution provided to the user
- Handle cases and tasks more efficiently
- Keep clear audit trail or history of actions on a case
- Analyze trends
- Generate fraud-related reports
The Case Management feature enables you to investigate transactions, and intuitively and effectively manage the transactions that are marked suspicious. This feature simplifies the challenge of recording and documenting every phase of an investigation, creating a clear and comprehensive trail of activity. This feature also saves time by automatically creating a report of the findings, including a detailed listing of reason, recommendation, geolocation information, connection details, and risk assessment details.
What Are the Components of Case Management
The components of the Case Management module include:
The following figure illustrates how these components work together.

Case Queues
A
Case Queue
(or simply a Queue
) is a list of cases that are grouped based on criteria, such as Date Created
, Date Updated
, Number of Open Transactions
, and Next Action Date
. RA supports multiple Queues for each organization in the system.RA allows you to set levels for Queues. Each Queue is assigned to a level when the Queue is created. Queue levels help define how cases are escalated. For example, cases from Queues of Level 1 get escalated to Queues of Level 2 in the same organization.
Note the following points related to Queue levels:
- RA allows you to set up to four levels for Queues.
- Each Queue is associated with exactly one level.
- Once you assign the Queue level, you cannot edit it.
- There can be a maximum of only one Queue for levels other than Level 1.
- Queue Criteria is not applicable to Queues at levels greater than Level 1.
The following figure depicts what a typical Queue looks like.

Queues are managed by Queue Managers, and are associated with a Queue Name, Case Order criteria in the Queue, and Case Priority. Queue Managers can define a new queue. New cases that are generated are added to the Queue when a Queue rebuild happens. By default, Queue rebuild
happens every 30 minutes. The GA can configure this frequency on the Miscellaneous Configuration screen. The Queue Manager for an organization can also issue a Queue rebuild request from Administration Console. Cases that do not fit into any individual Queue are assigned to the DEFAULT queue
The Queue Manager can assign Customer Service Representatives (CSRs) to work on each Queue, depending upon the skill of the CSR or other organization policies.
More than one CSR can be allocated to a Queue in an organization. Also, if there are multiple organizations in a CSR’s purview, the CSR can be allocated to multiple Queues.
Queue Server
The
Queue Server
is responsible for:- Caching Case Queues and Queue-to-Administrator mapping with the help of the Queue Monitor Thread.
- Dispatching the cases in the Case Queues to the active Administration Console instances with the help of Case Dispatcher Module.
- Maintaining the updated list of expired cases with the help of Expiry Monitor Thread.
Queue Monitor Thread
The
Queue Monitor
(referred to as Scheduler
) thread runs at the Queue Server-end and is responsible for creating the Case Schedule, populating the Case Queues with cases, and prepares the Queues for Case Dispatcher Module.This thread works as follows:
- It wakes up at a pre-defined interval and fetches from the database a list of all the cases that meet the following criteria:
- At least one transaction shows the Fraud Status asUndetermined.
- The case has not expired.
- Caches the Queues with cases.
- Based on the case state and other criteria (such asTransaction Date,Transaction Amount, orNext Action Date), the thread assigns the cases into the Case Queues.
- For more information about case states, see Case States.
- When a case is assigned to the Queue, an in-memory list is created for the Queue.
- On completion of the case assignment to a Queue, the state of all the assigned cases is changed to OPEN.
- When the Customer Service Representatives (CSRs) click theSave and Go to Next Caseor theGo to Next Casebutton:
- A request to fetch the next case in the Queue is sent to the Queue Monitor Thread via Queue Server.
- In response, the Case Dispatcher Module picks the case from the memory queue and returns its Case ID to the Administration Console instance from where the request originated.
- The state of the case is then changed to IN PROGRESS, and the CSRs can work on the case.
- On receiving the Case ID, the Administration Console instance fetches all the transactions for the case from the database and displays the same to the CSR.Based on the case review process, the case state can change. See Case States for more information.
Case Dispatcher Module
The
Case Dispatcher Module
(referred to as Dispatcher
) listens to the case requests from the individual CSRs at the Queue Server-end and "pushes" the cases (as per their order in the Queue) from the Case Queues to the individual Administration Console instances on demand.This module works as follows:
- When CSR logs in, a request is sent to the Dispatcher to fetch the next case.
- The Dispatcher fetches the next case from the Queue(s) assigned to this CSR.
- The Dispatcher, then, acquires a lock on the selected case in the RA database.
- The Dispatcher also changes the status of the case from OPEN to INPROGRESS, and updates the affected table with the name of the CSR from whose Administration Console instance the request originated.
- The Dispatcher, then, sends the case details back to the Administration Console instance, which then fetches the transactions for the case and displays them on the screen for the CSR.
- The Administration Console instance also sets a Timeout for the displayed case details.This prevents the CSR from opening a case page and then not working on it within the pre-defined time interval. If the current case allocation to the CSR times out, an appropriate message is displayed to the CSR. The case subsequently times out and its status is changed to OPEN.
- If the currently displayed case doesnottimeout and the CSR moves to the next case in the Queue, the case status is changed from INPROGRESS back to OPEN.The CSR can view the next case by clicking theGo To Next Casebutton on their screen.
Expiry Monitor Thread
The Expiry Monitor thread is responsible for escalating cases or marking all the cases that have expired since the last time the thread ran. It wakes up at a much lesser frequency than the Queue Monitor Thread.
This thread works as follows:
- It wakes up at a pre-defined and configurable interval and fetches a list of all cases that meet the following criteria:
- The case is in the OPEN or NEW state.
- The case update time is more than the configured expiration time.
- For all cases that have not been worked upon for the specified threshold duration and that currently belong to queues with Retention PolicyAuto Expire, the thread updates the status as EXPIRED in the RA database. For all cases that have not been worked upon for the specified threshold duration and that currently belong to queues with Retention PolicyAuto Escalate, the thread escalates the cases by adding them to the next higher level queue with IN PROGRESS status.
- The thread goes back to sleep.
Supported Case Management Roles that You Will Use
The Case Management feature supports the following broad categories of roles:
Summary of Case Management Role Privileges, summarizes the privileges available to these roles.
The following figure shows the different case roles and the tasks performed by each role.

Customer Service Representatives (CSRs)
As the name suggests,
Customer Support Representatives
(CSRs) are your organization’s interface with the end user. They are responsible for:Working on Cases
They typically review cases that are automatically allocated to them and work on these cases. When they start working on a case, the case is marked with their name. As a result, the case will not show in another CSR’s screen. However, the Queue Managers can reassign the case to another CSR by assigning another CSR to the Queue.
CSRs can also call end users to confirm the authenticity of a suspect transaction. Their main activities include:
- If required, call the end users to verify if a transaction is fraudulent or not.
- Add users to theException User Listfor a specified duration, based on the user input.The default duration is 10 days, but they can change it as required.
- After reviewing a case, CSRs can update the case. As a result of which, they can change the case status fromIn Progressto one of the following:
- On Hold
- Closed
- They can also take appropriate notes in a free-form field to capture the progress of the investigation.
Handling Customer Calls
At times, the CSRs also handle incoming calls from the end users. In other words, they attend customer calls. For example, a customer might call the Call Center because they see transactions that they did not perform. In such cases, these operators record the input from the customer, if a case for the specified user already exists. If a case does not exist for the customer, then a case is generated automatically.
The input collected by CSRs is used by the Fraud Analyst for analyses.
In this case, the CSRs:
- Handle user calls.
- Record user inputs.They can take appropriate notes in a free-form field to capture the progress of the investigation.
- View recent activities of the user.
- Add users to theException User Listfor a specified duration, based on the user input.The default duration is 10 days, but they can change it as required.
- Search for the transactions by the user in the given time period.
Queue Managers
Queue Managers
(or simply, Supervisors) determine the order in which cases are assigned to the Queue. They can:- Create new Queues and assign cases to one of several Queues for their organization.See How to Create a New Queue for more information about how to create a Queue.
- Manage the Queues for all organizations in their scope.See Case Queues, for more information about Queues.
- Rebuild a Queue.See How to Rebuild a Queue for more information.
- Assign and reassign CSRs to the Queues in their scope.
By default, Queue Managers
cannot
perform the tasks of a Fraud Analyst. However, you can use Custom Roles
to create a new role based on Queue Manager and assign the FA privileges to this role. For more information about how to create custom roles, see "Creating a Custom Role".Fraud Analysts
Fraud Analysts
and
the available filters, such as:- Transactions by the same user in the given time period.
- Transactions from the same user device in the given time period.
- Transactions from the same IP address in the given time period.
Based on their analyses, FAs can then advise the system administrators on fine-tuning RA. In addition, if they suspect a transaction to be suspicious, they can raise a request for CSRs to call the end user and find more details related to the suspect transactions, even if the system had not suspected those transactions previously.
The following list describes the main functions performed by Fraud Analysts:
- They can log in and view the list of transactions in real time.
- They can set a combination of filter conditions to view transactions for all users over a period of time for those matching specific risk status values.
- As part of the investigation, the FA can also search for similar transactions. They can define the filter to detect similarity based on:
- Transactions by the same user in the given time period.
- Transactions from the same user device in the given time period.
- Transactions from the same IP address in the given time period.
- If the transaction set is large, they can also export the data offline and then analyze it.
- If they locate suspicious patterns, they can raise alerts on those transactions for further investigation by the CSRs. The "alerted" transactions are automatically added to the case for the user in question.
Fraud Analysts
cannot
update any cases.Summary of Case Management Role Privileges
The following table summarizes the privileges available to the case roles discussed in the preceding topics.
Privilege
| CSR
| Queue Manager
| Fraud Analyst
|
Manage Inbound Calls | Y | N | N |
Work on Cases | Y | N | N |
Manage Queues | N | Y | N |
Rebuild Queues | N | Y | N |
View Queue Status | N | Y | N |
Analyze Transactions | N | N | Y |
Add User to Exception List | Y | N | N |
Delete User from Exception List | Y | N | N |
Search Cases | N | Y | N |
Decrypt Sensitive Information | N | Y | Y |
Report Privileges
| |||
View Fraud Statistics Report | N | N | Y |
False Positives Report | N | N | Y |
Rule Effectiveness Report | N | N | Y |
Case Activity Report | N | Y | N |
Average Case Life Report | N | Y | N |
Supported Case Management Workflows
This topic covers the workflows for the following phases in the lifecycle of a case:
Case Generation
Typically, cases are created automatically by the system. However, if a case operator manually flags a suspicious transaction for a user, or a Fraud Analyst discovers a suspicious pattern in user transactions, then they can add the suspicious transactions to the case.
A case is generated when:
- The advice for the risk evaluation for a transaction is eitherAlertorDeny.If a case is already open for the user, then this transaction is added to the existing case. You can configure this on the Miscellaneous Configurations page.
- A user contacts your Call Center to dispute a transaction.In this case, the case operator can either refer the disputed transactions for further investigation or can mark the transaction as a fraud. In both the cases, the transaction is automatically added to a case.
- A Fraud Analyst suspects some transactions to be fraudulent (typically, based on patterns detected earlier) and marks them for further investigation.These transactions are then added to the existing case.
Case Queuing
When a case is created and transactions are added to the case, the cases need to be assigned to the Queue that belongs to the organization. In addition, CSRs who can work on these cases must also be assigned to each Queue. The Queue Monitor Thread plays the pivotal role in this case.
See Queue Monitor Thread for detailed information about how this thread queues cases.
Case Assignment
After a case has been queued, it then needs to be dispatched to each CSR’s screen. The Case Dispatcher Module plays the pivotal role in this case.
See Case Dispatcher Module for detailed information about how this thread dispatches cases.
Notes Related to Case Assignment
Some points to remember on this topic are:
- A new case is assigned to a CSR from the organization to which the case belongs.
- The cases are assigned based on their order in the Case Queue. The order criteria can include:
- Next Contact/Action Date
- Number of open transactions in the case
- Age of the case (Date Created)
- How long ago the case was last updated
- Every case is eventually handled by a CSR in an organization.
Case Handling
Cases are handled by the CSRs as follows:
- A new transaction flagged by the FA or a Deny or Increase Authentication advice generated for a transaction creates a new case. The status of the casebeforethe Queue Monitor Thread schedules it isNEW. The Queue Monitor Thread changes it toOPEN, and when a CSR finally views the case, the case status is changed toINPROGRESS.Even before the case is handled by a CSR, more flagged transactions might be added to the case.
- A CSR is automatically assigned to work on the case.
- Contact the user out of band, say by sending an email or by calling them on the specified contact number.
- Based on the ongoing investigation and the results of contacting the end user, the CSR can update the case, as it develops:
- Search for transactions based on a specific time interval.
- During the user interaction, add previously unsuspected transactions to the case.
- Choose resolutions for one or more of the transactions in the case.
- Mark the case for follow up and set theNext Action Date.Typically, theCase Statusof such cases is then updated to eitherINPROGRESSorONHOLD, and the user is contacted by a CSR later.
- Based on user input, add the user to theException User Listfor a specified period of time.
- Resolve the case and change theCase StatustoCLOSED.
- The Queue Managers can also reopen an expired case, if required.
Case Expiry
A case can expire if all of its transactions are not handled within the stipulated amount of time or if there is no activity on the case for a pre-defined time period.
The default case expiry time is 48 hours.
See Expiry Monitor Thread for detailed information about how this thread manages expired cases.
Case Escalation
A case is automatically escalated to the next queue level if the case has not been worked upon for the specified threshold duration and if the case currently belongs to a queue with Retention Policy
Auto Escalate
.See Expiry Monitor Thread for detailed information about how this thread manages expired cases.
Fraud Analysis
The gist of the fraud analysis workflow for transactions by Fraud Analysts is as follows:
- FAs can search for transactions based on criteria, such as Transaction Date, Secondary Authentication Status, Transaction type, Risk Advice and Case Status. For more information, see How to View Transactions Summary:
- All transactions are initially shown in the Transaction Summary view.
- Initially, all transactions have the Case Status ofNew.
- The list of transactions can be exported to a .csv file for processing in Microsoft Excel.
- The FAs can click a case to view its details. For more information, see How to View Case Details.
- The FAs can also search for all transactions that are similar to a case. For more information, see How to View Similar Transactions.
- If they find suspect transactions and potential fraud patterns during their analyses, FAs can mark the transactions for further investigations by CSRs. For more information, see How to Mark Transactions for Further Investigation.