A More Efficient Stack
Michel Balter, CSO of CameronTec outlines the questions to ask and rules to follow when optimising a bank’s trading architecture.
Recently, we sat down with 30 of our biggest sell-side clients to discuss their trading architecture, pain points, lessons learned from recent years, their concerns for the future and what they are doing to improve their businesses today.
Inefficient architecture is the most common issue we heard about. After buying any technology required to close a deal during the boom years, combined with layers of acquisition and geographic expansion, different systems were not only siloed by asset class, but duplicated across regions and business lines.
Beyond these legacy issues, policies within banks were also responsible. Consider the degree of freedom within teams to determine their FIX infrastructure for example. Large banks never have one FIX provider. This freedom was tolerated because the technology could be on-boarded quickly, but now there are inefficiencies in the architecture. This is a real problem when it comes to basic functions, such as monitoring, efficiently on-boarding clients and testing systems.
Migrations are also a challenge for inefficient systems. The more solutions a firm has, the more migrations it will have. In a chain of 20 solutions, migrating one may require changes to 15 others, which creates potential headaches assuring quality. Addressing these problems takes time, which used to be solved by hiring people but firms can no longer afford that.
Large banks with reduced headcount often focus on day-to-day operations, and the time required to update systems to comply with regulatory changes is exponential as the number of systems increases. Some banks have exited businesses because the cost of maintaining compliant infrastructure is prohibitive.
We have also seen a power shift within banks. The power used to be with IT, but now it is more with
the business after the financial crisis. Banks are spending less, so everything is validated by the business. More and more, IT is sponsored by the business, and the business makes the ultimate decision.
Untangling your system
We advise banks to go through an infrastructure assessment to find their inefficiencies. A common issue our clients identified was that different teams are writing code without notifying other teams. When staff leave the company and a new person takes over the attitude is often ‘if it works, I do not have the time to change it’, because there is no documentation.
The most important decision is to simplify. Best practice in this area is about creating business rules for the entire flow: documentation to ensure the process can be taken care of if someone is not there; making infrastructure easily configurable rather than writing custom rules. Trading desks should shift from writing rules, which hide business intelligence, to customizing via in-built functions.
It is important to work with a partner that provides more than software solutions. A flexible partner should empower banks with best practice and readymade templates so the client can progress to the next level on their own. It is a bad sign when your provider says, ‘you only need to rely on us’. That is not a serious position.
Ultimately, efficiency is about the architecture. The first recommendation is to decouple the front office, market layer and the backbone layer, from any subsystems. There will always be disparate subsystems, but if client connectivity is coupled to a vendor platform, a firm may lose the connectivity via the vendor. As banks consider their regulatory and risk management requirements, decoupling allows a concentrated view across clients and each of their connections.
Asking the right questions
The first questions large brokerages should ask themselves are what are my inefficiencies and how can I better manage them. The reality often is that firms may not know what issues they have. Firms should ask their partners to tell them about their inefficiencies as well as the different approaches to addressing them. The solutions vary widely depending on how quickly a firm is ready, willing and able to implement change.
Another question brokers should ask is what are my peers doing and how has it worked. These provide invaluable insights that would otherwise be difficult to obtain.
In my experience, most firms plan about three years out. They need to plan farther to think what are the challenges of tomorrow and how can they best serve their clients today. Bear in mind, IT staff have two clients: the internal business owners and the external clients, each of whom have very different needs.
Building an architecture that is scalable will allow a broker to meet clients’ needs today and position the firm as a leader of innovative high value services which increases competitiveness.
Take back your stack
Here are four steps to take back your stack.
#1 No shortcuts.
Brokers must assess their existing flows and then translate those existing flows into better processes and architecture to improve efficiency. This process has no shortcuts. If you don’t go into the details of the flows, from the end point at the client connectivity level to the trading and the back office integration, valuable business knowledge may be overlooked.
#2 Integrating business logic into flows.
If business logic is well-integrated, it will greatly increase the effectiveness of risk controls. Many systems employ strong risk solutions, but apply them at the wrong end of the cycle. Order modification after the risk check often does not pass through the risk check again, which may result in a failure. The client can do something they are not allowed to getting both client and broker in trouble with the regulator. Designing business logic into the architecture is very important.
#3 Know your business.
As an external provider we are required to understand our client’s business, and so should the bank’s IT team. It is wrong, when improving efficiency is to only have the IT team in the room. Efficiency is achieved through infrastructure but it begins with knowledge of the clients’ needs, which usually sits with the business and the on-boarding team. The on-boarding team knows what type of business the client wants to do, what testing they have implemented, which type of orders they prefer, etc. Improving architecture should involve the business and IT as well as processes like risk and compliance.
Banks should not underestimate the number of people involved. Occasionally, we see a situation where management wants to do something and fears that the IT will block it, so they drive the change with minimal disclosure. That will not work. The best way to get to an honest solution is to include everyone in the process.
#4 Automate processes.
How can firms best improve efficiency? The most effective answer is the automation of processes and controls. Among our clients, about 70% perform manual FIX testing and 30% use automated testing. The most efficient testing system is a continuous testing service.
The on-boarding process has much that can still be automated. The solution most banks use is a certification utility, which can be locally deployed or accessed via a hosted solution with on-demand testing. The reality is that on-boarding is about much more than just certifying a client’s system.
A number of our clients are automating the creation of business rules specific to each client. In the certification process they test the rule in the broker UAT environment and automatically transfer it into the client’s production environment.
After speaking with many clients and leading brokers, the best way to for banks improve efficiency is to optimize the architecture itself. Only then will they be in a position to go after the next business goal and capture the next wave of growth.
We’d love to hear your feedback on this article. Please click here