Contract builder

[topofocus]

Hi,
trying to get familar with the Contract-builder.

As I understood, to test if a contract is valid, its sufficient to call contract_details.
In Ruby, the ibapi-gem comes with a handy verify method which does essentially the same.

The main difference: if some attributes are missing, all contracts returned by `req_ContractDetails' are returned. Thus:

Contact::call("BAYN").in_currency("EUR").expiry(202511).strike(29.0)
returns all call options in the contract month.

This is very handy if option-chains are to be selected and to check, which weekly and/or daily-options are offered. Then option-greeks, marketprice and volatilities for these specific contracts are easily fetched.
The tws-api is designed to select these contracts with only a few api-calls.
rust-ipapi simply returns only the first returned contract.

This may lead to errors. Concider the Bayer-example above. Req-ContractDetails returns two options for each call, Trading-Classes `BAY" and "BAYE". I haven'd figured out, how to specify the trading class, maybe the function is not implemented, jet.

It would be interesting, to allow ranges for expiries and strikes as arguments for Contract.contract_detail and to return a vector to indicate, that the api-call itself returns multible valid contracts.

Second, I suggest to implement a method "qualified_contract" or similar, a specialized Contrat with essential contract-attributes, required for a secure order-process: if contact_detail has been called: contract_id, currency and exchange, otherwise contract_detail is to be called and the attributes are only set, if exact one contract is returned.

Whats your opinion?

greetings

hartmut

[wboayue]

Hi Hartmut - Thanks for the feedback.

The builder API is designed to that the code will not compile when the contract is not valid. For an option contract it will need at least a symbol, strike, price and expiration date.

Trading class was something I overlooked. The builder API was designed to limit the ability to create invalid contracts but if something is missed it can limit ability to create valid contracts. I will add support for trading class. As a fallback for situations not anticipated there is the option to build the Contract object directly.

Not sure I understand the ranges. Are you suggesting the API request details without the expiration and filter based on the range?

If I understand correctly the goal of the qualified contract is to only return a contract if it is fully specified. Here I'm not sure about the line between API responsibility and application responsibility.

• Wil

[topofocus]

Wil, I see your point.
Thing is, its impossible to know if a Contract is valid at compilation time. You can check it using Contract.contract_detail. But this breaks the logic of the tws-api. Req_Contract_Detail is designed to return many contracts.
A solution might be to return a Vector.

Then this can be used to get vaild option contracts

r = Contract::put("CS").is_currency("EUR").has_contract_month(2025,11).strike(32.0).build();
rc =  r.contract_detail()

if rc is expected to be a vector, it should contain a list of valid put-options of that month at this strike (all exchanges [EUREX,MONEP,CEDX], daily, weekly and monthly expiring options (Trading-Classes: AXA, CS1, CS4, CS0) and cash settled options (Trading-class AXAE)).

[wboayue]

I added support for trading_class to the OptionBuilder.

Not sure I understand your other point. Client::contract_details already returns a Vec<ContractDetails>. Do you think the OptionBuilder currently requires too many fields?

[topofocus]

Thanks.
Its worth noting, that a Contract can always build by

c =  Contract{ contract_id: 226698, currency: Currency::from("USD"), exchange: Exchange::from("SMART"), ..Default::Default() }

and then can be verified with fully_qualified_contract = c.contract_details().

If you import contracts from a database, thats the way it is done.

Thanks for the hint, that contract_details returns a vector. Will try to use this to get current options-expiries and -strikes.