У цій статті ми розглянемо ситуацію, коли трейдер на Kraken Derivatives ліквідується, а нова Система призначення позицій (PAS) розподіляє незаповнену ліквідацію постачальникам ліквідності в PAS. Ми розглянемо всі приклади відповідей, які отримає учасник.
Припустимо, що є клієнт, поточні позиції якого:
- LONG 1 760 000 контрактів на PI_BTCUSD
- LONG 300 000 контрактів на FI_BTCUSD_200228
Обидві ці позиції використовують основний маржинальний рахунок FI_BTCUSD, який вимірює ризик у реальному часі, оцінюючи заставу проти вартості позиції, щоб визначити, чи потрібно ліквідувати.
Як тільки маржинальний рахунок для типу контракту опускається нижче рівня підтримуючої маржі, відбувається ліквідація, і система продає ці позиції в книгу ордерів за ціною 0-еквіваленту, що приписується для кожного контракту.
У цьому випадку ліквідація клієнта відбувається наступним чином:
Позиція | Розмір | Ліквідована сума | Призначена сума |
|---|---|---|---|
PI_BTCUSD | 1 760 000 | 1 007 379 | 752 621 |
FI_BTCUSD_200228 | 300 000 | 300 000 | 0 |
Це означає, що вся позиція FI_BTCUSD_200228 у 300 000 контрактів була успішно продана в книгу ордерів новим контрагентам, які мали існуючі заявки.
Однак позиція PI_BTCUSD у 1 760 000 контрактів змогла успішно ліквідувати лише 1 007 379 в книгу ордерів, а решта 752 621 не змогла знайти нового контрагента.
В результаті, цей незаповнений залишок ліквідації обробляється в PAS шляхом маршрутизації позиції LONG постачальникам ліквідності, які беруть участь у програмі, на основі індивідуальних переваг.
Нижче наведено приклад повідомлення про призначення 184 317 контрактів, виділених для "[email protected]". Клієнт отримує наступний електронний лист (зверніть увагу, що цей формат може змінюватися, тому не покладайтеся на нього):
Постачальник ліквідності негайно отримує сповіщення через WebSocket feed, що повідомляє його про призначення. Повідомлення має такий формат:
{
"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
}
]
}
Крім того, клієнт може опитувати кінцеву точку REST API для заповнень, щоб побачити:
{
"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"
}
...
]
}
Ключовими полями у відповідях є fill_type та fillType (для WebSocket та REST відповідно), які обидва приймають значення "assignee". Це є індикатором, який слід використовувати для програмної обробки призначення.
Примітка:
- Встановіть свої переваги на власний розсуд у розділі Програма призначення платформи.
- Ви не отримаєте призначення, яке не зможе обробити ваша доступна маржа для типу контракту.
Десяткові та тисячні роздільники, показані в цій статті, можуть відрізнятися від форматів, що відображаються на наших торгових платформах. Перегляньте нашу статтю про те, як ми використовуємо крапки та коми для отримання додаткової інформації.