Bloomberg - get real world prices from the API -

for number of financial instruments, bloomberg scales prices shown in terminal - example:

• fx futures @ cme: e.g. adz3 curncy (dec-2013 aud futures @ cme) show 93.88 (close on 04-oct-2013), whereas actual (cme) market/settlement price 0.9388

• fx rates: fx rates scaled - may vary way round fx rate asked for, eurjpy curncy (i.e. jpy per eur) has bgn close of 132.14 on 04-oct-2013. inverse (eur per jpy) 0.007567. however, jpyeur curncy (i.e. eur per jpy), bgn has close of 0.75672 04-oct-2013.

• fx forwards: depending on whether asking rates or forward points (which can set overrides)... if ask rates, might these in terms of original rate, eurjpy1m curncy, bgn has close of 132.1174 on 04-oct-2013. if ask forward points, these scaled factor - i.e. -1.28 eurjpy1m curncy.

now, not trying criticise bloomberg way represent data in terminal. goodness knows when first wrote these systems, , have maintain functionality market practitioners have come know , perhaps love... in context, scaling significant figures might make sense.

however, when using api, want real-world, actual prices. like... actual price @ exchange or actual price can trade eur jpy.

so... how can that?

well... approach have come use find flds communicate scaling information, , fetch value reverse scale have applied values. futures, that's px_scaling_factor. fx, i've found px_pos_mult_factor reliable. fx forward points, it's fwd_scale.

(it's worth mentioning how these applied vaires - px_scaling_factor futures prices should divided by, px_pos_mult_factor fx rates should multipled by, , fwd_scale how many decimal places divide forward points value can added actual fx rate.)

the problem doubles number of fetchs have make, adds significant overhead use of api (reference data fetches seem take longer historical data fetches.) (fwiw, i'm using api in java, question should equally applicable using api in excel or of other supported languages.)

i've thought finding out information , storing somewhere... i'd not have hard code that. also, require spend long time finding out right scaling factors different instruments i'm interested in. then, have no guarantee wouldn't change scale on me @ point!

what able apply override in fetch allow me specify scale should used. (and no, fields above not seem override-able.) i've asked "helpdesk" on lots , lots of occasions - i've been badgering them about 12 months, ever bloomberg, nothing seems have happened.

so...

• has else in community faced problem?
• has else found way of setting override?
• has else worked out better solution?

short answer: seem have available information @ hand , there not more can do. these conventions stable on time fine store scales/factors instead of fetching data everytime (the scale of eurgbp points 4).

for fx, have file with:

• number of decimal (for spot, points , all-in forward rate)
• points scale
• spot date

to answer specific questions:

• fx futures @ cme: on adz3 curncy > des > 3:

  for specific contract, price quoted in cents/aud instead of exchange convention usd/aud in order show greater precision both futures , options. calendar spreads adjusted accordingly. please note tick size has been adjusted 0.01 ensure tick value , contract value consistent exchange.

  not sure there can this, apart manually checking factor...

• fx rates: px_pos_mult_factor best bet indeed - note value of field given pair extremely unlikely change. alternatively, follow market conventions pairs , afaik rates actual rate. use eurjpy instead of jpyeur. major currencies, in order, are: eur, gbp, aud, nzd, usd, cad, chf, jpy. pairs don't involve of have fetch info.

• fx forwards: points follow market conventions, scale can vary (it 4 of time, 3 gbpczk example). should not change on time given pair.