http-nt-client 1.0.0
Nickel Trader API
Requires Python: >=3.10
Keywords: Swagger, Nickel Trader API

    # Nickel Trader TWAP algorithm for NT users.    ## Limits    This REST API has a global limit per user of **20 requests per minute**. HTTP 429 status is returned when user exceeds the limit and should be handled by the client.    Each API response contains &#x60;X-Rate-Limit-Remaining&#x60; header allowing users to plan requests accordingly.    ## High-level explanation    ### TWAP is designed with the following goals in mind:    - Guarantee execution of the exact size within the specified window.  - Minimize market impact vs a theoretical TWAP.  - Minimize risk of detection through randomisation of its behaviour.  - Minimize taker transaction costs.          ## Parameters of TWAP execution in NT:  - &#x60;site&#x60; - Instance of Nickel Trader used for the execution. One or more can be available.  - &#x60;executionId&#x60; - Unique identifier for the strategy, generated by the user. Limited to 8 characters. Creating a strategy with the same identifier twice leads to the replacement of the existing strategy.  - &#x60;instrument&#x60; - Instrument to trade, following symbol@exchange convention.  - &#x60;account&#x60; - Account to trade.  - &#x60;side&#x60; - Side to trade: can be buy or sell.  - &#x60;target&#x60; - Full quantity of the base asset to trade. The strategy will stop when target is reached. Only settable for an existing strategy in state NEW or STOPPED. Cannot be set together with &#x60;targetPosition&#x60;.  - &#x60;targetPosition&#x60; - Signed position size following successful execution of the trading algorithm. Only settable for an existing strategy in state NEW or STOPPED. Cannot be set together with &#x60;target&#x60;.  - &#x60;stepSize&#x60; - The average increment of each step of TWAP execution (subject to randomisation).  - &#x60;stepTime&#x60; - The average time delay in seconds between each step of TWAP execution (subject to randomisation).  - &#x60;aggressionFloor&#x60; - Distance from the current step&#x27;s target when aggressive execution takes over. Expressed in percentage points of the full quantity target. Used in conjunction with &#x60;aggressionCap&#x60;, and should be set close to &#x60;aggressionCap&#x60; to avoid large taker orders when passive execution is lagging behind the current step&#x27;s target. Must be within [0,100] or, most strictly, [&#x60;aggressionCap&#x60;, 100]. Set to 0 for taker-only execution. Set to 100 for maker-only execution.  - &#x60;aggressionCap&#x60; - Distance from the current step&#x27;s target when aggressive execution stops and passive execution continues. Expressed in percentage points of the full quantity target. Used in conjunction with &#x60;aggressionFloor&#x60;. Must be within [0,100] or, most strictly, [0, &#x60;aggressionFloor&#x60;]. Set to 0 for aggressive execution all the way to the current step&#x27;s target. Set close to &#x60;aggressionFloor&#x60; for minimal but frequent taker execution. Settable for an existing strategy in all states.  - &#x60;scheduledStartTime&#x60; - TWAP will start automatically at given start time.  - &#x60;scheduledStopTime&#x60; - TWAP will stop automatically at given stop time.  - &#x60;guaranteedExecution&#x60; - Ensure complete execution within scheduled execution period by executing more taker orders towards the end of the execution window (TRUE), or continue to quote the final slice until it&#x27;s taken (FALSE).  - &#x60;start&#x60; - Start strategy execution immediately after submit.    ### Parameter combination rules:  TWAP performs the execution in steps of &#x60;stepSize&#x60;, once every &#x60;stepTime&#x60; (both of these are randomised around the mean). For ease of below, let&#x27;s define &#x60;numberOfSteps :&#x3D; target / stepSize&#x60;.    #### Start  TWAP starts when &#x60;start &#x3D; true&#x60;, or when &#x60;scheduledStartTime&#x60; is reached. Set **at most one** of these parameters (you can set none to prepare the TWAP for a later manual start). **Setting both parameters will lead to a reject.**    #### Stop  TWAP stops when &#x60;target&#x60; is reached or when &#x60;scheduledStopTime&#x60; is reached, whichever is first.    #### &#x60;stepTime&#x60;  - If you provide &#x60;scheduledStopTime&#x60;, we automatically calculate &#x60;stepTime&#x60;, so **setting any value to &#x60;stepTime&#x60; in the request will lead to a reject**. We calculate it &#x60;as stepTime &#x3D; (scheduledStopTime - startTime)/numberOfSteps&#x60;, where &#x60;startTime&#x60; is when the strategy is started.  - If no &#x60;scheduledStopTime&#x60; is provided, &#x60;stepTime&#x60; is required.      ## Taker-only execution [&#x60;aggression floor &#x3D; 0&#x60;]    The most naïve implementation of TWAP, executing &#x60;(1/n)*target&#x60; every &#x60;stepTime&#x60; as a taker.    ## Maker-only execution [&#x60;aggression floor &#x3D; 100&#x60;]    TWAP will attempt to execute everything as maker (by quoting on the most aggressive non-crossing level in the orderbook available). This, however, means that in the absence of takers in the market, it&#x27;s possible the algo never gets any fills, or get a lot of the fills towards the end of the time window, resulting in bad execution vs. a theoretical TWAP.    ## Maker execution with occasional taker execution [&#x60;aggression floor in (0,100), aggression cap in (0, aggression floor)&#x60;]    To ensure poor taker-only execution doesn&#x27;t happen, we introduce the &#x60;aggression floor&#x60; and the &#x60;aggression cap&#x60;. The parameters are explained above, and they act to ensure aggressive execution takes over, should the executed size fall too far behind the current target. Graphically, an example of looks like this (with the current position line in black when executing as a maker, in pink as a taker):  ![image](./../resources/wiki/images/maker-taker-1.png)      The graph shows how the two parameters work:  - whenever the currently executed size dips below the &#x60;aggression floor&#x60; (orange line), taker orders are initiated  - TWAP returns to maker-execution when the currently executed size reaches the &#x60;aggression cap&#x60; (gray line)    # Guaranteed execution [&#x60;guaranteed execution &#x3D; TRUE&#x60;]    The taker logic outlined above does not guarantee the execution of the full &#x60;target&#x60; in the specified time. To see this, imagine a case where all the execution happens as a taker (in complete absence of the taker flow from the market):    ![image](./../resources/wiki/images/no-guaranteed-execution.png)  With this mechanism alone, we can only guarantee the &#x60;aggression floor&#x60; amount is executed, as it&#x27;s only when the amount executed dips below it that we initiate taker orders.    To ensure full execution in the specified time window, we add a &#x60;guaranteed execution&#x60; parameter (TRUE/FALSE), that adjusts the &#x60;aggression floor&#x60; and the &#x60;aggression cap&#x60; to ensure full amount gets executed by the end of the time window:    ![image](./../resources/wiki/images/guaranteed-execution.png)    # Randomisation [always-on]    The blue line on the graphs above indicates the non-stochastic target (which, in turn, would result in constant order size for each iteration). In reality, the TWAP algorithm randomises both the order size and the time between orders, doing so in a way that keeps the execution probabilistically very close to the blue line, but making it hard for market-makers to detect and widen their quotes.    # Try it yourself!    We created a spreadsheet you are welcome to play around with to see how different values of &#x60;aggression floor&#x60; and &#x60;aggression cap&#x60; result in different possible execution paths. You&#x27;re welcome to play around with it [here](https://nickelam-my.sharepoint.com/:x:/g/personal/alek_kloda_nickel_digital/EZVkCrDqYhxCrQYeyYkZ1AMBsOy35U1qhgxPPChXcbg5aQ?e&#x3D;C738nP), with a password &#x60;ndamtwap2023&#x60;!   # noqa: E501