Fraud Analysts
Monitor suspicious transactions, investigate anomalies, and continuously adjust fraud rules to reduce false positives while maintaining protection.
Case Study
Rule BuilderCustom Fraud Controls Without Code
Project Overview
As a Product Designer at Rapyd, I led the design of the Rule Builder - a tool that enables enterprise clients to create and manage custom fraud-prevention rules without engineering support.
The system allows finance, compliance, and risk teams to define conditions based on transaction amounts, accepted currencies, geographical restrictions, and other transaction parameters. Users can combine conditions and determine whether suspicious activity should be allowed, blocked, or sent for review.
I worked closely with the product manager, backend engineers, and QA throughout the process - from early discovery and rule-logic definition through implementation, testing, and launch.
The challenge was to make complex fraud logic flexible enough for enterprise risk scenarios - without requiring users to think like engineers.
Research Findings
Through stakeholder interviews and product discovery, we identified several recurring friction points across enterprise risk teams. These findings became the foundation for the Rule Builder redesign.
-
01
Delayed fraud detection
Suspicious transactions were only identified after the fact, leading to financial damage and operational delays.
-
02
Lack of customization
Clients couldn't tailor rules to their specific risk appetite, business model, or regional context.
-
03
Technical dependency
Business teams relied heavily on engineers to create or update rules, slowing down response times.
-
04
No visibility into active rules
Teams struggled to track existing rules, understand their logic, or identify ownership and status.
-
05
Conflicting logic
Overlapping or contradictory rules often created inconsistencies in decision-making.
-
06
No version control
Users couldn't test rules in draft mode or roll back to previous versions.
-
07
Permission issues
Anyone could modify rules without granular access control, increasing operational risk.
-
08
Lack of automation
Responses to high-risk activity required manual review, leading to delays in fraud prevention.
-
09
No testing environment
Users had no way to simulate a rule before publishing it to production.
-
10
Missing insights
There was no clear way to measure a rule's effectiveness or track its impact on fraud reduction.
Primary Users
The Rule Builder was designed for several business teams responsible for fraud prevention and operational risk. Although each role had different responsibilities, they all needed a shared interface that balanced flexibility, visibility, and control.
Risk Managers
Define organizational risk policies, establish approval thresholds, and ensure that fraud logic aligns with business objectives across different markets.
Compliance & Operations Teams
Maintain regulatory compliance, monitor rule performance, and coordinate operational workflows without relying on engineering teams for every configuration change.
Research Landscape
Before defining a new interaction model, I reviewed how existing rule builders approached complex conditional logic across different industries.
Although the products served different domains, they revealed recurring interaction patterns, structural limitations, and opportunities to simplify how users create and manage rules.
Despite the variety of approaches, most products were solving the same fundamental challenges: organizing complex logic, preserving readability, and reducing cognitive load. These recurring patterns became the foundation for the next phase of the design process.
Patterns repeat across products. The opportunity was not to reinvent rule builders, but to remove the cognitive friction they all shared.
Design Explorations
Rather than committing to a single interaction model immediately, I explored multiple directions to understand how different visual structures could communicate complex rule logic.
The exploration focused on readability, scalability, and helping non-technical users understand relationships without thinking in code.
Rather than committing to a single interaction pattern, I extracted the strongest principles from each exploration and combined them into a more coherent, scalable system. This process helped shape a solution that balanced flexibility, readability, and long-term maintainability.
Exploration was less about visual styling and more about reducing cognitive load while preserving the flexibility of a powerful rule engine.
Design Principles
Rather than simply exposing technical rule logic, the interface was designed to help business users build complex fraud policies with confidence. Every design decision focused on reducing cognitive load while preserving the flexibility required for enterprise-scale fraud management.
Reduce Complexity
Break complicated rule logic into small, understandable building blocks instead of exposing users to technical syntax.
Make Logic Visible
Users should always understand why a rule behaves the way it does through clear hierarchy, grouping, and readable conditions.
Support Safe Experimentation
Allow users to configure complex scenarios confidently without feeling they might accidentally break existing fraud policies.
Design for Scale
The interface should remain manageable even when organizations create dozens or hundreds of fraud rules over time.
Translating Research into Product Structure
The research and design principles established what users needed, but the next challenge was translating those insights into an interface that business users could understand at a glance. Rather than exposing technical rule engines, the product was organized around a workflow that mirrors how fraud teams naturally think: review existing rules, define conditions, configure actions, and safely manage changes over time.
Rule Library
A centralized list where teams can quickly browse, search, filter, and manage all existing fraud rules.
Visual Rule Builder
Instead of writing logic manually, users build rules using structured conditions that remain readable as complexity grows.
AND / OR Logic
Complex business scenarios can be modeled through nested condition groups while maintaining visual clarity.
Actions
Each rule clearly defines what happens when conditions are met, such as Allow, Block, or Send to Review.
Governance
Rule ownership, status, permissions, and lifecycle help organizations safely manage hundreds of active rules.
Scalability
The architecture supports increasing business complexity without overwhelming users, allowing the product to grow with enterprise customers.
The Final Product
The final product brings together the research insights, design principles, and product structure into a complete system for creating, managing, and maintaining fraud rules at scale.
Designing for first-time users was equally important. Empty states guide users before any rules exist and encourage confident adoption.
Creating Rules Visually
Once the overall product structure was established, the next challenge was enabling users to compose increasingly sophisticated rule logic without exposing technical complexity. The interaction model needed to remain approachable while supporting advanced business scenarios.
Fraud policies often need to reflect thresholds, currencies, geographies, and review decisions at the same time. A visual builder made those relationships easier to scan, adjust, and trust before publishing.
The Rule Builder transforms complex fraud logic into a visual workflow. Users can define conditions, combine AND / OR logic, and move from a simple rule to sophisticated multi-group configurations without writing code.
Users begin with a focused starting point and add conditions progressively, reducing the cognitive load of configuring complex fraud logic all at once.
As business scenarios become more sophisticated, the interface preserves readability through clear grouping, visible relationships, and a hierarchy that makes nested logic easier to understand and maintain.
The interaction was designed to scale in complexity without forcing users to think in technical syntax.
Outcome & Learnings
The Rule Builder gave operations teams a clearer way to configure and maintain fraud policies at scale. By translating complex business logic into a visual workflow, the experience reduced cognitive overhead and created a foundation for future fraud-prevention capabilities without adding operational complexity.
Key Outcomes
-
Successfully launched and adopted by multiple enterprise clients.
-
Enabled business users to configure complex fraud rules without engineering support.
-
Reduced manual fraud review efforts by approximately 30% during the first three months.
-
Increased confidence among Risk, Compliance, and Finance teams through customizable rule logic.
The strongest solution was not the one that exposed the most flexibility - it was the one that made that flexibility understandable, visible, and safe to use.
Key Learnings
-
Visual hierarchy is more important than exposing every available option.
-
Progressive disclosure keeps powerful workflows approachable.
-
Good enterprise UX reduces cognitive effort without reducing flexibility.