Skip to Content

rblncr | The case for declarative portfolio management

Posted on 5 mins read

This blog post is part of an intended series around an as-yet-unbuilt R package called rblncr, which will facilitate declarative equity portfolio management. Initially, it will integrate with Alpaca, but extensions to other brokers should be possible.

When I worked as an equity analyst at a local asset manager the division between portfolio construction and implementation was quite stark. The basic fault line was between determining what you should hold, and actually doing the trades. In plain terms, the analysts and the traders. Straddling these worlds was the performance and attribution team, who would compute where the alpha (or negative alpha, ha ha) was coming from so that higher ups had some content to base bonus allocations on.

I left that firm in 2017 to go study data science, and a big motivation for that was that I was frustrated at how much of my work was repetitive, automatible tasks. My claim at the time - and I’ve repeated it many times since - is that analysts and portfolio managers are primarily employed to exercise judgement. But analysts spend a very small amount of their time actually exercising judgement - most of the time they are downloading PDFs, looking for data, manually typing it into excel spreadsheets, etc etc. I thought that the firm that embraced this sort of knowledge work automation would develop a natural competitive advantage.

The trading side of things is not immune to this sort of thinking, and, in fact, prospects are even better for automation in this arena. While automation in research would require some novel work, automation in trading is basically a solved problem, and what’s holding you back is adoption. Back in 2017 you had two options for automating trades. Big firms could make use of broker-provided trading systems that used exotic protocols, required specialized devices, and cost a lot of money. Small time traders could use something like Interactive Brokers Workstation API, which basically allowed you to interact with an API exposed by the GUI of an app you ran on your machine, which would then route your instructions back to the broker.

Fast forward a few years and you have low cost brokers that actually expose REST APIs that you can interact with using your programming language of choice. This has dramatically simplified the task of automating the trading side of running an investment portfolio.

At the most basic level, automation of a trade via a REST endpoint involves sending an authenticated HTTP request with the required information for a broker to create an order. This instruction could be triggered manually, by running a script or clicking a button on a website, or it could be run conditonal on some external event occurring, like a cash deposit into the brokerage account.

while true:
  if(account_balance>$1000):
    order $1000 of AAPL at market
  else:
    sleep 24 hours

The above pseudocode would check your account balance once a day and, if the cash balance was greater than $1000, it would submit a buy order for $1000 of AAPL shares. Basically, you’ve automated a reinvestment strategy.

This sort of stuff is pretty simple to implement and brokers like Alpaca make is really easy to acheive with zero proprietary software requirements.

But when you move from thinking about a single asset to a portfolio of assets, things get a bit more complicated. Modern portfolio management thinks of a pool of capital as a pie, and allocates slices of that pie to different assets depending of investment factors that balance potential return against perceived risk. One thinks in terms of the percentage of the portfolio allocated to a stock rather than the monetary value of each holding. This complicates the scripting above quite a bit.

set desired_holding_proportion = 25%

while true:
  if(account_balance>$1000):
    get portfolio holdings as holdings
    for holding in holdings:
       if holding_value/holdings_value > desired_holding_proportion:
         sell 1% of holding
       if holding_value/holdings_value < desired_holding_proportion:
         buy 1% of holding
  else:
    sleep 24 hours

The above pseudocode is woefully inadequate to the task, but the basic idea gets across. Each day, it will try to keep each holding in your portfolio at 25%. Obviously if you have 3 holdings, or 5 holdings, it will break.

Flawed as it is, it has the beginnings of what I like to call a rebalancing engine. At its most basic, a rebalancing engine needs three components -

  1. A model portfolio. This is a specification of your desired portfolio weights.
  2. A set of current holdings. This is a summary of how much you hold of each asset in your trading account.
  3. An order generator. This is a body of code which compares the model portfolio to the current holdings and generates the set of required trades to make them the same.

Once you have an order list, you can submit it to your broker and let the market do its work.

I like to think of this as the beginnings of declarative portfolio management. Basically, you declare what you want your portfolio to be, and then the computer makes it so. Alpaca actually has an API that fulfils the above tasks - the Rebalancing API, but it is only open to Broker accounts, and theres a monthly SAAS fee of several thousand dollars. You also don’t have much control over how the order generator works. On the one hand, this is good - you trust Alpaca to have an army of programmers controlling the order generation logic. But, in the world of investment management, it’s always a good idea to control your trading behaviour, because brokers aren’t really incentivised to get you the lowest possible price for a stock unless they know they are competing with many other brokers for your business. And you forego that if you use their Rebalancing API.

Over the next few weeks I’ll be working on building out those three components, and I’ll try document each in a separate blog post. In each post we’ll hammer the pseudocode abov into successively more realistic code, and by the end we should be able to actually define and rebalance a portfolio.