The Trader Management Portal and Trade DSL for Simpler Portfolio Management

The Problem Statement

Implementation Velocity is real and we wanted to provide a coherent way for customers to manage their Portfolio Management user experience. We as a technology solutions provider sought to balance:

• Reducing new releases
• Make our front-end metadata driven, thereby making most updates configuration driven
• Accept that our front-end may have limitations but provide the "know-how" for customers to streamline implementation velocity

What our DSL Editor Really Does

• Takes highly complex service data, simplifying it for users
• A metadata driven front-end, zero hard-coding of our Domain Logic within the software
• Allows customers to manage their trade rules and other System Information
• Avoids needing security information inside saved definition files
• Allows us to roll out enhancements faster

Who is our Trader Management Portal for?

• Professional traders
• Portfolio managers
• Quant teams
• Risk teams
• Operations teams
• Developers integrating with our platform

Can our Editor Portal Serve your own needs?

So powerful is the metadata driven approach, we can build the Server Infrastructure and Metadata approach to serve a variety of front-ends.

Reach out if interested.

Requirements for the Prototype Trader Management Portal

The remit for the prototype was to:

• Create a UI that did not simply replicate the JSON file verbatim
• Focus on only exposing data relevant to the domain - i.e. that users weren't overwhelmed with field that weren't necessary
• Could work with our rich reporting datasets to add displays such as charts
• Not replicate what the Trading Exchange already gave users where possible - the Trading Exchange is the "Ultimate Source of Truth!"
• Sadly, the original prototype did not match these expectations

We set about a radical re-envisioning of what we wanted to experience as users and system developers.

Requirements for the New Trader Management Portal

Our remit for our production version:

• The Business Domain is the answer - each entity should only expose what is required
• Users should be able to not only manage the necessary fields in an entity
• The front-end should be metadata driven - no hard-coding to TypeScript or other Domain Specific Logic
• To add new Entities for managing without changing the front-end code in almost all circumstances
• To remove the need for API Keys and other security information by matching on portfolio name to the front-end
• To give the user a Human Readable and Editable Domain Specific Language
• Copy Capability of certain data to reduce re-editing the same but similar information
• To accept that the new TMP may not be as fully feature rich as a traditional rich client - the focus is on extensibility
• To leave the heavy lifting to the API and metadata generation routines
• Accept the Domain Specific Language is not a true expression tree, recursive parser as seen with YAML and other true Domain Specific Languages

Intermediate JSON (IJSON)

• This is the system view of trade data created by the user in the TMP Trade Editor
• This is what the user saves locally and can reload later
• Whilst it is passed to the API along with the Trade DSL, it is not used by the API

Trade DSL (DSL)

• This is a text-editor nested-block based representation of the Intermediate JSON
• This is what the user saves locally and can reload later
• It is passed to the API and parsed
• If successfully parsed, it is returned to the data as System JSON

System JSON (SJSON)

• SJSON is what our platform truly understands
• SJSON is more complex in nature, representing Trade Operations, Trade Rules and Trade Artifacts
• Trade Operation Types are typically verbose and hard for users to manage
• System JSON can be independently saved, edited and submitted to the System independently if required

Main Workflow

1. Choose our Trade Operation Type
2. Edit Rules within the Editor
3. Save the Intermediate JSON to disk
4. Save the generated DSL to Disk
5. Pre-stage and validate the DSL via the API
6. Upon Review of the SJSON, submit for trading

How else do we speed up Trade Rule Creation?

• Version Trade Rules in Source Control
• Use tools to extract and merge IJSON, SJSON
• Copy snippets into IJSON and SJSON
• Reload Trade Rules into the Trader Management Portal
• Edit in DSL to ease analysis and copying/merging of rules and blocks

Snippets and Samples

We cannot give users guidance on what rules to configure and what rules may work for individual customers.

We can provide samples of rules to help users test against small portfolio balances to aid them when creating trade rules for themselves

Adding Configurability

The system contains significant internal configuration. Some of this configuration, should be given back to the user. We are likely to give users the ability to change certain configuration.

Embedded Reporting Dashboards

We will embed our reporting dashboard. Again, as per our design principles, this works with our generic API and we are likely to make this configuration driven over coding to specific hand-crafted dashboards.

Two-Way IJSON to DSL translation

Our system is one way only, we can only move from IJSON to DSL.

Our plan is to make this two way to permit interoperability and additional usability for customers.

Limiting and Enhancing the Flexibility of the TMP

The TMP is too powerful in some respects:

It provides data that model wise, wouldn't make sense in the real world. We are adding restrictions and extensions to the TMP

Whilst we have a powerful editor, there are still some innate features where DSL and IJSON cannot fully represent SJSON. Customers may still need to maintain their own SJSON. We are investigating better approaches.

We always welcome customer feedback on the TMP capability

We are uncertain as to whether we will integrate our Key Management Capability into the TMP. We prefer short-live key data over living in the session state of the TMP

Customers can develop their own tools

We don't want to tie customers into every way that we do things. Customers with multiple instances may prefer to create their own portals, conforming to our security standards or potentially - we discuss new approaches.

We are planning different methods of trade execution and reducing API requests to increase trading capacity.

Some customers and engineers may wish to share in enhancing our platform.

Extra Rule Merging Capabilities within the Software

As our team uses and tests our software, we identify clear gaps needing plugging.

We always focus on this gap plugging being extensible and configurable over hard-coding.

Customers may still prefer to use their own tools to port logic between different strategies.

Yet, where plugins exist that can benefit customers within the Trader Management Portal, we will add this if customers wish so.