A Blueprint for an enterprise full systematic technology stack

About the author and chief consultant, Monim Albeer

A purest software engineer, my view is that a best practice systematic model and trading framework is simply business specific best practice software engineering. With an entrepreneurial spirit and 20 years of experience developing enterprise software, I specialised for 10 years in high profile front office strategies, and 5 years exclusively on systematic strategies.
I have been instrumental in launching and growing several front office businesses and trading desks; in global long-short equities, CTA's, fixed-income basis and financing, global systematic macro, FX and crypto and through the general automation of financial processes. I have often had full remit (technical project manager, architect and developer) over global systematic trading solutions running billions in AUM, including the design, development and delivery of a full multi-asset historical market data system (handling billions of data points), a comprehensive model framework and a suite of portfolio management API’s, execution platforms and full trade life cycle processes, tools and applications.
Software was primarily built in C# and Python, with model integrations in Python, Matlab and R, including full stack front to back development: GUI’s, micro services, complete DevOps stack and support and monitoring tooling.
I believe my skills and experience qualifies me to propose the following blue print for a systematic technology stack.

Overall Premise

A desk structure based on tech area and asset specific execution shadowing enables this blueprint.

The document will outline the high level approach for the following systematic concerns:

Desk structure and timeline of delivery

The desk can be scaled. A functional (systematic) unit of the desk consists of:

• Research specialist – focuses on asset class specific alpha discovery
  Hiring source: systematic hedge funds and tech savvy discretionary traders specialising in an asset class
  
  
• Execution specialist – focuses on asset class specific execution algorithms (note execution specialists should be seconded into a CED to be aware of the practicalities of the markets)
  Hiring source: desk execution juniors and systematic traders
  
  
• Technologist – develops technology content to fit in a systematic platform for both specialists (signals for the research specialist and algos for the execution specialist). The other side of the job is progressing the overall framework in its three main areas: data, analytics and visualisation
  Hiring source: systematic technologists or entrepreneurial technologists. Sports betting and crypto currency technologists that architect systems are also a possibility.
  
  

Proposed Headcount of 10 people

Delivery Schedule

The delivery schedule is based on an agile schedule per unit once the framework is in place.

Framework – 6 months

Units would deliver in 2 week sprints (signals and algos)

Management Approach for the desk head

There is no consistent desk head. The only consistent managing director is the CTO.

The desk head will change dependent on release at hand. For example if it is the launch of a new signal the research specialist of the asset class the signal applies to will take the lead. If multiple then the role is shared via a committee approach.

The CTO is responsible for the design, delivery and maintenance of the framework and facilitates content releases in agreement with senior management. There is a dotted line of all desk members to the CTO, after all, they are all creating technology IP.

The (optional) Head of Research sets the research agenda, however, I instead propose a small committee consisting of the appropriate fund chiefs, CTO and research specialists, and also including a guest senior product specialist.

Research Agenda

The research agenda should have 2 parts:

   1. The long-term agenda (5 years plus) – greenfield research primarily

   2. The mid-term agenda (6 month projection)

The short term agendas are built into the technology agile sprints per unit.

The research agenda should be set every 6 months by committee or Head of Research.

Data Architectures

The following 3 systems are required:

Historical market data system HMDS (long term, flexible & multi-asset ) - mainly used for backtesting

The next natural step is to build “adapters” into multiple quant languages including python and Matlab

The system can be extended to handle non-structured data for example weather pattern data or calendar schedules – these structures would automatically be available as a data time series.

Data driven data sourcing ETL layer (standardises data) – feeds the HMDS above

The next natural step is to build a graph database that captures more complex relationships between data and strongly leverages the above 2 technologies

Realtime market data system RMDS (very short term, rigid & combined with NLP processes)

An addendum is to add a tick sourcing layer as an extension of the ETL which can (optionally) build its own HMDS. This would effectively be a tick database under the hood. (Buying tick data is a separate concern of the overall HMDS)

The NLP process effectively allow for newsflow data to be delivered in a consistent framework. The NLP untis can be integrated with bigger NLP units like Reuters or Ravenpack

Model Framework blueprint

The model host service can be decomposed into:



The Model output view service transforms the raw model data into derived data sets like historical signal matrices and returns series. This data can then be visualised in a web or desktop GUI.

The other services are dependencies that are required for market and reference data.

Portfolio construction and management blueprint

A portfolio is simply a hierarchy of concepts, essentially a graph that needs to be recorded. If the building blocks to get there are robust, this is simply a job of collating information through the system and having the history for those collations.

Portfolio

The management of the portfolio should be fully automated besides the execution of the tradable portfolio.

Examples of the difference between an asset and real instrument:

An asset is a concept like a region or a sector

An asset is a non-time specific instrument, i.e. the concept of an instrument like “bunds”, “Eurodollar swaps” or “top ten S&P tech stocks”

An instrument is a real tradable asset that is bound by law such as the September future contract on the IBEX index or bund.

An instrument is a swap agreement.



One of the most fundamental decisions that needs to be made in a successful enterprise systematic technology stack is when models use assets vs real instruments in their computations. This decision needs to permeate though the entire tech stack.