FIX Certification Onboarding Productivity
I've spent the best part of a decade now talking to firms about the nuts-and-bolts of onboarding (or "certifying") customers to financial services APIs, typically speaking the FIX protocol. Time and again I see a starkly different perspective between "the business" and the people who do the job function.
Business folk are - for extremely good reason - focussed on revenue generation, and want to see new customers connect and trade as quickly as possible. They inevitably have a sense of urgency about them, driven largely from the need to hit quarterly revenue targets.
Because this is not their background, however, they often struggle to understand why the process appears to be so convoluted and manual. But most of all, they struggle with the reason behind why it appears to be so hard to predict when customers will go live. If FIX is a simple standard, why does one new customer take a week and the next take 3 months?
The danger of this disconnect is that because business (correctly) consider onboarding as a cost centre and not a revenue centre, they squeeze investment in it as part of across-the-business cost-cutting exercises. Not only does this make the problem worse, but it also means that they need to rely on expensive consulting headcount to handle large projects such as platform upgrades, MiFID II or Brexit changes.
We know that many firms are currently attempting to increase automation across the enterprise. As a non-differentiating service, FIX is often (correctly) highlighted as a function that can benefit from increased automation, and so how far can this go, and what form can it take?
I often find that the easiest way to illustrate the transition that FIX must traverse is to consider the way that physical shops have evolved over the last 100 years.
In the 1920s, most shops were based around the idea of counter-service. Upon entering a shop, I would walk up to a counter and ask a shopkeeper for a particular item. They would retrieve it for me, we would have a nice chat while they rang it up on the till, and off I would go.
During the 1930s and 1940s, shops in the US transitioned into a "self-service" model, with the UK catching up in the 1950s. Shoppers would enter, pick the item they needed off the shelves themselves, and then take it to a check-out to pay.
Bar codes were invented in the 1950s, but it wasn't until the 1980s that they achieve a level of critical mass that allowed greater efficiency in the check-out process; the ability for the cashier to simply scan the barcode instead of typing the product or price into the point of sale machine, thus dramatically reducing check-out times.
As we head into the 2000s, self-service checkouts started to appear alongside traditional, manned check-outs. The idea was that customers feel that time spent queuing is time wasted, and that customers felt self-checkout allowed them to complete the process faster, thereby improving the customer experience. Shops had the extra bonus of savings by reducing check-out staff. (Interestingly, studies have found that self-service checkouts take slightly longer than assisted checkouts as users are less familiar with them, and that frustration from a problem is higher than the frustration caused by queuing for a few minutes!)
More recently, Amazon has started trailing their new 'Go' supermarkets which replaces checkouts completely with very advanced technology to detect what shoppers have selected, charging them offline. In China there are also unmanned shops which operate like super-sized vending machines, allowing shoppers to pay via mobile wallets such as Alipay.
If we are completely honest about where most investment banks and exchanges are today on this scale of evolution illustrated above, I would say that most firms are either still in the "counter-service" mode of the 1920s, or early stages of "self-service". (Before you think to yourself that your firm is more advanced than this, I would add that I would place the majority of Tier 1 banks and even exchanges in this bucket!).
This estimate is based on the fact that FIX onboarding remains an extremely labour-intensive process, with staff required to have a lot of customer interaction in order to reach the desired outcome. I often hear stories of staff needing to be on the phone with customers as they walk through each test in turn - the FIX equivalent of counter service.
Yes, customer interaction is good because it establishes a good working relationship. But too much customer interaction is really a sign of inefficiency that needs to be addressed.
Remember I mentioned that business people are often a little impatient when it comes to FIX? Well, often I hear business folk demanding to move directly from today's counter-based service model directly to Amazon Go's checkout-free service, a demand that aligns with their view that (a) FIX should be simple enough to fully automate, and (b) the easiest way to give predictability to the onboarding time is to simply get out of the way of the customer and let them connect as quickly as they can.
Unfortunately, we don't believe that such a large transition is possible in a single leap. The journey to greater onboarding automation is just that - a journey.
You see, the reason why shops have become more efficient over the years is that they have built incrementally on technical innovations such as the barcode. In terms of FIX onboarding, two necessary foundations are:
The vast majority of firms engaged in FIX today have neither of these foundations in place. In fact, I would estimate that less than 1% have them. And it is impossible to progress up the efficiency chain without these two foundations in place.
Now this isn't a pitch for some magical new API documentation format such as FinSpec or FIX Orchestra, but it is a wake-up call for firms trying to accelerate FIX onboarding -- while you keep your documentation in PDF format, you will never achieve greater efficiency.
Just as shops embraced barcodes to boost efficiency, so too must investment banks, trading venues and software vendors embracing machine-readable documentation if they are to evolve.
I think the answer to this is a caveated yes. The technology is certainly possible to get a long way up the evolution stack towards full client self-certification. The caveat, however, is that for it to be usable firms must undergo a journey themselves and put in place the key building blocks required to make the process work. Failure to do this in a rushed attempt to cut costs (or corners) will almost certainly backfire, and lead to customer dissatisfaction.
The evolutionary path that FixSpec believes firms need to follow to move towards self-certification is one that incrementally delivers benefits at every step:
FixSpec works with firms of all shapes and sizes to improve their efficiency around connectivity. If you are struggling to know how best to get the best short-term return, or how to start your journey to greater efficiency drop us a line or message us at @FixSpec.