Order Entry pt2:
Advisor Order Blotter
Recap / Project Overview
Piersight would like to let its users submit self directed investment orders.The Order Entry project introduces an end-to-end flow for this, starting from helping the user make their investment decision, through to regulatory compliance checks of submitted orders, to packaging the orders to be sent out to trade.
Although none of our existing clients requested this service, Order Entry was identified as a priority project as it will improve Piersight's market positioning, and open up other priority projects.
Part 2 scope
In part two, we tackle the blotter where all the entered orders are dropped off into. We will design the workflow in which an advisor would triage, review, approve, and send off the orders, as well as the completed trades that come back.
The “Clients”
As with Part 1, the "clients" are an investment dealer company we’ve partnered with for this project. They do not have a business need for an order entry service, although they have shown interest in one. They act in a consultant capacity only, but we’ll be using their fund products for our initial offering. We will also consider their advisors and investors as our end users. For brevity, I will still refer to them as “clients”.
To remain compliant with my NDA and client confidentiality, this case study only showcases wireframes and sketches
Understanding the advisors
What are the advisors "reviewing" anyways?
-
Compliance check: This is to see if the order the investor entered "makes sense". An advisor has a profile on their investors called Know Your Client (KYC), and this profile needs to be updated once a year. It captures information such as the investor's risk tolerance, time horizon, net worth, and so on. If an investor enters a trade that contradicts with their KYC, this is a compliance problem known as a suitability breach.
Example: a low-risk investor is trying to buy a high-risk fund.
-
General order detail check: Sometimes investors may have missed a 0 or a decimal point when entering orders. We have implemented validations in the order entry modal to flag common mistakes, but it is the advisors responsibility to give it one last look.
Pain points, in their own words
We interviewed the clients again to understand their current workflow and pain points, specifically for the advisors that our blotter is for. The following is a summary of the main pain points:
-
Status clarity: There are many steps to get an order ready to be sent off, and it’s easy to lose track of what status an order is in.
-
Quantity of information: An advisor has much more data points they will require for their workflow than an investor, how do we show that cleanly?
-
Handling both outgoing orders and incoming trades gracefully: There will be orders/trades coming in and going out, it can be hard to keep track of what is what.
Rethinking the workflow with a workflow diagram
During our discussion above, we noticed even the advisors were fuzzy on the exact workflow for approving an order. There were actions in their current workflow that the advisors didn’t even realize were distinct “steps” in the process, thus becoming prone to human error (tracks back to the challenge mentioned above about Status Clarity).
An example would be an order needs to be 1) reviewed for regulatory compliance, 2) signed off by an advisor, and then 3) prepared to be sent off. This used to be considered the same step because it could be done in quick succession by the same advisor. However, as the business grows, the some steps might be done by different people, or simply become prone to human error as the quantity of orders increase.
We worked closely with the clients to understand their existing workflow, and then iterated until all the steps were clear.
Outcomes of rethinking the workflow
For the designers:
-
Understand the workflow of an otherwise complicated procedure. This allowed us to identify key insights that determined our design approach (see Design Insight section below)
-
Provide a skeleton in which the interaction design can be based upon
-
Identify where the main screens are, and data points required to show on these main screens
For the clients:
-
Visualize their workflow and identify potential complications and inefficiencies
See below for an excerpt of the workflow diagram ("Original detailed flow diagram"), and a summarized version (TL;DR version).
Design Insights
Through the user interview and workflow diagram exercises, we gained 3 important insights that shaped how we approached the design.
1. Orders require more attention than Trades
While outgoing orders require a lot of attention, advisors don’t actually pay much attention to incoming completed trades. Oftentimes, they might not even look at it until an investor happens to inquire about something, or they need to compare order versus trade details.
There are times when an order and its corresponding completed trade may have mismatching details (in other words, you didn't get exactly what you ordered). For this reason, the two should be considered separate entities, even though they originated from the same order. The advisor may want to compare the two in a process called reconciliation.
Outcome
We have decided to divide the blotter into 2, the order blotter for outgoing orders, and trade blotter for inbound completed trades. As the advisor does not need to review completed trades on a day to day basis, splitting it out avoids cluttering the UI. This also addresses the challenge of being able to handle both outgoing orders and incoming trades gracefully.
2. The advisors know their investors and funds like the back of their hands (most of the time)
One of the most important job to be done in this workflow is for the advisor to verify the suitability of the order. If an investor with low risk tolerance submits an order for a high risk fund, this is considered a suitability breach. Oftentimes, an advisor is knows both their investors and funds so well, they can tell if there's a breach by just seeing the investor name, fund name, and maybe some high level order information.
Outcome
-
The workflow should have both a flow for detailed suitability review, but also a concise suitability review for advisors that know both their products and their clients well.
-
When returning orders to investors due to reasons such as suitability breach, we should let them know why their order has been returned via a messaging functionality.
3. Breaches can be ignored
Some suitability breaches are acceptable, thus a suitability breach should not be considered a hard stop validation. Pushing an order through despite a suitability breach is called overriding. There should still be a way to track if a breach has been knowingly overridden for audit and liability reasons.
Outcome
-
Avoid hard stops where applicable.
-
Include an audit trail type of feature to keep track of status transitions, especially if a stop has been bypassed.
-
Include an additional check to ensure advisors acknowledge overriding .
The Design
The blotter will be divided into the Order Blotter and the Trade Blotter. Each blotter will be further divided into a main list and a details page.
Below is a high level of how the Order Blotter flows through the Suitability Check workflow.
The Trade Blotter follows a similar flow (more details in Trade Blotter UI section)
Main Order Blotter UI
The Advisor order blotter is a simple paginated table with additional filter controls to provide additional control.
From here, a few actions are offered
-
Multiple options to help push orders to the next status or return the order.
-
Options Menu provides actions to push the order to the next status, or return a problematic order back to the investor. You may also access the Order Details page for this particular order from here.
-
Submit a new order on behalf of the investor. The advisor’s order entry modal is similar to the investor’s, but with more options specific to their responsibility.
Some design choices to note
Order Details Page
This page consists of cards that list both order details and investor profile information. The main job to be done in the details page would be to review both the investor and order submitted in much more granular detail, then push the order status forward (or return) accordingly.
The cards found on this page are as following, in the order they appear:
Order Status:
Tracks the who, what, when, why of any order status transitions. Colours used in the statuses in the card matches with the colours of the status icons used in the main UI page.
Order Summary:
Surfaces the details of the order they entered.
Suitability check:
Surfaces the investor’s KYC information, pulled from their Piersight CRM profile. This, in combination with the advisor’s understanding of the fund, can determine the suitability of the order submitted with the investor. If additional information is needed, the card offers a link to the investor’s CRM profile, or to download the fund fact sheet.
Comments:
Advisor may leave comments only visible to other advisors on this particular order. There are 2 ways to enter comments. The first is by navigating to this card and entering a comment. The 2nd is whenever an order’s status gets pushed, a modal with prompt the advisor to leave a comment, which ends up in this card. The benefit of leaving comments include
-
Provide another form of audit trail to “cover your bases”.
-
Offer a way to leave contextual notes tied to a specific order. Useful for orders that may pass through multiple advisors
Trade Blotter UI
Accessed from the sidebar, the trade blotter and trade detail page’s UI will look extremely similar to the order blotter. The differences are
-
The blotter only shows completed trades
-
In the details page, the order status and order summary card is replaced by the trade status and trade summary card. As its name implies, the trade variant of the cards surface trade related information.
The trade blotter accomplishes a very vital task, which is keeping the order blotter from being cluttered up by completed trades.
User Acceptance Testing
Once development was completed and tested, we provided a version to the clients for testing. The following are feedback that eventually changed our design:
Changing the MVP scope, just a bit
After UAT, the clients decided they would like to alter the scope of the MVP slightly. They were not fully comfortable with the automated placing of outgoing orders, and automatic execution of completed trades. In other words, they would like to manually verify all outgoing orders before they leave our platform, and verify incoming completed trades before they reenter. This would be temporary until they become more familiar with the order entry workflow.
How it works today. All orders are entered into a CSV, and dropped into an FTP folder designated by the back office. Likewise, completed trades are dropped into an FTP to be picked up by the advisors afterwards. Order Entry’s automation is just the populating and dropping off of the CSV file in the FTP, and picking it up again afterwards.
Approach:
The temporary compromise was instead of directly sending the orders to the back office, we exported the CSV to a separate FTP location, only accessible to the clients. After reviewing, they may submit the CSV to the back office's FTP themselves. Similarly, once they picked up executed trade confirmations from the back office FTP, they may manually enter it into the trade blotter.
Despite the approval of this compromise, internally, we discussed about whether there were underlying UX problems that lead to distrusting the system. Maybe it was simply that the clients would like to ease into a new workflow that revamps their entire business operations? We asked ourselves questions such as are we missing some sort of final sign off? What is it about reading through an CSV that's preferred over seeing the same information in the UI?
We concluded that additional research and requirements gathering was required, but it should be a priority for phase 2, not the MVP.
Launch
After launching, the clients were able to use the system and submit orders successfully via both the investor and advisor side.
The clients reported that the order blotter was received well and gave advisors confidence that there were validations in place to mitigate human error. Investors also reported that the information clarity was appreciated and helpful. They have continued to use the order entry service at a limited capacity.
Internally, we accomplished our most important goal of adding the missing puzzle piece to Piersight’s product offering. In addition to bolstering our market positioning, TFS was also able to begin working on priorities such as:
-
Adding to Piersight’s fund accounting and portfolio management services, with a reconciliation tool and a fund modelling tool as strong candidates.
-
Enhancing existing services. For example, the order entry tool allows a lot of data collected in the CRM tool to have a downstream use cases.
Next steps
-
Automated compliance/suitability checks (by connecting with CRM)
-
Implement an import functionality so a user doesn’t have to manually enter trade details into the system (create fund modelling system for bulk order entry)
-
Implement a reconciliation function to automatically compare any differences between the executed order and completed trade (build trade reconciliation service)
-
Implement better table functionality. The table could use additional QoL features such as sorting, column rearranging and customizations like that.
What I've learned
Design:
-
Not holding back: A recurring theme from our UAT was that we didn’t push some QoL features enough. For example, we provided some shortcuts to let advisors push statuses quickly, but we held back on giving them the “bulk push” option which they eventually asked for.
-
Flow diagrams are valuable: Even the clients were unsure about how their current internal flow worked, so a flow diagram to get everyone on the same page was key to getting this project to the finish line.
Business:
-
“Should not” versus “cannot”: I have to admit I was a bit caught off guard by how contentious the discussion about the hard and soft validations were. There were many debates about whether the system should let an advisor knowingly incur compliance risks (example: push through an order that failed a compliance check without leaving an audit trail). Should the system be the enforcer of ideal, best practices, or should it be up to the end user’s discretion? Ultimately, it will be a case by case consideration, but I will note to bring this topic up earlier in the design process.