Automated trading system ATS - in a Concurrent Linear Framework CLF

Formalization of automated trading systems
in a concurrent linear framework
Dragiˇsa ˇZuni´c
joint work with: Iliano Cervesato, Giselle Reis and Sharjeel
Khan
QNRF research project seminar
Carnegie Mellon University in Qatar
October 24, 2018.
£
1 / 56

This work was funded by the QNRF as project NPRP
7-988-1-178
Project name: Automated veriﬁcation of properties of
concurrent, distributed and parallel speciﬁcations with
applications to computer security
– Prof. Iliano Cervesato (CMU) Lead-PI
– Prof. Giselle Reis (CMU-Q), Co-Lead PI
A continuation of NPRP 09-1107-1-168 (Formal Reasoning
about Languages for Distributed Computation)
£
2 / 56

Outline
Automated trading system ATS
Concurrent linear framework CLF
Formalization of ATS in CLF
Towards automated reasoning
£
3 / 56

Outline
£
4 / 56

General context
Trading venues (public and private) are complex systems
Inﬁnite state-space
At the same time
– the system must comply to regulations (natural language)
– the system must be in accordance to its speciﬁcation
(natural language)
. . .
£
5 / 56

General context
Furthermore
– order types may need to be added or changes
– regulation rules may evolve
Hard to detect ﬂaws (intended and unintended) in design and
implementation of trading venues
Systematic approach is needed
£
6 / 56

Compliance to regulation
Every official trading system, whether alternative (e.g., dark pool)
or public (stock exchange), must satisfy certain regulatory
requirements:
(focus on alternative)
submit the so-called “SEC Form ATS” - describing system’s
operation in english
meet the general requirements/guidelines defined by the
regulatory bodies (SEC 1), also in english
A real challenge for financial institutions.
1. U.S. Securities and Exchange Commission. £
7 / 56

Compliance to regulation
Institutions are facing a challenge in assuring regulatory rules are
satisfied – recent SEC fines :
Deutsche bank (US$ 37M, in 2016)
Barclay’s Capital (US$ 70M, in 2016)
Credit Suisse (US$ 84M, in 2016)
UBS (US$ 14M, in 2015)
Goldman Sachs (US$ 800K, in 2014)
Since 2011, more than US$ 230 million paid in fines to regulator
for alternative trading systems. 2
2. Source : https://www.wsj.com/articles/
wall-streets-dark-pools-face-new-transparency-rules-1531924509. £
8 / 56

Until 2009 trades on the ﬂoor of the New York Stock Exchange always
involved a face-to-face interaction. Electronic order matching was
introduced in the early 1980s in the United States (Chicago Stock
Exchange) to supplement open outcry. 3
3. Source : Wikipedia £
9 / 56

Automated trading system (ATS)
Modes of operation
price/time priority, or FIFO
– Price is the most important, and then comes time.
– All (resident) orders at the same price level are filled
according to the time priority ; the first-arrived order at a
given price level is the first order matched.
Pro-rata priority
Ignores the time the orders were placed, and allots quantities
to all orders at a given price level, according to their relative
quantities.
£
10 / 56

Automated trading system
Types of orders
An order is an investor’s instruction to a broker to buy or sell
securities (or any asset type traded on a ﬁnancial exchange), thus
we have buy orders and sell orders
£
11 / 56

Types of orders
Elementary types of orders :
Limit (or limit-price) order
Has set a speciﬁc limit price at which it is willing to trade ; it
will trade at the limit price or better.
Market order
Does not care about limiting its price ; it wants to trade
immediately at the best available/market price.
£
12 / 56

Types of orders
There are less general types of orders (hundreds of them)
IOC - immediate or cancel
FOK - ﬁll or kill
AON - all or none
Day, month, minute, etc.
Conditional
Stop
Peg
£
13 / 56

Automated reasoning
formalization of a general ATS (in CLF/Celf 4).
proving properties about ATS (including regulatory conditions)
4. CLF framework is implemented as the tool Celf
https://clf.github.io/celf £
14 / 56

£
15 / 56

£
16 / 56

UNIT-SIZE orders
Every order assumed to be of quantity 1, for simplicity
£
17 / 56

Operation : ADDING an incoming buy order
£
18 / 56

Operation : ADDING a buy order
£
19 / 56

£
20 / 56

£
21 / 56

Operation : EXCHANGE takes place - FILLING orders
£
22 / 56

£
23 / 56

£
24 / 56

£
25 / 56

GENERAL-SIZE orders
£
26 / 56

GENERAL-SIZE model - operations
£
27 / 56

GENERAL-SIZE model - operations
£
28 / 56

Real life examples : GDAX (Coinbase)
– Bitcoin market visualization
– (... also called the “depth chart”)
£
29 / 56

Real life examples : GDAX (Coinbase)
Midpoint price movement over time
(... also called “price chart”)
£
30 / 56

Real life examples : BINANCE
£
31 / 56

Real life examples : BINANCE
£
32 / 56

Outline
£
33 / 56

Logical frameworks
Concurrent linear framework, CLF
A logical framework is a meta-language for
representing deductive systems, and
reasoning about them
Concurrent linear framework (CLF), is based on Linear logic.
Linear logic connectives :
⊗ – multiplicative conjunction – linear implication
Instead of emphasizing truth (classical logic), or proof
(intuitionistic), linear logic emphasizes the role of formulas as
resources.
£
34 / 56

Logical frameworks
Concurrent linear framework, CLF
The majority of our encoding involves clauses in the following
shape (for atomic pi and qi ) :
p1 ⊗ ... ⊗ pn
consumed
{q1 ⊗ ... ⊗ qm
produced
}
The resources
on the left of are consumed
on the right of are produced
£
35 / 56

Outline
£
36 / 56

ORDER STRUCTURE
An order is represented by a linear fact
order(O, A, P, ID, N, T)
where
O is the type of order
A is an action
P is the order price
ID is the identiﬁer of the order
N is the quantity
T is a unique time stamp
£
37 / 56

ORDER STRUCTURE
An order is represented by a linear fact
order(O, A, P, ID, N, T)
where
O is the type of order ← either limit, market, cancel, ioc
A is an action ← either buy or sell
P is the order price ← natural
ID is the identiﬁer of the order ← natural
N is the quantity ← natural
T is a unique time stamp ← natural
£
38 / 56

RULES for handling orders 5
The basic actions are
filling/exchanging an order (partially or completely) -
exchange takes place
adding an order to the market - becomes a resident order
cancelling an order - special kind ; a directive to modify the
market’s state
Remarks : Only limit order can be added to the market, i.e.,
become resident order. Other types are (by their definition) either
filled immediately or discarded.
5. Reminder : we are in a price/time priority, or FIFO, mode £
39 / 56

RULES - ADD, FILL, CANCEL
Adding
Filling
limit-price
market
IOC orders
. . .
Cancelling
£
40 / 56

Adding ← only limit-price orders
Filling
limit-price
market
IOC orders
. . .
Cancelling ← only limit-price orders
£
41 / 56

Adding ← only limit-price orders
Filling
limit-price
market ← similarly
IOC orders ← similarly
. . .
Cancelling ← only limit-price orders
£
42 / 56

INFRASTRUCTURE
We need to keep track of
two lists : (1) of active buy-prices, and (2) of active sell-prices
activePrices(A, L) where A is either buy or sell.
for each active price there is a queue (as a list 6) of orders
priceQ(A, P, C) – for an action A and price P, queue C
time - order handling depends on time
time(T) – where T is the current time
queue of orders waiting to enter the market
queue(Q) – where Q is a list of incoming orders
6. Due to cancel operation we sometimes need to remove resident orders,
thus lists instead of queues £
43 / 56

INFRASTRUCTURE
the list of active buy-prices and active sell-prices (lists)
activePrices(A, L) – for an action A, the list L contains all
currently available prices in the market. For example, if there is
a sell order asking for $10, then 10 is in the list L for A = sell.
This list is kept sorted in ascending order.
for each active price there is a queue (a list 7)
priceQ(A, P, C) – for an action A and price P, queue C
contains all resident orders with those attributes. The orders are
sorted in ascending order based on timestamp. We maintain as
an invariant that the price queue can never be empty.
7. Due to cancel operation we sometimes need to remove resident orders,
thus lists instead of queues £
44 / 56

INFRASTRUCTURE
time - orders depend on time
time(T) – represents the time of the system where. As the sys-
tem runs state transition rules, the time increases the unit of
time. In the future, this can be used for managing orders with
an expiration : day orders, month, at-the-opening, at-the-close.
queue of orders waiting to enter the market
queue(Q) – represents the order queue in which orders are in-
serted for processing.
£
45 / 56

INFRASTRUCTURE
The begin fact is the entry point in our formalization. This fact
starts the ATS :
begin
{queue(empty) ⊗
activePrices(buy, nil) ⊗ activePrices(sell, nil) ⊗
time(z)}
£
46 / 56

All rules for FILLING limit orders
limit/1: queue( order(limit, A, P, ID, N, T) :: Q) ⊗ dual(A, A ) ⊗ activePrices(A , L ) ⊗
exchange(A, L , P, X) ⊗ priceQ(A , X, [(ID , N , T )]) ⊗ remove(L , X, L ) ⊗
nat-equal(N, N ) ⊗ time(T)
{queue(Q) ⊗ activePrices(A , L ) ⊗ time(s(T))}
exchange(A, L , P, X) ⊗ priceQ(A , X, [(ID , N , T ) :: (ID1, N1, T1) :: L]) ⊗
nat-equal(N, N ) ⊗ time(T)
{queue(Q) ⊗ activePrices(A , L ) ⊗ priceQ(A , X, [(ID1, N1, T1) :: L]) ⊗ time(s(T))}
exchange(A, L , P, X) ⊗ priceQ(A , X, [(ID , N , T )]) ⊗ remove(L , X, L ) ⊗
nat-great(N, N ) ⊗ nat-minus(N, N , N )
{queue( order(limit, A, P, ID, N , T), Q)) ⊗ activePrices(A , L )}
exchange(A, L , P, X) ⊗ priceQ(A , X, [(ID , N , T ) :: (ID1, N1, T1) :: L]) ⊗
nat-great(N, N ) ⊗ nat-minus(N, N , N )
{queue( order(limit, A, P, ID, N , T), Q)) ⊗ activePrices(A , L ) ⊗
priceQ(A , X, [(ID1, N1, T1) :: L])}
limit/5 : queue( order(limit, A, P, ID, N, T) :: Q) ⊗ dual(A, A ) ⊗ activePrices(A , L ) ⊗
exchange(A, L , P, X) ⊗ priceQ(A , X, [(ID , N , T ) :: L]) ⊗ nat-less(N, N ) ⊗
nat-minus(N , N, N ) ⊗ time(T)
{queue(Q) ⊗ activePrices(A , L ) ⊗ priceQ(A , X, [(ID , N , T ) :: L]) ⊗ time(s(T))}
£
47 / 56

Example exchange rule - simpliﬁed (limit/1)
Filling orders – an incoming buy order has price P ≥ ask, where
minP(LS , ask). N = N .
limit/1: queue( order(limit, buy, P, ID, N, T)
to be ﬁlled
:: Q) ⊗
activePrices(sell, LS ) ⊗
minP(LS , ask) ⊗ P ≥ ask ⊗
priceQ(sell, ask, [(ID , N , T )]) ⊗
remove(LS , ask, LS ) ⊗
N = N ⊗
time(T)
{queue(Q) ⊗ activePrices(sell, LS ) ⊗ time(s(T))}
£
48 / 56

Example exchange rule - simplified (limit/3)
Exchange/filling takes place – an incoming buy order has price
P ≥ ask, where minP(LS , ask). Case when N > N .
limit/3: queue( order(limit, buy, P, ID, N, T)
to be partially filled
:: Q) ⊗
activePrices(sell, LS ) ⊗
minP(LS , ask) ⊗ P ≥ ask ⊗
priceQ(sell, ask, [(ID , N , T )]) ⊗
remove(LS , ask, LS ) ⊗
N > N ⊗
{queue( order(limit, buy, P, ID, N − N , T) :: Q) ⊗
activePrices(sell, LS )}
£
49 / 56

Outline
£
50 / 56

Basic properties
Some of the standard requirements for trading systems :
1. The market is never in a locked or crossed state
– maximum buy (bid) strictly less than minimum sell (ask)
2. The trade always takes place at either bid or ask price
3. Order priority is always respected
4. Transitivity of order ranking (order priority is transitive), as a
necessary requirement
£
51 / 56

Basic properties
Explore methods for building proofs that can be automated
A method that includes so-called generative grammars
£
52 / 56

Basic properties
The market is never in a locked or crossed state
– deﬁne the generative grammar
– proof follows a general schema which can be illustrated as :
gen(Q, LB, LS , T)

gen(Q , LB, LS , T )

State-1
ATS // State-2
– the proof then consists of showing the existence of .
£
53 / 56

Conclusion and future aspects
Two challenges
theory for automating meta-reasoning in CLF (designed for
concurrent distributed and parallel speciﬁctions)
consider ﬁnancial models (trade systems) with more
concurrency and parallelism (remotely related to designing feir
markets, and the issues with HFT)
£
54 / 56

References
I. Cervesato, S. Khan, G. Reis and D. Zunic. Formalization of
Automated Trading Systems in a Concurrent Linear Framework.
Linearity TLLA Workshop, Oxford UK, 2018. (accepted)
I. Cervesato, K. Watkins, F. Pfenning and D. Walker. A Concurrent
Logical Framework I : Judgements and Properties. Technical Report
CMU-CS-02-101, CMU Pittsburgh, 2003.
I. Cervesato, F. Pfenning, D. Walker, and K. Watkins. A Concurrent
Logical Framework II : Examples and Applications. Technical Report
CMU-CS-02-102, CMU Pittsburgh, 2003.
G. O. Passmore and D. Ignatovich. Formal Veriﬁcation of Financial
Algorithms. In : CADE 26, 2017.
R. J. Simmons. Substructural logical speciﬁcations. Ph.D. thesis,
Carnegie Mellon University, 2017.
£
55 / 56

Thank you
This research was made possible by grant NPRP 7-988-1-178 from
the Qatar National Research Fund (a member of the Qatar
Foundation).
£
56 / 56

Automated trading system ATS - in a Concurrent Linear Framework CLF

More Related Content

Similar to Automated trading system ATS - in a Concurrent Linear Framework CLF (20)

Recently uploaded (20)

Automated trading system ATS - in a Concurrent Linear Framework CLF