Top 5 challenges faced by firms looking to automate FIX Connectivity

At FixSpec, we talk about automation A LOT.

There is a simple reason for this — we believe that it will become a key competitive factor for trading firms over the next few years with other factors such as latency becoming largely irrelevant for most. Trading services which offer customers a fast, slick API experience will trump those who don’t have their process together and ducks in a row. Firms that really value developer experience will win.

We recently ran a webinar series in which we described where we believe automation can help connectivity teams outpace competition. But in conversations since, we’ve realised that the recurring theme remains in people’s minds. The vision is great, but how do we get there? There is also an element of perpetuating the manual status quo for job preservation…which we find pretty alarming.

For those that are pushing for automation, here are the top 5 challenges faced by the firms that we speak to who are seeking to automate elements of their FIX Connectivity process.

1. What does automation mean in my world?

It may sound obvious, but the word “automation” gets thrown around too often these days to the point that it is now appearing in annual targets. A quick Google search could result in any number of tools that might provide various levels of automation:- from one element of your process, to those that claim to automate the whole thing.

When it comes to trading APIs and customer conformance we need to be especially careful.

Trading APIs are a very niche area, and off-the-shelf “automation” tooling can’t really help tackle any of the domain-specificity of checking API behaviour; at best it can help to smooth some of the project-level tasks around it. And so, if our vision is to create “automated API conformance”, then to solve the whole problem, firms need domain-specific tooling. Firms do not see the value in automating an element of conformance, the tool needs to automate the whole thing or there is no value.

So firms look at building something internally… and many are guilty of looking for quick-win bits of code which automate one tiny element of a process hoping for overall automation. The end result, however, is a patchwork of code which is extremely difficult to maintain and removes much needed flexibility (perhaps you already see this in your own firm). So, where do you start?

2. Documentation

Domain-specific tooling is impossible without a golden source that accurately reflects your trading world. Only then can you effectively implement your tooling, team and processes around that source. We therefore keep coming back to the same conclusion that, if there is any hope of moving to a place of genuine automation, firms need to be investing in consistent machine-readable documents as their golden source.

These become your “Blueprints” and your technical foundations for:

• Automated documentation
• Automated QA
• Automated conformance
• Automated QA test-case generation
• Automated upgrade paths

So we’ve identified a starting point. Where do we go from here?

Instead of simply jumping to the finish-line, it is essential to map out your process today and build out a roadmap of iterative steps to get you to the finish line. We’ve also identified that genuine automation in trading APIs is extremely difficult without a combination of tooling and people. This is really important to objectively identify the most appropriate method, process, or technology.

In the case of automated API testing and conformance, we’ve identified that we need to create an API blueprint. A machine-readable document that is structured, created, and managed in an automated way. Machine-readable documentation is great for adding new layers of automation to your process, but to avoid the need for big-bang, industry-wide adoption of one format over another, it’s important that any documentation you provide is both machine and human-readable. More precisely, we believe that documentation should capture both elements, and be easily convertible into a variety of formats based on context.

For us, this is our FinSpec (JSON) schema, but in the world of trading API connectivity, there are a variety of formats to choose from. Here’s our brief summary:

3. Building a compelling business case

We all know first hand the cycle of finding a tool on the Internet that — on the face of it — sounds great and could help automate a repetitive task or process. But you still need to get the department manager or COO to allocate budget for it (as well as time to embed it). Budget is, of course, extremely difficult to come by, especially when the result is not directly revenue-generating. And that is often where the idea evaporates, and you are back to the day-job of firefighting and manual processes.

Unless you can quantify savings corresponding to the cost, the budget holder will turn you down (and that is before IT security and procurement get their claws into it). But how do you quantify savings when those savings primarily come from people spending less time doing manual, repetitive tasks?

We would be naive if we thought that internal politics played no part in strategic decision making. It’s crucial that everybody in the organisation shares the same strategic direction, which often goes far beyond the benefits listed on paper.

When we look at automating tasks and processes, we often overlook the fact that the end result of well-implemented automation is providing better customer service.

It’s therefore important to put together a business case that considers the end-to-end benefits of automation which extend far beyond tooling taking on manual, repeatable processes.

The question should always be: “how can automation support customers, as well as internal teams?”.

4. Change is hard

And so to the biggest hurdle facing connectivity teams considering automation — how do I maintain the day-to-day tasks of managing customer connectivity, whilst investing time in creating automated processes?

The simple reality is there is a journey to go on. In fact, every challenge we’ve highlighted here is a step of that journey.

Start by identifying these steps in the context of your firm, and allocate small chunks of time to make incremental progress.

Internal teams are continually putting out fires and answering customer queries; FIX onboarding becomes more difficult as a firm evolves, and functionality becomes more complex as you evolve your unique selling proposition. There will always be the consistent elements of onboarding, but there is often a layer on top which is customer-dependent. A combination of customers not supporting everything and the demand for customisations to be made for certain customers. How does this become automated? This can feel like a mountain to climb when there is limited capacity for projects like this.

5. Finding time to take the first step

Always a good place to start is to identify in your mapped out connectivity process the most manual and repetitive tasks. These are the elements that are not customer-specific; these tasks have to be completed for or by every customer during the onboarding process and beyond. For example, every customer has to establish network connectivity and conform through the session layer in FIX certification. FIX onboarders and connectivity managers report that these repetitive tasks often take up as much of their day as the more complex customer questions. These sorts of tasks are quick wins and a good place to start.

Meaningful change cannot happen overnight; this has to be an iterative process.

We have recently been working with a large broker-dealer, who through significant growth both organically and by acquisition, has as a result led to each trading service becoming relatively siloed and sectioned off from each other. The firm’s challenge was to consolidate and create consistency across the business units to promote cross-selling and realise the economies of scale. We have identified that there are several consistent, repetitive processes across the group and bringing all the disparate specs and resources together into one portal removes the need to go through the same process multiple times. Network connectivity, the session layer and some order types are consistent across various specs and these are the quick wins for automation. The added benefit is the ability to cross sell between the various business units.

Management might want significant change overnight but the road to automation has to be iterative. Off the shelf tooling will not solve the whole problem; an iterative approach with the combination of people and domain-specific tooling will provide a far better outcome. By focusing on smaller pieces of the puzzle, you will be able to measure incremental progress and therefore demonstrate to your boss that it is worth investing the time. Take them on the journey in a structured, measurable way.

Sound overwhelming? Don’t worry — we can help walk you through the process.

If you have any comments or questions about automation, or anything else discussed in this post, do drop us a line at happytohelp@fixspec.com.