On 01/07/2011 15:55, Paul Sheer wrote:
Both sides of the transaction stamp the transaction with
timestamps with microsecond resolution.
Is this a fact?
When the trades are reconciled at the end of
the day, these timestamps need to match with a fuzz factor
that's in the sub-millisecond range
Is this too a fact in combination with the first statement?
Microsecond resolution of the timestamp, millisecondish fuzzing, yes.
So there's no contradiction here. The accuracy of the timestamps is in
the tens to hundreds of microsecond range, even if the resolution is
supposed to be microsecond. There's nothing contradictory about this at
all.
Are the trades always automatically reconciled at the end of each day?
There is a three day clearing period after the trade, yes.
Our billing logs also need to be reconciled, and such clock
offsets also matter. But it only matters on the rare cases that
one is doing a *manual* investigation.
All trades have to be matched up for them to be processed. If they
don't, they are kicked over to a human to match them up and to prevent
fraud. They very much matter and trying to sort out a large skew after
the fact is difficult. These procedures exist to prevent fraud.
So even in your case, it matters, and people have to get into the loop
sometimes.
Of course these days companies co-locate at the exchange to shave off
microseconds of latency from speed of light...
Warner
http://www.infoworld.com/d/the-industry-standard/hackers-find-new-way-cheat-wall-street-everyones-peril-699
I read this as people fraudulantly finding out things ahead of time
using back channels.
I believe this is not a timestamp issue. It's a latency issue.
-paul
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
