Limiting Quant Contractor Access to Trading IP and Data
Summary
The document collects practical ways for a small trading operation to reduce exposure of proprietary data, code, indicators, and strategy parameters when hiring a quant. Suggested controls include limiting access to only the resources needed, separating sensitive components from routine development, and keeping secret parameters outside the code provided to a contractor. A developer can work against synthetic or altered data, with the owner applying the finished code to the original dataset. Sensitive algorithms may also be exposed through a black-box function or service rather than shared directly.
The answers treat technical safeguards and legal agreements as imperfect protections. Non-disclosure agreements can define expectations, but they cannot prevent copying by someone determined to do so; restrictive monitoring or offline systems may also be burdensome. The discussion emphasizes hiring someone trustworthy and matching the contractor's role to whether the need is for financial expertise or software development. These suggestions are anecdotal rather than a tested security framework, and the document does not assess legal enforceability or the cost and effectiveness of each control.
Key ideas
- Give a contractor access only to the data, code, and systems needed for assigned work.
- Keep proprietary strategy parameters separate so development can use test values.
- Synthetic or altered data can support development before the owner runs the result on sensitive data.
- Black-box functions and separated software components can reduce direct exposure of core algorithms.
- Legal agreements and technical controls have limits, making trust and careful hiring important.
Tags
Full text
# When hiring a quant, how can I protect my IP? # When hiring a quant, how can I protect my IP? I am a one-man operation, and would like to hire a quant for around 4 weeks or work. I am worried that the person I hire might copy my data or the indicators that I have him work on. What have others done to protect their assets from re-use by employees and contractors? Additional info: - I work from home, so not able to provide a locked-down PC/environment. - I don't need to give them access to code, but to very particular historical data that can't be acquired anywhere else, in which I've identified opportunities that need further refinement. Maybe my only option is to use the quant to educate me... "if I have X and Y, how would I produce Z?" Painful for both me and the quant. ## Answer by Matt Wolf (score 13, accepted) https://quant.stackexchange.com/a/7017 - Non-disclosure agreements work on the legal side but not in reality, no agreement prevents someone with intent to still steal code or ideas. - Protect core code in obfuscated code bases, through APIs installed on the local machine or have it on a server that others do not have access to to and provide access through function calls. - Make sure the local machine does not have any hardware access to the hard drive, other storage media, and no open USB ports - Install monitoring software to gauge what the user is doing - Install web surfing web site blocking service in order to prevent users from uploading things (though this only works in well capitalized IT and compliance departments where there is staff that constantly updates the filters. Better to just disable internet access. Some are in my opinion radical measures, I recommend you pay more attention to whom you actually hire. And above all, only expose the resources to someone that this person really needs. No access to other drive folders, no access to code bases unless that person really needs it for his/her core work. Edit: What often works for me (for coding projects) is to hire people with zero knowledge of financial markets. This obviously only applies to projects where such domain knowledge is not needed. Someone without knowledge nor motivation to lay praying eyes on your strategy code or ideas has much less incentive to steal than someone who is closely connected to this industry and may know people who could potentially capitalize on your ideas and code. ## Answer by pyCthon (score 5) https://quant.stackexchange.com/a/7016 Non-Disclousre agreement? if your really paranoid you can try - Using a computer with no internet access? - not allowing use of a personal computer? - Using a modified compiler and or proprietary libraries/API? ## Answer by Darren Cook (score 4) https://quant.stackexchange.com/a/7075 For algorithms/strategies/indicators, the way this is normally done is you describe the general algorithm, but leave out the parameters. They are then taken from an settings file. So we do all the testing, including acceptance tests using x=12, y=18. But then you run it yourself using your secret numbers, x=10.56 and y=21.22. That is in the context of coding an existing trading strategy. If you want the person to find the optimal values of x and y, you could give them the algorithm as a pre-compiled black-box function. Your case of historical data is harder; unless there is some way you can sanitize it without making it useless. But if it is hard to obtain, maybe anything they learn will not be useful, going forward, anyway? Above all, you do need to feel trust in the person you work with. The NDAs and other paperwork are just to make it clear to each other what the agreement is; legally enforcing anything there is unlikely to work. It is the person's sense of ethics that enforces it. ## Answer by Autowealth (score 3) https://quant.stackexchange.com/a/7043 - Break the code into parts. (unit tests, error checking, algo) - Decide what code is sensitive and what code can be shared. - Create a "fake" version of the sensitive code for testing. - Have the programmer work on the part that is not sensitive. - Code the sensitive part (the algo) yourself. (Example: There is no reason a programmer cannot work on the part of the code that calculates and tracks slippage. Put that in the part of the code that is 'public'.) Note: The same concept works with data . . . for example: You could loop through the data and have it altered. The altered data can be used for testing purposes. Then, YOU can run the code on the real data once the system works. The key is simply not to expose anything significantly sensitive. ## Answer by ytoledano (score 1) https://quant.stackexchange.com/a/7039 Hire someone you know (family / a close friend). Sounds silly, but what works for the mafia should work for you. If you trust someone you don't need to take many precautions. Sometimes it's even worth compromising on skill. ## Answer by Phil H (score 0) https://quant.stackexchange.com/a/7072 You have a choice of approach, trust or distrust. If you can find someone you can trust, then you can focus on getting the right result. One way to induce such a trustful partnership is to include stock or options as incentive, a la Apple. If you will only distrust your quant, then your best bet is to hire an office space that you can both travel to, and sit together with him/her to work. I think you need to work out whether you need the quant for their financial knowledge or their development ability. A generic developer can do development given the requirements and unit tests. A quant can work with synthetic/fuzzed data as long as it is reasonable, and could spend time explaining things to you rather than necessarily doing it all by themselves. If you are paranoid (as in, overly distrustful), then don't give them access to the data. The cheapest and simplest option is to find someone you can trust. ## Answer by rtybase (score 0) https://quant.stackexchange.com/a/7074 Have you thought about using one of the cloud service providers? For example for data you can setup a free MongoDB instance with https://mongolab.com/products/pricing/. You can also setup a free (or relatively cheap) Linux/Windows virtual machine with Amazon http://aws.amazon.com/ec2/pricing/ Just few options to isolate your home environment (with sensitive information) from the development ...
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.