Question on Traded Volume

[geoffw123]

Hi

I am using listMarketBook() to get the current prices and traded volume on a selection. I am using EX_ALL_OFFERS and EX_TRADED params to get full book depth. What I have done so far is basically working but I am a bit puzzled by the traded volume list it is returning.

Some of the entries are at the standard Betfair price increments E.g. £9.75 @ 7.0, but I am also getting lots of non standard increments E.g. £8.08 @ 7.62. After a little thought this makes sense as a Back order may have been placed at a tick where 50% got matched at the requested tick, but 50% may have got matched at the tick above, giving a price average in the middle of the tick interval. (Please correct me if this isn't the explaination)

As I am trying to make myself a Ladder type form, having traded volume return at non standard intervals is a pain. Is there a setting I can tweak to persuade the server to round the returned data to the nearest standard tick ?

At the moment I am throwing away returned traded volumes that aren't at standard ticks. This of course means that the displayed rows of traded volumes don't add up to the totalTraded volume on that selection that I am also displaying.

Thanks for any help.

Geoff

[geoffw123]

While I was waiting for some feedback on this I thought I would check what one of the Professional Apps does? I downloaded one from the Betfair App Directory and compared the same horse selection at the same race.

My App is showing 3 traded volume rows of £7, £16 & £2 yet the total traded volume displays as £161. Not exactly a trivial error.

To my amusement the Pro App also displays £7, £16 & £2 for a total of £161.

It gave me quite a warm glow knowing I am currently implementing professional quality bugs.

[StefanBelo.]

Can you check my app:

http://bfexplorer.net/Products/Bfexplorer

If the app produces the same results?

[geoffw123]

Hi

I think I jumped to the wrong conclusion on what was going on here with the explanation of why Betfair returns non tick increments for the matched amounts.

I was looking at the returned data for a few horse races, some show the issue and some don't. I think I am seeing some races that have had runners removed and a rule 4 deduction applied. Apart from adjusting live odds of remaining runners, they must also factor in the reduction into the odds of the already matched amounts.

I guess most Apps, just ignore this and live with the discrepancies this introduces into a ladder grid view.

Geoff

[StefanBelo.]

Geoff, very strange of thinking you have got.

[geoffw123]

Huh ? I think that reply lost something in the translation ?

What is your explanation then for Betfair returning non tick increments for matched amounts ?

Geoff

[Nick JD]

Huh ? I think that reply lost something in the translation ?

What is your explanation then for Betfair returning non tick increments for matched amounts ?

Geoff

Just a guess, but it is very easy to have ten bucks matched at 2 or 3 different prices (say, $3.33@3.40, $3.33@3.45 and $3.34@3.60) resulting in an average matched price of something like, I dunno, $10@3.52 ... an invalid price.

Does BF report on amounts matched using the same logic? And then apply some kind of resolution algo on it to repair the goofiness?

Or is this just one of those situations that it's really difficult to transfer these HUGE amounts of data faultlessly to millions of people every time all the time?

[StefanBelo.]

Did you already hear about cross matching?

[geoffw123]

Hi Nick

Thanks for the reply.

Or is this just one of those situations that it's really difficult to transfer these HUGE amounts of data faultlessly to millions of people every time all the time?

Nope that is definitely not the explanation, it was consistent and repeatable.

Just a guess, but it is very easy to have ten bucks matched at 2 or 3 different prices (say, $3.33@3.40, $3.33@3.45 and $3.34@3.60) resulting in an average matched price of something like, I dunno, $10@3.52 ... an invalid price.

I think that is the same wrong conclusion I jumped to initially. Yes from your perspective your order is matched in two chunks the average of which is likely not a standard BF tick increment. But when BF is distributing that info to everyone as matched amounts/prices, it just says it saw x matched @3.40 and y matched @3.50. No invalid BF tick increments.

Stefan

Did you already hear about cross matching?

Yes I am aware of cross matching. You didn't explain how cross matching gives rise to the numbers I was seeing.

I am still of the firm opinion that the non standard matched prices I was seeing was due to it being a horse race with a removed runner and the rule 4 deduction being factored in.

Geoff

[geoffw123]

As I seem to be disagreeing with one of the Professional App guys here I thought I would write a bit of code to prove or disprove my point.
I ran this test a couple of hours before racing starts today.

UK and Ireland have 35 races today, The Win markets matched amounts had 23 markets with valid standard BF tick increments, and 12 with non standard ticks.

The correlation was 100%, where the market had no removed runners I got the standard ticks, where there were 1 or more removed runners I got the non standard ticks.

End of discussion

Geoff

[betdynamics]

I guess this is to do with adjustment factors then.

Where there is a "material" non-runner, bets that were matched prior to the selection becoming a non-runner are adjusted by an adjustment (reduction) factor.

The adjustment factor for each runner is part of the information returned by listMarketBook (it is part of the Runner object).

As I don't have any experience of ladder-based displays, I don't know how these reduced odds are returned in the traded volume information.

[StefanBelo.]

As I seem to be disagreeing with one of the Professional App guys here I thought I would write a bit of code to prove or disprove my point.
I ran this test a couple of hours before racing starts today.

UK and Ireland have 35 races today, The Win markets matched amounts had 23 markets with valid standard BF tick increments, and 12 with non standard ticks.

The correlation was 100%, where the market had no removed runners I got the standard ticks, where there were 1 or more removed runners I got the non standard ticks.

End of discussion

Geoff

Geoff, use just your common sense.

If a horse is withdrawn from a race, to remaining horses, to already matched bets on those horses, there is applied reduction factor, so it would meant that on all active horses you would find matched prices out of regular odds increments, but that is not true I believe.

You can find such irregular prices in tradedVolume only on horses on which cross matching bets were matched.

[vostro]

Check the MatchProjection setting you're using; I think setting it to NO_ROLLUP will solve this for you.

[geoffw123]

Hi Vostro

Thanks for the reply. I did test your suggestion, it makes no difference to what I observe. I am 100% happy my explanation for the issue is correct. Non standard odds increments only appear in horse racing markets and only appear if there is a removed runner in the race. As I didn't manage to convince at least one other person, I attached my test results for information.

These results do show that the inverse is not always true.

There are some races (E.g. MarketId=1.125576906) where there is a non runner but the matched odds tick increments are still the standard Betfair ones.

I think the explanation for this is that if the horse that is removed is a rank outsider and doesn't contribute more than 2.5% of the book then Betfair don't bother applying a rule 4 reduction factor.

Geoff

[StefanBelo.]

But when such rule is applied, then to all active horses should be applied reduction factor, so on horses traded volume data you would find irregular prices/odds, if you are right, but you cannot find them on all horses.

Such prices can be found on horses where cross matching bet was matched only.