Translating Rule Logic for Compliance Teams T r a n s l a t i n g R u l e L o g i c f o r C o m p l i a n c e T e a m s

Context

When building our new unified AML risk detection platform, we designed a transaction monitoring tool that enables clients to configure and review detection rules tailored to their risk appetite. One of the core features is the ability for clients to select and activate pre-built rules from a rule directory. Once selected, these rules become part of their configuration and need to be clearly auditable.

Our rule detail page was designed to serve two distinct audiences with different needs. For non-technical users such as compliance managers or risk officers, we provide a descriptive logic block in plain-English explaining what the rule does and how it’s triggered. For technical users like implementation specialists, rule builders, and engineers who configure and customise rule logic, we needed a deeper layer of transparency. These users need to inspect the exact conditions, aggregations, and parameters that drive a rule, without having to read raw DSL code.

It is worth noting that modifying rule logic itself is explicitly out of scope for this feature. The rule detail page is a read-only surface. Rule creation and customisation is handled separately through our AI-powered rule builder. The pseudo-code layer is purely serving inspection and audit purpose.

Approach

Technical users working with our transaction monitoring rules need precise visibility into the underlying logic. While they are comfortable with structured syntax, asking them to parse raw DSL code is inefficient and error-prone, particularly given how deeply nested our rule specifications can become.

To address this, we designed a pseudo-code layer that sits on the rule detail page alongside the plain-English descriptive logic. Rather than replacing the DSL, this layer translates it into a structured, human-readable format that preserves full logical fidelity. The goal was not to simplify for comprehension, but to make complex rule logic scannable, auditable, and immediately actionable for users who already understand what they’re looking at.

Goal

Expose the full underlying logic of each rule in a structured pseudo-code format, enabling technical users to inspect, validate, and build upon rules with precision.

My role

• I led the product design work, collaborating with the product manager for transaction monitoring to define priorities and shape our solution.
• I conducted research as well as usability testing with a group of external testers.
• I worked closely with the engineering team to understand how our rule logic code is currently structured and executed, ensuring the design was grounded in technical reality.

Research

Understanding our users and their workflow

The primary users of the pseudo-code layer are financial crime technology analysts, technical profiles within client organisations who are responsible for configuring, validating, and maintaining transaction monitoring rules. Unlike compliance officers who focus on outcomes, these users need to work directly with rule logic: verifying that a rule behaves exactly as intended, adapting thresholds to their institution’s risk appetite, and ensuring the rule’s conditions hold up under audit scrutiny.

In practice, these users often encounter rules for the first time during onboarding or configuration reviews. Their workflow typically involves cross-referencing a rule’s stated intent against its actual logic by checking that the conditions, aggregation windows, and thresholds align with what their compliance policy requires. Without a clear representation of the underlying logic, this process forces them to either rely on implementation documentation (which can lag behind the actual rule state) or request support from our team, creating unnecessary friction on both sides.

The pseudo-code layer is designed to remove that dependency entirely, giving technical users direct and reliable access to the full rule logic from within the product itself.

Understanding the rule DSL

Our rule logic is stored in a Domain-Specific Language (DSL) that resembles JSON. Each rule is made of a specification block containing nested logical operators (and, or), comparison operators (equals, greater_than, less_than), and typed value references, distinguishing between fields, constants, thresholds, and aggregations.

Aggregations are particularly complex: they define how transactions are counted or summed across time windows, filtered by grouping fields such as customer ID or transaction direction, and parameterised by boolean flags that control whether the current day or current record is included in the calculation. Depending on the rule, these structures can nest several layers deep, resulting in a specification block that is technically precise but practically unreadable without tooling.

Understanding this structure in detail was a prerequisite for designing the pseudo-code. Every design decision (what to surface, what to nest, how to represent types) had to be grounded in what the DSL encodes.

Defining what needs to be exposed

Not all DSL parameters carry equal weight for a technical user reviewing a rule. Some information is essential to understanding the core logic such as the comparison being made, the values involved, the time window in scope. Other parameters are important but secondary (grouping fields, boolean flags for record inclusion), relevant for deep inspection but not needed at a glance.

This distinction shaped the information hierarchy of the pseudo-code. Rather than flattening everything into a single layer, we mapped DSL elements into a clear structure: primary conditions are always visible, while supporting parameters are accessible through progressive disclosure. This keeps the interface scannable for quick validation while preserving full transparency for detailed auditing.

The key object types we identified and needed to represent were:

• Variables: transaction fields and attributes
• Values: split between constants (fixed, non-editable) and thresholds (configurable by the user)
• Logical conditions: and / or operators connecting conditions
• Time durations: aggregation windows with associated boolean parameters
• Grouping fields: filters applied to aggregations
• Aggregations: composite structures combining all of the above

Formula and expression builders

I looked at formula editors in tools like Notion formulas and custom expression builders in low-code platforms. A particularly relevant reference was this case study on designing a custom formula input field.

These tools serve users who are technically literate but not necessarily engineers, presenting logic in a structured format that feels precise without requiring knowledge of a specific language. They commonly use inline chips or tokens to represent distinct components of an expression by distinguishing functions, values, and operators visually while keeping the overall expression linear and readable.

Block-based logic representation

I’ve also explored how products that expose complex rule logic to technical users handle hierarchy, nesting, and logical operators in a readable way.

LaunchDarkly’s targeting rules UI offered a strong real-world product reference. Their if/then rule builder presents conditions as stacked rows, with typed chips distinguishing attributes, operators, and values. Logical connectors between rows are explicit and visually lightweight, and the result is a rule structure that is dense with information but easy to scan linearly.

Twilio Segment’s Audience Builder was another particularly relevant reference. It demonstrates how multi-condition logic can be presented in a human-readable format without sacrificing precision, including nested groups and mixed logical operators. Each condition reads almost like a natural language statement, yet the structure remains strict and auditable.

Together these references shaped how I approached the representation of nested aggregations, one of the most complex elements in our DSL. Rather than flattening everything into a single layer, they reinforced the value of progressive disclosure: a scannable top-level view with the ability to expand into full detail when needed.

High-Fidelity Designs

Complex DSL format to Pseudo-code Objects

To translate the DSL into user-friendly pseudo-code, we first broke down each rule into its fundamental object types, such as fields, thresholds, operators, and aggregations. These elements were then mapped into reusable “chips” with a consistent visual language.

Each chip is colour-coded by type (e.g. purple for fields, orange for thresholds, blue for durations) and prefixed with a simple icon to indicate the data category. This design system not only helps users quickly distinguish components at a glance, but also enables us to standardise the expression of complex rules into a readable structure that feels both technical and approachable.

Integrating grouping fields

In the DSL, many variables were associated with grouping fields, these aren’t always essential for understanding the core logic of a rule, but they are critical for users who need a deeper understanding of how aggregations are applied. To avoid overwhelming users with too much technical detail upfront, I chose not to display these grouping parameters by default. Instead, I added a small counter next to a grouping icon, which displays the full list of grouping fields when clicked. However, I remained cautious that this information might be overlooked by users who need it. Usability testing will be key for validation.

Additional contextual information

From the previous analysis of the DSL, we identified several key parameters, such as whether the current day or record is included in the rule. I considered these details important to display in a secondary layer.

Pseudo-code in-situ

To bring this back into context, this pseudo-code layer was appearing on the rule detail page, alongside the logic description in plain english, and the segment configuration.

Usability Testing

Purpose of the pseudo code and job to be done

Most AML officers already have a clear idea of which rules they want to include in their configurations. Across the industry, transaction monitoring rules tend to share similar names and conventions from one platform to another. Because of this, we didn’t aim to rename or reinvent the existing rules when transitioning from our legacy system to Mesh. When officers browse the rule directory, they can usually identify what a rule does based on its name and short description.

The pseudo code was designed for a different purpose: to support officers who need to dig deeper into the logic behind a rule. These users often have specific compliance or policy requirements and need to verify how a rule behaves at a technical level. The pseudo-code provides that transparency: a clear and structured breakdown of the rule’s logic without requiring them to read raw code.

Usability testing #1 - Pseudo-code comprehension rate

We presented participants with the rule detail page, which included the rule’s name, logic description in plain english, and pseudo-code. Participants were asked to describe in their own words what the rule was doing and how it worked. Internally, we tracked a list of key points we expected them to identify.

The pseudo-code included interactive elements such as tooltips and expandable variables that revealed additional details on hover, while others grouped information behind a click. This allowed us to test both comprehension and interaction patterns at the same time.

Usability testing #2 - Rule evaluation

In this task, users were shown three different rules and asked to select the one that best matched a human-readable description provided in the instructions. The description was intentionally written in plain language rather than in rule logic, to assess how effectively users could interpret the pseudo-code and connect it to real-world intent.

To increase challenge and realism, the three rules were intentionally similar, with subtle differences in logic. Some details were again hidden behind tooltips to test how users explored and navigated layered information.

Outcomes

Both tests achieved a great success rate, confirming that participants could accurately interpret and differentiate rules using the pseudo-code format. Beyond that performance, the sessions opened up dialogue. Half of our testers were existing clients familiar with our legacy platform, and their feedback offered valuable context.

One recurring theme was the complexity of rule variables, for instance names like “Bank payment creditor structure address country”. These long names often made rule logic difficult to read and reconstruct mentally. This highlighted a potential scalability challenge for our pseudo-code representation, especially as rules grow in depth and complexity.

Another key insight was that many of these complex rule structures result from multiple aggregations. Participants suggested that nesting these aggregations by allowing users to expand or collapse them as needed, could provide the best of both worlds: a high-level overview for scanning, and full transparency for deep inspection.

These outcomes validated that the pseudo-code system communicates logic effectively, while also revealing where we need to evolve our representation to better scale with real-world AML complexity.

Key learnings and next steps

This project reinforced how powerful transparency and clarity are when designing for complex logic. Translating a deeply technical DSL into a pseudo-code format that felt approachable to compliance officers required a fine balance between simplification and precision. Through user testing, I learned that users value transparency above everything else and they’re comfortable with technical detail if it’s presented consistently and visually structured.

A key takeaway was that pseudo-code can serve not just as a display layer, but as a communication bridge between engineering, product, and compliance teams. It turned out to be a shared language everyone could understand, discuss, and trust.

Looking ahead, we plan to leverage AI alongside the pseudo-code to automatically generate concise, human-readable summaries of each rule. These will replace the manually written summaries currently used, as they won’t scale once we introduce our self-serve rule builder.

We also see an opportunity to take inspiration from this pseudo-code visual system with its modular blocks and logical object representations, to design our future self-serve rule builder. This would empower users to construct and customise their own detection rules with the same clarity and consistency that the pseudo-code introduced.