On Kraken Futures you will never be allowed to have a negative balance on your account, unlike many CFD and other exchanges. This is thanks to our Equity Protection Process (EPP) which manages the risk automatically for all positions on the platform to ensure full market integrity.
When you enter a trade, you have an initial margin amount to lodge for opening the position, and then a maintenance margin level which triggers the equity protection process once you breach it.
Positions begin this process once the portfolio value (i.e., equity) of a margin account falls below Maintenance Margin threshold.
Expand the titles below for a detailed walkthrough of each product specific EPP:
Single-Collateral EPP
The Single-Collateral EPP follows three main steps:
- Liquidation
- Assignment
- Unwind
Liquidation
This is the first step of the process and it begins by submitting an Immediate-or-Cancel order to the market. The limit price of this order is chosen such that if the order is matched, the remaining portfolio value of the margin account will not be negative. A liquidation in one margin account will not affect any other margin accounts.
|
EXAMPLE: LIQUIDATION |
You have an open long position of 1,000 contracts in Bitcoin-Dollar Futures with an Avg Entry Price of 8000. The value of this position is 0.125 BTC (1000 / 8000) and the margin you used for this position was 0.01 BTC. The Initial Margin requirement for this position was 0.0025 BTC (2% of 0.125 BTC) and the Maintenance Margin level is 0.00125 BTC. In this position, the price at which you will be liquidated is 7481, where your position value will be 0.00125 BTC. As soon as the Mark Price reaches 7481 or below, your position will enter liquidation. An Immediate-or-Cancel sell order is submitted on your behalf at 7407, where your position value will be just above 0 BTC. The limit price of this order assures that if the order is matched, the portfolio value of the margin account will not be less than zero. |
|---|
If the liquidation order results in being filled at price better than the bankruptcy price, then the client keeps whatever remaining maintenance margin there is. This is contrary to how some other exchanges operate where you lose the entire maintenance margin regardless of what price your liquidation is filled at.
Assignment
If a position cannot be liquidated (for example due to lack of demand on the market) and there are unfilled contracts from the above Immediate-or-Cancel order, then the remainder of the position undergoes "assignment" process. This process takes the unfilled liquidation remainder and assigns it to a liquidity provider at the 0-equity price, in order that your counterparty is able to maintain their position.
Example Assignment
Let's assume that there is a client whose current positions are:
- LONG 1,760,000 Contracts on PI_BTCUSD
- LONG 300,000 Contracts on FI_BTCUSD_200228
Both these positions are using the main FI_BTCUSD margin account, which measures the risk in realtime, valuing the collateral vs position value, to determine whether to liquidate.
Once the margin account for the contract type is below the maintenance margin, liquidation occurs and the system sells those positions into the orderbook at the 0-equity imputed price for each contract.
In this case, the client's liquidation plays out as follows:
|
Position |
Size |
Amount Liquidated |
Amount Assigned |
|---|---|---|---|
|
PI_BTCUSD |
1,760,000 |
1,007,379 |
752,621 |
|
FI_BTCUSD_200228 |
300,000 |
300,000 |
0 |
This means the entire FI_BTCUSD_200228 position of 300,000 Contracts was successfully sold into the orderbook to new counterparties who had existing bids.
However, the PI_BTCUSD position of 1,760,000 Contracts was only able to liquidate 1,007,379 successfully into the orderbook, with the remaining 752,621 unable to find a new counterparty.
As a result, this unfilled liquidation remainder is handled in the PAS by routing the LONG position to liquidity providers participating in the program based on individual preferences.
Below is an example notification for an Assignment of -2500 PI_XBTUSD contracts allocated to "[email protected]". The client receives the following email (note that this format may change so do not rely on this formatting):
The liquidity provider immediately receives the notification over WebSocket feed alerting them to the Assignment. The message takes this format:
{
"feed": "fills",
"username": "[email protected]",
"fills": [
{
"instrument": "PI_XBTUSD",
"time": 1581026151,
"price": 9292.5,
"seq": 103,
"buy": true,
"order_id": "87755b99-bfb7-4f51-a72b-70f542f793a5",
"fill_id": "89f0f4f9-66b5-45eb-ba3f-6eeb2da5cadd",
"fill_type": "assignee",
"qty": 184317
}
]
}
Additionally, the client may poll the REST API endpoint for fills to see:
{
"result": "success",
"fills": [
{
"fill_id": "89f0f4f9-66b5-45eb-ba3f-6eeb2da5cadd",
"symbol": "pi_xbtusd",
"side": "buy",
"order_id": "87755b99-bfb7-4f51-a72b-70f542f793a5",
"size": 184317,
"price": 9292.5,
"fillTime": "2020-02-06T21:55:51.000Z",
"fillType": "assignee"
}
...
]
}
The key fields in the responses are fill_type and fillType (for WebSocket and REST, respectively), which both take the value "assignee". This is the indication that should be used to programmatically handle the assignment.
Note:
- Set your preferences as you see fit on the Assignment Program section of the platform.
- You will not receive an Assignment that your available margin for the contract type can not handle.
The decimal and thousands separators shown in this article may differ from the formats displayed on our trading platforms. Review our article on how we use points and commas for more information.
Unwind
If, for whatever reason, this assignment process is unable to find liquidity providers to take the position at the zero equity point, then the remaining contracts undergo an "unwind". This means that the contracts between you and your counterparties end and that the remaining portfolio value of the margin account is transferred to your counterparties. An unwind of one margin account will not affect any other margin accounts.
Example Unwind
Let's assume that there is a user whose current positions are:
- LONG 2,920,000 Contracts on PI_ETHUSD
- LONG 400,000 Contracts on FI_ETHUSD_200625
Both these positions are using the main FI_ETHUSD margin account, which measures the risk in realtime, valuing the collateral vs position value, to determine whether to liquidate.
Once the margin account for the contract type is below the maintenance margin, liquidation occurs and the system sells those positions into the orderbook at the 0-equity imputed price for each contract.
In this case, the user's liquidation plays out as follows:
|
Position |
Size |
Amount Liquidated |
Amount Assigned |
Amount Unwound |
|---|---|---|---|---|
|
PI_ETHUSD |
2,920,000 |
2,007,379 |
751,605 |
161,016 |
|
FI_ETHUSD_210625 |
400,000 |
0 |
0 |
0 |
This means the entire FI_ETHUSD_200625 position of 400,000 Contracts was successfully sold into the orderbook to new counterparties who had existing bids. The PI_ETHUSD position of 2,920,000 Contracts was able to liquidate 2,007,379 successfully into the orderbook and filled the remaining 751,605 contracts via the Position Assignment system.
As a result, the remaining 161,016 contracts will be unwound.
Below is an example notification for an Unwind of 10,000 Contracts to the unwound counterparty "[email protected]". The unwind counterparty receives the following email (note that this format may change so do not rely on this formatting):
The unwound counterparty immediately receives the notification over WebSocket feed alerting them to the Assignment. The message takes this format:
{
"feed":"fills",
"username":"[email protected]",
"fills":[
{
"instrument":"PI_ETHUSD",
"time":1623344903068,
"price":1647.0,
"seq":1,
"buy":false,
"qty":10000.0,
"order_id":"9bae454b-ec93-43f8-b31c-33d3881fe7ae",
"fill_id":"1298e9ed-4284-43b9-ab9e-0d93591efb36",
"fill_type":"unwindCounterparty",
"fee_paid":-0.00182149362,
"fee_currency":"ETH"
}
]
}
Additionally, the user may poll the REST API endpoint for fills to see:
{
"result":"success",
"fills":[
{
"fill_id":"1298e9ed-4284-43b9-ab9e-0d93591efb36",
"symbol":"pi_ethusd",
"side":"sell",
"order_id":"9bae454b-ec93-43f8-b31c-33d3881fe7ae",
"size":10000,
"price":1647,
"fillTime":"2021-06-10T17:08:23.068Z",
"fillType":"unwindCounterparty"
}
],
...
}
The key fields in the responses are fill_type and fillType (for WebSocket and REST, respectively), which both take the value "unwindCounterparty". This is the indication that should be used to programmatically handle the assignment.
The unwind mechanism encourages market participants to sufficiently collateralise their margin accounts. It also compensates any party whose position has been unwound as a result of their counterparty not posting sufficient margin. Unwind Thresholds are chosen such that they cover approximately a 1 hour 99th percentile adverse price move. Therefore, if a trade closes because your counterparty's position has been unwound, then the compensation payment should enable you to replace your trade with no loss (and potentially a profit). In the unwind scenario, there is an order of operations of who, on the other side, is picked as counterparty:
The ranking utilises the following criteria:
- Position Value = [absolute(Size/Price)] (inverse)
- Return on Equity = [PnL/IM]
- Effective Leverage = [Position Value/Portfolio Value]
Rank (1,2,3...)-- Separate for LONG and SHORT:
- if negative: [RoE/Effective Leverage]
- if positive: [RoE*Effective Leverage]
E.g. When a long position is unwound, it targets the positions of short by highest rank (1 first, 2 second, 3 third, etc.) until fully unwound.
Multi-Collateral EPP
The Multi-Collateral EPP follows four main steps:
- Liquidation
- Assignment
- Covered Liquidation
- Unwind
Liquidation
This is the first step of the process and it begins by submitting an Immediate-or-Cancel order to the market. The limit price of this order is chosen such that if the order is matched, the remaining portfolio value of the Multi-Collateral margin account will not be negative. Liquidations will incur a Liquidation fee in this step which will be debited from the account. The liquidation fee will be equal to half of the minimum MM% for the contract, for example: PF_XBTUSD would be 0.5% (1% * 0.5)
|
EXAMPLE: LIQUIDATION |
You have an open long position of 10 contracts in PF_XBTUSD with an Avg Entry Price of 20000. The value of this position is $200,000 (10 * 20000) and the margin equity used for this position was $10,000. The Initial Margin requirement for this position was $4,000 (2% of $200,000) and the Maintenance Margin level is $2,000. In this position, the price at which you will be liquidated is $19,200, where your position value will be $192,000. As soon as the Mark Price reaches 19,200 or below, your position will enter liquidation. A liquidation fee of $1,000 (0.5% * $200,000) will be debited from your account immediately. Afterwards an Immediate-or-Cancel sell order is submitted on your behalf around 19,100 (will differ slightly depending on taker fee%), where your margin equity will be just above zero. The limit price of this order assures that if the order is matched, the margin equity of the margin account will not be less than zero. |
|---|
If the liquidation order results in being filled at price better than the bankruptcy price, then the client keeps whatever remaining maintenance margin there is. This is contrary to how some other exchanges operate where you lose the entire maintenance margin regardless of what price your liquidation is filled at.
Assignment
If a position cannot be liquidated (for example due to lack of demand on the market) and there are unfilled contracts from the above Immediate-or-Cancel order, then the remainder of the position undergoes "assignment" process. This process takes the unfilled liquidation remainder and assigns it to a liquidity provider at a min / max price of 0.5% / 2.5% away from the Mark Price if there are sufficient funds inside the futures Liquidity Pool.
If there are no funds available in the liquidity pool at the time of the assignment, then the fill price will default to the zero-equity price in order that your counterparty is able to maintain their position.
Example Assignment
Let's assume that there is a client whose current positions are:
- LONG 10 Contracts on PF_XBTUSD
- LONG 3 Contracts on FF_XBTUSD_230728
Both these positions are cross margined on the Multi-Collateral margin wallet, which measures the risk in realtime, valuing the collateral vs position value, to determine whether to liquidate.
Once the margin wallet for the contract type is below the maintenance margin, liquidation occurs and the system sells those positions into the orderbook at the 0-equity imputed price for each contract.
In this case, the client's liquidation plays out as follows:
|
Position |
Size |
Amount Liquidated |
Amount Assigned |
|---|---|---|---|
| PF_XBTUSD |
10 |
8 |
2 |
| FF_XBTUSD_230728 |
3 |
3 |
0 |
This means the entire FF_XBTUSD_230728 position of 3 Contracts was successfully sold into the orderbook to new counterparties who had existing bids.
However, the PF_XBTUSD position of 10 Contracts was only able to liquidate 8 successfully into the orderbook, with the remaining 2 unable to find a new counterparty.
As a result, this unfilled liquidation remainder is handled in the PAS by routing the LONG position to liquidity providers participating in the program based on individual preferences.
Below is an example notification for an Assignment of -699.8 PF_LINKUSD contracts allocated to "[email protected]". The client receives the following email (note that this format may change so do not rely on this formatting):
The liquidity provider immediately receives the notification over WebSocket feed alerting them to the Assignment. The message takes this format:
{
"feed": "fills",
"username": "[email protected]",
"fills": [
{
"instrument": "PI_XBTUSD",
"time": 1581026151,
"price": 9292.5,
"seq": 103,
"buy": true,
"order_id": "87755b99-bfb7-4f51-a72b-70f542f793a5",
"fill_id": "89f0f4f9-66b5-45eb-ba3f-6eeb2da5cadd",
"fill_type": "assignee",
"qty": 184317
}
]
}
Additionally, the client may poll the REST API endpoint for fills to see:
{
"result": "success",
"fills": [
{
"fill_id": "89f0f4f9-66b5-45eb-ba3f-6eeb2da5cadd",
"symbol": "pi_xbtusd",
"side": "buy",
"order_id": "87755b99-bfb7-4f51-a72b-70f542f793a5",
"size": 184317,
"price": 9292.5,
"fillTime": "2020-02-06T21:55:51.000Z",
"fillType": "assignee"
}
...
]
}
The key fields in the responses are fill_type and fillType (for WebSocket and REST, respectively), which both take the value "assignee". This is the indication that should be used to programmatically handle the assignment.
Note:
- Set your preferences as you see fit on the Assignment Program section of the platform.
- You will not receive an Assignment that your available margin for the contract type can not handle.
The decimal and thousands separators shown in this article may differ from the formats displayed on our trading platforms. Review our article on how we use points and commas for more information.
Covered Liquidation
If, for whatever reason, this assignment process is unable to find liquidity providers to take the position, then the remaining contracts undergo a "covered liquidation" if the futures Liquidity Pool has enough funds to cover the additional losses. This means that another Immediate-or-Cancel order is submitted to the market, with it's price at a deviation of 5% away from the best bid / ask price.
However, if the Liquidity Pool does not have enough funds to cover the additional losses, the position will move onto the next step of the EPP; Unwind.
Example Covered Liquidation
Let's assume that there is a user whose current positions are:
- LONG 50 Contracts on PF_ETHUSD
- LONG 15 Contracts on FF_ETHUSD_230728
Both these positions are cross margined using the Multi-Collateral margin wallet, which measures the risk in realtime, valuing the collateral vs position value, to determine whether to liquidate.
Once the Multi-Collateral wallet margin equity is below the maintenance margin requirement for both positions, liquidation occurs and the system sells those positions into the orderbook at the 0-equity imputed price for each contract.
In this case, the user's liquidation plays out as follows:
| Position | Size | Amount Liquidated | Amount Assigned | Amount Liquidated (covered) | Amount Unwound |
|---|---|---|---|---|---|
| PF_ETHUSD | 50 | 30 | 15 | 5 | 0 |
| FF_ETHUSD_230728 | 15 | 15 | 0 | 0 | 0 |
This means the entire FF_ETHUSD_230728 position of 15 Contracts was successfully sold into the orderbook to new counterparties who had existing bids. The PF_ETHUSD position of 50 Contracts was able to liquidate 30 successfully into the orderbook and filled the remaining 15 contracts via the Position Assignment system.
Assuming the futures liquidity pool has enough funds to cover the additional losses, the remaining 5 contracts will attempt to be liquidated using an Immediate-or-Cancel order with it's price 5% below the best bid price at the time. Once the order fills, the bankrupt parties additional losses will be covered by the liquidity pool by crediting the margin account, such that the remaining portfolio value of the margin account will not be negative.
Unwind
If, for whatever reason, the covered liquidation is unable to be executed, then the remaining contracts undergo an "unwind". This means that the contracts between you and your counterparties end and that the remaining portfolio value of the margin account is transferred to your counterparties. An unwind of one margin wallet will not affect any other margin wallets.
Example Unwind
Let's assume that there is a user whose current positions are:
- LONG 50 Contracts on PF_ETHUSD
- LONG 15 Contracts on FF_ETHUSD_230728
Both these positions are cross margined using the Multi-Collateral margin wallet, which measures the risk in realtime, valuing the collateral vs position value, to determine whether to liquidate.
Once the Multi-Collateral wallet margin equity is below the maintenance margin requirement for both positions, liquidation occurs and the system sells those positions into the orderbook at the 0-equity imputed price for each contract.
In this case, the user's liquidation plays out as follows:
| Position | Size | Amount Liquidated | Amount Assigned | Amount Covered Liquidation | Amount Unwound |
|---|---|---|---|---|---|
| PF_ETHUSD | 50 | 30 | 15 | 3 | 2 |
| FF_ETHUSD_230728 | 15 | 15 | 0 | 0 | 0 |
This means the entire FF_ETHUSD_230728 position of 15 Contracts was successfully sold into the orderbook to new counterparties who had existing bids. The PF_ETHUSD position of 50 Contracts was able to liquidate 30 contracts successfully into the orderbook and filled the remaining 15 contracts via the Position Assignment system as well as covered the liquidation of 3 contracts using the liquidity pool.
As a result, the remaining 2 contracts will be unwound.
Below is an example notification for an Unwind of 10,000 Contracts to the unwound counterparty "[email protected]". The unwind counterparty receives the following email (note that this format may change so do not rely on this formatting):
The unwound counterparty immediately receives the notification over WebSocket feed alerting them to the Assignment. The message takes this format:
{
"feed":"fills",
"username":"[email protected]",
"fills":[
{
"instrument":"PI_ETHUSD",
"time":1623344903068,
"price":1647.0,
"seq":1,
"buy":false,
"qty":10000.0,
"order_id":"9bae454b-ec93-43f8-b31c-33d3881fe7ae",
"fill_id":"1298e9ed-4284-43b9-ab9e-0d93591efb36",
"fill_type":"unwindCounterparty",
"fee_paid":-0.00182149362,
"fee_currency":"ETH"
}
]
}
Additionally, the user may poll the REST API endpoint for fills to see:
{
"result":"success",
"fills":[
{
"fill_id":"1298e9ed-4284-43b9-ab9e-0d93591efb36",
"symbol":"pi_ethusd",
"side":"sell",
"order_id":"9bae454b-ec93-43f8-b31c-33d3881fe7ae",
"size":10000,
"price":1647,
"fillTime":"2021-06-10T17:08:23.068Z",
"fillType":"unwindCounterparty"
}
],
...
}
The key fields in the responses are fill_type and fillType (for WebSocket and REST, respectively), which both take the value "unwindCounterparty". This is the indication that should be used to programmatically handle the assignment.
The unwind mechanism encourages market participants to sufficiently collateralise their margin accounts. It also compensates any party whose position has been unwound as a result of their counterparty not posting sufficient margin. Unwind Thresholds are chosen such that they cover approximately a 1 hour 99th percentile adverse price move. Therefore, if a trade closes because your counterparty's position has been unwound, then the compensation payment should enable you to replace your trade with no loss (and potentially a profit). In the unwind scenario, there is an order of operations of who, on the other side, is picked as counterparty:
The ranking utilises the following criteria:
- Position Value = [Size*Price]
- Return on Equity = [PnL/IM]
- Effective Leverage = [Position Value/Portfolio Value]
Rank (1,2,3...)-- Separate for LONG and SHORT:
- if negative: [RoE/Effective Leverage]
- if positive: [RoE*Effective Leverage]
E.g. When a long position is unwound, it targets the positions of short by highest rank (1 first, 2 second, 3 third, etc.) until fully unwound.