2. About Me
● Software Engineering / Technology Background
● MSc Applied Computing
● Masters in Finance, London Business School
● Moved to the trading business in 2014
● Leading Asia quant team based in Singapore
3. About
● Overview and Introduction
● The Modern Trading Business
● Analytics Infrastructure
● Case Studies
○ Pricing
○ Hedging and Risk Management
○ Client Analysis
○ Algorithmic Execution
● Takeaways
4. Overview
● eFinancial Engineering == Quant
● Application of quantitative techniques / statistical analysis to the trading business
● Successful delivery relies on expertise in
○ Domain / business knowledge
○ Mathematics / statistics for data analysis
○ Software engineering / coding
● Heavy emphasis on coding
● Manage ‘the machine’
● Come up with ideas and strategies
● Research new models and techniques
5. The Trading Business
● 24 x 5.5 business
● Heavily automated
● Globally distributed, co-located in major trading centres
● Challenges
○ Latency (𝜇s resolution on market data)
○ Data deluge (billions of data points / day)
○ Separating the signal from the noise
● Modern trading business is highly automated, extremely technical, and analytics-driven
● The business runs on data
6. The Trading Business Evolution
● Heavily manual
● Voice sales / telephone channel
● Multiple overlapping traders /
specialists
● Pricing / hedging are manually-
driven
● Initiating a deal conversation to
executing the deal ticket can be a
couple of minutes
7. The Trading Business Evolution
● Electronic sales platforms
● Voice sales migrating to ‘e-Sales’
● Better connectivity
● More electronic trading venues
● Pricing and hedging becoming
automated / electronic
● Less manual intervention required
8. The Trading Business Evolution
● Pricing / hedging fully automated
● Voice channels superceded with
electronic APIs
● Globally distributed trading but
colocated in major trading centres
● Linked by high-speed networks
● A new type of trader: the ‘e-Trader’
● Trading is high-frequency
● Data volumes are immense
● Deal execution time pipelines
measured in µs
● Many venues: ECNs, dark pools,
exchanges
9. Analytics Infrastructure
● Regionally distributed high-performance tick database - Everything relevant goes in here
○ High-frequency tick data
○ Orders and trades
○ Signals
○ Administrative and operational messages
○ Decisions taken by the hedging and pricing engines
○ ~ 10 years of historical data
● Lots of analytics code
● Different tools for different jobs: q, R, Java, Python
● Visualisation tools – dashboards / drill-downs
● Reusable reporting infrastructure
● No large frameworks
14. Case Study 1 : Pricing
● In a decentralised market (such as FX), the objective is to find the ‘true’ market price
● Take in a stream of data points from N different market sources
● In real-time attempt to discern correct market level
● Market microstructure knowledge critical
● Latency-critical
● Estimation of volatility signals and price blending
● Lead-lag tradeoff / breakouts
● Models are generally heuristic-based
● Trained on huge amounts of data
15. Case Study 2 : Risk Management / Hedging
● As clients and market counterparties trade with us, our risk profile changes
● This risk must be monitored in real-time and appropriate hedging decisions made
● Many input factors: hedging cost, volatility regime, position size, etc
● Output: A decision - do not hedge / hedge with an appropriate level of urgency
● How to hedge – optimising the risk/return payoff
● The hedging model involves many different sub-models or strategies
● All are parameterised and backtested
● Every trading decision can be analysed in detail after the fact
16. Case Study 3: Client/Flow Analytics
● As clients trade over time we build up a performance profile
● Simplest measure is basic profitability
● We can identify those counterparties whose trading style can be classified as ‘toxic’ or
has high market impact
● More importantly we can attempt to determine why the flow is toxic
○ Not always a deliberate trading strategy by the client
○ Examples: correlated flow, aggregator logic, technical
○ The flow profile can be optimised by making decisions based on the data
● Avoid ‘adverse selection’
● Identify changes in trading behavior over time – enable proactive sales engagement
17. Case Study 4: Algorithmic Trading
● Consider a client who needs to execute a large amount in the market
○ Wants to minimise execution cost / slippage / information leakage
○ May have requirements on urgency levels, timing, market impact
● Algo trading outsources execution management to the machine
○ Previously a human trader may have managed the order execution
● Previously , a client may have called a sales desk, said “Sell me 500 million EURUSD”
with some caveats and the trader would have manually worked the order
18. Case Study 4: Algorithmic Trading
● Now the machine can take an order instruction like:
○ Execute a 500,000,000 EURUSD Sell order
○ Execute a time-weighted average price (TWAP) model
○ Do not take longer than 3 hours to execute the order
○ When executing show no more than 1,000,000 visible size at any time in the market
○ Execute in line with market volatility
○ Execute as much of the order passively as possible
○ If the market price goes below 1.1334 cancel the order
○ Prioritise executing on venues with low market impact
○ All while making sure all of the appropriate regulatory information is generated
● This is extremely difficult to manage manually!
19. Case Study 4: Algorithmic Trading
● Algorithmic trading strategies are designed and backtested using the analytics
framework
● Every decision the algo makes is informed by market analytics and quantitative models
● The algo will attempt to dynamically determine the optimal execution strategy given the
order parameters and constraints
● Post-order completion ,the analytics framework produces a detailed report of the order
execution – again using the analytics framework
20. Challenges
● Market fragmentation
○ More venues, more data sources, more cost
● Managing the data deluge
○ Both capacity and cost
● Market volatility
○ Algos trading with algos
○ Liquidity is thin and disappears in a flash
○ Algo behavior is highly correlated
● Is automation a help or a cause?
21. Key Lessons Learned
● Domain knowledge is critical
● Garbage-in, Garbage-out (GIGO)
● The data pipeline and its integrity are crucial
○ Some people refer to this as ‘data hygiene’
○ 90% of time spent cleaning / normalizing / matching data
● Apply good software engineering techniques
○ Write clean, reusable analytics code
● Prefer parsimonious models
○ Keep it simple .. Or at least as simple as possible
○ Can you explain your model behaviour?
● Keep up to date with research but be suitably sceptical when reading machine learning
investment model papers!