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
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:
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).
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):
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 
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?
Hi @AlwaysTraining,
- 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_.*/.
Currently there are two ways for you to apply labels yourself:
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.
Any updates on this?
Easiest to implement would be to add a tag to orders that can be used to filter a GetOrdersRequest so that at least the capital allocated for a specific portfolio can be calculated? Nicer would be to add a dictionary attribute to an asset that keeps running subtotals for the quantity of orders based on the order tag from above?
+1 on this feature, this would be really great to have to keep all strategies separate
ABSOLUTELY!!! 1000%. I am even creating a new thread. Please listen! And shorting fractional sized orders!!!
+1 for multiple sub-accounts or somehow separate the multiple strategies to be independent between each other.
+1, much needed feature, hope to see it ASAP, the post is already old
Yes +1. Really need sub accounts
+1 YES! We need this!