Options positions have an issue with cost_basis or avg_entry_price. All values based these values report wildly incorrectly. Seems like this is only in the paper environment. Might be related to what happened earlier in the week with misreported numbers?
Because avg_entry_price is 1/100th of what it should be, the percentage gain reported is misleading (as well as the cash value). It's possible to report a gain of 90$ on a 100$ cost basis, when actual loss is -10$.
Expected Behavior
avg_entry_price should be contract value. Cost Basis should either be Contract Value or Contract Value x 100. But there's currently a discrepancy.
SDK Version I encountered this issue in
alpaca-py == 0.21.0
But the issue seems to extend to alpaca's back end.
Steps To Reproduce
In the paper environment
api = TradingClient()
positions = api.get_all_positions()
options = pos.loc[(pos['asset_class'].str.contains("us_option",case=False))].copy()
print(f'[{options.symbol}] {options.current_price} {options.current_price/options.qty} {options.cost_per_unit} {options.avg_entry_price}')
print(options.symbol,options.current_price,options.avg_entry_price,options.cost_basis,options.unrealized_pl,options.unrealized_plpc)
all options contract's older than a day report incorrect values when it comes to cost_basis and everything based on it.
Filled out the Steps to Reproduce section?
[X] I have entered valid steps to reproduce my issue or have attached a minimally reproducible case in code that shows my issue happening; and understand that without this my issue will be flagged as invalid and closed after 30 days.
Anything else?
From what I can tell, there’s a state management issue or a wrong variable used, maybe both? In the paper environment it's present. In the live environment.
(there’s also a text overflow problem in the Asset Column)
On contracts bought same day, the values seem correct.
On contracts held overnight. The avg entry seems to go down by 1/100. Which then makes to Total P/L report a wildy wrong number the next day.
Today’s P/L seems to be accurately stating the actual % gain.
Market Value seems to be (price 100 Qty), price being reported in contract value. But Cost Basis (for options) is doesn’t get that same *100. Somewhere between avg entry and cost basis it’s being misused?
Any user logic built on top of those values would see position A, pnl = +90$ (when it cost 100$ & pnl = -10$). And the percentages based on that would be wrong as well.
The logic behind the daily values seems to be intact though. If I had built on the daily values this wouldn’t be an issue.
In live, all the values seem to be correct.
Then what happens every day is this huge jump in p/l...
Daily change is some sum of Total P/L (which is calculated wrong)? Which also happens to be the cash value of all current options + actual PnL
Start of each day, equity is pulled from the last value of the previous day. Equity ends up oscillating around what should be the actual equity (offset being the value of all contracts).
Is there an existing issue for this?
Current Behavior
Options positions have an issue with cost_basis or avg_entry_price. All values based these values report wildly incorrectly. Seems like this is only in the paper environment. Might be related to what happened earlier in the week with misreported numbers?
print(f'[{row.symbol}] {row.current_price} {row.current_price/row.qty}')print(f'[{row.symbol}] {row.cost_basis} {row.avg_entry_price}')print(f'[{row.symbol}] {row.unrealized_plpc:.2%}')Because avg_entry_price is 1/100th of what it should be, the percentage gain reported is misleading (as well as the cash value). It's possible to report a gain of 90$ on a 100$ cost basis, when actual loss is -10$.
Expected Behavior
avg_entry_price should be contract value. Cost Basis should either be Contract Value or Contract Value x 100. But there's currently a discrepancy.
SDK Version I encountered this issue in
alpaca-py == 0.21.0 But the issue seems to extend to alpaca's back end.
Steps To Reproduce
Filled out the Steps to Reproduce section?
Anything else?
From what I can tell, there’s a state management issue or a wrong variable used, maybe both? In the paper environment it's present. In the live environment.