Non-display fees

Discussion in 'Automated Trading' started by Joan, Oct 6, 2016.

  1. kmiklas

    kmiklas

    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.
     
    Last edited: Oct 7, 2016
    #81     Oct 7, 2016
  2. lspdtrdr

    lspdtrdr

    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.
     
    #82     Oct 7, 2016
    kmiklas likes this.
  3. terr

    terr

    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.
     
    #83     Oct 7, 2016
  4. kmiklas

    kmiklas

    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.
     
    #84     Oct 7, 2016
  5. terr

    terr

    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.
     
    #85     Oct 7, 2016
  6. kmiklas

    kmiklas

    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 :sneaky:
     
    #86     Oct 7, 2016
    IAS_LLC likes this.
  7. terr

    terr

    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.
     
    #87     Oct 7, 2016
  8. terr

    terr

    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.
     
    #88     Oct 7, 2016
  9. kmiklas

    kmiklas

    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.

    Code:
    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.
     
    #89     Oct 7, 2016
  10. lspdtrdr

    lspdtrdr

    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.
     
    #90     Oct 7, 2016
    kmiklas likes this.