Portfolios / Sub-accounts

Yes, positions are aggregated: e.g. if you buy 100 shares of ABC and a week later buy another 200 shares of ABC, Alpaca shows that your account is long 300 shares.

If these two purchases belong to two different trading strategies, you could tag each order with labels representing their respective trading strategy, and use a portfolio management app to analyze the evolution of the PL of each strategy by filtering by label (see above post).

+1 to this… $25k per account no problem.

I was wondering if there was any update on this?

I’m able to push orders with unique identifiers with “client_order_id=”

However, once it is converted into a position I’m not sure how to retrieve the order ID. How are people keeping their different strategy trades separated once they become a position?

1 Like

+1

I’m using Alpaca to backtest strategies on a paper account using the same ETFs and this would save a bunch of coding!

Thanks Xavier , I think this is a good idea in theory and would allow me to separate the different strategies, but also here, the devil is in the details: I have seen some corporate actions that result in transactions that I didn’t initiate. The assigned user ID is random and I would not know which portfolio / strategy these belongs to. While these are few, it would still result in a lot of effort to sort them out, which is needed to have all transactions balanced for each strategy - for quality control.

Hi @nthorwir, thanks for bringing new points to the discussion. Would you mind elaborating bit more on the corporate action you have in mind? Since corporate actions occur on live positions that can themselves be attributed to each strategy, I don’t expect them to be that problematic.

For example:

  1. If the corporate action occurs on a security that is held exclusively by algo1, it would be easy to tag the algo1 label to the activities representing the corporate action. The effect of the corporate action would thereby only impact algo1 in Feather Finance (we model each strategy’s portfolio based on all the activities tagged with that strategy).

  2. If instead the position is shared by several algos, then corporate action activities would need to be duplicated and the amounts would pro-rated according the each algo’s position.

You are right to say that it would currently involve a manual process, but the mechanics should be pretty straightforward (couple minutes max). We do have a few Alpaca users who tag strategy labels. If more users start using the feature we could even consider automating the manual process.

Thanks,
Xavier

Xavier,
thanks for a quick reply. I am thinking of e.g. splits, rights issue, symbol changes and mergers. I can believe that each of these can be attributable to the correct strategy as you point out and that it possible to reconstruct the holdings at a given point for each strategy. But it took me more than a couple of minutes each to identify the issue, find the details on what happened, correct the transactions, verify success and to make sure that the correction does not interfere with calculations such as profit per transaction etc.
How do you apply these so quickly ? Is there a general recipe or semi automation?

TLDR
@nthorwir I see what you mean. I think it helps split the question/problem in two: (1) portfolio issues caused by corporate events in and of themselves (regardless of subportfolios/labeling techniques), and (2) their implications on labeling strategies. When I said “couple minutes max”, I was referring to the additional work involved to make sure strategies remain well labeled on a typical corporate action.

Issues Caused by Corporate Events
I agree with you that it is often tricky to troubleshoot portfolio issues when there’s an ongoing corporate action on one of its holdings. The main problem is that complex corporate events (like spin-offs) don’t impact the portfolio all at once, as one “atomic” event. Instead the portfolio can transition through several (incomplete) states: corporate event’s ex-date, date at which symbol trades at post-event price, corporate event’s pay date, date(s) at which the broker (partially/fully) reflects the corporate event in the user’s portfolio… For the broker & the clearing house, the only real deadline by which everything needs to be in order in the user’s portfolio is several days later, when the corporate event settles (when hard money & cusips exchange hands at the clearing house…

If it makes you feel any better, I know for a fact that traders at top financial institutions face some of the same problems.

While there is no silver bullet to guard against such issues, portfolio management tools can help you troubleshoot these issues faster (e.g. trading desks at investment banks use such tools every day to reconcile their P/L):

  • P/L Attribution Tool (see thread)
  • Filtering by Symbol (see thread)
    • e.g. if you’re analyzing the impact of LB splitting into BBWI & VSCO, you can filter on a set of symbols (LB / BBWI / VSCO) and look at the evolution of that subset of your portfolio.
  • Temporarily Disabling Transactions / Inserting Temporary Transactions
    • If a corporate event has been partially processed it can be helpful to temporarily disable / temporarily add a transaction in your portfolio to put it in a more consistent state while waiting for other

Implications for Labeling
You raise a good point that any portfolio activity that isn’t directly initiated by you won’t be labeled automatically. That’s true of corporate events activities, but also of e.g. TAF & REG fees.

The way I see it, tagging your strategies only gives you more info to troubleshoot your portfolio issues. E.g. your labels will point you to which strategy is affected by the issue. I am not saying that labeling will always be effortless. If your trading strategies involve holding positions on many different symbols, there will come a time when a particularly thorny corporate event makes you reconsider the fact that you not only have to troubleshoot the issues caused by the corporate event, but also keep your strategy labels updated throughout that mess. However, over the long run, I think the benefits will outweigh the additional work for many of us.

Thanks Xavier for another helpful reply.
The resolving of corporate actions and attribution are of course separate issues and I can see how the latter is easier - good point.

If it makes you feel any better,
I know for a fact that traders at top financial institutions face some of the same problems.

It kinda does :slight_smile:

Definitely agree that tagging is the a good idea to enable flexibility in the future.

Hi, Is there documentation about the “FF” label format specification? I think it is bold of you to take away my client order id prefix! j/k, I store metadata keys and values encoded in a yaml like syntax in the client_order_id. Is there a programmatic way I can apply labels to orders for past and future in feather?

1 Like

Hi @AlwaysTraining,

  • On our documentation page, there is a section on Labels and a section on how to Filter by Label
  • Here is the description of the FF label format specification:
  • Tag a custom label to an order by specifying a client_order_id parameter in the following format:
    • custom_order_id = “MYCUSTOMLABEL” + “FF” + my_custom_id;
    • where MYCUSTOMLABEL is the label that will feed to Feather Finance, FF is a delimiter used by Feather Finance, and my_custom_id is a unique identifier for the order.
  • For the tech-savvy: here is the regular expression we use to extract the label from the client_order_id: /(^.+)_FF_.*/.
  • The above specification is hardcoded in Feather Finance at the moment, but it would be easy for us to let you choose your own label format specification if you can’t find a way to work with ours (i.e. in technical terms, we could let you specify your own regular expression in your Feather Finance User Settings).

Currently there are two ways for you to apply labels yourself:

  1. In the Feather Finance WebApp you can manually edit the label field of any portfolio activity.
  2. By prefixing a label to the Alpaca’s client_order_id parameter (discussed above).

If you have a one off request to back-populate the label field of historical activities based on a set of criteria, it would be easy for us to do it for you (we have internal tools that do just that).

Others have shown interest in programatically amending activities, so we may well implement such an endpoint for our public API.

Let us know how it goes! If you’re interested, I could put you in contact with other Alpaca users who have implemented this.

+1 for this feature. Ideally it’d work with the Rebalancing API as well. I assume that if it’s implemented it would be available for the Broker API.