Post by baldpate on Feb 12, 2015 19:09:51 GMT
The auction Loan Offers tab summarizes the bidding by aggregating all the bids made by a particular Lender at a particular Rate into a single entry. A lender may appear several times in the bidding list, of course, but apparently only once at each Rate. If a Lender makes several bids at the same Rate at different times, those bids are all aggregated into a single entry. That aggregate entry is stamped with the date & time of the earliest bid made by the Lender at that rate.
Imagine the following bidding scenario:
On Tue 10th, lender BigGuy makes 5 bids of £10 @ 17% (total £50);
On Wed 11th, lender LittleGuy makes 2 bids of £10 @ 17% (total £20);
On Wed 12th, lender BigGuy makes a further 50 bids of £10 @ 17% (total of a further £500).
On the Loan Offers tab, this would be seen as two entries, thus:
Lender Amount Rate Bids Date
LittleGuy £20 17% 2 Wed 11th
BigGuy £550 17% 55 Tue 10th
If all higher bids had been knocked out, LittleGuy might be forgiven for thinking that his modest £20 was in immediate danger of going the same way.
He would be wrong : in fact there are £500 worth of later bids (those made by BigGuy on Wed 12th) which are at jeopardy before LittleGuy's £50 is knocked out.
I've been caught out a couple of times by this 'feature'. I wonder how many others have been too?
I further wonder why ReBS chose to program it this way? I understand completely the argument for not listing each individual bid - the impact on page display would be horrendous (in the above example, 57 lines rather than 2). And it is quite unnecessary, because the bidding interface makes it very easy to simultaneously place large numbers of small bids. However, I strongly suspect that the sort of bidding tactic which BigGuy has adopted in the above example is relatively rare, and that there would be little impact on the display performance if only bids made on the same occassion were aggregated. If that were the case, in the above example the Loan Offers tab would look like this :
Lender Amount Rate Bids Date
BigGuy £500 17% 50 Thu 12th
LittleGuy £20 17% 2 Wed 11th
BigGuy £50 17% 5 Tue 10th
I'm sure you will agree this much better represents the true situation.
Any thoughts? It would be nice it someone from Rebuilding Society could respond - there may be technical impediments, but as a retired software developer I can't imagine what they might be.
Chris
Imagine the following bidding scenario:
On Tue 10th, lender BigGuy makes 5 bids of £10 @ 17% (total £50);
On Wed 11th, lender LittleGuy makes 2 bids of £10 @ 17% (total £20);
On Wed 12th, lender BigGuy makes a further 50 bids of £10 @ 17% (total of a further £500).
On the Loan Offers tab, this would be seen as two entries, thus:
Lender Amount Rate Bids Date
LittleGuy £20 17% 2 Wed 11th
BigGuy £550 17% 55 Tue 10th
If all higher bids had been knocked out, LittleGuy might be forgiven for thinking that his modest £20 was in immediate danger of going the same way.
He would be wrong : in fact there are £500 worth of later bids (those made by BigGuy on Wed 12th) which are at jeopardy before LittleGuy's £50 is knocked out.
I've been caught out a couple of times by this 'feature'. I wonder how many others have been too?
I further wonder why ReBS chose to program it this way? I understand completely the argument for not listing each individual bid - the impact on page display would be horrendous (in the above example, 57 lines rather than 2). And it is quite unnecessary, because the bidding interface makes it very easy to simultaneously place large numbers of small bids. However, I strongly suspect that the sort of bidding tactic which BigGuy has adopted in the above example is relatively rare, and that there would be little impact on the display performance if only bids made on the same occassion were aggregated. If that were the case, in the above example the Loan Offers tab would look like this :
Lender Amount Rate Bids Date
BigGuy £500 17% 50 Thu 12th
LittleGuy £20 17% 2 Wed 11th
BigGuy £50 17% 5 Tue 10th
I'm sure you will agree this much better represents the true situation.
Any thoughts? It would be nice it someone from Rebuilding Society could respond - there may be technical impediments, but as a retired software developer I can't imagine what they might be.
Chris
