Various Principles On Decision Trees in Stock Trading

A trader has to take many decisions and over a period of time he develops wisdoms, principles, strategies, trade plans and actions them out. This is an attempt to layout a structure.

A wisdom is a fully defined decision tree

A wisdom is a decision tree of principles
a principle is a decision tree by itself
When principle meets data decision is derived
A decision is a product of a decision tree
A decision tree is a product of a decision
My actions are my revealed preferences
my revealed preferences are my decision trees
Sometimes i learn new behaviours , those are decision trees I added to me

A strategy is a decision tree with environmental inputs defined- either as constraints or as incoming datapoint.

Choice has a basis or a reason.

Reasons are deterministic datapoints.

All sets of choices during a transaction I can make defines a decision tree.

A trading plan is a defined decision tree for a strategy.

Where ever there is an option, there is a decision tree.

A sample transaction decision tree

Chosen Instrument is a given starting point. A state of environmental variables is a given — CMP, OI, Order Book, values of various indicators, capital, allocation, bucket positions etc.

Buy-Sell is a choice.

Buy — new entry or exit , if exit — partial or full

Sell — new entry or exit , if exit — partial or full

 

Then trading terminal offers MIS/NRML , Market/Limit/SL/SL-M , Day/IOC, Regular/BO/CO/AMO. The user makes choices along this transactional decision tree. Every choice made from a group is every other choice not made.

Price & Quantity are also choices, which we’ll currently not include in the decision tree for simplicity sake.

Event: The event that happens post which one branch of the bayesian tree is irrevocably chosen. e.g. The buy transaction based on above choices.

Outcome: Let us for simplicity sake tie up value of a decision tree to a single quantifiable outcome and see various values for this outcome over a defined time frame. e.g. over next 1 hour, next 4 hours, today, this week, this month, matching with usual trading timeframes. Outcome starts after event occurrence. The outcome is calculated for the branch actually taken.

Alternate Outcomes: The outcomes calculated for each unique branch of the tree that could possibly have been taken.

At various timeframes, the value of outcome and alternate outcomes are compared. At various timeframes, there could be the chosen path or any one of the alternate path that has a better pay-off. These values form the basis of further analysis.


Consider a sample case for answering should I put market order or limit order while trading in cash/F&O segment, which decision is better.

At the timestamp of such a trade being executed- there is environmental data like order book, LTP, and subsequent tick data that allows one to build

X = entry price at limit order since subsequently LTP ticks show whether the limit order would have been executed or not and after how long.

Y = market order that results in picking off best bids

A difference between X & Y indicates cost of market order. Consistent positive difference indicates amount of overcharge due to market order and used to calculated probability and show recommended trade as limit order in case of option market , as I’ve discovered.

Consider another case: should i trade intraday or carry my trades?

Often intraday traders receive margin financing versus carry trades that require providing for full margin. This leads to smaller trades.

I would like to answer if I was better off trading intraday and larger sizes or trade smaller with larger capital can carry the trades. What is the impact on my IRR.

With outcome payoff calculated over various time frames, we can find the difference or multiple between intraday versus day of closing event profits/losses to arrive a ratio of intraday versus carry trade profits and if the ratio is smaller than what i would have gained using margin through intraday trade- an alternate trade recommendation would suggest trade type intraday & trade quantity as larger quantity as a decision path with higher payoff.

Source: www.medium.com

Embedding OpenSource Product into Our React HRM Product

We have an HR Management Product NeoHRM and wanted to build a feature that captures the culture of the firm and helps build the community around knowledge management related to core DNA of the firm through Q&A.

Further, the idea was to measure the participation of employees into the knowledge management process and identify people who advance the capabilities of the firm with their problem-solving approach. We were considering open source forums since the focus of our value was in measuring the interactions and establishing a feedback loop to the employee, so third-party product with custom measurement index would suffice.

Design Challenge :

Embed open source product developed with Ruby on Rails into our React application.

The EXISTING system design:

  • Open source product is hosted as a sub-domain
  • User logs into the HRM management product.
  • Navigates to the UI to find himself landing into the discussion panel as a completely new link.

Problems with this approach:

  • Multiple redirects for user tokens between both the products which increased the loading time and had a bad user experience. Need to reduce the loading time of screens.
  • Between these redirections, user sees a blank screen and has no clue about what’s going on. Remove screen transition gaps for better user experience.

The PROPOSED system design:

Constraints:

  • Both the products should be hosted under the same domain.
  • No code integration. The interaction between both products will happen through event and data exchanges.
  • The open source product is hosted in a docker on the independent EC2 instance

What are we solving for:

  • Combining two products as one through a micro front end approach
  • Faster and seamless interactions between the wrapper and embedded product
  • Designing Event bus to communicate across micro front ends.

How we solved the problems:

Problem no. 1: The micro front end approach

iFrames to render embedded product:

Product Screenshot on left where section highlighted will embed the UI on the right as a micro front end. The problem with embedding this micro frontend was we had 2 headers, one of each product. It was decided to hide the wrapper header and show those options in the left navigation when the micro frontend is embedded.

Steps to follow:

1. Read the current Route(URL)

2. Based on the route(URL) of the page, when it matches with the micro frontend specific link, the wrapper header is not shown and the UI is altered to show the header options is left navigation.

Wrapper Product

 

Micro Frontend

The wrapper product screenshot showing area which will embed the micro front end.

Problem no. 2: The loading time 

Convert redirects to XHR request:

These redirects can simply be converted to XHR requests to get the user token and then the final link is opened in the embedded micro frontend using the iframe.

In our case since both the products are hosted under the same domain so CORS issues are not to be tackled.

Problem no. 3: Designing Event bus to communicate across micro front ends.

Both the wrapper and the micro frontend had to communicate based on events and exchange data.

For two way communication between the wrapper and micro frontend, REST APIs and Webhooks are used.

1. Micro frontend REST APIs are used to send data from the wrapper product. List of APIs here.

2. WebHooks are set up in the micro product which is triggered for different types of events. Link to setup Webhooks.

Source: www.medium.com

The Switch

At Prodio, we have quarterly goals of lifting our development process up to next level based on pre-defined roadmap. That roadmap is not very clear, but pretty good in it’s approximation, and by the time we arrive there, we’re clear.

I call this The Switch. Once it is down, the inevitable consequence of it follow for the whole organisation. We fondly and regularly flip this switch. A new one is coming.

Recently chanced upon an article on Netflix Techblog and ended up overlapping it with out thought process to see if we’re in right direction. Seems we’re. So this is a little comparison of what we do that they do followed by what we intend to do next.

Where we are similar: We have teams dedicated around products and see their work as building and delivering products.

The portion of this philosophy that we need to cover next are:

  • The developers must participate in product definition and design process

They must be able to place the value of Epic-Feature-Requirement relationship and why a particular requirement is prioritised for delivery currently. For a given requirement they should be able to define the persona and user journey and list the value expected off that journey. They must be able to link this to UX patterns and choose a given UX pattern to achieve the objective. They must be able to check the UX/UI for logicality/Consistency/Contradiction test and should be able to write all test cases comprehensively to reduce future iterations.

  • The developers must participate in architecting process

The developers should be able to evaluate for a given new requirement the relationship with the underlying data model and architecture diagram and introduce definitions & test cases for backend required and check for impact.

  • The developers must be able to anticipate disruptions and look out pre-emptively

Library upgrades, OS upgrades, appstore policy changes, third party integrations bringing changes etc must be converted into a tangible framework for staying on top of potential changes


Where Netflix has created ‘centralized teams’ , our idea is to create an ‘engineering’ team. This team takes care of:

  • Infrastructure architecting & management
  • Monitoring
  • Tools
  • Design, architecture and patterns
  • Feedback & training

The brief of this team is to prepare a visibility map for upcoming product developments and laser sharp focus on accumulation of any Tech Debt in our portfolio. We’re setting uptill June’19 to convert these into tangible measurable processes.

Source: www.medium.com

Upon Axiomatic Thinking

As we walked in semi lit lanes of our tree covered area in this winter evening, the pleasure of clients turning friends started peeling layers upon layers.

The man is at the starting point of many bayesian forked forest of his entrepreneurial journey and pondering on some deep questions. The choices he makes will be a revelation of his character under formation, but which will leave closed the alternate paths not taken. He needs a friend to navigate.

Men who have travelled ahead, each offer him their preferences. Those in turn revealing their character.

But my advice is:

You must at any points carry your own certain Axiomatic Truths to navigate these decision trees. These may be few. But often having just one , renders rest of the carefully arranged thinking superfluous . A decision is often derived from the axiom you hold dear.

I offered him three of mine:

  1. A successful product is a densely packed bundle of logical value proposition for a user. Mixing value propositions of other stake holders may kill it.
  2. Any product must aim for monopolisation of its ecosystem by relentless market fit feedback to product development roadmap
  3. The capital that comes with no terms and no horizon surrenders it’s entire optionality to the product, leading to best environment for axiom 1 being fulfilled in a startups life. So that capital is good for product

Source: www.medium.com