0011-MARA-check_order_allocate_margin.md

Check Order Allocate Margin

Outline

When an order or other market instruction (amend, cancel, etc.) is submitted we need to check if it changes the margin requirement for the trader who has submitted it, and if it increases them we need to allocate (request to allocate in a future, shared world) margin before accepting the order.

Orders should be rejected if we can’t allocate sufficient margin.

Acceptance criteria

1. If an order is amended such that margin requirement is increased and user has sufficient balance in the general account to top up their margin account then the amendment is executed successfully. (0011-MARA-001)
2. In Spot market, if an order is amended such that holding requirement is increased and user has sufficient balance in the general account to top up their holding account then the amendment is executed successfully. (0011-MARA-018)
3. If an order is amended such that margin requirement is increased and user doesn't have sufficient balance in the general account to top up their margin account then their amend is not executed but the unamended order stays on the book. (0011-MARA-002)
4. In Spot market, if an order is amended such that holding requirement is increased and user doesn't have sufficient balance in the general account to top up their holding account then their amend is not executed but the unamended order stays on the book. (0011-MARA-019)
5. Cancelling an order releases the margin amount back to user's general account, provided the user has no other orders or positions (0011-MARA-003) In Spot market, cancelling an order releases the holding amount back to user's general account. (0011-MARA-020)
6. If an order is amended such that margin requirement is decreased then the amendment is executed successfully. (0011-MARA-004)
7. If an order is partially filled then the margin requirements are recalculated reflecting the reduced order size and new position size. (0011-MARA-005) In Spot market, if an order is partially filled then the holding requirements are recalculated reflecting the reduced order size. (0011-MARA-021)
8. If an order is partially filled and if this leads to a reduced position and reduced riskiest long / short then the margin requirements are seen to be reduced and if margin balance is above release level then the excess amount is transferred to the general account. (0011-MARA-006)
9. Margin is correctly calculated for all order types in continuous trading:
   1. Limit GTT (0011-MARA-007)
   2. Limit GTC (0011-MARA-008)
   3. Limit GFN (0011-MARA-009)
   4. Pegged GTT (0011-MARA-010)
   5. Pegged GTC (0011-MARA-011)
   6. Pegged GFN (0011-MARA-012)
10. Margin is correctly calculated for all order types in auction mode: 1.Limit GTT (0011-MARA-013) 1.Limit GTC (0011-MARA-014) 1.Limit GFA (0011-MARA-015) 1.Pegged GTT (parked in auction *) (0011-MARA-016) 1.Pegged GTC (parked in auction * ) (0011-MARA-017)
11. In Spot market, holding in holding account is correctly calculated for all order types in continuous trading:
    1. Limit GTT (0011-MARA-022)
    2. Limit GTC (0011-MARA-023)
    3. Limit GFN (0011-MARA-024)
    4. Pegged GTT (0011-MARA-025)
    5. Pegged GTC (0011-MARA-026)
    6. Pegged GFN (0011-MARA-027)
12. In Spot market, holding in holding account is correctly calculated for all order types in auction mode: 1.Limit GTT (0011-MARA-028) 1.Limit GTC (0011-MARA-029) 1.Limit GFA (0011-MARA-030) 1.Pegged GTT (parked in auction *) (0011-MARA-031) 1.Pegged GTC (parked in auction * ) (0011-MARA-032)

Pseudocode

The logic is something like this:

enum ValidationResult = Accept | Reject

/* NB: a position record is assumed to contain all required data about a trader's open volume and active orders to calculate margin. For example, this means containing or being able calculate the 'net worst' long and short positions given all orders.
*/

/*** Ensure that it is reasonably likely (guaranteed, in a non-sharded
		 environment) that there is sufficient allocated margin to execute
		 a market instruction, or reject the instruction. */

fn allocate_instruction_margin(
		m: Market,
		i: Instruction) -> ValidationResult {

	let current_pos = get_position(
			market: m,
			party: i.sender)
	let new_pos = calculate_updated_position(
			current_pos,
			instruction: i)

	// NB: this is oversimplified. In reality, margins are a list of
	// assets + amounts, 1 per margin asset for the market. So the margin
	// logic is repeated at each step for each asset.
	let current_margin = margin_account_balance(
			party: i.sender,
			market: m)
	let new_margin = calculate_adjusted_margin(
			current_pos,
			new_pos,
			current_margin)

	if new_margin.initial_margin > current_margin {
		let available = collateral_account_balance(
			party: i.sender,
			asset: m.margin_asset)
		if available < new_margin.initial_margin - current_margin {
			return ValidationResult.REJECT
		}
		request_transfer(
				from: collateral_account_for(
						party: i.sender,
						asset: m.margin_asset),
				to: margin_account_for(
						party: i.sender,
						market: m,
						asset: m.margin_asset),
				amount: new_margin.initial_margin - current_margin)
	}

	return ValidationResult.ACCEPT
}