Trading System I C #

Handelssystemer Hva er et handelssystem. Et handelssystem er ganske enkelt en gruppe av spesifikke regler eller parametere som bestemmer inn - og utgangspunkter for en gitt egenkapital. Disse punktene, kjent som signaler, blir ofte markert på et diagram i sanntid og ledetekst Den umiddelbare gjennomføringen av en handel. Her er noen av de vanligste tekniske analysverktøyene som brukes til å konstruere parametrene for handelssystemer. Gjennomsnittlig MA. Relativ styrke. Bollinger Bands. Often, to eller flere av disse indikatorene vil bli kombinert i Opprettelsen av en regel For eksempel bruker MA crossover systemet to bevegelige gjennomsnittlige parametere, langsiktige og kortsiktige, for å opprette en regelkjøp når kortsiktige kryss over lang sikt, og selger når motsatt er sant I andre tilfeller bruker en regel bare en indikator. For eksempel kan et system ha en regel som forbyr noe å kjøpe, med mindre den relative styrken er over et visst nivå. Men det er en kombinasjon av alle disse reglene som gjør et handelssystem. MSFT Moving Average Crossover System ved hjelp av 5 og 20 Moving Gjennomsnitt. Fordi suksessen til det totale systemet avhenger av hvor godt reglene utfører, bruker systemhandlere tid optimalisering for å håndtere risikoen, øke beløpet som oppnås per handel og oppnå langsiktig stabilitet Dette gjøres ved å endre forskjellige parametere innenfor hver regel. For eksempel for å optimalisere MA crossover-systemet, ville en forhandler teste for å se hvilke bevegelige gjennomsnitt 10-dagers, 30-dagers, osv. Fungerer best, og deretter implementere dem. Men optimalisering kan forbedre resultater med bare en liten margin - det er kombinasjonen av parametere som i det siste vil bestemme suksess for et system. Advantages Så hvorfor kan du ønsker å vedta et handelssystem. Det tar alle følelser ut av handel - Emotion blir ofte sitert som en av de største feilene til individuelle investorer Investorer som ikke klarer å takle tap andre gjette sine beslutninger og ende opp med å tape penger Ved å følge et forhåndsutviklet system, kan systemhandlere avstå fra behovet å ta noen avgjørelser når systemet er utviklet og etablert, er handel ikke empirisk fordi den er automatisert. Ved å kutte ned på menneskelige ineffektiviteter, kan systemhandlere øke fortjenesten. Det kan spare mye tid - Når et effektivt system er utviklet og optimalisert lite Det er ikke nødvendig med noe arbeid fra handelsmannen. Datamaskiner brukes ofte til å automatisere ikke bare signalgenerering, men også den faktiske handelen, slik at næringsdrivende befri seg fra å bruke tid på analyse og handel. Det er enkelt hvis du lar andre gjøre det for du - Trenger alt arbeidet som er gjort for deg Noen selskaper selger handelssystemer som de har utviklet Andre selskaper vil gi deg signaler generert av deres interne handelssystemer for en månedlig avgift Vær forsiktig, skjønt - mange av disse selskapene er falske Ta en lukk se på når resultatene de skryter om, ble tatt. Tross alt er det lett å vinne i det siste. Se etter selskaper som tilbyr en prøveversjon, som lar deg teste systemet i sanntid. Ulemper Vi har sett på de viktigste fordelene ved å jobbe med et handelssystem, men tilnærmingen har også sine ulemper. Tradersystemene er komplekse - Dette er deres største ulempe I utviklingsstadiene krever handelssystemer en solid forståelse av teknisk analyse, evnen til å lage empiriske beslutninger og grundig kjennskap til hvordan parametere fungerer. Selv om du ikke utvikler ditt eget handelssystem, er det viktig å være kjent med parametrene som utgjør den du bruker. Å skaffe alle disse ferdighetene kan være en utfordring. Du må kunne realistiske antagelser og bruke systemet effektivt. Systemhandlere må gjøre realistiske antagelser om transaksjonskostnader. Disse vil bestå av mer enn provisjonskostnader. Forskjellen mellom eksekveringspris og påfyllingspris er en del av transaksjonskostnadene. Bear in tankene er det ofte umulig å teste systemene nøyaktig, noe som forårsaker en viss usikkerhet når systemet blir levende. Problemer som oppstår når simulerte resultater avviger sterkt fra faktiske resultater kalles slippe. Effektivt å håndtere slippe kan være en viktig veiblokke for å utnytte et vellykket system. Utviklingen kan være en tidkrevende oppgave - Mye tid kan gå inn i å utvikle et handelssystem for å få det til å løpe og fungerer på riktig måte Å skille ut et systemkonsept og sette det i praksis innebærer mye testing, noe som tar en stund. Historisk backtesting tar noen minutter, men tilbakestesting alene er ikke tilstrekkelig. Systemene må også handles i sanntid for å sikre pålitelighet. , kan slippe få handelsmenn til å gjøre flere revisjoner av systemene deres selv etter distribusjon. De jobber Det finnes en rekke internett-svindel knyttet til systemhandel, men det er også mange legitime, vellykkede systemer. Kanskje det mest kjente eksemplet er det som er utviklet og implementert av Richard Dennis og Bill Eckhardt, som er originale skilpaddehandlere i 1983, hadde disse to tvil om hvorvidt en god t rader er født eller laget Så tok de noen mennesker bort fra gaten og trente dem basert på deres nåkjente Turtle Trading System. De samle 13 handelsmenn og endte opp med å lage 80 årlig i løpet av de neste fire årene, Bill Eckhardt sa en gang, alle med gjennomsnittlig intelligens kan lære å handle Dette er ikke rakettvitenskap Det er imidlertid mye lettere å lære hva du bør gjøre i handel enn å gjøre det. Handelssystemer blir stadig mer populære blant profesjonelle handelsmenn, fondschefer og individuelle investorer alike - kanskje dette er en testamente for hvor godt de jobber. Beslutning med svindel Når man ser etter å kjøpe et handelssystem, kan det være vanskelig å finne en troverdig bedrift. Men de fleste svindel kan bli oppdaget av sunn fornuft. For eksempel er en garanti på 2500 årlig klart opprørende som det lover at med bare 5000 du kunne lage 125.000 på ett år og deretter gjennom sammensetning i fem år, 48.828.15.000 Hvis dette var sant, ville ikke skaperen handle hans eller hennes måte å bli bi lionaire. Andre tilbud er imidlertid vanskeligere å dekode, men en vanlig måte å unngå svindel på er å søke etter systemer som tilbyr en gratis prøveversjon. På den måten kan du teste systemet selv. Ikke blindt stol på virksomheten skryter om. Det er også en god ide å kontakte andre som har brukt systemet, for å se om de kan bekrefte sin pålitelighet og lønnsomhet. Konklusjon Å utvikle et effektivt handelssystem er på ingen måte en enkel oppgave. Det krever en solid forståelse av de mange tilgjengelige parametrene, evnen til å lage realistiske antagelser og tid og dedikasjon til å utvikle systemet. Men hvis det utvikles og distribueres på riktig måte, kan et handelssystem gi mange fordeler. Det kan øke effektiviteten, frigjøre tiden og, viktigst, øke fortjenesten. Opprettingssystemer Design ditt system - Del 1.Den foregående delen av denne opplæringen så på elementene som utgjør et handelssystem og diskuterte fordelene og ulempene med å bruke et slikt system i en live tr adingmiljø I denne delen bygger vi videre på den kunnskapen ved å undersøke hvilke markeder som er spesielt velegnet til systemhandel. Vi vil da ta en mer grundig titt på de ulike sjangrene av handelssystemer. Rangering i ulike markeder. Egenkapitalmarkeder Egenkapitalen markedet er trolig det vanligste markedet for handel, særlig blant nybegynnere. I denne arena dominerer store spillere som Warren Buffett og Merrill Lynch, og tradisjonelle verdier og vekstinvesteringsstrategier er langt de vanligste. Mange institusjoner har imidlertid investert betydelig i design, utvikling og implementering av handelssystemer Individuelle investorer er med i denne trenden, men sakte. Her er noen viktige faktorer å huske på når du bruker handelssystemer i aksjemarkedene. Det store antallet aksjer som er tilgjengelig, tillater handelsmenn å teste systemer på mange forskjellige typer aksjer - alt fra ekstremt volatile over-the-counter OTC-aksjer til ikke-flyktige blå sjetonger. Effektiviteten av handelssystemer kan begrenses av den lave likviditeten til enkelte aksjer, spesielt OTC og rosa arks utstedelser kan øke til fortjeneste generert av vellykkede bransjer, og kan øke tapene OTC og rosa ark aksjer ofte pådrar ytterligere provisjonsavgifter. De viktigste handelssystemene som brukes er de som ser etter verdi - det vil si systemer som bruker forskjellige parametere for å avgjøre om en sikkerhet er undervurdert i forhold til tidligere prestasjoner, sine jevnaldrende eller markedet generelt. Forex Exchange Markets Valutamarkedet eller forex er det største og mest flytende marked i verden Verdens regjeringer, banker og andre store institusjoner handler trillioner dollar på valutamarkedet hver dag De fleste institusjonelle handelsmenn på forexen stole på handelssystemer Det samme gjelder for enkeltpersoner på forexen, men noen handelsbaserte på økonomiske rapporter eller rentebetalinger. Her er noen viktige faktorer å huske på når du bruker handelssystemer i forexmarkedet. Likviditeten i På grunn av det store volumet gjør handelssystemene mer nøyaktige og effektive. Det er ingen provisjoner i dette markedet, bare sprer seg. Det er derfor mye lettere å foreta mange transaksjoner uten å øke kostnadsbesparende til mengden aksjer eller råvarer tilgjengelig, Antallet valutaer til handel er begrenset Men på grunn av tilgjengeligheten av eksotiske valutapar - det vil si valutaer fra mindre land - er volatilitetsintervallet ikke nødvendigvis begrenset. De viktigste handelssystemene som brukes i forex er de som følger trender en populært å si i markedet er trenden din venn eller systemer som kjøper eller selger på breakouts Dette skyldes at økonomiske indikatorer ofte forårsaker store prisbevegelser på en gang. Futures Equity, forex og råvaremarkeder tilbyr alle futures trading Dette er en populær kjøretøy for systemhandel på grunn av økt utnyttbar utnyttelse og økt likviditet og volatilitet. Disse faktorene kan imidlertid kutte begge veier de ca n enten forsterker gevinstene dine eller forsterk ditt tap Av denne grunn er bruken av futures vanligvis reservert for avanserte individuelle og institusjonelle systemhandlere. Dette skyldes at handelssystemer som er i stand til å kapitalisere på futures markedet krever mye større tilpasning, bruk mer avanserte indikatorer og ta mye lenger å utvikle Så det er best Det er opp til den enkelte investor å bestemme hvilket marked som passer best for systemhandel - hver har sine egne fordeler og ulemper. De fleste er mer kjent med aksjemarkedene, og denne kjennskapen gjør utviklingen av en handelssystem enklere Men forex er vanligvis ansett å være den overlegne plattformen for å drive handelssystemer - spesielt blant mer erfarne handelsfolk. Hvis en handelsmann bestemmer seg for å kapitalisere på økt løftestang og volatilitet, er futuresalternativet alltid åpent. Endelig ligger valget i hendene til systemutvikleren. Typer av Trading Systems. Trend-Following Systems Den vanligste metoden av systemhandel er trend-følgende system I sin mest grunnleggende form venter dette systemet bare en vesentlig prisbevegelse, kjøper eller selger i den retningen. Denne typen system banker på håp om at disse prisbevegelsene vil opprettholde trenden. Gjennomsnittlig Systemer Vanligvis brukt i teknisk analyse er et glidende gjennomsnitt en indikator som bare viser gjennomsnittsprisen på en aksje over en tidsperiode. Essensen av trender er avledet fra denne måling. Den vanligste måten å bestemme inngang og utgang er en crossover. Den logiske bak det er enkelt En ny trend er etablert når prisen faller over eller under sin historiske prisgods trend. Her er et diagram som viser både prisblå linjen og den 20-dagers MA-røde linjen i IBM. Breakout Systems. Det grunnleggende konseptet bak denne typen av systemet ligner på et flytende gjennomsnittssystem Ideen er at når en ny høy eller lav er etablert, er prisbevegelsen mest sannsynlig å fortsette i retning av brannen eakout En indikator som kan brukes til å bestemme breakouts er et enkelt Bollinger Band overlegg Bollinger Bands viser gjennomsnitt av høye og lave priser og breakouts oppstår når prisen møter kantene på bandene. Her er et diagram som plots pris blå linje og Bollinger Bands grå linjer av Microsoft. Ulemper med Trend-Følgende systemer. Ved å bestemme trender, er det alltid et empirisk element for å vurdere varigheten av den historiske trenden. For eksempel kan det bevegelige gjennomsnittet være de siste 20 dagene eller for de siste fem årene, så utvikleren må avgjøre hvilken som er best for systemet. Andre faktorer som skal fastslås er de gjennomsnittlige høyder og nedturer i breakout-systemer. Lagring av natur - Flytte gjennomsnitt og breakout-systemer vil alltid ligge. Med andre ord kan de aldri treffer eksakt toppen eller bunnen av en trend Dette resulterer uunngåelig i en fortabelse av potensiell fortjeneste, noe som noen ganger kan være signifikant. Alternativ effekt - Blant markedet krefter som er skadelige for suksess av trend-følgende systemer, er dette en av de vanligste. Whipsaw-effekten oppstår når det bevegelige gjennomsnittet genererer et falsk signal - det vil si når gjennomsnittet faller like i rekkevidde, så reverserer det plutselig retning. Dette kan føre til store tap, med mindre effektive stoppstopp og risikostyringsteknikker er ansatt. Slike markeder - Trend-etter-systemer er i sin natur i stand til kun å tjene penger på markeder som faktisk trender. Men markeder flytter også sidelengs innenfor et visst område i lengre tid. Ekstrem volatilitet kan forekomme - Noen ganger kan trend-følgende systemer oppleve ekstrem volatilitet, men næringsdrivende må holde seg til sitt system. Manglende evne til å gjøre det vil resultere i sikret feil. Countertrend Systems I utgangspunktet Målet med motgangssystemet er å kjøpe på lavest lavt og selge på høyeste høyde. Hovedforskjellen mellom dette og trend-etter-systemet er at co untertrend-systemet er ikke selvkorrigerende Med andre ord er det ikke satt tid for å gå ut av posisjoner, og dette resulterer i et ubegrenset ulemper potensielle Typer av motstrømsystemer Mange forskjellige typer systemer betraktes som motstrømsystemer Ideen her er å kjøpe når momentum i en retning begynner å falme Dette beregnes hyppigst ved hjelp av oscillatorer. For eksempel kan et signal genereres når stokastikk eller andre relative styrkeindikatorer faller under bestemte punkter. Det finnes andre typer motstridshandelssystemer, men alle deler det samme grunnleggende målet - til kjøpe lavt og selge høyt. Ulemper ved å motvirke følgende systemer. Ønsket beslutningsprosess er nødvendig. For eksempel er en av faktorene som systemutvikleren må bestemme seg for, hvilke punkter relativstyrkeindikatorene fades. Ekstremvolatilitet kan forekomme - Disse systemene kan også oppleve ekstrem volatilitet, og en manglende evne til å holde fast i systemet til tross for at volatiliteten vil resultere i sikret feil. Ubegrenset ulemper - Som tidligere nevnt er det ubegrenset ulemper, fordi systemet ikke er selvkorrigerende. Det er ikke satt tid til å gå ut av posisjoner. Konklusjon De viktigste markedene som handelssystemer egner seg for, er aksje-, valuta - og futuresmarkeder Hvert av disse markedene har sine fordeler og ulemper De to viktigste sjangrene av handelssystemer er trend-følgende og motvirkningssystemene Til tross for forskjellene, krever begge typer systemer i utviklingsstadier deres empiriske beslutningsprosesser fra utviklerens side også , disse systemene er utsatt for ekstreme volatilitet, og dette kan kreve noe utholdenhet - det er viktig at systemhandleren holder fast med systemet hans i disse tider. I følgende avtale vil vi se nærmere på hvordan man skal utforme et handelssystem og diskutere noe av programvaren som systemhandlere bruker for å gjøre livet enklere. Det beste programmeringsspråket for algoritmiske handelssystemer. En av t de hyppigste spørsmålene jeg mottar i QS-postbag er Hva er det beste programmeringsspråket for algoritmisk handel Det korte svaret er at det ikke er noe best språk Strategi parametere, ytelse, modularitet, utvikling, fleksibilitet og kostnad må alle vurderes. Denne artikkelen vil skissere de nødvendige komponentene i en algoritmisk handelssystemarkitektur og hvordan beslutninger om implementering påvirker valg av språk. Først vil hovedkomponentene i et algoritmisk handelssystem bli vurdert, for eksempel forskningsverktøy, porteføljeoptimerer, risikostyring og utførelsesmotor. Deretter, ulike handelsstrategier vil bli undersøkt og hvordan de påvirker systemets utforming. Spesielt vil frekvensen av handel og det sannsynlige handelsvolumet bli diskutert. Når handelsstrategien er valgt, er det nødvendig å arkitisere hele systemet. Dette inkluderer valg av maskinvare, operativsystemet s og systemets fleksibilitet mot sjeldne, potensielle ly katastrofale hendelser Mens arkitekturen vurderes, må det tas hensyn til ytelse - både til forskningsverktøyene og i live-utførelsesmiljøet. Hva er handelssystemet som prøver å gjøre. Før du bestemmer deg for det beste språket du skal skrive med et automatisert handelssystem er det nødvendig å definere kravene Er systemet skal være rent utførelsesbasert Vil systemet kreve en risikostyring eller porteføljekonstruksjonsmodul Vil systemet kreve en høy ytelse backtester For de fleste strategier kan handelssystemet deles inn i to kategorier Forskning og signalgenerering. Forskning er opptatt av evaluering av en strategisk ytelse over historiske data Prosessen med å evaluere en handelsstrategi over tidligere markedsdata kalles backtesting. Datastørrelsen og algoritmisk kompleksitet vil ha stor innvirkning på beregningsintensiteten til Backtester CPU-hastighet og samtidighet er ofte begrensende faktorer for optimalisering av researc h utførelse speed. Signal generasjon er opptatt av å generere et sett av handelssignaler fra en algoritme og sende slike bestillinger til markedet, vanligvis via en megling For visse strategier er et høyt ytelsesnivå nødvendig. IO-problemer som nettverksbåndbredde og latens er ofte begrensningsfaktoren i optimalisering av kjøringssystemer. Valg av språk for hver komponent i hele systemet kan derfor være ganske forskjellig. Type, frekvens og volum av strategi. Type algoritmisk strategi som brukes vil ha en betydelig innvirkning på systemets utforming. vil være nødvendig for å vurdere markedene som handles, tilkoblingen til eksterne dataleverandører, frekvensen og volumet av strategien, avstanden mellom enkel utvikling og ytelsesoptimalisering, samt enhver tilpasset maskinvare, inkludert samlokaliserte tilpassede servere , GPUer eller FPGAer som kan være nødvendige. Teknologifallene for en lavfrekvens amerikansk aksjestrategi vil være vesentlig forskjellig fra de av en høyfrekvent statistisk arbitrage-strategi handel på futures markedet Før språkvalg, må mange dataleverandører evalueres som angår en strategi for hånden. Det vil være nødvendig å vurdere tilkobling til leverandøren, strukturen til noen APIer, aktualitet av dataene, lagringskrav og fleksibilitet i motsetning til en leverandør som går frakoblet. Det er også lurt å ha rask tilgang til flere leverandører. Ulike instrumenter har alle sine egne lagerkvaliteter, eksempler på hvilke inkluderer flere tickersymboler for aksjer og utløpsdatoer for futures for ikke å nevne noen spesifikke OTC-data. Dette må innarbeides i plattformen. Frekvensen av strategien er sannsynligvis en av de største driverne for hvordan teknologibakken vil bli definert. Strategier som bruker data hyppigere enn små eller andre linjer krever betydelig vurdering med hensyn til ytelse. En strategi som overstiger andre lag, dvs. tick-data fører til en ytelsesdrevet design Som hovedkrav For høyfrekvente strategier må en betydelig mengde markedsdata lagres og evalueres. Programmer som HDF5 eller kdb brukes ofte for disse rollene. For å behandle de omfattende datamengder som trengs for HFT-applikasjoner, er det omfattende optimalisert backtester og kjøringssystem må brukes CC muligens med noen assembler er sannsynligvis den sterkeste språkkandidaten Ultrahøyfrekvensstrategier vil nesten absolutt kreve tilpasset maskinvare som FPGAer, bytte samlokalisering og kjerne nettverk grensesnitt tuning. Research Systems. Research Systems vanligvis involverer en blanding av interaktiv utvikling og automatisert skripting. Den tidligere finner ofte sted innenfor en IDE som Visual Studio, MatLab eller R Studio. Den sistnevnte innebærer omfattende numeriske beregninger over mange parametere og datapunkter. Dette fører til et språkvalg som gir et rettferdig miljø til testkode, men gir også tilstrekkelig ytelse til å evaluere te strategier over flere parameter dimensjoner. Typiske IDEer i dette rommet inkluderer Microsoft Visual CC, som inneholder omfattende feilsøkingsverktøy, kode ferdigstillingsfunksjoner via Intellisense og enkle oversikter over hele prosjektet stabelen via databasen ORM, LINQ MatLab som er designet for omfattende numerisk lineær algebra og vektoriserte operasjoner, men på en interaktiv konsoll måte R Studio som bryter R statistisk språkkonsoll i en fullverdig IDE Eclipse IDE for Linux Java og C og semi-proprietære IDEer som Enthought Canopy for Python, som inkluderer databehandlingsbiblioteker for eksempel NumPy SciPy scikit-lær og pandas i et enkelt interaktivt konsollmiljø. For numerisk backtesting er alle ovennevnte språk egnet, selv om det ikke er nødvendig å bruke en GUI IDE som koden vil bli utført i bakgrunnen. På dette stadiet er det av eksekveringshastighet Et kompilert språk som C er ofte nyttig hvis ba cktesting parameter dimensjoner er store Husk at det er nødvendig å være forsiktig med slike systemer hvis det er tilfelle. Interpreterte språk som Python bruker ofte høypresterende biblioteker som NumPy pandas for backtesting-trinnet for å opprettholde en rimelig grad av konkurranseevne med kompilerte ekvivalenter Til slutt vil språket som er valgt for backtesting, bestemmes av spesifikke algoritmiske behov så vel som omfanget av biblioteker tilgjengelig på språket mer på det under. Språket som brukes til backtester og forskningsmiljøer kan imidlertid være helt uavhengig av de som benyttes i porteføljekonstruksjonen, risikostyring og utførelseskomponenter, som det vil bli sett. Porteføljebygging og risikostyring. Porteføljebygging og risikostyringskomponenter blir ofte oversett av detaljhandelsalgoritmiske forhandlere. Dette er nesten alltid en feil. Disse verktøyene gir mekanismen ved hvilken kapital vil bli bevart De forsøker ikke bare å avlevere iate antall risikable spill, men også minimere churn av handelen selv, redusere transaksjonskostnader. Avanserte versjoner av disse komponentene kan ha en betydelig effekt på lønnsomhet og konsistens. Det er greit å skape en stabil strategi som porteføljebygging mekanisme og risikostyring kan enkelt tilpasses for å håndtere flere systemer. Derfor bør de betraktes som viktige komponenter ved inngangen til utformingen av et algoritmisk handelssystem. Arbeidet med porteføljes konstruksjonssystemet er å ta et sett av ønskede bransjer og produsere settet av faktiske handler som minimerer kvelning, opprettholder eksponeringer mot ulike faktorer som sektorer, aktivaklasser, volatilitet etc. og optimaliserer kapitalallokering til ulike strategier i en portefølje. Porteføljekonstruksjon reduserer ofte til et lineært algebraproblem som en matrisefaktorisering og dermed ytelsen er høyt avhengig av effektiviteten av den numeriske lineære algebraimp lementering tilgjengelig Felles biblioteker inkluderer uBLAS LAPACK og NAG for C MatLab har også omfattende optimaliserte matriseprosesser Python benytter NumPy SciPy for slike beregninger En ofte gjenbalansert portefølje vil kreve et kompilert og godt optimalisert matrisebibliotek for å bære dette trinnet, for ikke å flaskehalser handelssystem. Risikostyring er en annen ekstremt viktig del av et algoritmisk handelssystem Risiko kan komme i mange former Økt volatilitet, selv om dette kan ses som ønskelig for visse strategier, økte korrelasjoner mellom aktivaklasser, motpartsstandard, serveravbrudd, svarte svan hendelser og uoppdagede feil i handelskoden for å nevne noen. Risikostyringskomponenter forsøker og forutsier effektene av overdreven volatilitet og korrelasjon mellom aktivaklasser og deres påfølgende effekt på handelskapital Ofte reduseres dette til et sett med statistiske beregninger som Monte Carlo stresstester Dette er veldig lik den beregningsmessige behov for en derivatprisemotor og som sådan vil være CPU-bundet Disse simulasjonene er svært parallelliserbare se nedenfor, og i en viss grad er det mulig å kaste maskinvare på problemet. Eksekveringssystemer. Jobben til kjøringssystemet er å motta filtrerte handelssignaler fra porteføljekonstruksjon og risikostyringskomponenter og sende dem videre til megling eller annen tilgang til markedsadgang. For de fleste detaljhandelsalgoritmiske handelsstrategier innebærer dette en API eller FIX-tilkobling til en megling som Interactive Brokers. De primære hensyn når å bestemme seg for et språk inkluderer kvalitet på API, språkpakker tilgjengelighet for en API, eksekveringsfrekvens og forventet sliping. Kvaliteten på API-en refererer til hvor godt dokumentert det er, hvilken type ytelse det gir, om det trenger frittstående programvare å få tilgang til eller om en gateway kan etableres på en hodeløs måte, dvs. ingen GUI. I tilfelle av interaktive meglere, er Trader W orkStation-verktøyet må kjøre i et GUI-miljø for å få tilgang til API-en. Jeg måtte en gang installere en Desktop Ubuntu-utgave på en Amazon Cloud-server for å få tilgang til Interactive Brokers eksternt, bare av denne grunn. De fleste APIer vil gi en C og eller Java grensesnitt Det er vanligvis opp til lokalsamfunnet å utvikle språkspesifikke wrappers for C, Python, R, Excel og MatLab. Merk at med hver ekstra plugin som brukes spesielt API-wrappers, er det mulig for feil å krype inn i systemet. Test alltid slike plugins og sørge for at de er aktivt vedlikeholdt. En verdig mål er å se hvor mange nye oppdateringer av en kodebase som har blitt gjort i de siste månedene. Ekspansjonsfrekvensen er av største betydning i utførelsesalgoritmen. Merk at hundrevis av ordrer kan sendes hvert minutt og som sådan ytelsen er kritisk. Slippage vil bli pådratt gjennom et dårlig utførende kjøresystem, og dette vil ha en dramatisk innvirkning på lønnsomheten. Statisk skrevet språk se nedenfor h da C Java generelt er optimal for utførelse, men det er en avgang i utviklingstid, testing og vedlikehold. Dynamisk typede språk, for eksempel Python og Perl, er nå generelt raske nok. Sørg alltid for at komponentene er utformet i en modulær mote se nedenfor slik at de kan byttes ut som systemet skalerer. Planleggings - og utviklingsprosessens komponenter. Komponentene i et handelssystem, frekvens - og volumkrav er omtalt ovenfor, men systeminfrastruktur har ennå ikke blitt dekket. De fungerer som en forhandler eller arbeider i et lite fond vil trolig ha på seg mange hatter. Det vil være nødvendig å dekke alfa-modellen, risikostyring og utførelsesparametere, og også den endelige implementeringen av systemet. Før du drar til bestemte språk, utformer du et optimalt Systemarkitektur vil bli diskutert. Del av bekymringer. En av de viktigste beslutningene som må gjøres i begynnelsen er hvordan å skille bekymringene fra et handelssystem I programvareutvikling betyr dette i hovedsak hvordan man bryter opp de ulike aspektene av handelssystemet i separate modulære komponenter. Ved å utstede grensesnitt på hver av komponentene er det enkelt å bytte ut deler av systemet for andre versjoner som hjelper ytelse , pålitelighet eller vedlikehold uten å endre ekstern avhengighetskode. Dette er den beste praksis for slike systemer. For strategier med lavere frekvenser, anbefales slik praksis. For ultrahøyfrekvenshandel må regelboken ignoreres på bekostning av å tilpasse systemet for enda mer ytelse Et mer tett koblet system kan være ønskelig. Å lage et komponentkart av et algoritmisk handelssystem er verdt en artikkel i seg selv. En optimal tilnærming er imidlertid å sørge for at det er separate komponenter for de historiske og sanntids markedsdatainngangene, dataene lagring, data tilgang API, backtester, strategiparametere, portefølje bygging, risikostyring og automatisert utførelse s ystems. For eksempel, hvis datalagring som brukes er for tiden underpresterende, selv ved betydelige optimaliseringsnivåer, kan det byttes ut med minimal omskrivning til datainntaket eller datatilgang-APIen. Så langt som backtesteren og de etterfølgende komponentene angår, Det er ingen forskjell. En annen fordel med separerte komponenter er at det tillater at en rekke programmeringsspråk brukes i det overordnede systemet. Det er ikke nødvendig å være begrenset til et enkelt språk hvis kommunikasjonsmetoden til komponentene er språkavhengig. Dette vil være saken hvis de kommuniserer via TCP IP, ZeroMQ eller noen annen språkuavhengig protokoll. Som et konkret eksempel, bør du vurdere om et backtesting system skrives i C for nummerkrypende ytelse mens porteføljestyring og utførelsessystemer skrives inn i Python bruker SciPy og IBPy. Performance Considerations. Performance er et betydelig hensyn for de fleste handelsstrategier For høyere frekvensstrate Gies det er den viktigste faktoren Ytelsen dekker et bredt spekter av problemer, for eksempel algoritmisk eksekveringshastighet, nettverkslatens, båndbredde, data IO, parallell parallellitet og skalering. Hver av disse områdene dekkes individuelt av store lærebøker, så denne artikkelen vil bare skrape overflaten til hvert emne Arkitektur og språkvalg vil nå bli diskutert med tanke på deres effekt på ytelsen. Den rådende visdom som Donald Knuth forteller om en av fedrene til datalogi, er at for tidlig optimalisering er roten til alt ondt. Dette er nesten alltid tilfelle - unntatt når du bygger en høyfrekvent handelsalgoritme For de som er interessert i lavere frekvensstrategier, er en felles tilnærming å bygge et system på den enkleste måten og bare optimalisere etter hvert som flaskehalser begynner å vises. Profilverktøy brukes til å bestemme hvor flaskehalser oppstår Profiler kan gjøres for alle faktorene som er oppført ovenfor, enten i et MS Windows eller Linux-miljø. Det er mange operativsystem og språkverktøy tilgjengelig for det, samt tredjepartsverktøy. Språkvalg vil nå bli diskutert i sammenheng med ytelse. C, Java, Python, R og MatLab inneholder alle høyytelsesbiblioteker enten som en del av deres standard eller eksternt for grunnleggende datastruktur og algoritmisk arbeid C-skip med Standard Template Library, mens Python inneholder NumPy SciPy Vanlige matematiske oppgaver finnes i disse bibliotekene, og det er sjelden gunstig å skrive en ny implementering. Et unntak er om svært tilpasset maskinvarearkitektur er nødvendig, og en algoritme gjør mye bruk av proprietære utvidelser som tilpassede caches. Men ofte gjenoppfinnelse av hjulavfallet tid som kan bli bedre brukt å utvikle og optimalisere andre deler av handelsinfrastrukturen. Utviklingstiden er ekstremt verdifull, spesielt i sammenheng med sålen utviklere. Latency er ofte et problem med utførelsen systemet som forskning verktøyene er vanligvis situated d på samme maskin For det første kan latens forekomme på flere punkter langs utførelsesbanen. Databaser må konsulteres i nettverksdriftstid, signaler må genereres operativsystem, kjernalmeldingsforsinkelse, handelssignaler sendt NIC latency og ordrer behandlet utvekslingssystem intern latens. For høyere frekvensoperasjoner er det nødvendig å bli godt kjent med kernaloptimalisering, samt optimalisering av nettverksoverføring. Dette er et dypt område og er betydelig utenfor artikkelen, men hvis en UHFT-algoritme er ønsket, vær da oppmerksom på dybden av Kunnskap kreves. Caching er svært nyttig i verktøykassen til en kvantitativ handelsutvikler. Caching refererer til konseptet om lagring av ofte tilgangsdata på en måte som tillater høyere ytelse, på bekostning av potensiell stallhet av dataene. En vanlig brukstilfelle skjer i webutvikling når du tar data fra en diskbasert relasjonsdatabase og legger den i minnet. Enhver etterfølgende Forespørsler om dataene behøver ikke å treffe databasen, og prestasjonsgevinstene kan derfor være signifikante. For handelssituasjoner kan caching være ekstremt gunstig. For eksempel kan dagens status i en strategiportel lagres i en cache til den er rebalansert slik at listen trenger ikke å bli regenerert på hver krets av handelsalgoritmen. Slike regenerering er sannsynligvis en høy CPU - eller disk-IO-operasjon. Imidlertid er caching ikke uten sine egne problemer. Regenerering av cacherdata på en gang, på grunn av volatilie Cache-lagringens natur kan stille betydelig etterspørsel etter infrastruktur. Et annet problem er hundelagring der flere generasjoner av en ny cachekopi utføres under ekstremt høy belastning, noe som fører til kaskadefeil. Dynamisk minneallokering er en dyr operasjon i programvareutførelse. det er avgjørende for at høyere prestasjonshandelsapplikasjoner skal være godt oppmerksomme på hvordan minne blir tildelt og fordelt under programflyten. Nyere språkstandarder slik som Java, C og Python alle utfører automatisk søppelkolleksjon som refererer til deallokering av dynamisk tildelt minne når objekter går utenfor omfanget. Innsamling av gjenvinning er ekstremt nyttig under utvikling, da det reduserer feil og hjelpevennlighet. Det er imidlertid ofte suboptimal for visse Høyfrekvente handelsstrategier Tilpasset søppelsamling er ofte ønsket for disse tilfellene I Java, for eksempel ved å stille inn søppelkollektor og haugekonfigurasjon, er det mulig å oppnå høy ytelse for HFT-strategier. C gir ikke en innfødt søppelkollektor, og så det er nødvendig for å håndtere all minneallokering som en del av en objekt s implementering Mens potensielt feilproblemer som potensielt fører til danglingpekere, er det ekstremt nyttig å ha finkornet kontroll over hvordan objekter vises i bunken for visse applikasjoner. Når du velger et språk, må du sørge for at å studere hvordan søppelsamleren fungerer, og om den kan modifiseres for å optimalisere for en bestemt bruk av sak. Mange operasjoner i algoritmiske handelssystemer kan brukes til parallellisering. Dette refererer til konseptet om å utføre flere programmatiske operasjoner samtidig, dvs. parallelt. Såkalte embarassingly parallelle algoritmer inkluderer trinn som kan beregnes helt uavhengig av andre trinn. Visse Statistiske operasjoner, som Monte Carlo-simuleringer, er et godt eksempel på embarassingly parallelle algoritmer, da hver tilfeldig tegning og etterfølgende baneoperasjon kan beregnes uten kjennskap til andre baner. Andre algoritmer er bare delvis parallelle. Fluiddynamiske simuleringer er et eksempel der Domenet for beregning kan deles opp, men i siste rekke må disse domenene kommunisere med hverandre og dermed operasjonene er delvis sekvensielle. Paralleliserbare algoritmer er underlagt Amdahl s Law som gir en teoretisk øvre grense for ytelsesøkningen av en parallellisert algoritme når det er underlagt N separat prosesser på en CPU-kjerne eller tråd. Parallellisering har blitt stadig viktigere som et middel til optimalisering siden prosessorens klockhastighet har stagnert, da nyere prosessorer inneholder mange kjerner som skal utføre parallelle beregninger. Stigningen av forbrukergrafikkhardware hovedsakelig for videospill har ført til utvikling av grafisk Behandlingsenheter GPUer, som inneholder hundrevis av kjerner for svært samtidige operasjoner. Slike GPUer er nå veldig rimelige. Høytstående rammer, for eksempel Nvidia s CUDA, har ført til utbredt adopsjon i akademia og finans. Slik GPU-maskinvare er generelt bare egnet for forskningsaspektet of quantitative finance, whereas other more specialised hardware including Field-Programmable Gate Arrays - FPGAs are used for U HFT Nowadays, most modern langauges support a degree of concurrency multithreading Thus it is straightforward to optimise a backtester, since all calculations are generally independent of the others. Scaling in software engineering and operations refers to the ability of the system to handle consistently increasing loads in the form of greater requests, higher processor usage and more memory allocation In algorithmic trading a strategy is able to scale if it can accept larger quantities of capital and still produce consistent returns The trading technology stack scales if it can endure larger trade volumes and increased latency, without bottlenecking. While systems must be designed to scale, it is often hard to predict beforehand where a bottleneck will occur Rigourous logging, testing, profiling and monitoring will aid greatly in allowing a system to scale Languages themselves are often described as unscalable This is usually the result of misinformation, rather than hard fact It is the total technology stack that should be ascertained for scalability, not the language Clearly certain languages have greater performance than others in particular use cases, but one language is never better than another in every sense. One means of manag ing scale is to separate concerns, as stated above In order to further introduce the ability to handle spikes in the system i e sudden volatility which triggers a raft of trades , it is useful to create a message queuing architecture This simply means placing a message queue system between components so that orders are stacked up if a certain component is unable to process many requests. Rather than requests being lost they are simply kept in a stack until the message is handled This is particularly useful for sending trades to an execution engine If the engine is suffering under heavy latency then it will back up trades A queue between the trade signal generator and the execution API will alleviate this issue at the expense of potential trade slippage A well-respected open source message queue broker is RabbitMQ. Hardware and Operating Systems. The hardware running your strategy can have a significant impact on the profitability of your algorithm This is not an issue restricted to high f requency traders either A poor choice in hardware and operating system can lead to a machine crash or reboot at the most inopportune moment Thus it is necessary to consider where your application will reside The choice is generally between a personal desktop machine, a remote server, a cloud provider or an exchange co-located server. Desktop machines are simple to install and administer, especially with newer user friendly operating systems such as Windows 7 8, Mac OSX and Ubuntu Desktop systems do possess some significant drawbacks, however The foremost is that the versions of operating systems designed for desktop machines are likely to require reboots patching and often at the worst of times They also use up more computational resources by the virtue of requiring a graphical user interface GUI. Utilising hardware in a home or local office environment can lead to internet connectivity and power uptime problems The main benefit of a desktop system is that significant computational horse power can be purchased for the fraction of the cost of a remote dedicated server or cloud based system of comparable speed. A dedicated server or cloud-based machine, while often more expensive than a desktop option, allows for more significant redundancy infrastructure, such as automated data backups, the ability to more straightforwardly ensure uptime and remote monitoring They are harder to administer since they require the ability to use remote login capabilities of the operating system. In Windows this is generally via the GUI Remote Desktop Protocol RDP In Unix-based systems the command-line Secure SHell SSH is used Unix-based server infrastructure is almost always command-line based which immediately renders GUI-based programming tools such as MatLab or Excel to be unusable. A co-located server, as the phrase is used in the capital markets, is simply a dedicated server that resides within an exchange in order to reduce latency of the trading algorithm This is absolutely necessary f or certain high frequency trading strategies, which rely on low latency in order to generate alpha. The final aspect to hardware choice and the choice of programming language is platform-independence Is there a need for the code to run across multiple different operating systems Is the code designed to be run on a particular type of processor architecture, such as the Intel x86 x64 or will it be possible to execute on RISC processors such as those manufactured by ARM These issues will be highly dependent upon the frequency and type of strategy being implemented. Resilience and Testing. One of the best ways to lose a lot of money on algorithmic trading is to create a system with no resiliency This refers to the durability of the sytem when subject to rare events, such as brokerage bankruptcies, sudden excess volatility, region-wide downtime for a cloud server provider or the accidental deletion of an entire trading database Years of profits can be eliminated within seconds with a poorly-de signed architecture It is absolutely essential to consider issues such as debuggng, testing, logging, backups, high-availability and monitoring as core components of your system. It is likely that in any reasonably complicated custom quantitative trading application at least 50 of development time will be spent on debugging, testing and maintenance. Nearly all programming languages either ship with an associated debugger or possess well-respected third-party alternatives In essence, a debugger allows execution of a program with insertion of arbitrary break points in the code path, which temporarily halt execution in order to investigate the state of the system The main benefit of debugging is that it is possible to investigate the behaviour of code prior to a known crash point. Debugging is an essential component in the toolbox for analysing programming errors However, they are more widely used in compiled languages such as C or Java, as interpreted languages such as Python are often easi er to debug due to fewer LOC and less verbose statements Despite this tendency Python does ship with the pdb which is a sophisticated debugging tool The Microsoft Visual C IDE possesses extensive GUI debugging utilities, while for the command line Linux C programmer, the gdb debugger exists. Testing in software development refers to the process of applying known parameters and results to specific functions, methods and objects within a codebase, in order to simulate behaviour and evaluate multiple code-paths, helping to ensure that a system behaves as it should A more recent paradigm is known as Test Driven Development TDD , where test code is developed against a specified interface with no implementation Prior to the completion of the actual codebase all tests will fail As code is written to fill in the blanks , the tests will eventually all pass, at which point development should cease. TDD requires extensive upfront specification design as well as a healthy degree of discipline in ord er to carry out successfully In C , Boost provides a unit testing framework In Java, the JUnit library exists to fulfill the same purpose Python also has the unittest module as part of the standard library Many other languages possess unit testing frameworks and often there are multiple options. In a production environment, sophisticated logging is absolutely essential Logging refers to the process of outputting messages, with various degrees of severity, regarding execution behaviour of a system to a flat file or database Logs are a first line of attack when hunting for unexpected program runtime behaviour Unfortunately the shortcomings of a logging system tend only to be discovered after the fact As with backups discussed below, a logging system should be given due consideration BEFORE a system is designed. Both Microsoft Windows and Linux come with extensive system logging capability and programming languages tend to ship with standard logging libraries that cover most use cases It is often wise to centralise logging information in order to analyse it at a later date, since it can often lead to ideas about improving performance or error reduction, which will almost certainly have a positive impact on your trading returns. While logging of a system will provide information about what has transpired in the past, monitoring of an application will provide insight into what is happening right now All aspects of the system should be considered for monitoring System level metrics such as disk usage, available memory, network bandwidth and CPU usage provide basic load information. Trading metrics such as abnormal prices volume, sudden rapid drawdowns and account exposure for different sectors markets should also be continuously monitored Further, a threshold system should be instigated that provides notification when certain metrics are breached, elevating the notification method email, SMS, automated phone call depending upon the severity of the metric. System monitoring is often the domain of the system administrator or operations manager However, as a sole trading developer, these metrics must be established as part of the larger design Many solutions for monitoring exist proprietary, hosted and open source, which allow extensive customisation of metrics for a particular use case. Backups and high availability should be prime concerns of a trading system Consider the following two questions 1 If an entire production database of market data and trading history was deleted without backups how would the research and execution algorithm be affected 2 If the trading system suffers an outage for an extended period with open positions how would account equity and ongoing profitability be affected The answers to both of these questions are often sobering. It is imperative to put in place a system for backing up data and also for testing the restoration of such data Many individuals do not test a restore strategy If recovery from a crash has not been tested in a s afe environment, what guarantees exist that restoration will be available at the worst possible moment. Similarly, high availability needs to be baked in from the start Redundant infrastructure even at additional expense must always be considered, as the cost of downtime is likely to far outweigh the ongoing maintenance cost of such systems I won t delve too deeply into this topic as it is a large area, but make sure it is one of the first considerations given to your trading system. Choosing a Language. Considerable detail has now been provided on the various factors that arise when developing a custom high-performance algorithmic trading system The next stage is to discuss how programming languages are generally categorised. Type Systems. When choosing a language for a trading stack it is necessary to consider the type system The languages which are of interest for algorithmic trading are either statically - or dynamically-typed A statically-typed language performs checks of the types e g integers, floats, custom classes etc during the compilation process Such languages include C and Java A dynamically-typed language performs the majority of its type-checking at runtime Such languages include Python, Perl and JavaScript. For a highly numerical system such as an algorithmic trading engine, type-checking at compile time can be extremely beneficial, as it can eliminate many bugs that would otherwise lead to numerical errors However, type-checking doesn t catch everything, and this is where exception handling comes in due to the necessity of having to handle unexpected operations Dynamic languages i e those that are dynamically-typed can often lead to run-time errors that would otherwise be caught with a compilation-time type-check For this reason, the concept of TDD see above and unit testing arose which, when carried out correctly, often provides more safety than compile-time checking alone. Another benefit of statically-typed languages is that the compiler is able to make many optimisations that are otherwise unavailable to the dynamically - typed language, simply because the type and thus memory requirements are known at compile-time In fact, part of the inefficiency of many dynamically-typed languages stems from the fact that certain objects must be type-inspected at run-time and this carries a performance hit Libraries for dynamic languages, such as NumPy SciPy alleviate this issue due to enforcing a type within arrays. Open Source or Proprietary. One of the biggest choices available to an algorithmic trading developer is whether to use proprietary commercial or open source technologies There are advantages and disadvantages to both approaches It is necessary to consider how well a language is supported, the activity of the community surrounding a language, ease of installation and maintenance, quality of the documentation and any licensing maintenance costs. The Microsoft stack including Visual C , Visual C and MathWorks MatLab are two of the larger pro prietary choices for developing custom algorithmic trading software Both tools have had significant battle testing in the financial space, with the former making up the predominant software stack for investment banking trading infrastructure and the latter being heavily used for quantitative trading research within investment funds. Microsoft and MathWorks both provide extensive high quality documentation for their products Further, the communities surrounding each tool are very large with active web forums for both The software allows cohesive integration with multiple languages such as C , C and VB, as well as easy linkage to other Microsoft products such as the SQL Server database via LINQ MatLab also has many plugins libraries some free, some commercial for nearly any quantitative research domain. There are also drawbacks With either piece of software the costs are not insignificant for a lone trader although Microsoft does provide entry-level version of Visual Studio for free Micros oft tools play well with each other, but integrate less well with external code Visual Studio must also be executed on Microsoft Windows, which is arguably far less performant than an equivalent Linux server which is optimally tuned. MatLab also lacks a few key plugins such as a good wrapper around the Interactive Brokers API, one of the few brokers amenable to high-performance algorithmic trading The main issue with proprietary products is the lack of availability of the source code This means that if ultra performance is truly required, both of these tools will be far less attractive. Open source tools have been industry grade for sometime Much of the alternative asset space makes extensive use of open-source Linux, MySQL PostgreSQL, Python, R, C and Java in high-performance production roles However, they are far from restricted to this domain Python and R, in particular, contain a wealth of extensive numerical libraries for performing nearly any type of data analysis imaginable, often at execution speeds comparable to compiled languages, with certain caveats. The main benefit of using interpreted languages is the speed of development time Python and R require far fewer lines of code LOC to achieve similar functionality, principally due to the extensive libraries Further, they often allow interactive console based development, rapidly reducing the iterative development process. Given that time as a developer is extremely valuable, and execution speed often less so unless in the HFT space , it is worth giving extensive consideration to an open source technology stack Python and R possess significant development communities and are extremely well supported, due to their popularity Documentation is excellent and bugs at least for core libraries remain scarce. Open source tools often suffer from a lack of a dedicated commercial support contract and run optimally on systems with less-forgiving user interfaces A typical Linux server such as Ubuntu will often be fully command - line oriented In addition, Python and R can be slow for certain execution tasks There are mechanisms for integrating with C in order to improve execution speeds, but it requires some experience in multi-language programming. While proprietary software is not immune from dependency versioning issues it is far less common to have to deal with incorrect library versions in such environments Open source operating systems such as Linux can be trickier to administer. I will venture my personal opinion here and state that I build all of my trading tools with open source technologies In particular I use Ubuntu, MySQL, Python, C and R The maturity, community size, ability to dig deep if problems occur and lower total cost ownership TCO far outweigh the simplicity of proprietary GUIs and easier installations Having said that, Microsoft Visual Studio especially for C is a fantastic Integrated Development Environment IDE which I would also highly recommend. Batteries Included. The header of this sect ion refers to the out of the box capabilities of the language - what libraries does it contain and how good are they This is where mature languages have an advantage over newer variants C , Java and Python all now possess extensive libraries for network programming, operating system interaction, GUIs, regular expressions regex , iteration and basic algorithms. C is famed for its Standard Template Library STL which contains a wealth of high performance data structures and algorithms for free Python is known for being able to communicate with nearly any other type of system protocol especially the web , mostly through its own standard library R has a wealth of statistical and econometric tools built in, while MatLab is extremely optimised for any numerical linear algebra code which can be found in portfolio optimisation and derivatives pricing, for instance. Outside of the standard libraries, C makes use of the Boost library, which fills in the missing parts of the standard library In fact , many parts of Boost made it into the TR1 standard and subsequently are available in the C 11 spec, including native support for lambda expressions and concurrency. Python has the high performance NumPy SciPy Pandas data analysis library combination, which has gained widespread acceptance for algorithmic trading research Further, high-performance plugins exist for access to the main relational databases, such as MySQL MySQL C , JDBC Java MatLab , MySQLdb MySQL Python and psychopg2 PostgreSQL Python Python can even communicate with R via the RPy plugin. An often overlooked aspect of a trading system while in the initial research and design stage is the connectivity to a broker API Most APIs natively support C and Java, but some also support C and Python, either directly or with community-provided wrapper code to the C APIs In particular, Interactive Brokers can be connected to via the IBPy plugin If high-performance is required, brokerages will support the FIX protocol. As is now evident, the choice of programming language s for an algorithmic trading system is not straightforward and requires deep thought The main considerations are performance, ease of development, resiliency and testing, separation of concerns, familiarity, maintenance, source code availability, licensing costs and maturity of libraries. The benefit of a separated architecture is that it allows languages to be plugged in for different aspects of a trading stack, as and when requirements change A trading system is an evolving tool and it is likely that any language choices will evolve along with it. Just Getting Started with Quantitative Trading.