AuditChain: A Trading Audit Platform Over Blockchain

A blockchain architecture and solution is proposed to audit processing under exchange regulation for trading activity of exchanges. A particular focus is made on dark pools and periodic auctions. An architecture of the solution is described conceptually and an implementation of the proposed solution is made in .NET framework in C# via a RESTful API for chain interaction with the periodic auction venue. The framework proof of concept is tested for different efficiency and latency considerations. This opens the concept to significantly more detailed and extensive developments.

1. Significance of Financial Trade Auditing

The onset of regulation aimed at enhancing market transparency and in particular the aspect related to electronic trading and trade execution practices has come under increasing scrutiny. In this work we develop a novel solution to a challenging problem that is required to be solved in the context of trade audit reporting, as required under new financial regulations. We seek to explore the potential to develop a distributed ledger blockchain solution for the audit process that applies to financial market trade processing. This is an important and innovative application of this emerging technology space that we believe can be a significant future use case of this technology. Our focus will be on the application of this audit chain blockchain solution to an auction liquidity venue type. This type of electronic market place is very new in traditional financial markets so by targeting this venue type and market structure we are capturing an emerging trend that is expected to become the dominant market type for large trade execution and block trading, effectively replacing dark pools, as will be discussed below. However, first we begin with a brief explanation of the significance of the audit process for trade execution and processing that has arisen under modern exchange regulations, such as MiFID II and EMIR II.

Auditing, the examination of financial transactions has always been an essential part of the regulation of markets. Proving the order of events and verifying who the action takers, i.e., traders or algorithms were in each event, is fundamental to ensure that the markets are operating in an orderly fashion without interruptions and added risk to the markets and participants. The creation and maintenance of detailed trading events and associated financial records are currently the responsibility of the venue operators and brokers. The regulators specify the policy, but the best practice and the day to day governance falls on the individual exchanges to ensure the veracity and validity of the data pertaining to their trade placement, execution and reporting.

However, should a market participant act maliciously or with nefarious motivations to perform market manipulation or mask specific trading actions, it would be in their best interest to create or exploit failures in the structure of such reporting governance structures. Should a malicious actor gain access to the reporting databases and associated reports, this may then facilitate the chance to commit forgery or malpractice by altering, deleting or tampering with order record keeping after the fact. This could happen internally or externally to the firm.

In the past, deleting a record from the ledger book, nowadays deleting a record from a database, can result in a completely different transaction accountability outcome with a significant impact to the counter parties participating in the trade. A transaction itself cannot be changed as it is reported real time through several publishing channels, but the events and initiators leading to the transaction trade can be altered.

Regulators are continuously creating and enhancing controls and enforcing governance over the financial markets in order to increase transparency of market participant activities and to incentivize the normal behavior of the markets, verifying that no illegal activity or malpractice goes undetected and unpunished. This transition from the regulator toward increased enforcement and better transparency over the financial markets has been increasing worldwide in the last decade or more, for instance the Markets in Financial Instruments Directive MiFID I (Skinner, 2007) (Directive 2004/39/EC) in EU and Dodd Frank in US are some examples of such enhanced regulatory reporting requirements. As part of this evolution in 2018, MiFID II Directive (2014/65/EU) (ESMA, 2016c) and the Markets in Financial Instruments Regulation (Regulation 600/2014) (MiFIR) came into force in the EU. The regulations impact a range of different market participants including investment firms, trading venues and market structures, as well as third-party firms providing investment services or activities in the EU. One of the major outcomes of these regulations on the market participants reporting requirements is a substantial increase in volumes and granularity of data required to be both stored and reported.

For instance, it is now required that every newly placed, updated or canceled order and transaction are needed to be recorded and identified under a classification according to the person or algorithm that was responsible for initiating these events. Furthermore, there are extended corporate governance requirements that are equivalent to those applied under CRD IV [the Capital Requirements Regulation (Regulation (EU) No 575/2013) and the Capital Requirements Directive (Directive 2013/36/EU)]. As a result, firms need to assess their regulatory permissions and in general many firms needed to assess their entire regulatory approach and data collection and data warehousing management processes and approaches.

To address these new reporting and audit challenges that have arisen we believe a solution based around a new technology known as blockchain will progressively gain momentum and uptake. In particular, the use of a distributed ledger system that also comprises a Blockchain solution in the back-end will be a powerful alternative to more traditional systems of trade reporting and audit. The reason for this is that such solutions will provide an immutable tamper proof, distributed and transparent ledger which can be used for many aspects of the order record keeping, reporting for regulation, transparency, and auditing contexts that we will explore in this manuscript for the context of trading venues. Furthermore, this solution can be extended to cover a broader perspective of the trading life cycle, horizontally most naturally is leading to Settlement and clearing (Chiu and Koeppl, 2019) further down the trade flow, but can be applied in trading (Malinova and Park, 2017) and vertically for more static common sensitive data as suggested in the paper (Peters and Vishnia, 2018) by the authors of this manuscript.

1.1. Contribution and Structure

The novelty we propose in this manuscript involves development of a design, architecture and implementation for an auditing and record keeping platform (termed AuditChain) that runs on a blockchain technology. Our primary motivation for this is the setting of trade audit reporting. This is a highly significant application domain as robust and immutable ledgers of trade processing and execution practices by exchange venues is increasingly required by regulation from most financial market regulators as a result of market transparency directives. We will discuss the detail and significance of these regulations as well as their evolution, which we believe provides a very strong motivation for development of the type of solution we propose in this manuscript via AuditChain (see section 1). Similar solutions are only just starting to be explored at present by international regulatory agencies, such as the Bank of England, Federal Reserve, the Australian Securities Exchange, the Swiss Borg, and others.

The regulatory events auditing requirements will be stored in a Blockchain which can be audited and validated at any time. The platform design is agnostic and can be used by any type of trading venue, such as a dark pool, Lit market, auction platforms and so on. We will display here an implementation for a Periodic Auction exchange audit platform, which provides a good entry point for these kind of auditing requirements. Nevertheless, this platform can be used for any type of trading platform and can be extended with the usage of Smart Contracts to provide a built-in automated auditing engine. Our solution is based on a governed Blockchain. The chain is maintained by the trading platform operator, and only this entity can add what we call here Audit Blocks, once added, these blocks become visible and are available for review by anyone. As a venue needs to report to only one regulator, we will briefly explore the some distributed ledger options in section 6.1, like having the regulator holding a node itself.

The structure of the paper proceeds as follows. First, will provide a high-level view of the relevant regulation. We will provide an overview of electronic trading markets, going into more detail regarding specifics of the Periodic Auction type of mechanism and the relevant distributed ledger technologies. Then we will go in to the details regarding the design of our Auditing Platform and its components, also touching on implementation. We'll conclude by suggesting several ways of extending the platform for other use cases.

2. Regulation Context

In this section we will describe some aspects of trade and exchange regulation, focusing primarily on the European context and trading venues. The financial regulation in this context has evolved tremendously in the last 12 years, with the last major update coming into force on the 3rd of January 2018.

We will begin by going into the details of these new rules and their actual implications and demands from the operators. This will follow by explaining how electronic exchanges work and the mechanics of their operations, with a deeper dive into the periodic Auction exchange model. We'll then review the basics of Blockchain technology and describe why the usage of technology can solve the challenges introduces by the regulator.

2.1. Trade Regulations

On 20 October 2011, the European Commission adopted formal proposals for a “Directive on markets in financial instruments repealing Directive 2004/39/EC of the European Parliament and of the Council” (MiFID II Directive), and a “Regulation on markets in financial instruments (MiFIR),” which would also amend the proposed European Market Infrastructure Regulation (EMIR) on OTC derivatives, central counter-parties and trade repositories. Both MiFID II and MiFIR entered into force on 2 July 2014. Under these new regulations there are fewer exemptions and they also expand the scope of the original MiFID to increase the number of companies and financial products captured under the regulation. Both MiFID II and MiFIR are set to take effect in January 2018 (ESMA, 2016a).

While MiFID I effort was more on market fragmentation and opening the Lit markets to other trading venues besides the primary exchanges, MiFID II is more concerned with dark pools and hidden liquidity, stability and resilience of the markets, and increased order trailing, transparency and auditing.

The core aims of the MiFID II regulation are targeted at a reduction of systemic risk and to further maximize transparency in markets and in order to ensure robust levels of investor protection. A core focus from MiFID II is the OTC markets for which there will be new extended pre-trade and post-trade transparency requirements, such as those that are currently applicable to equity markets to non-equity and equity-like products.

2.2. Order Record Keeping for Venues

MiFID II requires that trading venues and exchanges must, under regulation for transparency, record and store a significantly larger number of data fields in a trade and execution process than previously required. Some of this data is only available to the order initiator, and if this entity is also a member of the venue, this participant will also have to upload data to the trading venue in order for the venue to be able submit transaction reporting.

Under the regulation a selection of “data fields” are outlined which list the core components that must be captured, stored, and submitted to regulatory bodies for external oversight and transparency of exchange trade processing practices. The core elements to be captured has increased from 21 data fields under MiFID I to 83 under MiFID II. These data fields include details, such as who the participant in the trade was and identification code, the investment decision (Algo/Trader) for orders and executions, passive or aggressive decisions and more. This is clearly very sensitive and important data for such businesses to maintain securely. Clearly, the aspects of the data related to identification data are particularly important to keep secure and are needed for both the trader and decision maker, these data points are highly sensitive, such as address and national insurance number of the traders.

Although the data recorded for the order record keeping is not needed for day to day regulatory reports, the regulator can ask on occasion for a full audit transcript of a certain order or instrument traded in a specified time frame. The exchange operator then has a couple of days to come up with a full audit trail of every event occurring in that time interval. This data depends on the type of the exchange, but in general it must provide all orders and decisions (price determination) which impacted an execution.

It will be demonstrated later in this paper how we are utilizing blockchain properties to build a secure and easy to use audit trail for executions taking place on the exchange where all the relevant data required by regulators is captured and incorporated on the ledger.

We will next provide a more in-depth discussion on pertinent details of the core components for our proposed solution. However, for full requirements, look at Regulatory Trading Standards (RTS) 24 (ESMA, 2016b).

2.3. Quarterly and Yearly Reports

In addition to the daily trade and transaction reports, a trading venue is now required by exchange regulations to produce periodic reports, either quarterly or yearly. These reports are described in details in RTS 27 ESMA (2016c) and ESMA (2016d). One of the key reasons for these reports is to help the regulator calculate what are known as Dark caps and publish the new list of capped and uncapped stocks.

These reports are divided into several tables and contain data like:

• the universe of stocks or securities that are trade-able in the exchange;

• the aggregated count of events, such as new orders, amendment fills etc. per stock;

• the analysis of trades per stock based on specified time frames and size ranges; and

• the total volumes traded in the exchange.

For the purposes of transparency in financial markets, under these regulations discussed above, it is now common that these reports are to be made public and published on the operator website. An example is included in the footnote for two representative exchanges, one from BATS² and the other from Posit³.

2.4. Double Volume Cap Mechanism (DVC)

One of the biggest changes introduced by MiFID II regulation is the volume cap on dark trades, known as the Double volume Cap (DVC). A 4% cap will be introduced to any equity on a single dark pool, and 8% cap on any single stock applicable to all dark pools. Based on data collected over 12 months, a stock that breached the limit will be banned from trading for 6 months (Urrutia, 2014).

Each trading venue is responsible to generate a daily and bi-weekly volume reports and upload this data to the regulator (ESMA). These results are then used by the regulator to produce an update to exchanges on whether a name is eligible to trade in a dark pool, and to check if a daily limit has been reached. There is no decided or consensus on the appropriate mechanism which will aggregate the executions and trades from all venues in real time and publish the caps to be taken into consideration by the live markets. Sample volume number for the FTSE 100 are displayed in Table 1.

TABLE 1

Table 1. FTSE 100 market share by venue—week ending 04 July 2018.

Based on the Daily volume reports described in the previous section ESMA will publish every month its latest list of symbols that are restricted from trading. This is known as the double volume caps⁴.

2.5. LIS Waiver (Large in Scale)

An exemption to the double volume caps described in the above, is the Large in Scale (LIS) waiver. This exemption means that if a trade is larger than a certain threshold, its volume doesn't ads to the volume cap calculations, and consequently, such orders are entitled to be traded in the dark pools. The waiver is based on the stocks “Average daily trade” (ADT) and an illustration for a European context, as sourced from ESMA, is provided in Figure 1.

FIGURE 1

Figure 1. ESMA Large in Scale table. Regulatory technical and implementing standards – Annex I.

3. Electronic Trading Platforms

To understand the context of the reporting and regulation just discussed, it is important to briefly recall the representation of an electronic market, both lit and dark pools. Formerly, these are characterized by the data structure known as the limit order book. An exchange or trading venue will provide trading opportunities for investors, speculators and hedgers to participate in the exchange of two assets via a market mechanism that is characterized discretely in time by the limit order book that will be briefly described next. Figure 2 shows a high level overview of this type of platforms components.

FIGURE 2

Figure 2. Trading platform basic components.

3.1. Limit Order Books

The Limit Order Book (LOB) can be viewed as a list of the willingness of people to buy or sell a certain quantity of a certain asset at a certain price. When a buy and a sell price match, we have an execution or trade that takes place. Sizes do not have to match on a trade, and one part of the deal can remain with a residual (see discussions in Gould et al., 2013; Panayi and Peters, 2015; Panayi et al., 2015; Richards et al., 2015). In modern market places one common distinction that has arisen for different types of LOB is between lit and dark books or sometimes referred to as lit and dark liquidity.

3.2. Lit (Visible) Limit Order Book

Understanding the order book dynamics and properties can give the trader, investor and regulator an in-depth knowledge of the current market status and can help in either earning significant gains or preventing markets from being manipulated. Different markets use different trading systems and the regulation differs between the market and exchanges, but the basic mechanism or the Limit Order book is the same for all.

We can look at the order book as a dual price queuing system, one list for buy orders and one list for sell orders, each position in the queue is called a level, i.e., the first in the queue on each side will be level 1, second will be level 2 etc. On each level there are also queues noting when the order was inserted to the level. This is called the depth of the level as illustrated in Figure 3.

FIGURE 3

Figure 3. Limit order book.

The data in the Lit limit order book is visible to market participants usually by subscribing to a venue feed, whether directly or via a data provider, such as Thompson Reuters or Bloomberg.

It is common to quote the price of an asset based on a combination of the best ask and best offer prices and sometimes to also include liquidity and volumes. In the simplest case of the mid-price, one can use the definitions of the best bid, ask and the midpoint as follows. First, we introduce the BestBid which is the maximum price a participant is willing to buy X amount of shares at a certain point in time.

$\begin{array}{ll}BestBid=Max(P_b^1,P_b^2,\dots ,P_b^k)& (1)\end{array}$

The BestAsk which is the minimum price a participant is willing to sell X amount of shares at a certain point in time.

$\begin{array}{ll}BestAsk=Min(P_a^1,P_a^2,\dots ,P_a^k)& (2)\end{array}$

Then the simplest way that one can quote the “market price” is via a combination of these two prices known as the Mid price which is simply the midpoint between the best bid and the best ask.

$\begin{array}{ll}Mid=(BestAsk+BestBid)/2& (3)\end{array}$

Importantly for the context of this paper, it does not have to fall under the tick size rules.

3.3. Brief Introduction to Dark Pools

Dark pools are trading venues which offer electronically off the book block trades. These trades are typically stated to be executed based on unobserved latent limit order books that only the venue can observe, however the orders executed in such markets are typically done so at the mid-price, though at present it may also be possible to cross the book both passively or aggressively. Since the decision to execute the trades is opaque to the participant submitting a large block trade, one needs to be able to trust the mid-price used, as it cannot be externally verified by the participant by accessing the dark limit order book via an API or data feed. Therefore, to add the ability to check the performance of such executions it is common to use a reference price taken from the primary exchange (PBBO—Primary Best Bid-Ask).

By not publishing public limit order books and only report trading events after the trade, Dark Pools remove market impact. Electronic dark pools market share grew immensely in the last years and have seen much scrutiny from the primary exchanges and the regulator. Since the beginning of 2018 Dark pools have been put under extended regulation and volume caps as part of MiFID II directive, which we described in more details in the regulation section above.

3.3.1. Dark (Hidden) Limit Order Book

We explained the Open (Lit) Limit order book in the previous section which is crucial to understand how the dark order book works, as they both share the same principals. A Dark Limit Order Book (DLOB) is, as its name states, not publicly visible, i.e., the orders that reside within it are not public and no one knows at any point which entries and what sizes/ prices are currently in the dark pool order book. In a DLOB there is no best Bid/Ask and volume being published, that is trading orders/interest are not disclosed to the market publicly. Once a trade occurs in the dark pool it will be published and is then visible to the public [via Simplitium for example (known as Boat platform before)⁵].

The Orders that reside in the DLOB are adhering to client limit prices and to queue/size priority as per venue regulations, but only the venue operator and the sender of the order to the dark pool knows about this order until it is executed. In addition, it is also the case the removing or canceling an order from the DLOB is also not visible to the outside world. See discussions on such venues in Degryse et al. (2009) and Gresse (2015).

3.3.2. Dark Pools Under Regulation

A dark pool is primarily for use by institutional traders, and provides a latent or dark liquidity pool or unobserved Limit Order Book for each asset in this liquidity pool. The dark pools are basically set up with the goal of offering off book, i.e., off the lit observable by the market LOB for each asset, offering additional latent hidden liquidity. Such dark pools have attracted the bulk of large block trades from most large institutional investors through a combined strategy of lowering submission and execution fees and limiting market impact, which has acted as an attractive complement to traditional exchanges lit LOB's. The rise in number of such dark pools has been significant, as stated in Degryse et al. (2009) nowadays in the US alone, more than 40 dark pools are operating, and their trading volume is annually growing at a rate of 40%. Further, according to (Tabb, 2004) reporting on institutional equity trading in America, about 90% of all large investment management firms report that they are using a crossing network (CN) of some type or a dark pool for their trade executions. However, this is primarily for large institutional investors, since in the categories of medium or small firms, this rate is somewhat lower but still highly significant reaching resp. 86 and 60%. In the next couple of years, these numbers, as well as the intensity of usage, could still increase as order flow keeps on migrating toward these cheaper venues. Obviously, this evolution poses a number of challenges to traditional exchanges, traders and regulators.

As a consequence, regulators initially sought to regulate such trading venues and this was primarily achieved through caps. The EU's revised Markets in Financial Instruments Directive instigated from January 2018 a limitation on the amount of trading in a stock to a cap of 4% on a single dark pool and a market wide cap of 8% across all such venues. Breaching the caps was punished with by a 6-months suspension on market participation. In the context of MiFID II regulations this key feature of a cap is known as the “double volume cap” (DVC). The DVC aims to limit dark trading in shares, i.e., trading when the price and quantity to be traded is not disclosed to the market before execution. According to the FCA in the UK, under the DVC rules in MiFID II, dark trading in a given share is suspended, with exemptions for large trades, for 6 months if it exceeds 8% of total trading, or on any one trading venue it exceeds 4% of total trading.

Since the development of this regulation, it was challenging to implement and there was significant market request to relax such caps. Consequently, in Europe it was noted in Agini (2018) that in late 2018 some of these restrictions were relaxed. At this point, there was suspensions on 624 stocks lifted according to equities broker ITG. Consequently, this relaxation of the restrictions triggered an immediate spike in dark pool trading volumes. Subsequently, it has been observed that many of Europe's traders returned to dark pools after these restrictions on the private venues lapsed, demonstrating huge demand remained for executing trades on such liquidity pools by large institutional investors.

According to Tabb, dark pools' share of continuous European trading volumes between September 12 and 18 was 6%, compared with a 5-months average of 3%. This does not include so-called blocks, large trades that qualify for limitless dark trading under MiFID II.

MiFID II's dark pool caps were supposed to encourage traders to buy and sell more on traditional stock exchanges, where participants reveal the price and size at which they are willing to deal. But many prefer to use private venues when trading large amounts of shares so as not to alert the wider market to their intentions and see prices move against them.

As such the presentation of trading in the dark pools hit the liquidity on the lit books at venues, but also opened the way to development of other trading platforms, such as Systematic Internalizers (SI) and Periodic Auctions (PA). Although not entirely a new concept, the Periodic auction. MTF is one of the trading platforms that gained from these regulatory restriction on dark trading and the volume traded in the Periodic Auctions has grown rapidly since the beginning of 2018. Like any other trading venue after MiFID II, Periodic Auction MTF's are also required to follow a strict order record keeping and audit trail in order to operate as stated in MiFID II.

In this regard there are numerous versions of this technology being developed both in the public domain through research groups, open source projects and partnerships with universities as well as by different commercial consortiums. Examples of significance include the following leading enterprise blockchain solutions: Ethereum, Tron, Enigma, R3 Corda, Hyperledger Fabric, Fluidity, Thorchain, VeChain, and Ripple to name a few of the many emerging technologies (see Valenta and Sandner, 2017). We will seek to extend some discussion on a few of the more promising technologies for the application of trade reporting and audit later in the manuscript.

4. Overview of Periodic Auctions

The Auction phase of a market is a defined time period when buyers and sellers can send orders into an order book with their desired price and size, and the exchange will try to maximize the number of shares that will get filled at the end of the phase. The exchange will publish during this period an indicative price and indicative volume so the participants can react to these updates and modify their order. In most EU markets there is an open and a close auction at the beginning and at the end of the trading day and also an intra-day (volatility) auction which can happen after stock trading has been halted due to a circuit breaker event, such as a rapid drop or rise in price over a very short interval of time that depletes a large portion of the limit order book. Some markets will also have systematic intra-day auctions, for instance this can happen if there is a lunch break, e.g., the Istanbul stock exchange is a Primary exchange with this feature. At the time of this writing, some MTF's are looking at having systematic auction periods, the latest to announce such a move is UBS who will open their Periodic Auction on the 18th of June⁶. In this section we will discuss the particular auction mechanism in an exchange known as the periodic auction. Figure 4 illustrates the time line of the auction.

FIGURE 4

Figure 4. Auction time line.

It has been suggested that the rising popularity of periodic auctions is driven largely by the DVC rule enacted under MiFID II. This new trading facility emerged to fill in the gap caused by the introduced caps on dark trading. In order to avoid being considered a Dark trading venue, the trading facility needs to offer Pre-Trade transparency, i.e., the visibility of the bid/ask/indicative prices that are on the exchange order book. This is where the Periodic Auction is the perfect candidate to take the liquidity which is now prohibited from trading in the Dark pools. The idea in a nutshell is to have very short (milliseconds) periodic auctions where the indicative price and size is published just before the trades is happening covers the pre-trade transparency requirements. Auctions are part of any primary exchange and happen normally twice a day at the open and close and also in case of extreme market conditions as a volatility auction. But if there is no “match” in the auction, no indicative price or size will be published (BATS Periodic Auction for example⁷). Periodic Auction venues are gaining momentum and see more liquidity and volumes since Jan 3rd 2018.

According to the FCA in the UK one can think of a periodic auction mechanism as analogous to a conventional auction whereby the “operator collects offers to sell shares at or above a minimum price and buy at or below a maximum price specified by the selling or buying firm, respectively. The auction platform then determines a single ‘uncrossing' price which maximizes the amount of business which can be executed at the same uncrossing price.”

There are numerous methods or models that can be implemented to achieve this periodic auction strategy framework. For instance, a common approach involves collection of trading interest throughout the day and then to trigger a “call period” every time that a pair of opposing orders can be matched, in which there is an order to buy and an order to sell, where the selling price is not higher than the buying price.

In this case, during the call period for a very short time interval, typically a fraction of a second, the operator distributes information about the indicative uncrossing price and the number of shares expected to be executed. Other participants can then decide to submit their own buy and sell orders into the auction. As a result of this public information disclosure, despite its very limited duration one may formally consider periodic auctions as not being a form of dark trading since public information is provided about buying and selling interest during the auction call periods adhering to the pre-trade transparency rules according to MiFID II rules. But, while CLOB trading requires detailed disclosure of buying and selling interest at every price level, periodic auction operators are required only to disclose indicative uncrossing price and volume for the auction.

The key difference between periodic auctions and central limit order books (CLOBs), which is the most common format for share trading, is that CLOBs are continuous. If a trading firm sends a buy order to a CLOB and there is a matching sell order resting on the order book, the trade will execute instantly in accordance with the time at which the order is received. In a periodic auction, the firm has to wait until the end of the call period. However, given the speed of modern share trading that wait maybe only of the order of around 100 ms.

To run such a periodic auction, the exchange will try to find the best equilibrium price to maximize the volume traded in the auction. In order to prevent market abuse or some fat fingers mistakes hindering the price and volume determination mechanism, most exchange provide a threshold of price movement allowed with the auctions and can also give priority to different order types which contribute more to the auction validity.

The brief time from which an indicative price and volume is being published until the auction trade is occurring (between 50 and 100 ms randomize and depends on venue) leaves very small window for market participants to interact with the auction. It is required by the venue operator to store for auditing purposes all of the events that led to the price and volume published and the trade itself, which will be published as it is happening. Due to the speed of the auction, the publish indicatives are not human readable in real time (The indicatives are published at near real time but cannot really be interacted by a human trader) hence the auditing extra importance here.

4.1. Details of Periodic Auctions

To proceed with more details of periodic auctions we first need to identify a notation to describe the components of a periodic auction. We note that any order can go to the auction, but there are a couple of specific order types that some exchanges support that will only target the auctions, whether on the open or close:

• LOO/MOO—Auction specific – Limit on close—an order that targets the auction only. Can be for open and close auctions and wither market or limit.

• LOC/MOC—Auction specific – Limit on close—an order that targets the auction only. Can be for open and close auctions and wither market or limit.

In order to proceed to more details of what is required to form the input data to the audit chain proposed, we need to introduce a few basic definitions.

• Let Oa and Ob represent orders on the Periodic Auction book;

• Let s ∈ {1, …, N} be the size of an order O;

• Let p ∈ {1, …, R} be the price of an order O in discrete tick sizes;

• Let t be the time the order was inserted into the book;

Then with these basic notations we may define the key components of the book which correspond to each characterizing entry in the LOB:

• $O{a}_t^{p,s}$ is the Ask order at time t with price p and size s;

• $O{b}_t^{p,s}$ is the Bid order at time t with price p and size s;

• IPt is the Indicative Price at time t;

• IVt is the Indicative Volume at time t.

We will define the indicative price and volume based on the notation devised by Kylie-Anne Richards in her Ph.D. thesis (Richards, 2019).

• $I{P}_i^{(p,l)}$ The Indicative Price on the Auction book at time t_i in level l.

• $I{V}_i^{(v,l)}$ The Indicative Volume on the Auction book at time t_i in level l.

• $I{P}_t^{*}i$ the published indicative Price at time t_i.

• $I{V}_t^{*}i$ the published indicative Volume at time t_i.

Next, we will describe in more technical detail how periodic auctions work. Technical specifications of periodic auction venues like Posit and Bats can be found on-line, here we will provide a more general overview. As stated above, the periodic auction book is not displayed until there is a possible match, only then an indicative is published, and we are entering the phase of the pre-trade transparency.

A periodic auction venue can receive a Limit or Market order with possible size restriction per exchange policy. Orders entered into the Periodic Auction book will have one of these types:

1. Day—a day order valid until the end of the trading day.

2. GTC—Good till cancel order will continue to sit in the book until canceled.

3. GTD—Good till date order will continue to sit in the book until it's data has expired.

4. GTA—Good till Auction—this order will get canceled back after the next auction in the particular stock.

4.1.1. Matching

A match will occur when two opposite orders can trade at a price. Exchanges put collars on the possible price to prevent too big of a price shift, collars are some X percent tolerance from the current EBBO.

Once there is a match, i.e., two orders can execute, an indicative price and volume will be published for a random period, up to 100 ms in which the participant can interact and add/change the price and volume of the auction. Once the auction ends, it can either result in an execution or nothing done if one of the sides canceled its order or the additional orders created imbalance which results in no match.

4.2. Audit Data

For the purpose of auditing, an exchange needs to safely store all of the events that led to the execution. The Audit block will include:

• Orders—the buy and sell events that generated the trade or participated in the price formation, this includes all new, cancels, correction, etc.

• Indicative—all the indicative messages that were publicly published.

• Transaction—the execution that happened from the match.

4.2.1. Samples

We will also describe below some basic scenarios of a match to clarify the data and usage.

Case 1—Simple match no residuals.

In this basic case, we are looking at two orders, a buy and a sell of the same size, one has a limit followed by a market order on the opposite side. This means we now have a match, so indicative price is publishes with the price of 10 and size of 100, followed by an execution.

Case 2—Simple match with residuals.

In this case, we are still having two orders, a buy and a sell, but not with the same size. The sell order is for 50 shares only. In this case our match is only for 50 shares, hence the indicative price is 10 and the indicative size will be 50. After the execution there is a cancel back of the residuals to the order initiator.

Case 3—Simple match with residuals, continues & participating in next auction.

In this case, we are initially having two orders which partiality match but the residuals are kept in the book until another order is entered. Once a new order (buy 70) enters the book, we see another indicative on the size of 50 and price of 10.4 that is being executed. The residual of 20 shares at price 10.4 will stay on the book until it will be matched or canceled.

5. Blockchains Briefly Explained

There is a wide range of different blockchain architectures and here we'll attempt to illustrate how such structures can be relevant to electronic exchange reporting under the new exchange transparency and reporting requirement regulations discussed previously in this paper.

5.1. Blockchain

A blockchain is not a database but it can conceptually be thought of as acting like a database in the sense that it is a ledger that takes several records and puts them in a block (rather like collating them on to a single sheet of paper). Each block is then “chained” to the next block, using a cryptographic signature. This allows block chains to be used like a ledger, which can be shared and corroborated by anyone with the appropriate permissions. There are many ways to corroborate the accuracy of a ledger, but they are broadly known as consensus (the term “mining” is used for a variant of this process in the cryptocurrency Bitcoin)—see below. If participants in that process are preselected, the ledger is permissioned. If the process is open to everyone, the ledger is permissionless—see below. The real novelty of block chain technology is that it is more than just a database—it can also set rules about a transaction (business logic) that are tied to the transaction itself. This contrasts with conventional databases, in which rules are often set at the entire database level, or in the application, but not in the transaction.

5.2. Permissioned Ledgers

Permissioned ledgers may have one or many owners. When a new record is added, the ledger's integrity is checked by a limited consensus process. This is carried out by trusted actors—government departments or banks, e.g., which makes maintaining a shared record much simpler that the consensus process used by permissionless ledgers. Permissioned blockchains provide highly-verifiable data sets because the consensus process creates a digital signature, which can be seen by all parties. Requiring many government departments to validate a record could give a high degree of confidence in the record's security, for example, in contrast to the current situation where departments often have to share data using other means, such as physical copies. A permissioned ledger is usually faster than a permissionless ledger.

5.3. Fully Private Blockchains

A fully private blockchain is a blockchain where write permissions are kept centralized to one organization. Read permissions may be public or restricted to an arbitrary extent. Likely applications include database management, auditing, etc., internal to a single company, and so public readability may not be necessary in many cases at all, though in other cases public auditability is desired⁸.

5.4. A Consortium Blockchain

A consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of nodes; for example, one might imagine a consortium of 15 financial institutions, each of which operates a node and of which 10 must sign every block for the block to be valid. The right to read the blockchain may be public, or restricted to the participants, and there are also hybrid routes, such as the root hashes of the blocks being public together with an API that allows members of the public to make a limited number of queries and get back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered partially decentralized.

6. Introducing Audit Chain

Why use Blockchain for Auditing? In the previous sections, we described some of the new regulation requirements for order record keeping for venues. It means that any event should be stored and be made available by demand to the regulator. There is more than one way to implement this type of storage, and here we will set out a Blockchain-based design which answers these requirements, build on top of the venue infrastructure and data; hence, it does not interfere with daily trading.

In this section, we will describe in detail our suggested design and implementation of the Audit Chain. We will use a Periodic auction venue (described in section 3) to demonstrate this in a real-world sample.

6.1. Overview

In this section, we present the Chain solution, with implementation notes. We think this is a viable solution for the following reasons:

1. Fully built-in immutable tamper-proof auditing trail.

2. Can be used for straight through processing and trade reporting.

3. Public output ledger.

For the presentation of this idea, we have decided to implement a stand-alone Blockchain solution and not use a framework, such as Ethereum. The reason behind this is that, as an audit chain, we are not bound by a platform and, to present the generic idea, we thought it would be better to show a platform implementation which can then be transferred to any other platform by the reader. Note that, due to the governed nature of the presented chain, we do not present a consensus mechanism, only verification of the blocks, which is much quicker and requires less resources from the system.

6.2. Trading Platform Basic Components via Periodic Auction

A Periodic Auction implementation will vary according to the platform, programming language and business logic behind the execution model. We will first describe what would be the basic components needed in order to implement it in a generic form.

At the heart of the Periodic Auction Platform (or any exchange, for that matter) resides the matching engine. The matching engine is the component that determines if, at a single point in time, an execution will occur at a certain size and price. Surrounding the matching engine will be the utilities functions, which, without the matching engine, will have nothing to work with. We will explain in more depth the feed handler, the order book collector and the reporting mechanism.

6.2.1. Order Book

The order Book is the component which collects all the platform participants trading orders in an orderly manner.

6.2.2. Feed Handler

Although a venue can have its own book, whether it is published or not depends on the venue type. In more than one case, it will need a feed from the primary exchange; for example, Crossing can be done on any price which corresponds to the pool specifications. Most commonly, the price will be the Mid-price of the PBBO (Primary Best Bid Ask) or the EBBO (Consolidated Best Bid Ask). Passive or Aggressive fills are banned under MiFID II but are an option. The Platform should listen to a market data feed handler in order to be able to calculate the current Mid-price.

6.2.3. Real Time Pricing Publication

All exchanges besides Dark Pools need a mechanism to publish the current bid and ask, Auction Indicative price and different levels of their own order book, depending on the subscription type and what the exchange is willing to make public. All exchanges, including dark pools, are obliged to publish a trade within a certain threshold of this trade taking place on the exchange's matching engine.

6.2.4. Matching Engine

The matching engine in the trading platform is the piece of code which determines if in the current state of the order book, the conditions are of such that there is a match between buyer(s) and seller(s) which results in a trade where X number of shares are changing hands at a certain price. Different trading platforms will have different matching engines with different matching rules which can also change intra-day between several trading periods. The matching rules themselves are published by the platform and publicly available, for example, in the LSE guide⁹.

Taking this to the Blockchain/DLT world, we can think of these sets of rules implemented in a Smart contract which is executed when all conditions are met and generates, as an output, an execution to be put on the ledger with a full Audit trail of data that comes with it. We present the idea of matching engine on Smart contract as an extension to this paper, as this is a large research by itself, taking into consideration many other market constraints, such as speed, capacity, and more. There is current research done around the area of trading platforms over Blockchain, such as the Ox project (Will and Amir, 2017).

6.2.5. Reporting Engine

One of the major responsibilities of the platform operator is to report to the regulator on execution, less than a minute after the execution has occurred. The reporting and publication requirements vary between regulatory entities (US, EU, etc.), but in all cases, it is obligatory to imminently report on a trade. This component can be an integral part of the system or an additional component that listens to the platform and does the reporting part. For our purposes in this paper, we will look at the reporting as a built-in feature of the platform.

6.2.6. Audit Engine

The audit engine is the component responsible for packing all the match data and sending it to the Blockchain for safe keeping. The audit engine collects all of the relevant orders that contribute to the indicative price and volume changes, the published indicatives and the execution details and passes them on to the Blockchain, where they will be put into a block, hashed and added to the chain.

6.3. Ledger Design and Implementation

For the purpose of this paper, we have implemented a Blockchain to incorporate all of the properties and functionality we need to assure the sequential, tamper-proof audit trail and reportable solution. Figure 5 displays the system diagram for the audit trail.

FIGURE 5

Figure 5. System diagram.

As a high-level view, our chain will include the following:

1. Block per transaction—each block will include all the needed data in order to build the full event trail which led to the execution.

2. Viewable audit—each block can be viewed via web application.

3. Day cluster—for performance, we will use a chain per day structure so the main chain will be date created.

For practicality of the solution and to take it out from the venue infrastructure, we are suggesting an end of day process to take the data from the venue and sign it in a blockchain as an end of day process. Of course, it is preferred to move this close to the venue infrastructure and have an off-chain process to store the events on the Blockchain as they happen.

If we'll break down the process of what needs to be done, we come up with the following process:

1. Read events—Start going over on the stream of Events

2. Process events—Process each event and create its representing object.

3. Add event to block—Hash the object and add it to its container block.

4. Repeat—Repeat this process for all events.

5. Sign and verify—Sign the chain and verify the integrity of the data.

Blockchain implementation was done using the .NET framework in C# and using RESTful API for chain interaction with the Periodic Auction venue. We used as a base the great introduction from Hackernoon¹⁰.

6.4. Hashing

Our hashing Algorithm is the standard SHA256 framework.

The hashing is done in the following order:

1. Object data (i.e., excluding the hash fields) is translated into JSON;

2. The object previous hash field is being set with the previous block hash;

3. The previous block hash is being added to the JSON representation of the object;

4. The new string is being hashed;

5. The new hash is being set to the Object hash field.

6.5. Scalability, Capacity, Latency, Throughput, and Recovery

By nature, distributed ledger technologies offer all of the properties for scalability, capacity and recovery.

6.5.1. Scalability

Scalability, briefly, is the ability to scale your business without the need to rewrite the code. There are two ways to scale; horizontal, which is adding more computers to the environment and vertical, which is adding more power like CPU or RAM to the existing environment.

6.5.2. Capacity

Node or instance capacity can be measured by the number of audit transactions it can hold and which can be queried (this is not how many transactions it can process per second, which we measure via Throughput). This, of course, depends on the trading activity taking place on the platform. An easy option to deal with capacity will be to shard the data and cluster it into dates; every day/month, for example, each node will create a new chain for that period.

6.5.3. Recovery

This describes the time it takes your application to recover from a crash or other unexpected event, such as network power outage. On DLT, as we already have more than one node, there is no single point of failure in the system, and if one node is down, there are others to cover for it until the faulty node is restored.

6.5.4. Latency

Latency is a point which is not a strength of DLT, as the network, and, in some applications, the calculations of the Paxos, are time-consuming. We see this in the amount of time it takes to complete a transaction in crypto-currencies. There are some new ideas out there for solving this problem, but they are still in the early stages.

6.5.5. Throughput

Throughput is usually a bit of an Achilles heel in DLT systems, as, due to the computational power needed to validate and hash each transaction, the actual registration of the record on the ledger can take time. There is a lot of progress in this area, using off-chain solutions and the like. For our solution, since we are not RT critical and are a governed chain, no consensus is required; just using hashing of an Audit Block, we are less prone to Throughput issues.

7. Testing Methodology and Practice

In order to test this system, we took a day load of events from a live Periodic Auction exchange and re-played it. We replayed the data in several time frames; once as a real-time play, i.e., the events enter the system as they happened on the day; another as a bulk play, where we could see the throughput and capacity-handling of the system, as well as its recovery capabilities. Our testing data set comprised events from two nodes, with 600,000 rows, on average. Table 2 shows a sample of the data.

TABLE 2

Table 2. Sample stream of events on one node.

In the sample data we used, we loaded 2,226 distinct instruments, which resulted in the creation of 13,375 blocks on the chain. The load time from the data files to the memory took about 12 s, and building the chain took another 18 s. As an end of day process for creating an Audit chain this is fairly fast.

7.1. Some Thought About Distribution Ledger

As discussed previously in the overview, we suggest a distributed governed ledger, i.e., the trading platform operator has control of the ledger. This does not mean that all nodes need to be on the platform network; we can have a node that resides on the relevant regulator's network, which gives the regulator full continuous access to the data. For platforms that operate at different regulated jurisdictions, a node can be set for each relevant regulator in its region, and, if needed, these nodes can be connected or separated. These are illustrated in Figure 6.

FIGURE 6

Figure 6. Nodes.

7.1.1. Node at the Regulator

A node that sits in the regulator and is constantly updated with all of the other nodes on the distributed ledger adds another level of assurance and protects all of the data and infrastructure in the control of the venue operator. In a scenario when a venue decides to close down due to some malpractice and deletes all of its order records data, a node at the regulator alleviates this problem. A node at the regulator also makes it very easy for them to query and look at data when needed and run more frequent checks.

7.1.2. Nodes

There is more than one way to split the nodes (see image); it can be done per country, per region, or per instance of the matching engine. It very much depends on how the trading venue is set up, what trading location and instances it has, and more in-depth networking considerations, but it is worth mentioning that, although important in the deployment architecture, this does not affect the implementation.

7.1.3. Block

There is of course, also more than one way to put the events into blocks. In our process overview, we talk about wrapping an event, signing it and putting it in a block. This can be a block per instrument, a block by date, a block per country, etc.; this is primarily an implementation detail according to the preference of the exchange. The size of a block, how many events, and how to split it up are also very specific implementation questions. We chose the instrument/size block but this is just our preference.

8. Conclusions

In this paper, we've demonstrated a real-life usage of Blockchain application to adhere to new regulations and auditing requirements on the financial markets. This usage takes advantage of the immutability property of the Blockchain and its un-tampered nature which makes it a perfect candidate for auditing usage. Because of the nature of the data and its origin which comes from one source, we are suggesting a governed chain, although distributed between several nodes of the trading venue with an option of a full node residing at the regulator.

This solution is presented as an “add-on” to a trading venue, as a fuller integration will require many more resources and will take much longer to implement and embed. But By introducing this usage of a trading platform with a blockchain technology, we open the door to deeper integrations and inherent linking of the trading platform and Blockchain technologies. We demonstrated this principle in this paper via the Periodic Auction trading platform, but we see this as a base enabling to extend to any other exchange type, from Dark pools to Lit venues, and as a foundation for a more complete solution which combines the trading venue and the Blockchain in all parts, and through all of trading life cycle. A solution which is self-encrypted and audited from the low-level messages (FIX) to the execution publication message.

Data Availability Statement

The datasets generated for this study are available on request to the corresponding author.

Author Contributions

All authors listed have made a substantial, direct and intellectual contribution to the work, and approved it for publication.

Conflict of Interest

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Footnotes

1. ^https://fragmentation.fidessa.com/fragulator/

2. ^Best Execution Reports https://markets.cboe.com/europe/equities/best_execution/

3. ^RTS27 reports https://www.virtu.com/regulatory-disclosures/

4. ^ESMA double-volume-cap-mechanism https://www.esma.europa.eu/double-volume-cap-mechanism

5. ^Simplitium https://www.simplitium.com/

6. ^UBS Periodic Auction https://www.ubs.com/global/en/investment-bank/multilateral-trading-facility/periodic-auction.html

7. ^BATS Periodic Auction http://cdn.batstrading.com/resources/participant_resources/BATSEuro_PeriodicAuctions.pdf

8. ^On public and private blockchains https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/

9. ^LSE guide https://www.lseg.com/guide-to-trading-system

10. ^Learn blockchains by building one https://hackernoon.com/learn-blockchains-by-building-one-117428612f46

References

Agini, S. (2018). Traders Rush Back to Dark Pools as Mifid II Caps Lift. London: Financial News.

Google Scholar

Chiu, J., and Koeppl, T. V. (2019). Blockchain-based settlement for asset trading. Rev. Financ. Stud. 32, 1716–1753. doi: 10.1093/rfs/hhy122

CrossRef Full Text | Google Scholar

Degryse, H., Van Achter, M., and Wuyts, G. (2009). Shedding light on dark liquidity pools. Trading. 2009, 147–155. Available online at: https://guides.pm-research.com/content/2009/1/147

Google Scholar

ESMA (2016a). Regulatory Technical and Implementing Standards–Annex I (Paris).

Google Scholar

ESMA (2016b). Rts 24–European Commission–Europa EU (Paris).

Google Scholar

ESMA (2016c). Rts 27–European Commission–Europa EU (Paris).

Google Scholar

ESMA (2016d). Rts 27 Annex–European Commission–Europa EU (Paris).

Google Scholar

Gould, M. D., Porter, M. A., Williams, S., McDonald, M., Fenn, D. J., and Howison, S. D. (2013). Limit order books. Quant. Finance 13, 1709–1742. doi: 10.1080/14697688.2013.803148

CrossRef Full Text | Google Scholar

Gresse, C. (2015). Effects of lit and dark market fragmentation on liquidity. J. Financ. Markets 35, 1–20. doi: 10.1016/j.finmar.2017.05.003

CrossRef Full Text | Google Scholar

Malinova, K., and Park, A. (2017). Market Design With Blockchain Technology. Available online at: https://ssrn.com/abstract=2785626

Google Scholar

Panayi, E., and Peters, G. W. (2015). Stochastic simulation framework for the limit order book using liquidity-motivated agents. Int. J. Financ. Eng. 2:1550013. doi: 10.1142/S2424786315500139

CrossRef Full Text | Google Scholar

Panayi, E., Peters, G. W., and Kosmidis, I. (2015). Liquidity commonality does not imply liquidity resilience commonality: a functional characterisation for ultra-high frequency cross-sectional lob data. Quant. Finance 15, 1737–1758. doi: 10.1080/14697688.2015.1071075

CrossRef Full Text | Google Scholar

Peters, G. W., and Vishnia, G. R. (2018). Blockchain architectures for electronic exchange reporting requirements: EMIR, Dodd Frank, MiFID I/II, MiFIR, REMIT, Reg NMS and T2S. Handb. Blockchain Digit. Finance Incl. 2, 271–329. doi: 10.1016/B978-0-12-812282-2.00012-7

CrossRef Full Text | Google Scholar

Richards, K.-A. (2019). Modelling the dynamics of the limit order book in financial markets (Thesis), University of New South Wales, Sydney, NSW, Australia.

Google Scholar

Richards, K.-A., Peters, G. W., and Dunsmuir, W. (2015). Heavy-tailed features and dependence in limit order book volume profiles in futures markets. Int. J. Financ. Eng. 2:1550033. doi: 10.1142/S2424786315500334

CrossRef Full Text | Google Scholar

Skinner, C. (2007). The Future of Investing in Europe's Markets After MiFID. New Jersey, NJ: John Wiley & Sons.

Google Scholar

Tabb, L. (2004). Us Institutional Equity Trading 2019 Market Structure: A Buy-Side Perspective. Consulting Report, The Tabb Group.

Google Scholar

Urrutia, J. P. (2014). Living in the Post-MiFID II World (London).

Google Scholar

Valenta, M., and Sandner, P. (2017). Comparison of Ethereum, Hyperledger Fabric and Corda. Technical report, FSBC Working Paper.

Google Scholar

Will, W., and Amir, B. (2017). White Paper. Available online at: https://cryptoactu.com/wp-content/uploads/2018/12/0x-white-paper.pdf

Google Scholar