Case Study

Rebuilding the Rules Engine for Kount 360

How I redesigned policy management so fraud teams could create and ship rules faster — across three product versions and three changes in product leadership.

Enterprise Product Design  //  Design Leadership  //  UX Architecture

Screenshot of the Equifax Kount 360 policy management interface, showing a list of payment fraud segments, including 'Force Review by Billing Email' and 'Apple private relay.'
Screenshot of the Equifax Kount 360 policy management interface, showing a list of payment fraud segments, including 'Force Review by Billing Email' and 'Apple private relay.'

Roles

Sole Product Designer — research through delivery

Team

Product management, engineering architects, compliance, stakeholders

Timeline

2021–2024, shipped across three versions

Tools

Figma, Jira, Confluence, Heap, Optimal Workshop

Platform

Kount 360 (Equifax)

Outcomes

1M+

The platform scaled from roughly 100,000 transactions a day to over 1,000,000 across the redesign period.

50%

In testing, the "OR" logic and segment model reduced rule-creation steps by 50%

41.5%

Analyst feedback moved from "triggers are confusing" to praise for segments clarifying rule firing; adoption rose to 41.5%.

64.5%

A Task Completion Rate of 64.5% for new policies was achieved .

Project Background

Kount 360 integrates identity verification, payment security, and compliance tools into a unified system. It allows organizations to address threats right from initial customer interactions. The Policy Management feature enables users to define rules, segment traffic, apply logic conditions, and schedule updates. As the sole designer, I managed research, wireframing, mockups, prototyping, and user testing throughout the project.

The work progressed in 3 phases:

Version 1 (2021 - 2023)

  • incorporated "OR" logic for rules, traffic segmentation, and scheduled policy changes.

Version 2 (2023-2024)

  • Added support for multiple event types and merged two legacy code bases by removing policy sets and renaming triggers to segments.

Version 3 (2024-2025)

  • introduced versioning, reintroducing policy sets to support staging updates, enhanced fraud rule control, and groundwork for testing against different data sets.

This evolution addressed needs in sectors like e-commerce and fintech, where rapid policy adjustments are crucial to minimizing losses. The team faced shifts, including three changes in the lead product manager, which influenced collaboration dynamics.

Screenshot shows two different user interfaces side-by-side. The left side is a rules management or fraud control platform, displaying a list of rule sets with some rules named 'RC Test', 'KVS Testing', 'Hold for review', 'phone # test', and others. The right side is a policy management interface, showing details for a policy set named 'Default' with an active status, created on July 24, 2025. It includes segments like 'Force Review by Billing Email' and 'Apple private relay.'
Blurred image of multicolored star-shaped lights against a dark background.
Two people sitting at a white conference table, one person using a smartphone and the other writing on paper near a laptop.

Identifying the Issues

Challenges varied by version. In the first, development moved slowly, with some discrepancies in implementing the intended user experience. The second version involved early research and wireframing, but key discussions excluded design input for months, resulting in a minimum viable product that favored speed over refined usability. For the third, requirements came late, with initial timelines of just two weeks. Scope grew after collaboration, but priorities prevented full user validation. Later, higher-level feedback prompted a redesign, handled partly through team wireframes during an absence, limiting final input to high-fidelity refinements.

Feedback from the legacy platform highlighted several hurdles. Rule setups were often complex, leading to longer task times and lower completion rates. Users struggled with understanding fraud policies, and the absence of features like "OR" logic or versioning increased risks during updates. The aim was to streamline these processes, improve usability, and boost overall efficiency without sacrificing security.

Approach to Design

Flowchart diagram illustrating rules engine hierarchy with color-coded sections for events, set, policies, conditions, versions, and segments, including various interconnected nodes labeled with configuration options, statuses, and attributes.
A hand-drawn wireframe diagram illustrating a user interface with sections for header, content, and sidebar. It includes text labels such as Trigger, Policy, and Condition, with arrows showing interactions like clicking to duplicate or delete items, and notes about filtering or conditional functions.

The process emphasized collaboration and iteration. Stonehouse worked with product managers and engineering architects to define problems using tools like Jira and Confluence. Research involved interviews with internal and external users, plus analytics from Heap and studies via Optimal Workshop.

Hand-drawn sketch of a user interface wireframe for creating a rule set, including sections for trigger conditions, categories, options, and results, with labels for policy creation, breadcrumb navigation, search, and save/cancel buttons.
Screenshot of the Equifax Kount 360 Policy Manager interface displaying various conditions for setting up rules, including distance to billing address, device country, and comparison velocity.
Hand-drawn diagram of a user interface for device rating. The interface includes dropdown menus for 'Omniscore', 'Device Rating', and a numerical score of 36.7. There are sections for conditions with labels 'Decline', 'Review', and 'Approve', each marked with red outlines and error indicators. Blue sections show 'Device' layers with variables and conditions, with checkboxes and buttons, and notes explaining error indicators, color changes, and interaction features.
Flowchart diagram for handling policy updates and emergency procedures. It includes steps like navigating to the policy manager, checking if there is an emergency, activating rule sets, implementing changes, and scheduling check-ins.

Steps included:

  1. Outlining issues with product managers through documentation in Jira and Confluence, supplemented by Optimal Workshop.

  2. Gathering insights from users and data via Heap and Optimal Workshop.

  3. Aligning teams on direction in the product requirements document, resolving feasibility questions.

  4. Developing wireframes in Figma.

  5. Iterating with product and engineering to refine solutions.

  6. Creating high-fidelity mockups and prototypes to illustrate functionality.

  7. Validating designs with users through internal tests, external participants on Optimal Workshop, and Heap data where possible.

  8. Adjusting based on feedback, though time constraints in later versions reduced validation opportunities.

This structured method ensured each version built on prior learnings, adapting to team changes and priorities.

Key Enhancements

Innovations targeted specific user needs:

Version 1 (2021 - 2023)

  • In Version 1, "OR" logic simplified rules, segmentation improved targeting, and scheduling allowed planned changes. These addressed complexity in the legacy system.

Version 2 (2023-2024)

  • Version 2 enabled multiple event types and code base reconciliation. Removing policy sets and using segments streamlined concepts, though it was a business choice that made scheduling more involved to achieve a quick release.

Version 3 (2024-2025)

  • Version 3 added versioning with policy sets, facilitating staged updates and better control. It simplified scheduling as a byproduct and set up future testing capabilities, despite some de-optimization from scope cuts.

These updates made the feature more adaptable, helping teams respond faster to fraud patterns.

Results Achieved

Overall, the redesigns improved policy understanding, task speed, and completion rates, strengthening fraud prevention. Visuals such as paper wireframes, Figma designs, prototypes, and before-after comparisons are available by contacting me directly.

User responses and metrics showed progress:

  • For Version 1, feedback indicated triggers were confusing, but "OR" logic helped reduce rule complexity.

  • Version 2 received praise for segments clarifying triggers, though scheduling felt more complicated without policy sets.

  • In Version 3, adoption hit 41.5 percent, with a 64.5 percent completion rate for new policies. Users noted a clunky feel due to reduced scope.

  • May - 100k transactions per day

  • November - 1M transaction per day

This project demonstrates how iterative design can overcome obstacles to deliver practical improvements in high-stakes tools like Kount 360.