Kount, an Equifax company · 2025

Rules engine

41.5% adoption of the new policy model and 64.5% task completion for new policies, while platform volume crossed a million transactions a day. Rebuilt Policy Management across three phases so fraud teams could write, segment, and stage rules without treating every change as a production risk.

Role
Lead product designer
Team
6 product leads over the life of the work · engineering · Compliance · Fraud Analysts
Timeframe
2021–2025
Platform
Web · policy configuration

Shipped

Policy Management set views showing the active set, pending changes, and publish path
Active set, pending changes, and a publish path. Staging is the difference between configuration and a leap of faith.
Segment editor in Kount 360 Policy Management showing conditions, tags, and linked segments
Segments group traffic. Policies attach conditions and outcomes. The surface has to make both readable in the same place.

Constraint

A bad policy publishes into live traffic. The problem is not fewer form fields. It is boolean logic an analyst can re-read, plus a path to change policy without betting the day on a single publish.

I was the lead designer on this surface for four years, across a cloud migration and six product leads. It shipped in three phases. Each phase answered a failure mode of the last. Features that made rules easier to write but harder to stage were incomplete.

Decisive moves

Make OR legible

Rule managers could only combine conditions with AND. Common policies became workarounds that were hard to defend later. I started on paper so engineering and product could see how OR changes IF and ELSE before anyone committed a screen.

What shipped was a file-management model. Sets held the slices of traffic. Policies under them could use AND or OR. Scheduling landed in the same pass, so a change could be planned instead of forced live.

Hand-drawn paper wireframes exploring OR logic and nested policy structure
Early structure work for OR logic. The evaluation model had to be right before the UI was worth polishing.

Replace triggers with segments

The next failure was scale of a different kind. Policy Management had to serve multiple event types, and two policy engines had to become one: Login, New Account Opening, and Payments Fraud on one configuration surface.

Triggers were renamed segments. A segment is a named slice of traffic for an event type, with its own linked policies. You define who falls into it and what runs when they do. Policy sets left in this phase, and scheduling got harder without them. Analyst sessions, heatmaps on rule-creation drop-off, and several editor directions followed. Pure drag-and-drop lost to a hybrid that kept power without forcing everyone into a syntax surface.

Stage, then publish

Sets came back with a clearer job. A set is a collection of segments and policies for an event type. Only one set is active per event type. Edits do not go live on save. They land as pending changes, can be compared to the published version, and publish only when someone confirms. Historical versions stay readable and locked. Restore is explicit.

Publish path

  1. 01Segment traffic
  2. 02Attach policies
  3. 03Stage as pending
  4. 04Compare to published
  5. 05Publish

Policy states

StateWhat the analyst sees
Active setThe published collection for that event type. Only one is live.
Pending changesEdits held off traffic until someone compares and publishes.
Version historyPrior publishes, readable and locked. Restore is explicit.

Segments stayed. OR logic stayed. Triggers as a label did not: if analysts could not say what fired, the name was wrong. I had designed pieces of this surface earlier. Deciding which of those decisions still held was part of the job. Public product language on Kount’s support site matches the model that shipped: sets, segments, policies, pending changes, and version history.

Evidence

Three shipped phases that made fraud policy writable and stageable under live traffic.

41.5%
adoption of the new model
64.5%
task completion for new policies

Platform volume moved from roughly 100,000 transactions a day to over a million during this work. Adoption and task completion are from internal measurement after Version 3. Users still called parts of the surface clunky where scope was cut. Stated plainly because the alternative is a cleaner story than the one I lived.

NextAuthorized payment protection