For all of the custodial banking accounts we were allowing users to create, we now needed to design an internal tool for Prime Trust to manage and approve these accounts.
The team for this project consisted of 4 product designers (including myself) and a PM.
Although we designed a comprehensive internal tool that allowed PrimeTrust's compliance offers to manage and approve numerous tasks - AML checks (Anti-Money Laundering checks), CIP checks (Customer Identification Program checks), and disbursement (withdrawal) requests - I am going to specifically focus on the CIP check portion of the app as it was my main focus during the project.
Perhaps the most important function of this internal tool was to allow for PrimeTrust's compliance offers to manage and approve CIP checks. Per the United States government, a Customer Identification Program (CIP) is "...a requirement where financial institutions need to verify the identity of individuals wishing to conduct financial transactions with them and is a provision of the USA Patriot Act".
In order to understand how to best design the user flow and interactions for this process, I first needed to iron out the persona of the compliance officer. I needed to know how they wanted to sort through this information - what were their behaviors, needs, and goals throughout this process?
After user interviews with a few of PrimeTrust's compliance officers, I developed this persona to help guide the design process:
I also used the information gathered during the user interviews to create a task flow to better understand the order of operations a compliance officer will take when conducting CIP checks.
With the user flow and pain points identified, I could now set out in designing the tool. The most interesting pain points I solved were creating a filtering / flagging system to identify accounts needing review, improving communication between compliance officers and account holders, and solving the mess that is "related contacts".
Identifying Priority Accounts (Filtering):
As identified above, the first step in a compliance officer's workflow is to identify pending and rejected accounts, and the errors that caused such status. I wanted to provide a flexible filtering system for the compliance officers to achieve this. While the first step was to provide filtering by account status (approved, pending, rejected), I also provided filters for contact (account holder) type (individual, LLC, S corp, C corp, trust), and finally account location (US and international). The hard part was trying to figure out the best interaction for the user to apply these filters.
Eventually I stumbled upon the most elegant solution of all my explorations - a quick filter button for account status filters (because they were the most used) with the last option being "advanced filters". Selecting this would open a side sheet that would allow a compliance officer to select filters by contact type and location. Finally, these selected filters would generate individual chips at the top of the dashboard that could be toggled on/off via a checkbox, or deleted.
Communication with Account Holder:
Communication is key throughout the account review process. Clients want to know why their account is pending, and compliance officers need to be able to communicate with them effectively within the app.
I first identified the most common CIP errors in account registration through user research, and decided to provide those as selectable note templates for the compliance officer. In addition to this, I wanted to give the option to write a custom message, as well as the ability to upload files. I also wanted to allow for these messages to be invisible to the client, in cases where the CO wants to make a note on the account for their own records. Finally, there would be an activity history tab for the compliance officer to keep track of their past actions on the account.
Once the nuts and bolts of the design were in place, I took the design to high fidelity.
The "Related Contacts" Problem:
The biggest challenge with the CIP check portion of this tool was solving for related contacts - that is, contacts that the account holder has added to the account. Note that an account holder can be a single person or a company (there can be multiple), and these account holders can have up to 15 related contacts. To make things more complicated, each of those related contacts can also have multiple related contacts. So there are actually three levels to this problem:
This three level structure proved challenging. How could we organize all these relationships in a way that made sense? Even if we could get the information organized well enough, how then would a compliance officer be able to smoothly add/edit these three levels of contacts? Through some explorations I realized that a triple nested accordion design would be inefficient at best, and instead found an elegant solution involving a single accordion and a side sheet interaction.
Once I had the overall interaction figured out, I mocked up my screens in high fidelity in Sketch and then went about making a prototype in Principle.
Although this was a smaller scale project, I really enjoyed it because it presented some very challenging problems that I was forced to wrestle with. I also was able to squeeze in some motion design which is always a fun process. It was so rewarding to actually build out custom animations for some of the interaction design patterns I had built, instead of just throwing them into a rapid prototyping tool like Marvel or Invision. It was also very rewarding to work on an app that was solving such a crucial issue for internal users.