Hi, Anyone out there running a fund use auto-trading? Do you add a special risk disclosure in your docs discussing auto-trading? Or, has anyone seen such disclosures in any other context? I'm working on docs for a commodity pool, which uses auto-trading. I'm much more concerned about auto-trading risks than some of the other risks I'm disclosing. There are always potential bugs, race conditions latent in the code... I always have the (irrational?) fear I'll log in and find the code stuck in a "buy 1 at market" infinite loop. I try to manage this risk, but I do want to disclose it. Just wondering what others have done in this regard.
Technically you an not disclose them short to say "you are an idiot ignoring standard IT operation procedures". Those, established for more than 20 years, call for critical operations being monitored by humans. Which basically means: Unless you have customers sign you off the liability UNDER FULL DISCLOSURE THAT YOU ARE BEHAVING UNPROFESSIONAL, you will always be liable for program errors of that kind because a customer may sue you for "gross neglect" by willfuly ignoring normal operating procedures for critical IT systems Sucks. Seriously. THis is one thing that I Think API providers should help out with - establish maximum losses through the API (that can be configured OUTSIDE of the main API connection) so tha t they basically take over the monitoring for "stupid programming bugs". Short to that, you ahve to keep someone looking at accounts and positions while trading - much like all critical operations are being monitored. As I said: standard operating procedure.
I'm not convinced there isn't hope. For example, maybe I'll establish a separate LLC structure which owns/develops/manages/maintains the software. The general partner could license the software for use in the context of a specific fund, with limited abilities. That way, my automation code is no more liable than Windows, QuickFix, or any other platform component would be. Does that make sense?
No, does not work. You will find that "limitations in liability" generally do not protect you from: * Willfull harm you cause (i.e. betraying customers). * Gross neglect. And that term has a nice legal definition, too. You will probably find out very fast that... while the owner of the LLC is protected.... the CEO can then be hold liable. Sometimes even the owners. Last good case of that - Madoff. Yeah, his company was a LLC. Did not protect him. The issue here is "gross neglect" this is not "hm, i overlooked something", it is a GROSS ignorance of normal procedures, willfull acceptance of harm where everyone professional knows the risk. Gross neglect normally can not be limited. Your only real limit is to tell customers about the real risks, and not having automated trading watched IS significant risk and IS unprofessional and ignoring standard operating procedures. Better be specific and inform them also that you ignore normal operating procedures. You are a lot better off hiring - even possibly relatively cheap outsourced - some administrative stuff that looks over your software while it runs. OR, at least, to use multiple software instances and an automatic alarm system. If you have a trading system in data in one data center, and three control systems in other data centers that can phsyically deactivate the trading system and close the positions (for exampl eby shutting down the virtual machine it runs on), and those run three different versions of software (yes, costs money), one can mke a case that the risk is controlled from all kinds of issues and the waiver can then explicitely make customers accept only the rest risk. Note through that this is still substantial: * Failure of infrasstructure - for example when you use zen-fire for orer routing and they fail for watever reason, you may have unprotected market positions. * Failure of whatever exchange you have. It is not like CME etc. did not go down occasionally, sometimes even for days. A trader watching the system may shut it down and manually try to hedge exposed positions through other means (especially if he has explicit prepared instructions for that - like heding currency on forex, stock indices on other markets.... normally they move somehow in concert). MOST important, a trader can pick up the phone, call the broker and work with him on a hedge while software can not do that. If anything, setting up a LLC to protect specifically from a cas of gross neglect that you plan can be seen as comitting fraud.
Hmm, I'd be interested what background you have in these issues. You make pretty strong statements. I do have my fund attorney looking over these issues as well. Some of what you state is clearly overstated, however. Electronic trading risk (specifically mentioning things like orders being lost/not placed) is one of the most common risk disclosures you'll see in a fund prospectus. Unless CME Globex + ZenFire/Rithmic has 24/7 administration monitoring their (automated) backend systems taking my order, it seems like you're saying I can sue them for gross neglect as well. I do have various alerts built-in, and multiple instances might be a good idea. These are all engineering solutions, and no engineering solution is ever truly fail-proof. I'm looking for the legalese that lets CQG sell an auto-spreader, for example.
Well, CQG pretty surely tells you in clear terms their system may not be available all the time AND they have / may have an operations team available 24/7. Plus they are probably a LOT more redundant than you are - how many computers do you plan to run your trading system on? How good is your data center connected? What do you do if your precious computer running the trading system fails... not that power supplies never blows. I had exactly one incident like that some weeks ago where a power flucturation that should never have happened crashed half the servers in my cluster. But this is not exactly important because... ...they only do order handling, no trading decisions. First thing when I open accounts for electronic trading is to make sure I know how to handle my orders WITHOUT electronic trading: * Get the phone number of the emergency order desk and operations team so that they can shut down my account access and close all positions on demand. * Make a test to make sure they know about me, how to identify, numbers work etc. * Do not run without external monitoring. This is either me or someone from my company sitting at the desk making sure everything is fine, or a number of external systems (running on at least 2 different locations) checking things. Note that "computer reachable" MAY not be good enough, but it is a minimum baseline. Internet connections and computers fail. You on your side are different. You make the trading decisions. CQG etc. can easily say "hey, this is JUST a cheap way for you to route orders, but we have other avenues and at the end your trading decisions are your responsibility, prepare". You can also be pretty sure that they will hav SOP in place and their systems are monitored properly. You can not say that to investors into your automated trading. Because you are where the decisions are made and the backup mechanisms should be in place. And unless you tell me upfront sincerely about the risks.... i WILL take you out for gross neglect. Simple like that. Or at least try, and believe me, you do NOT want to have to defend against that. Btw., do not run Linux or Windows unattended Both systems are not suitable for such use per definition (Linux: not certified at all, Windows: MS says so in the EULA), without being monitored Btw., make sure your attornes knows about IT issue. Because the definition of standard operating procedures is not exactly something most attorneys will know (they know the LEGAL definition, but they won't know how the standard is because they are not in the IT area). But a skillfull lawyer will show hundreds of examples of other companies where critical IT system operations are always monitored by humans permanently to establish standard operating procedure. Including your data center which will have engineers at hand... 24/7 in case something happens to their infrastructure. * I am sure CME Globex has people on site whenever they run (not necessarily 24/7 - they are not available 24/7, and even if you take in the sunday "cleaning" they do, that leaves saturday without operations). Remember that a lot of things go in in Globex systems likely during off-time anyway (cleanup, maintenance, database loads, analysis etc.) - simply because the systems are less stressed then. You dont do things like that without overlooking. Gven the tremendous amount of people and income Globex has running around, I would be tremendously surprised if their admin staff would not be a on 24/7 schedule. They DEFINITELY would be suable for gross neglect for not having this as standard operating procedure. Including having backup data centers etc. * I am pretty sure Zen-Fire has no people on site. This is like 90% sure.... because to my knowledge... * Zen-Fire operations is managed by Rithmic. That said, I am pretty sure Rithmic has people on operations whenever they need to be there. That being said, though, you should read the Zen-Fire / RIthmic risk disclosure carefully. They pretty much WILL state the system may fail and you have to prepare for that case. Easy for them to say so - they just route orders. Different for you, where trading decisions originate. Basically they can tell you sincerely that you should have an alternative. What is your alternative to your automated trading system failing? Telling customers you were sleeping and they lost money because you were unprepared? Would be nice if Rithmic would have some additional functionality, and one of them would be a position dead man switch. Ordes / their positions tradked with a "trade ID" and if a trade expires all roders and the position is auto closed. The idea is that a separate API call (like once per minute or once per 5 minutes) sends them the trade ID's that my trading system considers active. Typical dead man switch (my system goes down, they close out things I may have forgotten).
You can implement your "position dead man switch" via the Rithmic API with your own application running independently. I don't know that they need to get involved. That specific error scenario isn't a concern at all for me. I'm more interested in more refined risk control, preferably at the gateway level instead of only at my application level. I'm pretty confident at my engineering solutions. I do have geographically distributed servers running multiple instances, all of which communicate and track current application status. I haven't decided on my preferred recovery mode, yet... simply shutting everything down, or attempting to have a second instance pick up trading. I'm tempted to just shut everything down. Your discussion about the engineering aspect of this isn't the kind of help I was looking for. I can handle that part. What I want is succint legal disclosure. The standard legal disclosure for electronic trading risks, for example, reads like this: The General Partner intends to trade on electronic trading and order routing systems, which differ from traditional open outcry pit trading and manual order routing methods. Transactions using an electronic system are subject to the rules and regulations of the exchanges offering the system or listing the contract. Characteristics of electronic trading and order routing systems vary widely among the different electronic systems with respect to order matching procedures, opening and closing procedures and prices, error trade policies and trading limitations or requirements. There are also differences regarding qualifications for access and grounds for termination and limitations on the types of orders that may be entered into the system. Each of these matters may present different risk factors with respect to trading on or using a particular system. Each system may also present risks related to system access, varying response times and security. In the case of internet-based systems, there may be additional risks related to service providers and the receipt and monitoring of electronic mail. Trading through an electronic trading or order routing system is also subject to risks associated with system or component disruption or failure. In the event of system or component disruption or failure, it is possible that for a certain time period, it might not be possible to enter new orders, execute existing orders or modify or cancel orders that were previously entered. System or component disruption or failure may also result in loss of orders or order priority. Some contracts offered on an electronic trading system may be traded electronically and through an open outcry pit during the same trading hours. Exchanges offering an electronic trading or order routing system and listing the contract may have adopted rules to limit their liability, the liability of futures brokers and software and communication system vendors and the amount that may be collected as a result of system failures and delays. These limitations of liability provisions vary among the exchanges. The General Partner plans to use such electronic trading systems and thus the Limited Partners will be exposed to risks associated with these systems disruption or failure as noted above. That covers a HUGE body of potential risks in two paragraphs. After looking the last few hours at disclosures for various platform providers, brokers, and funds that engage in varying auto-trading, high-frequency trading, etc... I'm coming to the conclusion the above disclosure is enough.