Non-display fees

[kmiklas]

They're not idiots, it's the task that is impossible. Again, how exactly can they "audit" that only that program can connect to the API? It's your program (or programs). You're in control. Programs don't have fingerprints.

Basically, how do you forensically determine whether the API order was placed manually or automatically?

I was told that there is some kind of entitlement system either in place or being put in place, where only an authorized version of an algorithm is permitted to consume the data. You may have to run their monitoring process on your box... and run as r00t. Full cavity search, my friend.

In some systems an automated order does not go directly to the exchange. Automated orders are sent through your terminal, and appropriately logged as originating from the API:

[YOUR ALGO] -----order----> [YOUR TERMNIAL] -----order----> [EXCHANGE]

It's a fairly simple task. All been done for years.

 

[lspdtrdr]

They're not idiots, it's the task that is impossible. Again, how exactly can they "audit" that only that program can connect to the API? It's your program (or programs). You're in control. Programs don't have fingerprints.

what kmiklas said, and programs DO have fingerprints. they hash the binary of your program and use that during the authentication process. if your binary changes, then you're no longer authenticated.

 

[terr]

what kmiklas said, and programs DO have fingerprints. they hash the binary of your program and use that during the authentication process. if your binary changes, then you're no longer authenticated.

Who are "they" that hash the binary? It is YOUR program. Your code. You write it. You compile it. You run it. You are sending the order. You control what is being sent. Whatever authentication process there is, you're the one controlling it.

 

[kmiklas]

Who are "they" that hash the binary? It is YOUR program. Your code. You write it. You compile it. You run it. You are sending the order. You control what is being sent. Whatever authentication process there is, you're the one controlling it.

I know brother, it's aggravating. Terr and I are saying the same thing in different ways. You have to version your code, and submit this version for approval. The Man approves this version, and only this version one can be run. If you so much as change a letter in a comment, recompile, and run it, a flag will be raised... and you'll get locked.

"They" are the programmers from the exchanges, backed by "They's" lawyers. "They" grab you by the balls, and won't let go.

 

[terr]

I was told that there is some kind of entitlement system either in place or being put in place, where only an authorized version of an algorithm is permitted to consume the data. You may have to run their monitoring process on your box... and run as r00t. Full cavity search, my friend.

Yes, if they can put their monitoring process on your box, running as root, they can check whatever they want. But (and it's a big but) this is so invasive as to be illegal, I would like a cite showing that they can or do do it, and (since the variety of computer systems out there so great and they would have to tailor the process to every OS variation) I think the technical effort on their side would be enormous.

 

[kmiklas]

Yes, if they can put their monitoring process on your box, running as root, they can check whatever they want. But (and it's a big but) this is so invasive as to be illegal, I would like a cite showing that they can or do do it, and (since the variety of computer systems out there so great and they would have to tailor the process to every OS variation) I think the technical effort on their side would be enormous.

My guess is that you'd have to sign off on this before your algo can be run.

I don't think that it would be terribly difficult. Just write it in C++ or some other portable language, and recompile on the major platforms. Yes, some effort, but not "enormous." The task is not really that complex: all you really have to do is check the hash every time the program is launched, and compare it to what's on file.

If you wanted to be slick, write the algo in such a way that parts can be loaded dynamically, so that the hash of the "shell" program doesn't change... but the functionality does

 

[terr]

I know brother, it's aggravating. Terr and I are saying the same thing in different ways. You have to version your code, and submit this version for approval. The Man approves this version, and only this version one can be run. If you so much as change a letter in a comment, recompile, and run it, a flag will be raised... and you'll get locked.

"They" are the programmers from the exchanges, backed by "They's" lawyers. "They" grab you by the balls, and won't let go.

What you describe can only be done if the exchanges write interfaces for every API, and for every environment, then FORCE you to use their interfaces to communicate with the API. And even then there are ways around it. Fairly simple ways.

That is not what exists today, and I don't see that happening in the future. That's an enormous task.

 

[terr]

If you wanted to be slick, write the algo in such a way that parts can be loaded dynamically, so that the hash of the "shell" program doesn't change... but the functionality does

Very easy to do with the modern programming environments. Hell, you could even dynamically compile new code and incorporate it in the program. As I said there are a myriad ways around this stuff. It's all bits and bytes. There is a way around everything. Just like there is no pirate-proof protection scheme, there is no way to do this for them.

And as I said, requiring you to place their (face it, that's what it is) virus on your machine is terribly invasive. I don't think that will fly.

 

[kmiklas]

What you describe can only be done if the exchanges write interfaces for every API, and for every environment, then FORCE you to use their interfaces to communicate with the API. And even then there are ways around it. Fairly simple ways

That is not what exists today, and I don't see that happening in the future. That's an enormous task.

I still don't see the task as enormous. They'll probably push it to the broker-dealers and their terminals. If they don't want to play ball, they might fall onto the "unapproved." list.

It's really just the following bit of (pseudo)code, right? On program launch, send the program's hash value back to the broker/dealer, pull it from a database, and compare with what's on file. Hash matches? Good to go. Hash mismatch? Either flag and log, or actually prevent it from running.

hash = getHash();
response = sendHashToServer(userId, hash);
if (response == false) { exit(1), call in the auditors!}
else (no problemo)

I think that it can be done in three months; definitely less than a year. Maybe that's why it's taken them this long to start enforcing. The laws were passed a while ago, maybe now they've got the enforcement code finished.

 

[lspdtrdr]

Very easy to do with the modern programming environments. Hell, you could even dynamically compile new code and incorporate it in the program. As I said there are a myriad ways around this stuff. It's all bits and bytes. There is a way around everything. Just like there is no pirate-proof protection scheme, there is no way to do this for them.

And as I said, requiring you to place their (face it, that's what it is) virus on your machine is terribly invasive. I don't think that will fly.

of course you can hack anything... but do you actually want to go through all the trouble?

it wouldn't be a 'virus', it would just be part of the authentication process of the API provided by the vendor. it's actually not that uncommon.