Auto Limit Approval & Portfolio Margining
The auto validation and limit approval at point of trade execution
About
One of the most challenging products I worked on was the digitization of price sourcing and trade execution. This involved the integration of a new enterprise SaaS platform that involved mapping and re-engineering existing processes and designing new system features to replace tasks that would have been done manually.
However, along the way there were opportunities for new features that were not in the original design. This is one of them.
The Platform
A SaaS enterprise platform that is intended to automate the price sourcing and trade placement. The intention is to shift the responsibility of sourcing of market prices from trading to sales, providing trading more capacity to manage complex structured trades. The responsibility would be distributed across many users instead of just a few.
My Role
As Product Manager and Owner for the entire multi year initiative, I was responsible for the entire roadmap and timelines.
Specific Challenges
Due to the long timeline, changes in the organisation constantly introduced new priorities that had to be managed and juggled to avoid any adverse impact on the whole initiative.
The vendor selected had minimal experience in dealing with a smaller firm (est. 250 people) and previous platform was based on old architecture.
It was the first time where the firm was integrating this type of platform solution, and the first time for the vendor developing a product based on cloud architecture.
The Journey
Discovery
Being an entirely new platform, the roadmap was never static and many features were requested and prioritized. One common complaint but strangely never scoped as platform feature was the number of loss or failed trades due to insufficient cash in the client account at point of trade execution. This was a common occurrence under the original workflow.
Hypothesis
I posed this question to multiple users across the department
If there was a way to easily check the amount of cash in the client’s account, there would be less instances of missed trades or error trades.
Original Workflow
To understand the workflow better, I organized a mock scenario with participants from Sales, Sales Support, and Risk. I will call them SA, SS and RI respectively.
My point of entry here is where the client has agreed to all trade terms and consented to place the trade
I asked everyone to walk me through the scenarios and the workflow was discovered
Seeing Through The Ambiguity
It was now clear to me that the 2 pain points to solve for were;
2 different applications are required. 1 for trade placement, the other to check the amount of free cash. The application to check for client’s free cash is slow to load and the information was not easily observable.
The time taken the request a limit increase and for the approval to be reflected in the application.
I worked with the team to design a process that will work for us and the unique needs of the organization which essentially removed the lag times and would provide better information on the client’s available free cash.
The Product (Solution)
For the Product Solution, Risk and IT developers were my key partners.
We implemented a data feed between the existing client account application and the platform. However, due to system constraints, this datafeed could only happen 4 times a day.
We then had to design an automated approval workflow where parameters could be set up so that request for margin increases would be automatically approved and the trade can be completed.
To do this, we set up a “Virtual Liability”.
Virtual Liability
This Virtual Liability would be assessed against the client profile and documentation with approval conditions defined.
Virtual Liability =
Max [ (Weighted Average Haircut x Uncollateralized Portfolio value), (Free Cash x Leverage) ]
The system logic when performing trade checks.
Auto Approval
The solution allowed a lot of flexibility according to the specific client profile through the use of the following fields
Leverage Factor: Can be set according to client’s total assets, wealth and payment and trading history
Payment and trading history: Obtained from trading data the new platform captures
Total Assets and Wealth: These are refreshed every 6 months
Weighted Average Haircut value: This is auto calculated by Risk and set weekly.
Effectively, the virtual liability represents in 1 figure what the client’s maximum loanable value when trading on the platform. Additionally, we built in the function to cap the virtual liability according to the client’s preference
Metrics For Success
Error Trades
Number of error trades due to limit breach eliminated
Client Complaints
Client complaints and lost trades decreased
Speed of execution
Time taken to complete trade decreased
Feature Extension
Traditionally, for a given position in stocks and/or options, the margin limit granted to a retail investor is lower than that for a professional trader. The general rational being the retail investor is less capable at managing the risk of the portfolio. With the increasing sophistication level of retail investors and tools available, this gap is rapidly closing.
Portfolio margining is typically based upon overall position risk of the account. It factors in suitable risk hedges in the portfolio thereby allowing for higher margin limits or lowering the required margin.
However, portfolio margining is not permitted for all markets and not all firms have the necessary infrastructure to implement the dynamic stress testing and netting rules.
When faced with these constraints, extending this feature allows for margining on part of the portfolio thereby enabling collateralization on some of the assets owned in a managed account.
The Product (Solution)
We separate a portfolio into 2 sub portfolios
Within Portfolio M, margin is granted based on the issuer of the securities, not the individual securities itself. This maintains consistency with the portfolio risk approach.
*Refer to my other post here on simplifying the issuer concentration
The portfolio margin limit would therefore be
Sub Portfolio M limit = Max [ 0, sum (Weighted Average Haircut per Single Issuer in portfolio) ]
Key Benefits
Flexibility
The margining rules only have to be set up at the issuer level without having to adjust the rules of the portfolio itself
Easier Implementation
Only the sub portfolios and issuer margining rules are needed. There is no need for dynamic stress testing and complex netting rules
Compliance
Margining is on part of a portfolio, there is no breach of regulatory rules
Future Features
With the integration of the monitoring and the platform’s improved data capture, there were so many possibilities, a couple of future ideas that I brainstormed along the way
Systemic look back
We look at client frequency and regularity of trading vs cash flows. Based on defined parameters the platform will automatically increase the lending limits.
Trade lifecycle and cash flow management.
The platform will perform trade lifecycle management and check past cashflows to predict future cashflows.
The platform will then auto raise a limit increase request, roll the loan on same terms, or notify the client.
Client Onboarding
With standardized client documentation, the onboarding can be streamlined and systematically matched against suitable products. Monitoring client activity will also facilitate the recommendation of suitable products in the future.