The path to STP in primary equity issuance

In the secondary market, you can place and execute an order in a fraction of a second using fully automated processes and systems.

In stark contrast, entering an order indication needs several manual steps before an issuing client receives it. (We will use the term order indication to distinguish from secondary market orders, as order indications can typically be amended or cancelled until the book of demand closes)

This is both hugely inefficient and error prone. In this paper we will set out the current state-of play and our views on why this needs to be addressed and what Primary Portal is doing to contribute to an STP solution.

The process is labour intensive as it requires a lot of manual rekeying. This is compounded by the duplicative nature of the industry as there can be many banks in a deal syndicate. Furthermore, order indications will sometimes be resubmitted several times over the course of a transaction, as the deal parameters and price guidance change over the course of the transaction.

The current modus operandi is very error prone. The combination of many counterparts exchanging several iterations of order indications invariably leads to many mistakes. Unfortunately, it is only too common for banks to end up with very different indications from the same asset manager by the time the books have closed.

Increased focus from regulators globally is highlighting the current lack of accountability and record keeping in capital markets communications. At the end of a transaction, the banks and asset managers will increasingly need to record all interactions to justify investment and allocation decision and to show compliance with all regulatory requirements. In the absence of good systems this can be both very laborious and expensive (in terms of fines).

The key reason that the problem exists is that in the primary issuance space, the OEMS systems are not interoperable with banks’ different bookbuilding systems. It is hard to fathom that for all the billions of tech dollars spent on both asset managers’ and banks’ systems, a solution has not yet emerged.

The reason for this is that this is a classic Collective Action Problem, where individual asset managers and individual banks are not incentivised and not able to create a solution for the wider industry. It requires a large portion of banks and asset managers to actively contribute towards a solution that benefits them all.

Previous attempts have been undertaken, notably in the mid-2010’s when a group of buyside firms and banks pushed the two incumbent bookbuilding providers (Ipreo and Dealogic) to create the ability to accept order indications directly from the buyside. This failed, in our opinion, as the solution required agreement from too many participants and was not a ‘systems agnostic’ solution.

The realisation of STP will require two sets of integrations, one into OEMS systems and the other into bookbuilding systems, with a facilitating layer in between. Our view is that decoupling the integrations is the approach that will progress STP. Asset managers and brokers can independently implement functions in phases and at a time suitable for each of them. Previous attempts failed when players in the industry all had to move at the same time. Our approach creates value for each participant independently of when others move.

Any solution must be systems agnostic. There is no single technology solution. We strongly believe that each bank and asset manager will create a digital tapestry of internal and external systems to meet their capital markets technology requirements and that these systems will be
entirely interoperable.

In effect, we are creating a ‘decentralized protocol’ that will allow traders to use their OEMS systems to submit an order indication to the syndicate members in the deal irrespective of bookbuilding systems they are using.

The Primary Portal solution aims to tackle the challenges above, namely decoupling broker and asset manager adoption and remaining systems agnostic. Our objective is to let the buyside take advantage of entering an order indication however they choose (over Primary Portal’s interface (web-UI) or via an OEMS integration) and pass that indication on to all desired banks, regardless of how each bank chooses to consume the indication.

Our strategy has 3 key pillars:
A. Primary Portal UI
B. Integrations into OEMS using the FIX protocol
C. Integrations into bookbuilding systems

A) Primary Portal UI
Primary Portal’s web-based order indication entry is already up and running for both brokers and asset managers. Order indications can be placed in a more efficient way over the UI as the buyside input the indication only once (instead of sending separate messages to each bank). The order indication is then transmitted to the selected banks on the syndicate. This information is passed to syndicate bankers as well as to the sales trading counterparts as selected by the buyside trader.

B) Integrations into OEMS using FIX Protocols
Primary Portal’s FIX engine can be integrated into the existing buyside OEMS workflow. Buyside clients receive FIX IOI messages from Primary Portal on deals available for order submission. The buyside can use their OEMS to transmit a New Order-Single message back to Primary Portal using the agreed FIX schema. Primary Portal’s platform then automatically ‘translates’ and unpacks this order indication for onward transmission to each of the banks selected by the trader. Each of the targeted banks retrieve the order indication in the most suitable way to them: by way of direct message to a sales trader, via Primary Portal’s sellside UI, or over an API
integration to the bank’s bookbuild system.

C) Integration s into bookbuilding systems
Once the buyside have submitted their order indication via Primary Portal, the banks have multiple ways of retrieving the indication and entering it into their bookbuilding system. For banks to benefit from immediate visibility of the order indication, and to eliminate rekeying risk, Primary Portal’s API allows integrating order indications directly into their bookbuilding systems. This integration is systems agnostic, meaning banks with proprietary systems can connect the API directly into their own software, or leverage an integration facilitated by one of the incumbent bookbuilding system providers.

For buyside OEMS to correctly cope with ECM workflows, two hurdles need to be overcome: a way to handle instrument reference data for new issuers, and protocol semantics required to handle reflecting a single order indication to multiple banks.

A) Security Identifiers
For new listings such as IPOs, the creation of a valid OEMS-friendly security identifier is an essential pre-cursor to achieving STP. Without it, the trading system will not be able to properly reference the stock in question. However, ECM processes today are tardy in this regard, often only issuing exchange tickers, ISINs or other identifiers very late in an IPO’s lifecycle. Institutional buyers will need to indicate interest well before identifier creation.

Primary Portal addresses this collective action problem by providing a proxy identifier that is 100% ISIN-compliant and guaranteed to be collision-free with already issued ISIN codes. This Primary Portal Deal Identifier is generated as the deal is announced and remains associated to the deal throughout. As and when the listing exchange assigns a ticker, or other instrument code issuing authorities publish additional bona fide identifiers, Primary Portal enriches the deal data with these instrument codes. At this point, OEMS systems are updated enabling the switch to the ‘real identifier’ for booking, settlement and future purposes (price tracking, etc.)

B) Protocol Semantics
At the time of writing, the latest version of FIX (5.0) does not natively support the workflow semantics and protocol requirements for existing ECM processes. Previous attempts to address this have been made, but none have gained any traction. These failures are due, in part, to the inability for competing firms (particularly on the sell-side) to work together on this, with banks vying for differentiation in the eyes of their clients, rather than collaboration. Primary Portal has already seen good traction by focussing on only buy-side FIX support initially. This approach allows meaningful engagement with institutional investors who are seeking to transmit a single multi-lateral order indication (a single order that is reflected to many banks in the syndicate).

More work needs to be done here to incorporate various firms’ practices, agree on version and respective FIX customisation constraints, both because of OEMS vendor challenges and the vagaries of how each firm prefers to set up their FIX connectivity. We have made good progress and would welcome the opportunity to engage with buyside firms and buyside OEMS vendors to socialise our thoughts and to solicit the views from the wider investor community.