top of page

ACH Rules Redesign for Centrix ETMS

Frame 69.png

BACKGROUND

Overview

Centrix ETMS, a fintech platform intended to prevent check fraud,  offers features (ACH Authorization Rules and Transaction Filter Blocks) where users can create rules to allow or flag suspicious ACH payments if it matches the certain criteria. Users can review any incoming flagged payments. 

​

However these features have risks that make FI’s hesitant to give their users permission to create rules. Additionally, rule creation exists on multiple pages. Overall, our goal is to simplify and add more flexibility to rule creation in Centrix ETMS. 

​

Previously, a redesign for these features was completed in the past as part of a larger design project.  Instead of implementing all the pages from the workflow, we just want to focus on optimizing the ACH rules/Transaction block filter pages.

​

I worked on this project from Feb - May 2024. Designs will be implemented in Q1 of 2025. 

Goals

  • Address or Combine ACH and Transaction Filter Blocks

  • Address Global Rule

  • Align design with appropriate design patterns 

Process

DISCOVER

ANALYZE

  • Create self documenting process for end users

  • Mitigate risks 

  • 4-6 week Development

​

​

​

​

​

​

​

​

​

​

​

​

IDEATE

TEST

DISCOVERY

The Problems

Interviewed stakeholders, who shared user pain points they collected in user groups and client interactions. I reached out to our internal product trainers to understand roadblocks when making rules during the onboarding process. Overall, I compiled a list of reoccurring issues to address:

1

REDUNDANCY INCREASES COGNITIVE LOAD 

Compared to the ACH Authorization Rules page, the Transaction Filter Block page receives little traffic and is usually ignored by financial institutions due to confusion and redundancy. Both pages create rules, one page allows payments while the other flags them. 

2

SECURITY/FRAUD RISK CONCERNS

Users can leave fields like "Company IDs" and "Max Allowable Amount" blank. These fields are crucial to filtering out suspicious ACH payments, so when they're left blank, the user risks allowing all ACH payments to go through. 

3

CONFUSING TERMINOLOGY

Financial Institutions are reluctant to let their clients create their own rules due to risk and confusion/inefficient rules. Fields like "Description" and "Max Allowable Amount" are especially misunderstood. 

4

ADDITIONAL FILTERING NEEDED

Financial Institutions have been requesting more filters to make their rules more accurate/foolproof. 

Flow Analysis

I started by diving into the current flow to create an rule in both ACH Authorization Rules and Transaction Filter Blocks

​

ACH AUTHORIZATION RULES: 01 - CLICK ON PLUS BUTTON

Image 11-2-23 at 11.19 AM (1).jpeg

ACH AUTHORIZATION RULES: 02 - ADD INPUTS/SAVE CHANGES

TRANSACTION FILTER BLOCK: 01- CLICK ON PLUS BUTTON

Image 2-27-24 at 2.34 PM.jpeg

TRANSACTION FILTER BLOCK: 02 - ADD INPUTS/ SAVE CHANGES

Image 2-27-24 at 2.34 PM (1).jpeg

Flow Ideation

I created a user flow  aiming to combining both the transaction filter blocks and ACH authorization rules in to one page. I wanted to focus on deprioritizing transaction Filter blocks because of it's low usage. 

Frame 99.png

SOLUTION

Breakdown

After user testing I put together a high-fidelity mockup of the ACH Rules creation process. Overall, I wanted to reduce cognitive load with a full screen modal and also create a task that was more self documenting. Here are some of the key points/recommendations for the redesign: 

REQUIRE FIELDS FOR MORE INTENTIONAL RULES

Design B.png

2

1

3

1

I renamed "Description" to "Rule title" to increase clarity and required it. Users mentioned having rules without titles made it harder to navigate 

2

I required "Company IDs" because of the risk associated with it being left blank. If left blank, any transaction with any ID might be able to pass through the system without notice. 

3

"Maximum allowable amount" was renamed and also required so users have to be intentional about the amount of money they want to allow through the system before it creates concern. 

CONSOLIDATE RULES/REDUCE AMOUNT OF RULES NEEDED

Design B.png

1

2

1

The "Account ID's include" field will become a multi select as opposed to single select. This will allow users to make one rule apply to multiple/all accounts for a client. Previously, users would have to make the same rule over and over again per account. 

2

Overall, the rule creation page consolidated transaction filter blocks into one page by deprioritizing  the Filter Blocks function and converting it into the "Include all except" options in the "add condition" feature. 

Frame 66.png
Frame 57.png

CONVERSATIONAL FLOW TO GUIDE CLIENTS 

Design B.png

2

1

1

Added a text block documenting the purpose of the "Create ACH Rule" modal. 

2

Renamed the inputs to create a full sentence with the "Authorize transactions if" text on the screen. For example Authorize transactions if "Account ID's include." This helps the user work through the process of setting up a rule by setting up logic statements. 

CHALLENGES

Challenge 1

HOW MUCH SHOULD TRANSACTION FILTERS BE DEPRIORITIZED OR INTEGRATED?

Product was concerned about my workflow deprioritizing filter blocks. They wanted to maintain more of the existing design pattern, but keep it on the same page as the ACH Authorization rules. I then proposed an A/B usability test to get feedback on both types of workflows. 

​

For our usability test, Six participants interacted with two newly designed prototypes to create authorization rules in CentrixETMS. 

DESIGN A

Design B.png

Design A was overwhelmingly preferred during usability tests. Users were confused by or ignored the create exception button underneath the "Company IDs include" input.

DESIGN B

Design A.png

Design B was not preferred during usability tests. Some participants failed to create a separate authorization rule, creating an exception-only rule instead. Participants more likely to leave fields blank (e.g., the“Amount is less than...” field) while creating either rule.

Challenge 2

WITH  A 4-6 WEEK DEVELOPMENT CYCLE HOW MUCH CAN ACTUALLY BE ACHIEVED?

After discussing insights from usability testing and completing a hi-fi mockup, I organized a prioritization exercise with my product owners to rescope the design to fit the projected 4-6 week development cycle.

ACH Rules Redesign MoSCoW Prioritization - MoSoW Priorization Matrix .jpg

From there I created a rescoped design, and I worked  with the developer to check if these proposed solutions are technically feasible.

Rescoped design.png

IMPACT

Enhanced
Functionality

Self documenting software with more safe guards allows the financial institution to trust their clients to complete the workflows on their own with minimal assistance. Additionally, filters are available for users to create rules better suited to their needs. 

Reducing Clutter

Combining the ACH Rules and Transaction Filter Blocks helps reduce the amount of pages in Centrix ETMS. Additionally, updated features allows for consolidation of redundant rules for users. 

Designed by Yasmin Haq in 2024

  • Instagram
  • LinkedIn
bottom of page