AML Screening

AML Screening

AML Screening

Simplifying enterprise transaction screening investigations, contributing to over $500k in new ARR

Product Design

Enterprise SaaS

JUMP TO

Overview

Challenge

Research

Decisions

Reflection

Overview

1

Transaction Screening is a critical part of anti-money laundering operations. Analysts investigate payment screening hits to determine whether transactions should be released, blocked or escalated.


Built incrementally over several years, the existing experience fragmented the investigation across multiple views. Analysts spent more time reconstructing evidence than assessing risk, increasing effort at the moment of decision.

Transaction Screening is a critical part of anti-money laundering operations. Analysts investigate payment screening hits to determine whether transactions should be released, blocked or escalated.


Built incrementally over several years, the existing experience fragmented the investigation across multiple views. Analysts spent more time reconstructing evidence than assessing risk, increasing effort at the moment of decision.

Transaction Screening is a critical part of anti-money laundering operations. Analysts investigate payment screening hits to determine whether transactions should be released, blocked or escalated.


Built incrementally over several years, the existing experience fragmented the investigation across multiple views. Analysts spent more time reconstructing evidence than assessing risk, increasing effort at the moment of decision.

Outcomes

$500k+ ARR

$500k+ ARR

Contributed to winning two enterprise customers through demonstrations of the redesigned Transaction Screening experience.

Unified Investigation

Unified Investigation

Redesigned the end-to-end analyst investigation workflow, improving usability, consistency and decision-making.


Scalable Foundation

Scalable Foundation

Established reusable interaction patterns that now underpin future AI-assisted investigation workflows.


Role

Role

I led the end-to-end redesign of the Transaction Screening experience, partnering with Product, Engineering, Data Science and AML subject matter experts from discovery through developer handover. My responsibilities included workflow redesign, interaction design, prototyping, usability testing and design system implementation.

I led the end-to-end redesign of the Transaction Screening experience, partnering with Product, Engineering, Data Science and AML subject matter experts from discovery through developer handover. My responsibilities included workflow redesign, interaction design, prototyping, usability testing and design system implementation.

I led the end-to-end redesign of the Transaction Screening experience, partnering with Product, Engineering, Data Science and AML subject matter experts from discovery through developer handover. My responsibilities included workflow redesign, interaction design, prototyping, usability testing and design system implementation.

The Challenge

2

Fragmented Investigation

Critical evidence was distributed across multiple screens, forcing analysts to reconstruct investigations before they could make a decision.

Critical evidence was distributed across multiple screens, forcing analysts to reconstruct investigations before they could make a decision.

One Workflow, Two Very Different Problems

Transaction Screening had been created by splitting the existing Transaction Monitoring experience.

While this accelerated development, it inherited workflows, terminology and interaction patterns designed for behavioural monitoring rather than live payment screening.

The result was a workflow optimised around system architecture rather than the fast-paced nature of transaction screening investigations.

Repetitive False Positives

Previously resolved false positives repeatedly returned because analysts couldn't easily convert investigation outcomes into reusable allow-list rules.

Understanding the Legacy Experience

3

The analyst investigation journey had evolved around the platform's architecture rather than how investigations naturally progressed.

Resolving an alert meant interpreting technical rule output, completing administrative steps and switching between systems before the investigation could progress.

Mandatory case creation interrupted the workflow

Mandatory case creation interrupted the workflow

Manual task allocation

Manual task allocation

Rule-engine terminology exposed ("USD = False")

Rule-engine terminology exposed ("USD = False")

Investigation required navigating multiple disconnected screens

Investigation required navigating multiple disconnected screens

Critical actions shared identical styling

Critical actions shared identical styling

The workflow prioritised system processes over analyst decision-making, introducing unnecessary friction before any meaningful investigation could begin.

Research Insights

4

Analysts spent more effort locating evidence than evaluating financial crime risk

Analysts spent more effort locating evidence than evaluating financial crime risk

Because evidence was separated by system, analysts spent their time reconstructing the case instead of assessing risk.

Because evidence was separated by system, analysts spent their time reconstructing the case instead of assessing risk.

Existing workflows reflected the underlying system architecture rather than analyst mental models

Existing workflows reflected the underlying system architecture rather than analyst mental models

Users were forced to understand how the platform was built instead of how investigations naturally progressed.

Users were forced to understand how the platform was built instead of how investigations naturally progressed.

Analysts needed confidence before speed

Analysts needed confidence before speed

Speed mattered, but only when users understood why a recommendation was being made.

Speed mattered, but only when users understood why a recommendation was being made.

Key Product Decisions

5

01 Unified Investigation Workspace

01 Catalog and Filter System

I brought the task, its screening hits and supporting evidence into one workspace, so analysts could assess a case from a single point of view.

I brought the task, its screening hits and supporting evidence into one workspace, so analysts could assess a case from a single point of view.

I brought the task, its screening hits and supporting evidence into one workspace, so analysts could assess a case from a single point of view.

  • Clearer task context

  • Highlight the triggered entity

  • Critical transaction details pinned

  • Investigation first

  • Review hits inline

  • Actions adapt to investigation state

Analysts could now investigate, compare and decide from a single workspace, significantly reducing navigation while maintaining investigation context.

Analysts could now investigate, compare and decide from a single workspace, significantly reducing navigation while maintaining investigation context.

Alternatives Considered

Alternatives Considered

We iterated extensively as our understanding of analyst workflows evolved. The investigation layout, transaction summary and information architecture went through multiple iterations. Early concepts grouped screening entities into tabs to improve organisation, but user feedback showed analysts frequently performed bulk actions across entities, making this approach inefficient.

  • Entities organized by tabs

  • TX details displayed in a more artistic way

  • Hits organized by entity

  • Hits in cards

Competitor research initially influenced a card-based presentation for screening hits. However, usability testing revealed this reduced analysts' ability to quickly scan and compare multiple hits—a core workflow during Level 1 investigations. We ultimately moved to a dense, table-based layout that prioritised speed and efficiency.

We explored configurable transaction fields to reduce visual clutter by allowing analysts to choose which attributes were displayed. The feature was ultimately removed, as varying transaction types and inconsistent analyst configurations increased the risk of important information being missed.

oisinmckeever.com

02 Progressive Information Hierarchy

Investigations rarely require every piece of information at once. I prioritised evidence based on analyst workflows, revealing supporting detail only when it became relevant.

  • Review multiple hits seamlessly

  • Expand only when needed

  • Decide without losing context

This reduced visual noise while ensuring analysts could still access supporting evidence when required.

oisinmckeever.com

03 Investigation-Driven Allow Listing

Verified false positives kept returning because the path to create an allow-list rule sat outside the investigation. That separation added friction and made proactive maintenance less likely.

Verified false positives kept returning because the path to create an allow-list rule sat outside the investigation. That separation added friction and made proactive maintenance less likely.

  • Reduce future false positives

  • Create rules in context

  • Prefilled from investigation

I placed allow listing inside the investigation, so a rule could begin from the screening hit already under review.

I placed allow listing inside the investigation, so a rule could begin from the screening hit already under review.

Creating an allow-list rule became a natural extension of the investigation, transforming verified false positives into reusable knowledge without interrupting analyst workflow.

Creating an allow-list rule became a natural extension of the investigation, transforming verified false positives into reusable knowledge without interrupting analyst workflow.

Alternatives Considered

We evaluated a fully centralised allow list management experience outside of investigations. Although suitable for administration, it slowed analyst workflows by forcing them to leave the task, so we adopted a hybrid approach with in-task creation and dedicated admin management.

Reflection & Hindsight

6

The most challenging aspect of this project wasn't simplifying the interface—it was balancing efficiency with analyst confidence. Every decision had to reduce friction without removing the evidence analysts relied on to make defensible decisions. Rather than hiding complexity, the goal became presenting it in a way that reflected how investigations naturally unfolded.


The project also changed how I think about enterprise workflows. Instead of designing around system architecture or backend processes, I focused on designing around user intent. That shift led to interaction patterns that not only improved Transaction Screening but later became the foundation for other AML investigation experiences across the platform.


Looking back, I'd involve less experienced analysts earlier in the validation process. The workflow performed well for experienced investigators, but earlier testing with new users may have identified opportunities to improve onboarding and discoverability before the patterns were adopted more broadly.

03 Investigation-Driven Allow Listing

Analysts repeatedly investigated the same legitimate transactions because creating allow list rules was a separate administrative workflow. Breaking away from the investigation interrupted the analyst's flow and discouraged proactive maintenance.

I integrated allow listing directly into the investigation experience, enabling analysts to create exclusion rules from the current screening hit without leaving the task.

Rather than treating allow listing as a standalone administration feature, it became a natural extension of the investigation process. Analysts could immediately convert a verified false positive into a reusable rule, reducing repeat investigations while maintaining full visibility over the rule being created.

oisinmckeever.com

Reflection

5

The most difficult part of this project wasn't redesigning the interface—it was reducing cognitive load without reducing analyst confidence.


Every design decision balanced speed with trust. Analysts needed enough information to make confident decisions, but not so much that investigations became overwhelming. This project reinforced the importance of designing around user intent rather than underlying system architecture and established patterns that continue to influence the wider platform.

oisinmckeever.com

oisinmckeever.com

oisinmckeever.com

Regulatory Reporting

Data Marketplace

Home

Home