Fraud Analysts
Investigated suspicious activity and adjusted rules as fraud patterns changed. They needed to build and test detailed conditions quickly while reducing false positives.
Case Study
Rule Builder:Custom Fraud Controls Without Code
Project Overview
The Rapyd Client Portal was the main platform through which enterprise clients managed their financial products and operations. As the product designer responsible for the portal, I designed the experience from the ground up and owned the Rule Builder from discovery through launch.
I worked closely with Product, Customer Success, backend engineering, QA, and internal fraud experts throughout the process.
Before the Rule Builder, clients who needed to create or change fraud policies contacted Customer Success, and the configuration was handled internally. This created dependency, slowed iteration, and limited clients’ ability to respond as their risk policies changed.
We introduced the Rule Builder as a self-service capability within the Client Portal. It gave fraud, risk, compliance, and operations teams direct control over their policies, allowing them to create, update, test, and restore rules without requesting every change through Rapyd.
Users could define conditions across transaction amounts, currencies, geographies, and other payment attributes, combine them through AND / OR logic, and decide whether matching activity should be allowed, blocked, or sent for review.
The core challenge was to give clients meaningful control over complex fraud policies while making every condition, relationship, action, and change understandable, traceable, and safe to manage.
Research Findings
Conversations with users, Customer Success, product stakeholders, and internal fraud experts revealed four connected problems that limited how enterprise clients managed fraud policies.
-
01
Reactive Fraud Response
Risky activity was often identified too late, while manual processes delayed the response. Teams needed policies that could act consistently as transactions occurred and direct uncertain cases to human review.
-
02
Limited Control and Internal Dependency
Standard configurations could not reflect every client’s business model, regional context, or risk appetite. Clients depended on Rapyd teams to create or update rules, making it difficult to respond independently as risks changed.
-
03
Fragmented Visibility and Governance
Teams lacked a clear view of active rules, their logic, ownership, and possible conflicts. Limited permissions and missing version history also made changes difficult to trace and govern safely.
-
04
Unsafe Testing and Iteration
Users could not confidently evaluate a rule before publishing it or understand how a change might affect transactions. They needed drafts, simulation, visibility into how rules performed, and access to previous versions.
Primary Users
The Rule Builder served several teams involved in fraud prevention and operational risk. Each had different responsibilities, but all needed to understand the same policies, collaborate on changes, and trust what would happen when a rule became active.
Risk Managers
Defined risk policies and approval thresholds across products, regions, and markets. They needed visibility into active rules, ownership, conflicts, and the impact of proposed changes.
Compliance & Operations Teams
Coordinated how rules were reviewed, approved, and updated. They needed clear permissions, status, and history without depending on Rapyd for every configuration change.
Research Landscape
Before defining the interaction model, I reviewed rule builders across fraud prevention, workflow automation, and other products that translate conditional logic into visual interfaces.
I examined how they introduced conditions, represented AND / OR relationships, grouped nested logic, and separated conditions from outcomes.
Familiar patterns made simple rules easy to create, but many interfaces became difficult to scan as complexity increased. This established a clear direction: preserve familiar rule-building patterns while keeping advanced logic readable.
The opportunity was not to reinvent rule builders. It was to make complex logic remain understandable as rules became more powerful.
Design Explorations
I explored several interaction models before defining the final structure. Early concepts placed the Rule Builder inside a modal, allowing users to configure a rule without leaving the Rules Library.
The modal worked for short configurations, but became restrictive as rules grew more complex. Users needed to combine condition groups, review AND / OR relationships, define outcomes, test the logic, and return to earlier decisions. This was not a quick secondary action, but a focused task requiring time and attention.
I moved the experience into a dedicated drill-down workspace. The additional space created a clearer hierarchy, preserved the full rule context, and allowed the workflow to grow without compressing complex logic into a temporary overlay.
Building a fraud rule was not a quick configuration step. It was a complex decision-making workflow.
Design Principles
Four principles guided the interaction model and product structure.
Build Complexity Progressively
Reveal conditions, groups, and advanced options as users need them, rather than presenting the full rule engine upfront.
Keep Logic Visible
Make conditions, AND / OR relationships, groups, and outcomes easy to scan without requiring users to interpret technical syntax.
Make Change Safe
Use drafts, permissions, simulation, and version history to help teams evaluate and manage changes before they affect live transactions.
Design for Operational Scale
Keep ownership, status, and rule-level information clear as organizations add more rules, users, and markets.
Translating Research into Product Structure
I translated the research into five connected parts that supported the complete rule lifecycle: finding an existing policy, creating and testing a rule, publishing it safely, and managing it over time.
Rule Library
A central workspace for searching, filtering, and managing rules, with clear visibility into each rule’s status, owner, and resulting action.
Dedicated Rule Workspace
A full-page environment that kept the rule’s purpose, conditions, logic, and outcome visible throughout the task.
Conditions and Logic
Structured conditions, groups, and visible AND / OR relationships allowed users to model advanced scenarios without writing code.
Outcomes and Validation
Rules connected conditions to a clear outcome: Allow, Block, or Send to Review. Drafts and simulation supported evaluation before publication.
Governance and Lifecycle
Permissions, ownership, status, and version history made changes traceable and safer to manage over time.
The Final Product
The Rule Library became the operational starting point for understanding and managing the client’s fraud policies. It replaced a collection of isolated configurations with a structured view of the rules the client could now control directly.
Managing an Active Rule Landscape
Rules were grouped by their resulting action, such as Allow, Block, or Send to Review. Search, filtering, status, and rule-level information helped teams understand what was active, locate a relevant policy, and open it for review or modification.
Supporting the First Rule
The experience also needed to support clients before they had created any rules. The empty state explained the purpose of the library and provided a clear path to creating the first policy.
The Rule Library turned a growing collection of fraud policies into an understandable system that clients could manage independently.
Creating Rules Visually
After organizing the rule landscape, the next challenge was helping clients create and modify the logic of an individual policy. The builder translated each rule into a clear relationship: when these conditions are met, take this action.
Users could define transaction attributes such as amounts, currencies, and geographies, connect them through AND / OR logic, and choose whether matching activity should be allowed, blocked, or sent for review.
Starting with a Focused Decision
The initial state presented only what users needed to begin. Conditions were added progressively, allowing clients to focus on one decision at a time instead of confronting the full complexity of the rule engine upfront.
Scaling Without Losing the Logic
As rules became more sophisticated, visible groups and explicit AND / OR relationships preserved their structure. The hierarchy helped users understand how conditions were connected, review the resulting action, and return to individual decisions without losing the broader context.
The same workspace could support both simple policies and advanced, multi-group fraud scenarios without requiring clients to think in technical syntax.
Outcome & Learnings
The Rule Builder was launched and adopted by enterprise clients within the Rapyd Client Portal. It shifted fraud-policy management from an internally handled service to a self-service capability that clients could use and update as their needs changed.
Key Outcomes
Enabled fraud, risk, compliance, and operations teams to create and maintain policies without requesting every change through Rapyd.
Connected rule creation, testing, permissions, status, and history in one workflow.
Gave clients clearer visibility and control over active fraud policies.
Created a foundation for managing more rules and increasingly complex scenarios over time.
Key Learnings
The project reinforced that flexibility is valuable only when users can understand the logic they are creating and trust the changes they make.
The interaction model must reflect the depth of the task. A dedicated workspace was more appropriate than a modal for a workflow requiring sustained attention.
Progressive disclosure and visible hierarchy made advanced functionality approachable without limiting experienced users.
Permissions, drafts, simulation, and version history were not secondary administrative features. They were essential to making self-service safe.
The strongest solution was not the one that exposed the most options. It was the one that made complex control understandable, visible, and safe to use.