1. Simplifying the Approach to Complex Regulation
Achieving Dynamic Compliance in today’s Regulatory Landscape
25th January 2017

2. simple
solution
Implement a future proofed solution and still meet the deadlines
smart

3. Functional Requirements for a Regulatory Solution
Alerts
Flexible CEP engine and alerts definition for instant deployment and detection of trading patterns indicating market abuse, erroneous trading or malfunctioning algorithms
Multi Asset & Multi Market
High performance data capture (rates, trades, orders, news) across multiple asset classes and markets
Back-testing & Calibration
Allows surveillance analysts to test new alert algorithms against historical data and to recalibrate alerts to minimize false positives
Reporting & Visualization
Highly flexible dashboards for surveillance analysts to monitor real-time trading activity and perform post-trade analytics and reporting
Market Replay
To reconstruct market conditions and step forward and backward through order book activity for cross-market and single-market analysis
Regulatory data model (extensible, includes exeuctions/trades and market data)
APIs, manual plus automated,
RTS; best ex. Customers telling us Priority list . Are they on yours?

4. For the Techies -- Solution Architecture!!
Scalability: [Horizontal/Vertical] and Standby
Manual Entry
Native Lambda/HTAP Architecture
Stream for Kx
Reference Data
Core
Batch
Loader
Batch
Loader
Stream Engine
Ticker Plant
Stream Engine
Ticker Plant
Stream/
Complex Event Processing
Micro-services
Queries
Transforms
Event-triggered
Time-synched
Sequenced
...
In Memory
Database
In Memory
Database
eComms
Historical
Database
Historical
Database
Market Data
Stream Feed Handler
Stream Feed
Handler
Orders & Executions
q language & scripting
Pricing
Third-Party Interoperability
pub/sub, web services, change data capture,…
R, Python, Matlab, Java, ODBC, web sockets…
Everything has architecture….. But often its an afterthought ( deliver a fix first, then worry about how you did it)
... So you end up with mutiple incompatible systems
AND THEN CONSTANT DUPLICATION..

5. Key Non-technical requirements
Dynamic,
End user oriented, Interactive
Simple architecture
Performance is essential
Fast to implement and proven
Future Proof
Dynamic - more than flexible --- adaptable and EVOLUTIONARY
End User Oriented – not dependent on techies or suplliers to make changes
Simple Architecture – rubbish hadoop! NOT A SCIENCE PROJECT
Performance -- big issue -- VAST DATA, but still expect interactive response
Fast to implement/ Proven -- YOU CAN’T TAKE RISKS WITH MONTHS TO GO
Future proof

6. Compliance out of the Box
MiFID II
Systematic Internaliser
Best Ex
RTS 27/28
MAR
Alerts and more Alerts
Dodd Frank

7. Solutions Using Kx - Mifid II Examples
European Best Bid
& Offer
Trade
Reconstruction
Transaction Cost
Analysis
Best
Execution SI
Determination
PnL Impact
Analysis
Fast to ingest data, fast to retrieve data, fast to build modules and applications

8. Report Templates for Best Execution Reporting Requirements under MiFID II

9. Mifid: Systematic Internaliser
Highlights
Market Share per Instrument
Market Share, Trade Size , SI Max and SI Alert level
Instrument breakdown – Volume, Size & Market Share
In-house Volume vs Market total
A systematic internaliser (SI), recently brought into the limelight by MiFID II/MiFIR, is an investment firm or exchange that deals on its own account on an organised, frequent, systematic and substantial basis. They use their own internal liquidity pools to match orders.
The SI dashboards have been designed to help companies determine whether they meet regulatory requirements for trading as a systematic internaliser. The display takes trading data from that trading venue, for either equities or FX, and compares this to market data to allow comparison of trading volumes and market share of in-house trading vs the wider market.
The SI dashboard provides a trader with insight into their current market participation in line with MiFID2 regulations.

10. MAR: Abuse examples FX Equities Fixed Income Commodities Rates
Credit Derivatives 1
Abusive Squeeze
Yes NA 2
Inappropriate Barrier Running 3
Creating Floor or Ceiling in Price Pattern 4
Inappropriate Stop Loss Triggering 5
Prearranged Trading 6
Ping Orders 7
High Order Rate 8
Front Running 9
Inappropriate Client Allocation during Benchmark Window 10
Inappropriate Assignment (Client Orders) 11
Large Order 12
Bait & Switch 13
Benchmark Manipulation 14
Trade Cancel/Amend (Fixing Window) 15
Marking the Close 16
Pre-Auction Spoofing 17
Mark Up Breach 18
Trade Out of Bounds 19
RFQ Out of Bounds

11. More: Abuse examples FX Equities Fixed Income Commodities Rates
Credit Derivatives 20
Order to Trade Ratio
Yes NA 21
Parking 22
Partial Fills 23
Rapid Price Dislocation & Reversion Alert 24
Unusual Price Movement 25
Breaking the Market 26
Spoofing 27
Time-Order Priority 28
High Order Rate 29
Unusual Trade Volume 30
Wash Trades 31
Inter Trading (Cross Instrument Manipulation) 32
Phishing 33
Painting the Tape 34
Pump and Dump / Trash and Cash 35
Fictitious Quotes 36
Momentum Ignition 37
Smoking 38
Insider Trading 39
Attempts to Inside Trade

12. MAR: Alert Dashboard
Market Replay
Action Tracker

13. Reconstruction

14. Simple, Powerful Architecture  Proven and Future Proofed Solutions
3 q(uicks)

15. Contact James Corcoran www.kx.com www.kxcommunity.com
Senior Vice President, Engineering