With apologies to George Carlin…

So, how might we design a workbasket system – regardless of whether or not our system actually looks like workbaskets, or just uses things like database queries to display logical subsets of the screening matches? Even if we have a entity-centric model (see that earlier post), there is usually significant utility in being able to segment the screened records.

Of course, this list of possible match segmentation is very much firm-dependent… but let’s just say these are possible ways to look at our data:

1. Probably the most generally useful segmentation (and the most frequently implemented) is by processing stage – like New Match, Pending Approval, False Positive Matches, True Matches
2. It is not uncommon to segment by the general data source type – employees, vendors, customers, transactions – and/or the screening method – real-time, batch file processing
3. If multiple business lines are screening and their data is screened separately, these results are not infrequently kept separately within the workflow
4. If multiple geographic regions or records in different languages are screened in the same system, they may be kept separately

From a design standpoint, workbaskets are not the only tool that can be used – and, if not well thought-out, they can lead to operational headaches. 

When one’s screening needs cover a significant number of varied data (e.g. geographies, data types, business lines), keeping them separate can lead to complex naming and organizational challenges. In theory, this apparent complexity can be better managed by alternate means; one could run multiple instances of screening systems for segments of the business that do not or should not be commingled with other segments or staff. For example, even if a screening system can keep employee screening results out of the view of staff who are not supposed to view it by other means, a firm might choose to run that screening physically separate as a business decision and/or to reduce the complexity of workflow functionality.

On the other hand, relying exclusively on capturing every variation in screening results with a large population of workbaskets brings different design challenges. The easier challenge is that many workbaskets can, at any point of time, have no results in them. That complicates the job of reviewing operational dashboards and reports. However, suppressing empty workbaskets – or even reporting them separately largely mitigates that problem 

The harder issue is that, just like empty workbaskets, sparse data (e.g. lots of workbaskets with screening records, but many of them with very few results) complicates reporting and MIS – as well as managing operations. One of my former clients, for example, had 3 business units, each of which had its own instance of workflow – and each of those, despite my firm’s advice otherwise, had over 100 workbaskets each.

Where’s the sweet spot here? My inclination is to minimize the number of workbaskets for the purpose of getting work done, but provide sufficient detail so that staff can prioritize their work  as day-to-day needs dictate, that there is proper separation of duties and visibility control, and that management conducting oversight can retrieve sufficient operational detail for reporting and control needs.

I’ve worked with a number of processing systems over the years, both when I was a payments guy and my longer stint in the sanctions world. And how the work is organized and processed, from the systems I’ve worked on, has fallen into 2 major designs – from what I’ve seen. And I wanted to see – because I’ve only really been exposed to a handful of systems (Accuity’s ComplianceLink, Dow Jones’ SAM and ASAM products, EastNets SIDE SafeWatch and LexisNexis Bridger Insight XG) – whether there was something else out there, and was my categorization even a fair way to look at things.

Yes, let’s discount the fact that AI systems tend to validate our assumptions… but first I asked:

I am familiar with two basic ways of visualizing and accessing work items in sanctions screening.

In one model, all work items are in one collection. Some systems using this model provide filters or database queries to see subsets of the data. Each work item may have multiple attributes, like department or geography, person or role assigned to work the item, and the status of the item. While staff may be able to use a filter or query to see items assigned to them, there is no separate workbasket that one could view in a product’s list of workbaskets, in a vendor-provider MIS function or in vendor-provided reports – although one could use system capabilities to see the corresponding subset of work items.

In the other model, there are separate named workbaskets, either vendor supplied or configured by system administrators. There are typically rules for populating workbaskets when new work items are created, methods for moving items between workbaskets (e.g. when an item is escalated for approval), and workbaskets for holding completed items.

For sanctions screening systems, do their workflow functionality fit roughly into one of these two models? Are there other generalized workflow systems used by sanctions screening systems? If so, please describe in general terms.

and here was the response:

You are absolutely on the right track. The two models you described cover the vast majority of Case Management Systems (CMS) used in sanctions screening today. In industry terms, these are generally distinguished as Queue-Based(your second model) versus Attribute-Based (your first model) workflows.

Shutterstock

Here is a breakdown of how the industry classifies these two models, followed by the “third ways” that are emerging as technology evolves.

1. The Two Standard Models

Model A: The Queue-Based Workflow (Your “Named Workbaskets”)

This is the traditional “Inbox” model found in legacy banking systems and major vendor platforms (like early versions of Fircosoft or Oracle Watchlist Screening).

• How it works: An alert is generated and physically or logically “routed” to a specific container (e.g., “EMEA Level 1 Review,” “High Net Worth Escalations”).
• User Experience: An analyst logs in and sees a folder structure. They enter a folder and “pull” work from it.
• Pros: Clear ownership; easy for managers to visualize backlogs (e.g., “The EMEA basket is overflowing”).
• Cons: Inflexible. Moving items requires specific routing rules or manual transfers. If an analyst is out sick, their personal basket might sit stagnant unless an admin intervenes.

Model B: The Attribute-Based / Pool Workflow (Your “Single Collection”)

This is the modern “Data Lake” or “Flat View” approach, common in newer, agile platforms or custom-built internal tools.

• How it works: All alerts sit in one massive table. “Queues” are virtual—they are simply saved search filters (e.g., WHERE status='Open' AND region='Asia').
• User Experience: The analyst sees a filtered list.
• Pros: Highly flexible. An admin can change a “queue” definition instantly by altering the filter query without moving data rows. It supports “swarming” (many users tackling one view) easily.
• Cons: Danger of “cherry-picking” (analysts skipping difficult items). Risk of collision (two analysts opening the same item) if the system doesn’t handle record locking well.

---

2. Alternative “Generalized” Workflow Systems

While most systems are variations of the two above, there are distinct methodologies that fundamentally change how users interact with work items.

A. The “Get Next” / Push Model (Dynamic Assignment)

This is increasingly common in high-volume environments (like FinTechs or Tier 1 banks) to combat the “cherry-picking” problem inherent in both models above.

• The Concept: The analyst does not see a list of items or a basket at all. They have a single button: “Get Next Case.”
• The Logic: A backend algorithm (often called a “distribution engine”) decides in real-time what the most important item is based on SLA deadlines, risk scores, and the analyst’s specific skill set.
• Difference: It removes the “browse and select” aspect entirely. The workflow is purely algorithmic and priority-driven.

B. Entity-Centric (Profile) Workflow

Traditional screening workflows are Alert-Centric—you review a “hit” (a potential match). This model changes the unit of work to the Customer.

• The Concept: Instead of generating 5 separate work items for 5 different wire transfers made by “John Smith,” the system aggregates them into a single “John Smith Profile” case.
• The Logic: The analyst reviews the relationship, not the transaction. If they clear “John Smith” once, the decision propagates to all associated alerts.
• Difference: The workflow is hierarchical. You don’t work “items” (transactions); you work “entities.” This significantly reduces false positive volumes but requires a much more complex data architecture (often involving Entity Resolution engines).

C. The “Four-Eyes” / State-Machine Model

This is less about where the item sits and more about who has touched it. It is strictly process-enforced.

• The Concept: The item is locked into a rigid state transition diagram (e.g., Draft -> L1 Review -> L2 Review -> Final).
• The Logic: An item cannot physically be seen by an “Approver” until a “Maker” has digitally signed it. It focuses on the separation of duties.
• Difference: In the Queue model, an admin might accidentally drag a file into the “Completed” folder. In a State-Machine model, the system forbids the status change unless the cryptographic logic (User A ≠ User B) is satisfied.

Comparison Table

Feature	Queue-Based	Attribute-Based	“Get Next” (Push)
Visibility	Distinct Folders	Filtered Lists	Single Item View
Analyst Autonomy	High (Select from list)	High (Select from list)	None (System assigns)
Management Focus	Managing Pile Sizes	Managing Query Logic	Managing SLAs & Skills
Best For	Complex, multi-team flows	Agile, flat teams	High-volume operational floors

What do I think of the other models? It depends on what you need out of them. I have no problems with the Push model – if you get some MIS out of what hasn’t been pushed out to a staff member. I’d want to know how many high-value current day payments are waiting, and for how long, and for how much total money, is sitting as I get closer and closer to a currency cutoff.

Again, I have no issues with the entity-centric model – if I can identify higher-priority items. And it would seem it would only bring value to “frequent flyers”. If you’ve got 5 “hits”, as the example goes, I’d assume that the client has actually performed 100s of transactions that day. For a wholesale BtoB environment, that would seem to work – but it seems like the theory of its utility might outweigh its value on a day-to-day basis. But, if someone wants to show me one of these in actual production… can’t really pass judgment quite yet.

Finally, the “four-eyes model”? Does any solution not at least provide the tools to do this? Personally, I am used to being able to restrict either access to or visibility of, items by role or user and/or control the state changes / workflow processing commands by role or user. And, to be perfectly frank, having a workflow system where that sort of restriction isn’t either built-in or configurable is an audit finding waiting to happen.

Full disclosure: In my payments days, I supervised Swiss Bank’s (now UBS) wholesale funds transfer operation. And, for Accuity, a good chunk of my role was consulting with clients on how to configure their workflow setups. Did clients always make the best decisions? uh…. they thought so.

By the way, Gemini asked me if I wanted to show which vendors used which models…

Based on the two models you described and the industry landscape, here is how the major sanctions screening vendors typically align with those workflow styles.

It is important to note a key distinction in this industry: Screening Engines (the math that finds the match) vs. Case Management (the workflow tool where you click “False Positive”).

• Some vendors (like Fircosoft) are famous for the Engine but often feed data into a separate, third-party Workflowtool.
• Others (like Oracle and Nice Actimize) provide massive, all-in-one suites that include both.

1. The Queue-Based Vendors (Your “Named Workbaskets” Model)

These vendors follow the traditional banking compliance structure: hierarchies, rigid ownership, and folder-based views.

• Oracle FCCM (Financial Services Crime and Compliance Management):
  • The Model: Classic Queue-Based.
  • How it works: Oracle is the archetype of the “Inbox” model. It uses distinct “levels” of investigation (e.g., Level 1, Level 2, QA). Administrators configure rigid routing rules (e.g., “If Country = Iran, route to Sanctions Specialist Queue“).
  • User Experience: Analysts log in and see a list of queues they have permission to access. They “checkout” or “assign” items to themselves from these queues.
• Pega (Pegasystems):
  • The Model: Highly Configurable Queue/Process.
  • How it works: While Pega is a BPM (Business Process Management) tool rather than a dedicated screening vendor, it is the underlying “Workflow” engine for many of the world’s largest banks (often sitting on top of a Fircosoft engine).
  • User Experience: It is famous for “Get Next” (push routing) logic but is architected around “Workbaskets” where items sit until a user or robot acts on them.

2. The Attribute-Based Vendors (Your “Single Collection” Model)

These vendors often have a “lighter” or more modern architecture, viewing alerts as a single dataset that you filter dynamically.

• Refinitiv (World-Check One):
  • The Model: Attribute-Based / Filter Driven.
  • How it works: In their native UI, you essentially view a list of all matches. You use facets and filters (like “Group,” “Risk Level,” or “Date”) to slice the data.
  • User Experience: You don’t usually “move” an item from a “Level 1 Folder” to a “Level 2 Folder.” Instead, you change the status attribute from “Open” to “Resolved,” and it disappears from your “Open” filter view.
• Fircosoft (Firco Continuity / Firco Trust):
  • The Model: Hybrid (History of Queues, moving toward Attributes).
  • How it works: Legacy implementations use “decision queues.” However, because Fircosoft is so often integrated via API into a bank’s own custom interface, it is frequently the backend for “Attribute-Based” custom tools.
  • Note: If you use their out-of-the-box UI, it feels more like a list/queue system. If you use them as an engine only, you build the workflow yourself.

3. The Entity-Centric Model (The “Third Way”)

As mentioned, this is the shift from “working alerts” to “working customers.”

• Nice Actimize (WL-X):
  • The Model: Entity-Centric.
  • How it works: Actimize markets this heavily. Instead of a queue of 50 alerts, you might see a queue of 10 Entities.
  • User Experience: When you open a “Case,” you see the customer profile and all their associated alerts (sanctions, negative news, PEPs) in one view. You decision the relationship, not just the transaction line item.
• Quantexa:
  • The Model: Network/Entity-Centric.
  • How it works: They are a newer player (often overlaying legacy engines) that focuses entirely on “Context.” They don’t just show you the match; they build a network graph showing who that person is transacting with.
  • User Experience: The “Workflow” is an investigation of a network graph rather than processing a list of tickets.

4. The “Get Next” / Push Routing Model

This is rare as a default setting in “out of the box” software but is the standard configuration for FinTechs and Neobanksusing these tools.

• Silent Eight / Rippleshot (AI Overlays):
  • The Model: API-driven “Push.”
  • How it works: These are often AI adjudicators that sit on top of Fircosoft or Oracle.
  • User Experience: The AI pre-closes the false positives. The human analyst only sees the complex “gray area” cases, often served up one by one because the volume of “easy” stuff has been removed.

Summary Table

Vendor	Primary Workflow Model	Best For
Oracle FCCM	Queue-Based	Large traditional banks with rigid “Level 1 / Level 2” staffing structures.
Refinitiv (WC1)	Attribute-Based	Compliance teams needing quick, flexible filtering without complex routing logic.
Nice Actimize	Entity-Centric	Teams that want to reduce volume by reviewing “Customers” rather than “Alerts.”
Pega	Queue/Push (Hybrid)	Massive operations that want custom “Get Next” logic to maximize efficiency.

So, you’ve got your matching algorithm and you may have applied some False Positive Reduction (FPR) tools and techniques. But, you still have some matches left that you need to research and make conclusions about. How do you organize and process them? By having some sort of workflow functionality in your screening system, of course.

Workflow involves, at a bare minimum, the following:

• A way of organizing new matched records
• A way of moving records along a path from initial research, to one or more approvers
• A way of, at the very end of the process, organizing items that were false positives (looked like a match, but was not) and true matches

That is a bare-bones list. A more robust screening system should also support:

• Ways to document the research performed and the justification for the decision made
• Ways to notify external parties of actions taken (e.g. for Compliance Officers who only log into the screening system in specific instances)
• Robust real-time MIS dashboards and reporting

Making the system conform to one’s risk management standards also requires a design that can be configured to segment the work (e.g. along geographic or business unit lines), and to control access and visibility of the work.

I will cover all these in subsequent, bite-sized posts. As you may have noticed, this is all me.. no Gemini involved – I’ve had exposure to a lot of workflow systems in my day, both when I was a sanctions nerd and, before then, a wholesale payments nerd.