By Jim Northey, Principal Consultant and Industry Standards Liaison, Itiviti
All market participants are under enormous pressure to maintain profitability in the face of stagnant trading volumes, sustained record low interest rates, increased regulatory pressure, and stifling competition. No one is immune to these challenges. Venues, buy-sides, sell-sides, service and product providers are all being squeezed. The adoption of advanced automation of heretofore largely manual processes can both future proof trading systems and meet regulatory requirements.
Manual processes surprisingly remain very prevalent today within the financial markets, particularly for fairly standard tasks such as regression testing and client onboarding, both of which are labour intensive and divert critical resources away from adding value elsewhere within the organisation. It also exposes firms to the risk of human error, which can be costly and lead to trading errors and lost business.
Moving towards automation
Testing is an area that is ripe for automation. The supply chain in a trading environment even in SME (Small Medium Enterprises) consists of multiple different computer applications, systems, and networks, often spread across several geographical locations. The effort required to construct test cases that fully exercise the system when one component is changed is prohibitively expensive in terms of labour and time. Further compounding the testing issue are changes by counterparties to their systems that can have an impact on internal systems. For when one piece of the trading infrastructure is upgraded, the whole chain needs to be tested to ensure there are no unintended impacts on up or downstream programs. Every time a trading or order management application is updated – the whole end-to-end flow requires full regression testing. These tests are standard and repetitive. Automating the process allows firms to reduce the number of resources required to focus on testing, at the same time simultaneously expanding the entire testing capability. This is where it helps prevent oversights in scenarios where important components or integrations are left untested or insufficient when updates are rushed to market. Today many sell sides use some tools to automate this process, but in large part remain consumed by time-intensive manual testing – either due to testing tools that lack full automation capabilities, or just don’t provide the full range of functionality.
The move to offshore manual regression testing regimes that started nearly twenty years ago has not resulted in improved testing efficacy. The offshoring of manual testing has simply lowered the price of inadequate testing. Automated testing practices can not only cost less than outsourced manual testing, if techniques such as model based testing and service virtualisation are employed, the effectiveness of testing can dramatically increase. The cost per test case can be orders of magnitudes less expensive. This means that a higher volume of testing can be done.
Another popular technique is the use of the Agile Software practice of Behaviour Driven Development using software testing tools based upon Cucumber. While there is no argument that when building a new application in which requirements are fluid and the solution to a business problem is being discovered, the results are a very narrow thread of testing that do not provide sufficient breadth and depth to fully exercise a distributed system. Behaviour Driven Development and testing tools such as Cucumber and the Gherkin language are important tools, but are insufficient to fully exercise and test complex trading applications.
We have the benefit that our distributed trading applications are usually connected by industry standard messaging protocols (FIX and ISO 20022) and de facto standards from exchanges (Itch and Ouch), and vendors (think of the major market data vendors and EMS APIs). Each of these protocols defines a specific model of behaviour. This predefined system behaviour can enable the use of model based testing. Model based testing using a model of the system under test and automatically permutes possible behaviours of the system not limited by human thought on “how the system should behave”. The permutations generated by model based testing have a much higher likelihood of uncovering unexpected errors and outages that we have come to accept as part of doing business.
Time and cost
It is an error to assume that test script development and execution is the majority of cost in a complex distributed test environment. Much of the time is consumed by configuring the test environment. Even when firms have adopted best practices in the areas of continuous integration, continuous deployment, and DevOps, there is still considerable effort required to configure systems for various testing scenarios. This is where service virtualisation, the ability to emulate behaviour of systems based upon well-defined protocols can provide significant benefit. The learning curve and lack of availability of expertise have limited the use of both model based testing and service virtualisation. A focus on employing model based testing and service virtualisation in very specific domains such as FIX can provide a powerful and readily accessible automated testing environment that can provide an immediate return.
Client onboarding and certification is another business area that is weighed down and compromised by manual processes. Before a new client can start trading, a raft of integration work and certification testing must firstly take place. Connections must be established which are then checked to ensure all systems are effectively communicating. Ideally the client sends a number of different types of test orders to ensure orders will be processed correctly from end to end. Once this has been completed, business can commence.
Approximately 20 percent of customer onboarding is currently automated. And it is not uncommon for this process to take a couple of months from start to finish, and in extreme cases it has taken up to six months. Because the process is so labour intensive, some sell-side firms maintain substantial backlogs of new and existing clients still waiting for connections to trade. This is costing the business.
Client onboarding is a major pain point for many sell-side firms, sapping large teams of internal resources and needlessly blocking potential revenue. And it is not only a problem that exists for new clients. Existing clients also go through the onboarding process each time they start to trade new markets or when the sell-side makes a major system upgrade. Slow customer onboarding time and time again leads to customer frustration. Automating the process removes this client dissatisfaction and importantly closes the revenue gap.
Automating the onboarding process also makes it much easier for a sell-side firm to upgrade the FIX connectivity layer. Let’s say a broker has 1000 clients. During an infrastructure migration, all of these existing clients need to be on-boarded again, and the broker must ensure the ability to route orders is not impacted. The prospect of doing this manually can discourage many firms from performing a valuable upgrade. But if the onboarding process is automated, improving, (and future-proofing) the firm’s own FIX infrastructure, it becomes a much simpler and less daunting task.
While savvy trading firms will always be careful to evaluate technology investment, automating key manual processes that immediately help firms reduce operational costs and shorten time to revenue, while improving customer retention and satisfaction in the long term, needs little consideration. For these are key weapons that future-proof connectivity and system infrastructure, while positioning firms for greater growth and leadership.
With a focus on improving and simplifying existing processes and systems, automation is a first step in reducing overhead, simplifying the process of upgrading, and taking advantage of new technology as it emerges.
To kill two birds with one stone, some may ask ‘how will automation help meet regulatory requirements such as RegSCI and the emerging requirements from ESMA in Europe?’ Building a reporting system for existing manual testing processes to meet regulatory requirements leads to increased costs, time, and resources. Automated systems automatically produce output that can be used to meet reporting requirements with little effort. Taking this a step further using a “fit for purpose” reporting system designed to meet regulatory requirements and you end up with significantly improved testing at a lower cost that can be meet reporting requirements.
We’d love to hear your feedback on this article. Please click here
How Automation Can Future Proof Trading Systems And Meet Regulatory Requirements
