Place records into queues for working by an analyst. Review any current or historic queue record and its comprehensive audit including the triggering record and any subsequent actions and results.
The queue hierarchy is designed to ensure some control over the priority in which records can be placed into queues for operators to work. By working with a queue hierarchy, we ensure records are placed in a queue for review with the correct priority and duplication of work never exists.
A Queue Campaign is used to isolate different fraud-management disciplines; e.g., Transaction Fraud Prevention and Application Fraud Prevention.
Queue Divisions are prioritised department- or team-level grouping of Queue Definitions.
Queue definitions are the physical queue containers that will contain the Queue Records.
When a Queue Record becomes available to be worked, a unique Queue Record is created that can be tracked throughout its life cycle.
Queue Records are never reopened; once closed, they remain closed. In the event that a case is required to 'Reopen,' a new Queue Record is created, which ensures there is an accurate history of queue records being opened, worked and closed. Queue records are not automatically deleted by the system and will be there indefinitely, although a user can force a queue record to be deleted if necessary.
Comprehensive Queue performance reports can thus be constructed, which may include time from availability to start, start to finish and total Queue Record handling time.
Work is presented to analysts by a 'Grab and Lock' mechanism. When an analyst grabs a case, Risk IDS immediately places a lock status on the Queue Record to ensure it is not eligible for another analyst.
Once grabbed, the Queue Record is placed into the user’s session and any subsequent action taken by the user in the Relationship Browser will be evaluated to see if it has any effect on the queue status.
This approach allows a team of analysts to work a queue without the need for an analyst to have an appreciation for the contents of the queue. However, when the analyst has 'grabbed' a case, he has true ownership of it.
Risk IDS ensures when a Queue Record is created, a full picture of the responsible record (e.g., a credit card transaction) is captured and stored, which ensures a queue record can be pinpointed to an exact triggering record and its disposition at the time the Queue Record was created.
When viewing a Queue Record, the Relationship Browser will highlight the exact record that caused the Queue Record to be created.
All Queue Record management is performed via the Relationship Browser as once a Queue Record has been grabbed, it keeps a detailed copy in the session. It will monitor for any changes within the Relationship Browser to see if this will have an implication for the Queue Record. Typically, to manipulate a Queue Record, the analyst adds a memo that will include an Action and Result code. Action and Result codes control the following:
Copyright Risk IDS Ltd.
Risk IDS Limited. UK Registered Company 05026181.
