And two minutes from program launch, the program pulls in a text file, heavily encoded, unencrypts it, dynamically compiles it, and runs it, completely changing its functionality. Try to monitor that.
A lot of the burden is being placed on the vendors, as Robert alludes to with what is being done with the Sterling and LSPD APIs. And since you connect to the vendor's software, it's pretty easy to monitor what you are up to in terms of usage and control what programs connect to their API. It's already happened on the pure data vendor side of the biz. And now it's happening at the brokers.
think about what you're talking about here terr... literally, a method to hack a broker/vendor api used to authenticate data/execution. this would be a very bad idea. this is no longer misrepresentation, this is criminal hacking. good luck with that if you get caught.
Shreddog, I deal with lots of different vendors and their APIs. They can easily control *who* connects to their API. They can easily log every API call. They definitely have no way of finding out or controlling exactly what the logic of the program that is placing the orders is, how it arrives at its decisions, and whether it displays anything to the user or not.
lspdtrdr - it's not hacking. It is pretty straightforward programming. Almost the only way for the monitoring you're suggesting to work is if you're required to submit the full source code of your program to the monitors so they can look through it and see if anything "forbidden" is going on, then THEY compile it, THEY add the hash-checking stuff to it, THEY give it to you and you can ONLY run that to connect. And even then (as you can see from the unsuccessful anti-pirating efforts of numerous software companies for decades) there are ways around it. And - I am still waiting for the cite that the "auditing" by NYSE involves anything nearly as invasive as placing their monitoring software on your computer.
True enough, but as you say, they can watch your API calls. You better make sure it looks like a human making those calls for his charting program!
Stepping out of the details for a moment, what really annoys me is how all this paywalling limits innovation, and creates advantages for those who have the ca$h. It's not just market data. It's book data: Level 1, level 2, level 3, 4, 5, and up--if you think that the numbers on your screen match what's at the exchanges, think again. It's market order queue data: what does the line look like: who is at the head of the line, who is cutting the line, and who is trading AGAINST the line? It's data access speeds. How can anyone compete with a collocated rig in the same rack as an exchange server, connected via fiber and a high-speed NIC card? Call me a dreamer, but I imagine a level playing field, where everyone can see the DOM, real-time ticks, order queue, and other data. Anyone is free to write algos, and may the best (wo)man win. (Queue John Lennon "Imagine" here...)
kmiklas - data isn't free, since someone has to collect it, distribute it, maintain the infrastructure etc. That is not the problem. Redistribution fees are also logical and fair. But pricing it differently based on the individual's use to which the data is put is utterly disingenuous. It's like selling you a map and pricing it $1 if you want to put it on your wall but $100 if you want to use it to drive around town. I am generally not a fan of government regulation. But this is ridiculous and if the exchanges persist, I hope the authorities somehow step in. I wouldn't object to exchanges throttling orders somehow, or pricing access differently based on the orders-per-second limitation. That seems reasonable.