Role

UX Designer (Solo)

Organization

Broadcom (CA Technologies)  

Duration

3 months  

2 Personas

Head of Fraud, Fraud Strategist

Dual Interface

Visual blocks + code for authoring

10M+

Transactions visualized  per merchant 

Sankey Flow

Full transaction journey visualized

The Problem

Merchants using the Arcot fraud prevention platform needed visibility into their transaction risk — but the existing tooling was built for technical fraud analysts, not the broader team of fraud managers who owned strategy and outcomes. Two different users, one tool, no distinction between what each needed to see or do.

"Fraud managers needed to understand performance and tune strategy. Fraud analysts needed to write and test rules. These were not the same job — the tool shouldn't treat them the same way."

Two Personas, One Product

Head of Fraud - Strategic decision-maker

Needs high-level KPIs, trend visibility, and ruleset version control. Evaluates fraud mitigation performance across merchant portfolio.    Reads dashboards, not code.

Fraud Strategist - Technical operator

Needs to author, test, and tune fraud rules — including writing custom logic. Works with raw transaction data and rule performance tables. Needs both visual and code-based rule authoring.

Entry Point

The registration screen establishes brand positioning immediately — 'Get True Risk Insight to be Competitive and Win' — setting expectations for a strategic intelligence tool, not just a transaction log.

Dashboard - Two Views

The dashboard serves the Head of Fraud persona. A tab-based multi-merchant architecture lets processors manage Best Buy, Walmart, Patagonia, and Etsy from a single interface. Two views: a grid card summary for at-a-glance status, and a detailed analytics view with trend line, donut charts, and transaction table.

Rule Authoring

THE CORE DESIGN DECISION — DUAL INTERFACE FOR RULE AUTHORING

Fraud rules had to serve two users with completely different technical backgrounds. The Head of Fraud needed to review and activate rules without writing code. The Fraud Strategist needed to author complex conditional logic with full programmatic control.

Decision: A single rule editor with two views — Blocks (visual drag-and-drop programming, accessible to non-technical users) and Code (raw Python-style syntax for technical users). Both views represent the same underlying rule. A user can switch between them on any rule without losing their work. This eliminated the need for separate interfaces or separate tools.

Ruleset Performance

The Ruleset Performance view closes the loop — showing how each rule actually performed across the transaction population. A Sankey flow maps rules to advice outcomes (Allow, Review, Challenge, Deny) through to transaction results (Success, Failure) and fraud classification (Genuine, Unknown, Fraud). Rule-by-rule counts with yesterday/week/2-week comparison enable rapid iteration.

If I revisited this

The dual Blocks/Code interface solved the authoring problem well, but rule testing remained a weak point. Fraud Strategists could write rules but validating them against real historical transaction data required leaving the interface. I'd invest in an inline sandbox — let users test a rule against a sample of past transactions before committing a new version.

The Sankey flow diagram was the most impactful visualisation in the product — merchants immediately understood their transaction funnel from advice through to fraud outcome. I'd make this the lead view on the dashboard rather than the card grid, which front-loads KPIs before users have the context to interpret them.