Sanctions Search

Back to work

Sanctions Search

Cutting manual sanctions screening from hours to minutes, without losing the human check that compliance needs.

👤UX Designer📅2025-20263-4 months
Sanctions Search hero image

Problem

50 tabs, one entity

Screening an entity and its subsidiaries for sanctions meant manually working through the top 50 Google search results for each one - opening every page, downloading it, and annotating anything sanctions-related by hand. It was slow, repetitive, and left room for human error. The operations team behind it handles around 21,000 reviews a year, adding up to roughly 4 million hours spent on manual review - and the load only grows as new reviews come in.

My role

Primary UX designer, brought on to design the MVP before handover to the project team.

Team

1 product owner, 4 data scientists, and 2 software engineers.

Process

Designing around a black box

Three things shaped Sanctions Search, most of them about designing around what we couldn't control.

🎙️

Shadowing, not just interviewing

We started with interviews with team leads to get the shape of the problem, but the people doing the work daily were too stretched for long interviews. So we shadowed them instead - watching them work and narrating their steps in real time.

📦

Designing around a vendor black box

The plan was to build on an open-source model, but a bank-wide AI consolidation meant we had to switch to an already-onboarded vendor tool instead. It was more limited - we couldn't see or control the underlying sources it drew from - so the design had to work within a black box rather than around one we controlled.

🚧

Not every ideal survives the API

One early idea was a split-screen view - results on one side, the source page with the relevant section highlighted on the other. The vendor's API couldn't support it, so it didn't make the MVP.

Outcome

Minutes, not hours

~96%

Estimated reduction in touch time

<5 min

Touch time per review, down from 120 min

Sanctions Search is currently in MVP, being tested ahead of full rollout. Reviewers enter an entity and its ID, and the tool handles the search, match-flagging, and summary - work that used to mean combing through 50 search results by hand.

1

Search

Run a public domain search using the entity's name and ID.

2

Summarise

Summarise the findings, close out false positives, and highlight the true matches.

3

Confirm

Update the sanctions document for confirmation with the client.

Reflection

What a vendor constraint teaches you about advocacy

🔒

Designing around what you can't see

The vendor tool was a black box - we couldn't inspect the sources it searched or tune its logic. Good design here meant shaping the experience around a system we didn't fully control, not fighting to change it.

🗣️

The real users weren't in the room at first

Our early conversations were with people who oversaw the work, not the people doing it. We had to keep pushing to get direct access to the actual reviewers - and that access is what the design was ultimately built on.

🤝

Bring the people on the ground in earlier

If I did this again, I'd get frontline reviewers and the eventual project team involved from day one. Without them early, you're designing blind to what's actually feasible and what their constraints really are.