The structured, the nimble, and the delegator.

A tale of data from the BrokerTec migration to CME.

Measuring the size of the BrokerTec migration to CME Globex by either trading volumes, market participants, or lines of source code impacted, this was an industry-wide initiative with high stakes and thousands of actors involved.

At ION, the measure of the importance of the initiative extends to the number of ION customers impacted and the activities we helped them perform from late 2019 until February 2021.

As the repeated use of the word “measure” suggests, in this post, we used data to assess readiness, specifically for the go-live of the EU and US repo platforms. It’s worth highlighting that while the CME platform is the same for bonds and repos, repo trading has additional technical requirements.

Taking support inquiries as a proxy helps join dots to spot emerging patterns and lessons that apply in a wider context so that dealers, markets, and vendors can improve the way they share and prepare in the future.

We started by looking backward, defining as ready those ION clients that didn’t have critical or serious problems in the first week.

The long march to go-live

First, let’s look at the overall picture. The distribution of tickets across all ION repo clients were for each month from January 2020 to January 2021 we can see how the tickets received by ION were split in percentage across three categories:

  • Planning inquiries
  • Documentation inquiries
  • Incidents (anything related to unexpected software behaviors)

The high-level trajectory is clear:

  • Firms tended to first understand when they needed to test (planning inquiries, in blue), then focused on assessing the changes (documentation inquiries, in grey), and tested all the flows (incidents, in green)
  • The increasing percentage of incidents shows how testing started in September (at the time the go live was planned for 16-Nov in EU and 7-Dec in the US)
  • The continued flow of any type of tickets proves that the migration was a priority for around 6 months
  • The stable trajectory of incidents from July to the go-live with a pause around Christmas (see the dip in December?) implies that immediately prior to the rescheduled go-live significant testing was still to be completed

Did clients that fit our definition of ready have the same trajectory?

According to our definition of ‘ready’, we identified three different categories of clients, let’s call them “structured, “nimble” and “delegators”.

 

Client A – the structured

  • They’re a large organization
  • That trade in EU and the US with a setup for multiple legal entities in each region
  • With a strict upgrade policy and the need to coordinate changes with multiple teams

They

  • Had as many questions as functional incidents, although they front loaded the preparation – see how over time documentation inquiries were gradually replaced by incidents
  • Started preparing in September, and then had a pause in December
  • Upgraded to a subset of new ION releases, in some cases delaying the rollout of fixes or enhancements

 

Client B – the nimble

  • They have a small footprint setup and trade in a single region
  • They can quickly do changes to the network and the software

They

  • Mostly raised tickets on the back of testing rather than documentation inquiries
  • Started relatively close to the go-live, and then had peaks of activity when it started getting closer
  • They upgraded to most of the new versions ION released

Compared to the average client, they started preparing and testing later

 

Client C – the delegator

  • The software is hosted and managed by ION
  • They have a global setup with desks operating both in EU and in the US
  • The upgrade process is executed by ION

ION

  • Managed the entire project for them
  • Participated in all mock trading sessions, with a test plan tailored to their setup
  • Performed upgrades agreed based on a joint risk assessment of the changes to be rolled out, and by default always using the latest version of the ION software

The last rush

The chart below shows a zoom in on the functional incidents raised since January across all ION clients, with a breakdown by type:

  • Third-party errors (e.g. network problems, market configuration, or functional incidents)
  • User or configuration errors
  • ION incidents

Looking at the type of tickets is useful to link the problems to their root cause, and assess which ones could have been avoided, especially those that resulted in temporary disruptions that affected the business once the new BrokerTec platforms went live.

See the proportion of blue and grey areas in the chart?
It shows that starting from when the EU go-live was approaching and the number of requests for help ramped up, most tickets were due to user/configuration errors, followed by third-party incidents and, third, ION software incidents.

While that’s the picture for all ION clients, did they all have the same trajectory and impact?

How did clients A (the structured), B (the nimble), and C (the delegator) go?

Among the three of them, at the time of the EU go-live they reported a fraction of the problems – especially user and configuration errors, and on go-live only had the same third-party problems that affected ION and non-ION clients:

The implications are clear: they did avoid some types of problems (see the smaller grey areas for user errors?), and especially when close to go live they had fewer problems and therefore limited disruption compared to the others.

Considerations

A, B and C have major differences in terms of setup, ION knowledge, and internal processes.

What their paths show is that what really made a difference is a tailored balance between planning and agility: good preparation solved some problems up front, while reactivity helped or compensated for those that weren’t planned, or couldn’t be planned.

Good coordination between all the actors (a client’s teams, ION, the market) was key in all cases.

C, having a setup hosted and managed by ION, benefited the most from delegating to ION almost everything, which greatly simplified the interactions with the market and allowed them to focus on the business UAT.

While much of the focus on data analysis and automation is about adding business value and functionality, a vital element remains system monitoring and proactive support. At ION we’re automating this.

Anvil product logo icon

Learn more about our solutions

Our clients use a tailored combination of ION standard products and services that cover real-time trading checks, automated testing, annual stress-testing and reports, and smart safety monitoring.