IMPORTANT: Multi-Country Functionality

Throughout Portfolio123’s history, US and Canadian stocks have functioned independently, and one could not run a screen, ranking system, or simulation using both countries simultaneously.

We are introducing that capability on Tuesday night/Wednesday morning (1 am CST; the site might be down between midnight and 1). The reason is that we will soon be rolling out European data, followed by Asia-Pacific, and this capability is essential for the full use of that data.

This required us to make a number of changes to the website, including some that will affect your current systems. The changes that will have the greatest impact on your current systems are those pertaining to the calendar, taxonomy series, and industry-based scope parameters. But many other parts of the website will change as well.

In order to enable you to familiarize yourself with the new system, we have launched a beta site at https://beta.portfolio123.com. This site does not have all of your user data (user data will be a few days old), but it will update prices and have a server for backtests. Forums have been disabled, and any changes you make to your systems will be lost. But it will enable you to get a feel for the changes. For a full description of the changes, go to https://docs.google.com/document/d/1ypyTXBiMRjkRSjAbr3wvIQITqcMNeVynNGDV9jxRpeA/edit?usp=sharing. We highly recommend that all users read this document.

Here are the two things that will be most likely to affect your current systems:

[]Bars will now include holidays. There will now be 261 bars per year (occasionally 262), and 5 bars per week, no matter whether there is a holiday or not. So if you’re using SMA(21)/SMA(252), for instance, you’ll notice some slight differences.
[
]The rules for what companies are included in the taxonomy series and industry-based scope parameters are changing, which means you’ll see somewhat different numbers for the functions ending in Ind (Pr4W%ChgInd, Pr2BookQInd, Beta1YInd, and so on) and for functions using the industry-based scope parameters (#Sector, #Subsector, #Industry, and #Subindustry). The rules used to include more tiny companies, and companies would flit in and out of the groups.
Please let us know if you have any questions or concerns.

Changing the definition of a bar just simply cannot happen, this is mind boggling.

Cool! This looks like a nice upgrade.
First question: How would I proceed to create a joint US-Canada universe, removing ADR’s, OTCs and masterlps?

Using “Universe(NOOTC)” in the universe rules seems to exclude all Canadian stocks.

sglinski is not as bad as it seems. We discussed this a lot. Won’t matter much for things like SMA(50). Can you give an example where you think it’s problematic?

RE: Bars will now include holidays

This is very unusual! How are we to, for example, create a 200 day moving average, or anything else that counts bars? Are you setting this up to exclude bar holidays from the calculation?

What happens if the number of bars back lands on a holiday bar? I’m assuming that bar will be empty, so will this throw an error?

Seems to me I’m going to have to go back through all of my screens, hundreds of custom formulas, etc. and recalculate bars back. In doing so how will I know how many empty bars are going to be in a range so I can add them to my bars back. For instance, how many empty bars are there looking 200 bars back that I will have to add to the 200 to actually get 200 bars of data?

Unless I’m reading this change incorrectly, including holiday bars seems like a complete disaster in the making… I’ve used dozens of price platforms over the years and none of them have included holiday bars. The definition of a bar is the data based on a trading day.

Use “!Universe(OTC)” or “Universe(OTC) = 0” . . . both the NOOTC and the OTC universe are US-only universes.

What happens to the predefined constants like #year? I will not be happy if the European integration affects my US-only models.

Bars that land on holidays replicate the previous bar in terms of price and volume. So you don’t have to worry about empty bars or errors.

It would be impossible for us to accommodate all the different holidays that each exchange in each country trades on. Can you imagine 200 bars landing on totally different days depending on what country the stock primarily trades in? In many countries exchanges are open far fewer than 251 days per year. This is, I’m afraid, the price we have to pay for going global.

#year is now 261; #year2 is now 522; and #month is still 21.

The holiday bar is filled in with previous day data. So an SMA(200) will likely duplicate about 7 prices.

There are several reasons why we went this route:

1- Doing risk statistics would be extremely difficult with multiple countries with a single benchmark
2- It should not impact your systems
3- FactSet distributes price data with no holiday gaps. They bring in the hloc from previous day but with a 0 volume (we also copy the volume). So avoiding holidays using FactSet data would be very hard.

There are things we could do of course, like treat single country universes different and use the same approach as we use now. But it’s a technical challenge that requires either a lot more memory or CPU cycles.

Below is a comparison between the current way and the new way for the DJIA for Sma(200)/Sma(50). Yes there are differences, but only one stock flipped where the Sma200 is below the Sma50 instead of above. The spreadsheet is here Holidays-Skip-Vs-No-Skip-SMA5-SMA200 - Google Sheets

We encourage you to try your own tests and do let us know.

Thanks


For me, the beta site is returning slightly lower annualized returns and average returns on select models. I’m Ok with that, but I hope that trend doesn’t continue with further European integration. After dealing with the Valueline and FactSet changes, it’s a bit frustrating having to reexamine what I considered finished, settled work.

Marco, thank you for the clarification as to holiday bars and data. I’m still wary as the values returned using bars this way are going to be different from a calculation made away from P123. If one were to want to examine my work, and find my values are different from anywhere else, that presents a confidence problem.

I wonder if it would be possible to flag holiday bars in US data and then add an option in screener, etc. “Don’t use holiday bars”?

“It would be impossible for us to accommodate all the different holidays that each exchange in each country trades on. Can you imagine 200 bars landing on totally different days depending on what country the stock primarily trades in? In many countries exchanges are open far fewer than 251 days per year. This is, I’m afraid, the price we have to pay for going global.”

IMO, this is certainly a solvable database design problem, and the extra CPU and memory could be mitigated as well. On the other hand, depending on the number of countries and databases you are dealing with I guess that you may be limited by your programmer resources.

The only other option I can see at the moment is to split into two platforms, one for global data, including USA, with redefined daily bars, and the other being the current USA only platform.

As far as Marco’s example above, I suspect the longer term MA’s will have fewer flips than shorter ones (I use predominantly 252, 40, 10, and 5 bar windows in most of my simulations…) It will take me some time to measure the impact.

Also, since there are concurrent changes to taxonomy and calendar, it will be harder to break out the individual effects.

I like that idea.

That is a good idea. I’m just guessing, but it seems P123 is having to convert Factset data to accommodate the addition of European data. Which implies that the original, untouched Factset data could be directed to USA users before modification.

Aren’t the calendar holidays based on the chosen benchmark? I’m pretty sure you have to choose a Canadian index for Canadian portfolios to work. Can’t you do the same throughout the world? In some countries, you may have to allow a liquid stock to be the benchmark but would be preferable to what is being proposed. An alternative would be to have an additional parameter to allow SMA and other lookback functions to be selectable to have either business days offset or calendar days offset. Just add an extra parameter at the end, with the default set to the way things were done previously. That way there is no effect on existing systems and provides a way forward for global models.

I appreciate the transparency on the changes from the p123 team.

To add some data points on the net effect to strategy performance, I re-ran three strategies on the current and beta platforms. Two of those strategies hold 20+ positions and the results look comparable across versions: annualized return within 1 percentage point, Sharpe within +/- 0.05. One looked slightly worse on the beta and the other slightly better. The third strategy only holds single digit positions, and while the Sharpe was only 0.05 lower on the beta, I did see a 4 percentage point drop in annualized return. Across all three strategies, trading statistics were very comparable (turnover, percentage of winners, average winner/loser/etc).

When you drill down to the Performance by Calendar Year, I do see more variation. Looks like there are several years with 10+ percentage point swings in yearly return (comparing current to beta) for for the first two strategies, and I see 20+ percentage point differences for some years on the third strategy with fewer positions. I think the small variations in factor differences from the calendar changes can produce minor changes in rank which can amplify differences in strategy returns based on the positions selected for the portfolio. The smaller the portfolio, the greater the potential for amplification.

That said, I’m not overly concerned by the change. The comparable trading statistics across current version to beta makes me think that the differences in strategy returns are mostly noise.

While I would prefer a solution that maintains current calendar behavior for single country universes, I’ll trust Marco’s word that it would require too much complexity. In this case, it may be better to take Facebook’s approach of “move fast and break things” as the benefit of having additional exchanges sooner may outweigh laboring to maintain backwards compatibility.

I would add one request though: it would be incredibly helpful if each strategy were tagged with the p123 platform version on which it was last run. When the Factset estimate lagging fix was applied a few months back, it was tricky to know if you were comparing two strategies that were both pre-fix, post-fix, or mixed. With another breaking change like this, the version marker would help provide some clarity.

Thanks.

Can’t find one of my sims on the beta site.
https://www.portfolio123.com/port_summary.jsp?portid=1676378

returns: Strategy not found

Please explain those rule changes. Are they something more than reassigning companies whose primary listing is not in North America?

As for the changes in primary listing, will that happen regardless of whether a user is subscribed to European/Asia-Pacific data?

As it stands now, I’m strongly in favor of spinning off the global market p123 into a separate site. I don’t need access to non-US markets and what I have now works for me. Make the global market site the place to experiment.

Two things:
1/ Two more functions need to be added in the diversification section:
CountryCount and CountryWeight

2/ There should be a universe that includes all securities (All US listed securities (including ADR, FShares…) + Canadian stocks)

Thank you.