Number of matched bets @ price? SV

[decomez6]

looking to save the number of matched bets at a fixed odd position ,
similar to number of unmatched Back / Lay SV at a price .

- trigger only 1 bet /per 1 fixed odd outside the current trading price.

Problem :
----whenever a rule is set to fire only once , some of the bets hit the market unmatched . creating a missed opportunity.

----set to trigger multiple times the rule will sometimes match excessive bets , even when the refresh rate is reduced to seconds or milliseconds.

Solution ?
an SV that stops the rule from triggering at a fixed odd when a certain amount of bets are matched @ the price.

Any ideas greatly appreciated THANKS


.

[ShaunWhite]

What's going to be tricky is when offers are filled at several prices. It might not affect your use case but would need to be considered in the design of a general solution. The average price matched might not be a step on the price ladder....

The matching algorithm for Fill or Kill orders behaves slightly differently to that for standard limit orders. Whereas the price on a limit order represents the lowest price at which any fragment should be matched, the price on a Fill or Kill order represents the lower limit of the Volume Weighted Average Price (“VWAP”) for the entire volume matched. So, for instance, a Fill or Kill order with price = 5.4 and size = 10 might be matched as £2 @ 5.5, £6 @ 5.4 and £2 @ 5.3.

[decomez6]

Thanks Shaun ,
Always greatfull to the insights you offer on the market .and just like that , learned something new on how the matching algorithm works

What's going to be tricky is when offers are filled at several prices. price = 5.4 and size = 10 might be matched as £2 @ 5.5, £6 @ 5.4 and £2 @ 5.3.

personally wouldn't mind any sort of control over how much amount/ number of bets matched @price .
I think a solution would be:
have a possibility of clearing any unwanted bets @ price.

-So you can have one SV that controls amount matched @price
-another cancel / clears any excess @ the same price .

At the moment I can clear any unmatched bets (price dependant)... But i need to know how much has been matched @ the same price and store the same to run as a condition.

[ShaunWhite]

Thx dec. Cutting and pasting from the api documentation makes me appear to know far more than I do.

It just tied in with something I was looking at recently, eg time between making an offer and it being filled. Too fast and you're too generous, too slow and you're too greedy. So matching, partial fills, avg price fills, XM etc were in my consciousness so to speak. There's an understandable disconnect between people seeing how BA works and knowing what's under the hood so things that sounds easy often aren't or the other way round. I could be wrong but this had the feel of a job that's not as easy as it might seem.

... Or Dallas might do it in 5 minutes.

Take care buddy.

[decomez6]

.... Or Dallas might do it in 5 minutes.

Take care buddy.

Dallas doesn't respond in 5mins..

Then You know , solution's self explanatory .. OR the topic has been covered countless times before.

Ta da

[Dallas]

What's going to be tricky is when offers are filled at several prices. It might not affect your use case but would need to be considered in the design of a general solution. The average price matched might not be a step on the price ladder....

The matching algorithm for Fill or Kill orders behaves slightly differently to that for standard limit orders. Whereas the price on a limit order represents the lowest price at which any fragment should be matched, the price on a Fill or Kill order represents the lower limit of the Volume Weighted Average Price (“VWAP”) for the entire volume matched. So, for instance, a Fill or Kill order with price = 5.4 and size = 10 might be matched as £2 @ 5.5, £6 @ 5.4 and £2 @ 5.3.

Also with XM and in football XMXM I'm not even sure if what it would be counted at, the price on the selection its placed on or the equivalent price of the other selection or market it was XM'ed against

So the short answer to the initial question is like you've already said there's a lot that would need to be factored in for something like this and just how useful/accurate it would be may render it pointless to most?

[decomez6]

What's going to be tricky is when offers are filled at several prices. It might not affect your use case but would need to be considered in the design of a general solution. The average price matched might not be a step on the price ladder....

The matching algorithm for Fill or Kill orders behaves slightly differently to that for standard limit orders. Whereas the price on a limit order represents the lowest price at which any fragment should be matched, the price on a Fill or Kill order represents the lower limit of the Volume Weighted Average Price (“VWAP”) for the entire volume matched. So, for instance, a Fill or Kill order with price = 5.4 and size = 10 might be matched as £2 @ 5.5, £6 @ 5.4 and £2 @ 5.3.

Also with XM and in football XMXM I'm not even sure if what it would be counted at, the price on the selection its placed on or the equivalent price of the other selection or market it was XM'ed against

So the short answer to the initial question is like you've already said there's a lot that would need to be factored in for something like this and just how useful/accurate it would be may render it pointless to most?

Thank you Dallas
initially thought it would be a matter of tracking individual bet references .
Once a bet is matched , then use the reference to identify the price it was matched @.
Store the price as an SV in a history list that accumulatively store number of matched bet in the selection @ a price...
So to say , each price on the ladder would have its own history list waiting in a standby mode , just to store the number or amount of bets .