ability to manage multiple algorithms under one account

[yoshyoshi]

In order to run multiple algorithms while understanding which order came from which algorithms. In order to test multiple algorithms simultaneously to cut down the testing period.

[bdowling]

I think it was suggested that it may be even more generally beneficial to implement this feature through the use of sub-accounts. Sub accounts could be created and from the master account a portion of equity could be allocated to the sub-account, enabling limits to be managed at the service level.

The complication comes when multiple algo's are working on the same symbols, how is avg_entry_price issues addressed [noting the difference between avg_entry_price (tax FIFO) and avg_cost_basis (sub-account Average).]

Providing attributes/tags #18 is related so a user can manage tags on orders/positions for better reporting.

[JNAV86]

I second that!

sub accounts would be great too, but I think the most important goal here would be to run multiple algorithms.

[oducille]

Hi. I'm new to Alpaca but not to coding. It seems to me to be clear that there should be a distinct logical separation of processes with separate keys and their own Alpaca work-space for testing lgos. I was faced with this issue and immediately solved it by simply creating two accounts. One with my regular email and the other with my alternate (recovery) email required by most email providers anyway. I am not new to the kind of issues in coding being discussed here. Sometimes there needs to be more than one process or algo running. As in most multi threaded environments, there are synchronization issues requiring mutexes and critical sections that prevent corruption of data and control thread 'traffic' with multiple writers and multiple readers of segments of data. However, properly implemented one avoids things like memory leaks and deadlock. Now with algos accessing accounts and sub accounts where multiple algos are running that could spawn multiple threads as well, it represents all kinds of spurious and mischief innocently caused by code. So, my multiple account solution for paper trading is simply the safest approach. Thoughts anyone?

[umitanuki]

Agree. #18 would mitigate the risks you describe, but not the best approach. It should be isolated by the API side so users/algos don't need worry about it.

[philgapp]

Following and believe this is important to scaling up R&D with Alpaca. Here's the Alpaca Forum post for this issue as well: https://forum.alpaca.markets/t/portfolios-sub-accounts/678

I would like to help if I can as well! I'm basically developing an algo trading app leveraging the Alpaca API full time right now. Node.js/React with TensorFlow machine learning.

[zorrored]

+1, please add this feature.

[SierraVista90]

YES! Please introduce the sub account or multiple account feature in Alpaca! I run 3 algos on alpaca live trading. I would like to have 3 sub accounts, one account for one algo. So I can track the performance of each account better. Thank you!

[jasondarnell]

+1, please add this feature.

[fsiler]

+1, please add.

[vertfin]

+1, pretty please.

[AlwaysTraining]

+1, please please please

[matiasmsm]

+1 pretty please!! also for alpaca Brokerage would be very niceee :)

[aidanjalili]

+1, would be nice to have

[xavierrobitaille]

One way to do this is to tag the trades of your different algos with different labels via Alpaca's "client_order_id" field.

You can then slice and dice your Alpaca account by algo label in the Feather Finance portfolio management app. We have recently integrated the Alpaca API.

Here are the steps to follow (takes 2-3 minutes):

1. Signup for Feather Finance (it’s free, and we plan to always have a free tier)
2. Link your Alpaca account(s) to your Feather Finance account.
3. Prefix a label to the client_order_id your algo sends to Alpaca. Use different labels for your different algos.
4. Your transactions will feed automatically into Feather Finance, and they will be tagged with the algo label you've provided.
5. Analyze the performance of each algo in Feather Finance by filtering by label.

Would love to get some feedback if this is useful to you.

Here's a video where I walk you through how to do this: https://www.youtube.com/watch?v=hw3JLMQvvRM&t=26s&ab_channel=FeatherFinance

Here's a video where I walk you through how to retrieve the performance of a given algo via Feather Finance's public API : https://www.youtube.com/watch?v=F3UBPb4zsBs&t=2s&ab_channel=FeatherFinance

[JeremyWhittaker]

Please add sub-accounts feature.

[masnwilliams]

I would love to have the ability to manage sub-accounts that are all tied to one parent account.

[norunners]

Sub-accounts would be huge for customers!

[wewuyi]

why not just tag each account by client_order_id (e.g., "aaa_timestamp} and later group all filled order (from account activiteis) by client_order_id?

[oducille]

Or track each algo (transactions, balance, and profitability) by magic number? Not trivial! There's a persistence issue to decide (each run or perpetual) as well as data storage considerations with (extra tables etc) and back end processing matters.

On Tue, Mar 29, 2022 at 11:24 PM wewuyi @.***> wrote:

why not just tag each account by client_order_id (e.g., "aaa_timestamp} and later group all filled order (from account activiteis) by client_order_id?

— Reply to this email directly, view it on GitHub https://github.com/alpacahq/Alpaca-API/issues/35#issuecomment-1082581328, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADTTHRLG53EXPFRNJ6MURV3VCPCOPANCNFSM4GUSSSWA . You are receiving this because you commented.Message ID: @.***>

[norunners]

why not just tag each account by client_order_id (e.g., "aaa_timestamp} and later group all filled order (from account activiteis) by client_order_id?

Limiting API access and funds/balance per sub-account increases security and limits blast radius of strategy or asset being traded.

[oducille]

Ok. So run each algo in a different instance each with its own "time_stamp" or magic number while accessing the same account. That would require some client side coding and reporting, a little elbow grease.

I agree that a client side solution would work for testing but not necessarily for some real life applications - say for an asset manager with multiple clients! Where one set of algo credentials would access multiple sub-accounts. That would call for a for a provider side solution of multiple sub accounts which is the suggestion in discussion here. That would be much more elegant approach all around in that it might meet the muster of risk segregation as opposed to pooling funds for clients into the same account. Any Volker Rule experts want to weigh in?

On Wed, Mar 30, 2022 at 11:42 PM norunners @.***> wrote:

why not just tag each account by client_order_id (e.g., "aaa_timestamp} and later group all filled order (from account activiteis) by client_order_id?

Limiting API access and funds/balance per sub-account increases security and limits blast radius of strategy or asset being traded.

— Reply to this email directly, view it on GitHub https://github.com/alpacahq/Alpaca-API/issues/35#issuecomment-1084041317, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADTTHRJRGT34EBTOGVAF5KLVCUNJ7ANCNFSM4GUSSSWA . You are receiving this because you commented.Message ID: @.***>

[donewiththedollar]

Should definitely offer sub account APIs for the paper trade. Would change lives. Otherwise, I do not see why you would not do it this way unless you simply cannot make it scale.

[sshcli]

In the meantime, for those interested... Right now, you can compare the performance of two different Algo by using 2 different symbols with identical correlation.