QuantRule

No-code Risk Decisioning Platform for Bank Fraud Teams

Overview

End-to-end design across four product surfaces — an operator inbox, a performance dashboard, a visual workflow builder, and a versioned publish flow with backtested impact analysis. Plus the design-system foundation that lets the surfaces share one vocabulary.

My role

Product designer, ~2021 — bank fraud-risk decisioning on desktop SaaS. The scope ran across operator dashboards, the workflow builder, the rule editor, the versioned publish flow, and the design system that keeps them coherent.

Problem

Bank fraud and risk teams have to translate business policy into rule logic, evolve those rules as fraud patterns change, and prove the new version of a rule is safer than the one already live — before it ships. In legacy stacks every rule change is an engineering ticket. That makes the team slow, the rules brittle, and the cost of a bad change high enough that people stop changing them.

QuantRule’s bet was that the risk team should be able to build, version, and publish workflows themselves — visually, with rule atoms instead of code, and with a backtest in front of every publish so they can show the bank what the change is actually going to do.

Approach

The operator’s day

The inbox is what an operator opens first. Two trend cards at the top — alerts created, alerts resolved — set the day’s tempo. Tabs for All, Assigned to Me, High Priority, Overdue, Untriaged let the operator filter to what they own. Each row has the workflow that triggered it, the risk score, and the current status. The whole screen earns its keep by being boring: nothing decorative, every column doing work.

Performance — does the system know what it’s doing

Three gauges at the top — auto-decision rate, approval rate, false-positive rate — answer the three questions a risk lead actually asks. How much of this is the system handling on its own. How much are we approving. How often are we wrong about a good customer. The line chart below breaks each segment down by day; the bar chart at the bottom attributes manual-review volume to specific rules, so the noisiest rule is also the obvious one to fix next.

Workflows — versioned, not deleted

Each workflow has a name, a version (V1, V2, V3), an edit history, and a status (Approved / Draft). Editing forks a draft. The live version stays serving traffic until the draft is published. The list is the entry point to the more interesting screens below.

The visual builder

The workflow is a node graph: data lookups (Acuant, Socure, internal DB, CRM), transformations, rule blocks, and a final action. The minimap top-left, zoom controls top-right, and an Edit CTA are the only chrome. Read mode is sparse on purpose. The whole point of the surface is to make a complex decision pipeline visible to a non-engineer.

Rule editor — drag a block, name it, configure it

Edit mode reveals the logic-block palette at the bottom — Ruleset, Internal Model, Internal Database, CRM, vendor lookups, Transformation, Call Workflow, Notifications. The vocabulary matches what the engineering team would write anyway, but the operator never has to know that. Dragging a block onto the canvas opens a name modal — the rule gets an identity before it gets logic, so it’s findable in version history later.

Ruleset panel — inline, not a new page

When the operator opens a configured Basic Rules block, the ruleset expands inline below the graph instead of taking them to a separate page. Each rule shows its atoms — If/Then, Decision Table, Breakout — as small chips on the right. The operator never loses context. The graph is still there above; the rules they’re editing live in the same surface.

Publish — the part that earns trust

The publish flow is a four-step modal: Summary of changes, Impact analysis, Approvals, Deployment. Impact analysis is the one that matters. Side-by-side: how the proposed rule would have decided historical traffic vs. how the prior version actually decided it — approved, rejected, investigated, all three counts. Above the comparison, an orange disclaimer: “Estimates are provided using backtesting, and may not perfectly reflect future performance.” That line is the difference between a backtest people trust and one they ignore.

Customers and profile — the human layer

Customers are who the rules are deciding about. The list view is dense and scannable — Name, Status (Active / Blocked), last update, alert counts, open-alert description. Click into one and you get a customer profile: contact, identity, all the alerts they’ve generated, and an executions log showing which workflows ran for them and what the outcome was. The profile is where an operator goes when a rule isn’t enough and a human has to decide.

Design system — one vocabulary, four surfaces

Patterns documented at the system level: alert/profile cards, button states (primary blue, default, danger, ghost — across default, hover, disabled, loading), status tags (Approved, Reject, Investigate, Draft), rule-atom tags (If/Then, Decision Table, Breakout, New), and the five-tab pattern from the inbox.

The logic-block palette is its own pattern — a search bar, a grid of icon-tagged blocks, and the same blocks documented in three states (default, hover, disabled). This is the vocabulary the workflow builder is built from, and the part of the system that needs to stay coherent as new vendor integrations come online.

Alternatives considered

A form-based rule editor instead of a node graphForms hide how a decision actually flows. A visual node graph makes the pipeline legible to a non-engineer — the whole reason for handing rules to the risk team in the first place.
A simple “are you sure?” publish confirmA blind confirm trains people to publish at random. Putting proposed-vs-prior backtests side by side, with an honest disclaimer about the estimate, is what makes the next version trustworthy.
A full permission system in the MVPTempting, but it would have blown the launch window. Rollout was limited to a small set of users for v1, with the richer permission model deferred — visible version history covered the immediate safety need.

One product, four surfaces

The screens show a coherent system: the same logic-block vocabulary that appears in the design system is what the operator drags in the editor; the version concept in the workflows list is what the publish flow ships; the alerts on the inbox are the same alerts an operator triages in the customer profile. Four surfaces, one product.

Reflection

The single best decision in this design is the backtest in the publish flow. Risk-rule systems live or die on whether the people running them trust the next version more than the current one. A publish flow that puts proposed-vs-prior side by side, with an honest disclaimer about the limits of the estimate, is the difference between a tool people use and one they route around.

The piece I’d push further is the Approvals step inside that same publish flow — only the stepper title is visible in the current screens. Who approves, parallel vs. serial approvers, what happens when one rejects, how an approval escalates past a deadline — all of that is the next thing I’d ship.

What I’d keep. The inline ruleset panel. Most rule editors send you to a modal or a separate page when you start configuring — fine for the first rule, miserable from the second on. Expanding under the graph lets the operator hold the workflow and the rule in the same mental frame.

Pot

Plant Care App with AI Helper