Knight Upgrade Utlöst Old Handel System

Knight Capital Group gjorde en olycklig ond dator slår ner ett handelshus. Knight Capital Group är ett handelshus som hjälper andra att få tillgång till finansiella marknader genom att utföra sina affärer. Det tjänar som en särskild markör, vilket innebär att det ger köpförsäljningsorder så att andra Kan alltid utföra en handel mot det för mer än 600 värdepapper på börserna NYSE och NASDAQ. Det fungerar också som marknadsmäklare för många andra värdepapper. Marknadsföring och handel är nyckelaktiviteter på finansmarknaderna, vilket kräver pålitlig och ärlig handel. Det är inte konstigt att dess webbplats bär slogan Standard of Trust. So vad är en att tänka på händelsen som ägde rum den 1 augusti, där en flurry av affärer från Knight ledde till att det samlade en handelsposition på 7 miljarder, långt Mer än vad den kunde hålla, vilket ledde till en gemensam insats för att driva positionen till en mindre riskabel nivå. I sin brådska för att minska riskexponeringen sålde den oundvikligen några av sina innehav Billigt också känd som brandförsäljning och slutade att förlora 440 miljoner. Även mot de standarder för förluster som vi har blivit vana vid i denna finanskris var det en mycket dålig dag för Knight. Sedan dess har Knight kunnat hitta investerare med Nyskapande kapital på 400 miljoner, i stort sett samma belopp som det förlorade, vilket kommer att stabilisera företaget om det inte lider mer katastrofala förluster. Det har också undersökt orsaken till den plötsliga ökningen i inköpsorder. Här är informationen lite oklart, men Wall Street Journal rapporterar en oväntad anledning En botched uppdatering av datorsystem Det som verkar ha hänt är att de nya datorsystemen installerades och fungerade korrekt, men de var inte installerade på alla handelsplattformar varje system måste replikeras över alla handelsplattformar. Detta ledde till att Till gamla system som handlas på vissa plattformar medan nya system handlas på andra, och det var tydligen det gamla systemet som gick fel. Exakt hur det här är möjligt är oklart för att De gamla systemen hade uppenbarligen fungerat bra tidigare men en möjlig anledning är att de gamla systemen inte längre lade upp sina affärer i riskhanteringssystemet, så att deras verksamhet till den totala risken gick oupptäckt. Denna förklaring är spekulativ, men om rapporterna Att det nya systemet fungerade bra är korrekt, då den enorma uppbyggnaden av köporder tyder på att det måste ha varit någon information som släppts från riskbedömningssystemet. Denna berättelse om datafel startar och slutar med mänskligt fel Människor misslyckades med att installera det nya systemet Över alla handelsplattformar och folk misslyckades med att stoppa affärer när NYSE-handelsgolvstjänstemän noterade de ovanliga branscherna och varnade Riddare om att det var källan till ovanliga handelsrörelser. Men nyckeln här är att datorsystemen var så snabba och effektiva i deras Arbeta att det fanns lite tid att stoppa dem när de kom. Detta är ett fenomen som är känt från forskning om organisationsolyckor. Det är också en ma Jor orsak av oegentligheter, som jag har noterat i arbetet med kollegor Don Palmer och Jo-Ellen Pozner. När det gäller riddare var handlarna förmodligen så farliga att det är ett domskäl om företaget har upprätthållit sin uppgift för lämpliga riskhanteringsmål , Vem som helst Men tilldelningen av ansvar kommer att vara svårt eftersom dessa verksamheter var oavsiktliga och olyckan inträffade i gränssnittet mellan snabba och felaktiga datorer och långsammare människor försöker komma ikapp. Klart har denna historia viktiga lektioner för hur organisationer tänker på riskhantering Och kvalitetskontroll, särskilt när de gör allt fler av sina nyckelsystem automatiskt. Det är också en påminnelse om att finansiella marknader innehåller mänskliga handlare, som kan vara ganska felaktiga i sina domar, och att ersätta dem med datorer gör ibland domen ännu värre , Om du någonsin har haft en mjukvaruuppgradering är dålig, tänk på Knight Capital och hur mycket värre det kunde ha varit jag tvivlar på att du någonsin har upplevt En datoruppgradering som drog in pengar från ditt bankkonto och distribuerade det till främlingar. Greve, HR Palmer, D och Pozner, J 2010 Organisationer Gone Wild Orsakerna, processerna och följderna av organisationsbristande Academy of Management Annals 4 1, 53 107 Patterson, SJ Strasburg och J Bunge 2012 Knight Upgrade Triggered Old Trading System, stora förluster Wall Street Journal 15 8 2012. Lägg till en kommentar Redan medlem Logga in. Henrich R Greve är professor i entreprenörskap på INSEAD. Most delade artiklar. Hur en Ett par indiska sjukhus har gjort kostnadsfria operationer ett hållbart hälsoparadigram. De kompletterande styrkorna hos företagsuniversiteter och B-skolor gör dem till naturliga partners via INSEADKnowledge. Europeiska kommissionen för konkurrens sätter sitt rykte på Apple-Irland-fallet via INSEADKnowledge. Survey Unga vuxna föredrar överväldigande personliga kurser till online-utbildning VinikaDRao HenrikBresman via INSEADKnowledge. Bernhard 15 03 2017 kl 12 42. Bra artic Le - jag njöt av att läsa den här artikeln En sak som jag skulle vilja påpeka är att digital. Christel 14 03 2017 vid 09 52 ammunicationsrådgivare - Tack för att du delar delarna och gör att vi börjar på en personlig nivå Our. webeditor 13 03 2017 klockan 02 59. Tack för frågan - Les, är Prof Beechler borta till den 1 april, så kommer jag se till att hon ser det här på henne. Brohms 09 03 2017 kl 04. 29.Retired Scientist - Det här ämnet tycks röra fler tankar i Läsare, som mig Neuroscience, nu. Brahms 09 03 2017 kl 04.00. Rettled Senior, specialiserad i fysikvetenskap - Tack för analyserna av Technostress-komponenterna. I strålkastaren. INSEADs globala ledarskapscentrum erbjuder unik expertis som ledande Centrum för forskning och övning i ledarskap och ett partnerskap mellan INSEAD Knowledge, Knowledge Wharton och World Economic Forum Global Agenda Council på tillväxtmarknaden. För att utnyttja möjligheter som uppstår genom digitalisering, måste organisationer och ledare omfamna den nya verksamheten Realiteter. Jag talade vid en konferens förra året om ämnena DevOps, Configuration as Code och Continuous Delivery och använde följande historia för att visa vikten av att implementeringarna automatiseras och repeteras som en del av ett DevOps Continuous Delivery-initiativ Sedan den konferensen jag Har blivit uppmanad av flera personer att dela berättelsen genom min blogg. Den här historien är sann, detta hände verkligen. Det här är mitt berättande om historien baserad på vad jag har läst. Jag var inte inblandad i detta. Det här är historien om hur ett företag med nästan 400 miljoner i tillgångar gick i konkurs på 45 minuter på grund av en misslyckad implementering. Knight Capital Group är ett amerikanskt globalt finansiellt företag som bedriver marknadsföring av elektroniskt genomförande och institutionell försäljning och handel. År 2012 var Knight den största näringsidkaren i amerikanska aktier med marknad Andel av cirka 17 på vardera NYSE och NASDAQ Knight s Electronic Trading Group ETG lyckades en genomsnittlig daglig handel på mer än 3 3 miljarder handel S dagligen, handla över 21 miljarder dollar dagligen Det är inget skämt. Den 31 juli 2012 hade Knight cirka 365 miljoner i kontanter och ekvivalenter. NYSE planerade att lansera ett nytt Retail Liquidity Program ett program som syftar till att ge bättre priser till privatinvesterare Genom detaljhandeln, som Knight den 1 augusti 2012 För att förbereda detta evenemang uppdaterade Knight sin automatiserade, höghastighetsalgoritmiska router som skickar order till marknaden för körning som kallas SMARS En av SMARS kärnfunktioner är att ta emot order från Andra komponenter i Knights Trading Platform förälderorder och sedan skicka en eller flera order order för utförande Med andra ord skulle SMARS få stora order från handelsplattformen och bryta dem upp i flera mindre order för att hitta en köparesäljare match för Volymen av aktier Ju större förälderordern var, desto fler order skulle vara genererade. Uppdateringen till SMARS var avsedd att ersätta gammal, oanvänd kod som kallas Power Peg functi Onality som Knight inte hade använt i 8 år varför kod som hade varit död i 8 år fortfarande var närvarande i kodbasen är ett mysterium, men det är inte meningen Koden som uppdaterades återställde en gammal flagga som användes För att aktivera Power Peg-funktionaliteten Koden testades grundligt och visat sig fungera korrekt och pålitligt. Det kan eventuellt gå fel. Vad kan eventuellt gå fel. Mellan 27 juli 2012 och 31 juli 2012 installerade Knight manuellt den nya mjukvaran till en begränsad Antal servrar per dag åtta 8 servrar i alla Det här är vad SEC-filing säger om den manuella installationsprocessen BTW om det finns en SEC-fil om din implementering kan det ha gått väldigt fel. Under utplaceringen av den nya koden kopierade en av Knight s tekniker emellertid inte den nya koden till någon av de åtta SMARS datorservrarna. Knight hade inte en andra tekniker granskar denna installation och ingen hos Knight insåg att Power Peg-koden Inte hade tagits bort från den åttonde servern, eller den nya RLP-koden tillagt Knight hade inga skriftliga procedurer som krävde en sådan granskning SEC Filing Release nr 70694 16 oktober 2013.Ot den 9:30 AM Eastern Time den 1 augusti 2012 öppnade marknaderna och Knight började behandla order från mäklarehandlare på sina kunders vägnar för det nya Retail Liquidity Programmet. De sju 7 servrarna som hade rätt SMARS-utplacering började behandla dessa order korrekt. Beställningar som skickades till den åttonde servern utlöste den supposable repurposed flaggan och togs tillbaka från Död den gamla Power Peg code. Attack av Killer Code Zombies. Det är viktigt att förstå vad den döda Power Peg-koden var tänkt att göra. Denna funktionalitet var tänkt att räkna sha Res köpte säljs mot en förälderorder när barnorder beställdes. Power Peg skulle instruera systemet att sluta dirigera barnbeställningar när förälderordern var uppfylld. I grund och botten skulle Power Peg hålla koll på barns order och stoppa dem när förälderordern var klar Under 2005 flyttade Knight denna kumulativa spårningsfunktionalitet till ett tidigare skede i kodkörningen och tog bort räkneuppföljningen från Power Peg-funktionaliteten. När Power Peg-flaggan på den åttonde servern aktiverades började Power Peg-funktionaliteten att dirigera barnorder för utförande, men Det var inte möjligt att spåra mängden aktier mot moderordningen något som en oändlig loop.45 Minutes of Hell. Imagine vad som skulle hända om du hade ett system som kunde skicka automatiska höghastighetsorder till marknaden utan att spåra för att se om det var tillräckligt Order hade utförts Ja, det var så dåligt. När marknaden öppnade klockan 9:30 visste folk snabbt att något var fel Vid 9 31 var det uppenbart för många människor Le på Wall Street att något seriöst inträffade Marknaden var översvämmade med beställningar för vanliga för regelbundna handelsvolymer på vissa lager. Vid 9 32 AM undrade många på Wall Street varför det inte hade stoppat. Detta var en evighet i high - Hastighet handelsvillkor Varför hade ingen drabbat dödkontakten på vilket system som helst som det visar sig att det inte fanns någon dödsbrytare Under de första 45 minuterna av handel utgjorde Knight s avrättningar mer än 50 av volymen, Upp över 10 av deras värde Som ett resultat av detta minskade andra lager i värde som svar på de felaktiga affärer. För att göra saken värre började Knight s system skicka automatiserade e-postmeddelanden tidigare i dag så tidigt som 08 01 när SMARS hade behandlat beställningar kvalificerade För handel före marknadsföring E-postmeddelandena refererar till SMARS och identifierade ett fel som Power Peg inaktiverad Mellan 8 01 AM och 9 30 AM var 97 av dessa e-postmeddelanden skickade till Knight-personal Naturligtvis dessa ema Ils var inte utformad som systemvarningar och därför tittade ingen på dem direkt Oops. During 45-minuters helvetet upplevde riddaren att de försökte flera motåtgärder för att försöka stoppa de felaktiga affärerna. Det fanns ingen dödsbrytare och inga dokumenterade förfaranden För hur man ska reagera så att de kvarstod försöker diagnostisera problemet i en levande handelsmiljö där 8 miljoner aktier handlades varje minut Eftersom de inte kunde bestämma vad som orsakade de felaktiga ordern reagerade de genom att avinstallera den nya koden från servrarna Med andra ord tog de bort arbetskoden och lämnade den trasiga koden. Detta förstärkte bara problemen som orsakade ytterligare föräldraordningar för att aktivera Power Peg-koden på alla servrar, inte bara den som inte användes korrekt. Kunna stoppa systemet efter 45 minuters handel. Under de första 45 minuterna öppnades marknaden Power Peg-koden mottagen och behandlade 212 föräldraordningar. Som en Resultatet SMARS skickade miljontals barnorder till marknaden vilket resulterade i 4 miljoner transaktioner mot 154 aktier för mer än 397 miljoner aktier. För dina börsklubbar innebar detta att riddaren antog cirka 3 5 miljarder nätlånga positioner i 80 aktier och 3 15 miljarder netto kort Positioner i 74 aktier Under lekternas villkor realiserade Knight Capital Group en 460 miljoner förlust på 45 minuter. Kom ihåg att Knight bara har 365 miljoner kontanter och ekvivalenter. Under 45 minuter gick Knight från att vara den största näringsidkaren i amerikanska aktier och en stor marknad Maker i NYSE och NASDAQ till konkurs De hade 48 timmar för att höja kapitalet som var nödvändigt för att täcka sina förluster som de lyckats göra med 400 miljoner investeringar från cirka ett halvt dussin investerare. Knight Capital Group förvärvades så småningom av Getco LLC december 2012 Och det sammanslagna företaget heter nu KCG Holdings. En lektion att lära. Händelserna den 1 augusti 2012 borde vara en lektion för alla utvecklings - och operationsgrupper. Det är inte tillräckligt att b Uild bra programvara och testa det, du måste också se till att den levereras på marknaden korrekt så att dina kunder får det värde du levererar och så att du inte går i konkurs med ditt företag. Ingenjörerna som distribuerade SMARS är inte enbart skyldiga processen Processen Knight Hade upprättats var inte lämplig för den risk de utsattes för Dessutom var deras process eller brist på det i sig föremål för fel. Varje gång din implementeringsprocess bygger på människor som läser och följer instruktioner som du utsätter dig för att riskera. Människor gör misstag. Misstagen kan vara i Instruktionerna, tolkningen av instruktionerna eller i utförandet av instruktionerna. Distributionen måste automatiseras och repeteras och som fri från potentiellt mänskligt fel som möjligt. Had Knight implementerat ett automatiserat installationssystem kompletterat med konfiguration, implementering och testautomatisering Fel som orsakar riddare skulle ha undvikits. Ett par principer för kontinuerlig leverans app Ly här även om du inte implementerar en fullständig kontinuerlig leveransprocess. Releasingprogramvara bör vara en repeterbar, pålitlig process. Automate så mycket som är rimligt. Ett scenario Låt oss anta att de hade mycket bra DevOps Så alla servrar skulle synkronisera Men antar att Den nya koden hade en bugg Så alla servrar är synkroniserade men har samma buggy-kod. Vad händer om två versioner av koden, det vill säga de senaste 2 implementeringarna hade det här felet. Så snart de inser att något är fel, döljer de tillbaka Koden, buggan stannar kvar Precious minutes har gått Kanske 20 minuter i stället för 45 minuter i din artikel. Så kort sagt är deras katastrofdrömbrytare en code rollback-implementering i en levande miljö. Det skulle fortfarande vara en defekt design Vad De behöver att vara en stor röd strömbrytare nästan bokstavligen någonstans i instrumentbrädan för att omedelbart sluta. Var är affärsregeln som säger att först gör ingen skada. VJ om utplaceringen till alla servrar hade fungerat skulle de ha varit bra men i det här fallet , 7 av 8 för o Ne-delsystemet användes korrekt På grund av det dåliga beteendet rullade de tillbaka de andra 7 tänkte den nya koden i det delsystemet var problemet som multiplicerade problemet tills den eventuella dödkontakten. Dysrarna är nästan alltid komplexa. I det här fallet var det dåligt kodande praxis , Plus tvivelaktiga testkodskontrollmetoder, plus ett fel vid implementering, plus en återgång till delsystemet i granulariteten i stället för hela systemet. Om du löser några av dessa problem får du inte en katastrof. En av de saker jag har sett I företag som inte känner igen den faktiska betydelsen och inverkan av sina IT-system är det att de inte tillhandahåller budget för uppdateringar av äldre kod. Till exempel har jag sett situationer där IT inte har någon budget. Det måste motivera allt det gör mot en företagskostnad. Ständigt kryptering för att ställa upp nya projekt Företag ser sällan behovet av att uppdatera gammal programvara som för närvarande arbetar, så de vägrar att betala för det. Resultatet är konstant ny torsk E, gjord av de billigaste kodarna möjliga, samtidigt som de inte investerar i den teknik som i slutändan skulle förbättra prestanda och minska risken. Varför Eftersom dessa ses som IT-problem och inte vad gäller vilket projekt IT-medarbetarna arbetar på så kommer ingen att betala för Det En bra läsning om denna övning är The Phoenix Project av Gene Kim, Kevin Behr och George Spafford. Tack för att du tillämpar hjärnan på hype. Troligtvis bör man fråga varför de berörda teknikerna fick ta skulden men fick inte befogenhet att Döda omkopplare på egen hand. Okej, det är därför du sätter Ops SRE på plats ändå. R är för ansvarig, aka flame bete. Jag har skrivit lite om denna händelse, och jag skulle varna någon att använda SEC-rapporten som någonting hos Allt annat än vad SEC behövde det för. Fascinerande läs Jag arbetade på ett stort auktionshus för frukt och grönsaker en gång där en ny mjukvaruversion installerades och misslyckades, vilket ledde till stora förluster för handlarna, men inte så stora som dessa Det här var också ett felaktigt utnyttjande och ingen återgång. Läran att lära sig är att det finns domäner där datorn inte borde fatta något beslut utan mänsklig validering. Vad sägs om de människor som förlorade sina jobb, eftersom oj, det fanns en bugg Vad sägs om de andra företagen som kanske kom i trubbel på grund av plötslig förändring av lagervärdet. Automation av beslut på hög nivå ska hanteras noggrant. Njut och pedagogisk post. Användning av Cynefin-ramverket ger en bättre karakterisering av detta DevOps-fel. Detta inlägg Verkar ha skrivits ur ett DevOps-perspektiv. De föreslagna lösningarna överensstämmer med ett DevOps-perspektiv, undersöka frisättnings processen, automatisera mer och skapa en dödswitch med rollback-funktioner. Vem som helst kan läsa inlägget och lägga för mycket tonvikt på Knight-tekniker som Kopierade inte den gamla koden till någon av de åtta servrarna Någon kan överskriva en orsak och effekt-relation Någon kan insistera på nya regler för att förhindra detta f Rom någonsin händer igen. En mer kraftfull metod kan investera för att öka mångfalden för att analysera situationen och syntetisera bättre alternativ. Förbättra kommunikationen mellan specialiteter. Förbättra implicit samordning mellan specialiteter. Rekrytera personer med mer kunnande för att skriva och granska code. A major faktor som begränsat möjligheterna att förbättra förmågan Av teamet från nio år innan den signifikanta felhändelsen misstänkte systemet. I en Cynefin-ram är det att associera systemet med Obvious-domänen när det begränsas av ett misslyckande med ett DevOps-problem där det finns enkla orsak och effektrelationer som kan identifieras av Proffs Felet bör inte vara associerat med Cynefin Complicated domänen där en betydande analys av specialister skulle ha förhindrat felet. Systemet ska vara associerat med Cynefin Complex-domänen ett komplext adaptivt system. Systemet är dispositionellt. De samma initiala villkoren kommer inte att producera samma Misslyckande utom med a Ccident För mer information om Cynefin, besök och CognitiveEdge. Jag uppskattar att du framhäver de tysta faktorerna i en sådan katastrof. Som författaren arbetar jag också med operationer, och det är lätt att falla i samma gamla tankemönster på orsaker och lösningar som jag särskilt Njut av din punkt som rör mångfald Som upplever i alla former upplever du nivåer, kulturella och pedagogiska bakgrund, färdigheter, ålder mm, eftersom jag tycker att det här är en stark drivkraft bakom framgången med DevOps själv. Med en mängd olika perspektiv, både inom och utan din Team, titta på ditt projekt har stark, demonstrerbar potential och kan hjälpa till att bekämpa överblickar som den som uppstått i denna artikel. Varför kod som hade varit död i 8 år fortfarande var närvarande i kodbasen är ett mysterium, men det är s Inte punkten. Tvärtom, det är exakt punkten Kod med oanvända och därför otestade konfigurationsmöjligheter är en katastrof som väntar på att hända. Det är därför jag är väldigt skeptisk till funktionen flagga Baserade tillvägagångssätt i allmänhet Konfigurationen är lika mycket en del av ditt program som koden är och konfigurationsändringar ska gå igenom samma livscykeldragningsförfrågan, kodgranskning, släpp, distribuera till staging som någon annan förändring. Om din släppprocess är för tung och du Behöver göra snabba konfigurationsändringar till produktion, fixa din släppprocess. Det fanns för många misstag för att ange det episka misslyckandet med att bara DevOps, men jag håller fullständigt med om att automatisering och testning är det enda sättet Ingen lagarbete och checklistor medan man gör en uppdatering på produktionen Servrar Varje uppdatering på produktionen bör kräva att ett lag tittar över varandra och går igenom en checklista 8 års oanvänd gammal kod i produktion Det berättar mycket om bristen på förståelse för riskerna med att dangla oanvänd kod Otillräcklig loggning från koden, Och otillräcklig loggövervakning, korrelation och analys i realtid Det skulle ha utlöst tillräckligt många ledtrådar till ingenjörer och opsfolk. Ingen hot-hot failover till Ett kluster med den tidigare versionen Det skulle ha stoppat alla problem efter 1 eller 2 minuter Det är den röda knappen som artikeln nämner. Om du också har länge byggt arkitektur, system och företag, vet du att katastrof händer, du Vet att några buggar bara fångas i naturen och inte under simuleringar, precis som du vet att maskiner kommer att gå ner. Du måste förbereda dig för det värsta fallet i båda scenarierna. Murphy s Law är så sant i vår värld. Jag har varit i vad som är Nu kallad DevOps-rummet i nästan 20 år, över hälften av det i den finansiella världen, var Knight både en leverantör till och en konkurrent till det företag jag jobbar för för närvarande. Utvecklingsautomatisering kan ha hjälpt Kanske Men få företag har råd med exakt dubbla miljöer, Och detta orsakades huvudsakligen av miljöskillnader. Även automatiserad validering av implementering kunde inte ha hjälpt i det här fallet om automationen inte visste om miljöskillnaden. Automation är bara så bra som th E kännedom om de människor som ställer upp det Om en manuell installation inte var medveten om det gamla systemet, så är det en bra chans att det automatiserade systemet inte skulle ha känt att kontrollera det heller. En automatisk återställning är också lika bra som beslutet - produktion om huruvida man ska göra back-rollen Och om automatiseringen oavsiktligt startade det gamla systemet finns det ingen garanti för att byte av det moderna systemet tillbaka skulle ha stoppat det gamla systemet du kunde ha hamnat med samma problem även efter en automatiserad Återuppbyggnad av det moderna systemet. Vilket tar mig till en slutpunkt Automation är ett krav i stora, moderna miljöer Men överlitighet på det kan leda till att de som använder systemet är omedvetna om vad det gör Automation är mest användbar för valideringar , Eftersom validering av saker görs på rätt sätt är tråkigt och lätt att skimpa på när det görs manuellt. Även när automatiseringen har mänskliga inblandade brytpunkter eller mänskliga driven steg, försäkrar de att de fungerar Hans system känner till systemet och hur det fungerar, vilket förbättrar deras förmåga att felsöka problem, diagnostisera problem och göra lämpliga förslag på vilka åtgärder som ska vidtas för att stoppa eller mildra ett problem. Automatisering är ett verktyg, men det är bara ett verktyg och det är fortfarande Kräver en hantverkare att använda det på lämpligt sätt Expertis är det som gör och håller bra system bra. Berättade detta på Garrett SY Hampton och kommenterade Incredible DevOps titta alltid på, dokumentera och granska dina implementeringar. En mörk magi Uppkomsten av robothandlare. Platser De hektiska återförsäljargolvorna på 1980-talet har ersatts av stora grupper av datorservrar. Människor kan inte tävla på hastighet, det är så enkelt som det. För år sedan var John Coates en näringsidkare i Wall Street. Idag är han neurovetenskaplig vid Cambridge University och tillbringar sina dagar övervakningshandlare hormoner för att se vad som gör dem frikopplade. Det finns enkla test du kan göra När du ser ett grönt ljus, klickar du på en mus. Det snabbaste du kan göra är 100-120 millisekunder. En grundläggande kognitiv bearbetning, att räkna ut saker, kanske 200 till 300 millisekunder. Problemet är att rutorna - förra gången jag såg ut - de behandlade en handel på 10 millisekunder, och idag tror jag att vi talar om miljonder av en sekund. Dessa lådor är robothandlare - datorer som fattar egna beslut om när man ska Köpa och sälja, men tusen gånger snabbare än någon mänsklig burk. De verkar algos som effektivt efterliknar vad handlarna brukade göra Remco Lenterman, direktör för handelsföretaget IMC. När du tänker på ett handelsgolv i London eller New York, kanske du Föreställ dig en giggle av svettiga män som böjer varandra ut ur vägen, eftersom de använder utarbetade fingerrörelser för att förmedla sina fräcka order. Det är en bild populär av 1980-talet komedi Trading Places Men det är också 30 år gammalt. För faktum är Den finansiella handeln har genomgått en datoriserad revolution som liknar Amazonas övertagande av High Street. All den verkliga åtgärden har flyttat till cyberspace. Ta New York Stock Exchange Idag äger de flesta handel inte sig bakom den berömda neocl Assikala fasaden precis utanför Wall Street, men i mycket mindre glamorösa New Jersey. Det är där NYSE har etablerat en stor elektronisk handelsanläggning som täcker 10 hektar fyra hektar, bostadsrad på rad datorservrar. Och många fler hektar är ockuperade av Servrar av robot handelsföretag kopplade till det. Nerdy brainboxesputerised handel är en iboende hemlig värld. Handelsföretaget håller ett tätt grepp om sina handelsstrategier, människor och datorkod eller algoritmer. Annars kan en rival finna ut sina komplexa men ändå Fullt automatiserade handelsmönster, och sedan kopiera dem, eller ännu värre, dämpa sina datorer för att överlämna miljoner. Bildtext Den loadsamoney-handlare på 1980-talet har sänts till skräp av historia. Remco Lenterman, en regissör hos ett sådant företag, IMC i Nederländerna försöker att demystifiera sin verksamhet. Han säger Förr i tiden för 10 år sedan skulle ett skrivbord av aktiehandlare ha mellan 80 och 100 av de mänskliga handlarna hos en investeringsbank idag finns det s Kanske åtta av dem kvar. Vad de gör är att driva algos som effektivt efterliknar vad handlarna brukade göra, och de anpassar dem ständigt med dessa algos och övervakar risken för vad som händer på marknaden. Med andra ord, de ikoniska högtestosteronerna Loadsamoney-handlare från det förflutna - Universitetsmästarna tappade av den amerikanska författaren Tom Wolfe i vanfängelsens bonfire - har blivit ousted av quants, de nördiga brainboxesna som designar och driver dataprogrammen. I ett senare efterskrift till sin roman, som skrevs för Daily Beast Tom Wolfe beklagade emasculationen av hans anti-hjältar, omdirigerar dem Eunuchs of the Universe. Closer servrar, rakare kablar. Former som Lenterman s gör sina pengar genom att skrapa en liten vinstmarginal på en otänkbart stor volym snabb eld köp och sälja. Differenta algohandlare använder mycket olika strategier Men de delar alla behovet av att identifiera handelsmöjligheter - flyktiga skillnader mellan det tillgängliga marknadspriset och där datorn anser priset E borde vara - och reagera sedan på dem snabbare än någon annan. Rast till noll. De alternativ som finns tillgängliga i slutet av förra året för alla som vill skicka en elektronisk handelsorder mellan New York och Chicago. Den tid som krävs för en komplett rundtur. Det kallas loppet till noll och det har lett till investeringen av miljarder dollar i snabbare, smartare datorer och i de snabbaste möjliga förbindelserna. På börser över hela världen betalar handlare häftiga Avgifter för att lokalisera sina servrar direkt bredvid utbytena. Och hundratals miljoner har spenderats på att bygga rakare kablar för att raka några fraktioner av en sekund utanför tiden som krävs för att överföra order mellan världens stora handelscentra London, New York, Chicago och Tokyo. Allt detta kan verka lite irrationellt när Storbritanniens och USA: s regeringar kämpar för att skrapa ihop tillräckligt med pengar för att uppgradera den infrastruktur som behövs för att föra människor från en plats till en annan. Flodkraschen. Det finns dock en mörkare Sida till denna rush att datorisera. Till exempel kan olyckor inträffa. I början av augusti höjdes det högteknologiska finansföretaget Knight Capital till en konkursbrott med en algoritm som gick haywire, racking upp mer än 440m av Förluster på bara 45 minuter innan den stängdes av. Kanske var den mest kända missgärden den nu legendariska Flash Crash, klockan 2 45:00 i New York den 6 maj 2010. På några minuter föll New York Stock Exchange och sedan lika plötsligt Återhämtas igen Aktiekurserna i vissa företag, till exempel konsultföretaget Accenture, sjönk till en bråk över noll, medan Apple steg till 100 000. För månader efteråt kunde ingen förklara vad som hade gått fel. Den officiella amerikanska regelutredningen sa att den hade blivit utlöst av En enda order, placerad av en stor institution, med hjälp av en algoritmisk handelsstrategi. Men vad som gjorde saker som var värre var en het potatisffekt bland förvirringen. En efter en försökte robothandlarna att skära och springa och börsens datorer Blev översvämd. Direkt manipulation. De nya algoritmiska handlarena har också anklagats för några ganska gamla skolbrutala beteenden. Eric Hunsader, av det amerikanska dataanalysföretaget Nanex, säger att miniatyrversioner av Flash Crash händer i enskilda bestånd många gånger om dagen och han påstår Att mycket av det är direkt manipulation. Han har producerat kartor som visar det konstiga och underbara beteendet på marknaderna som datorer försöker överträffa varandra genom att snabbt generera och sedan avbryta tusentals beställningar en sekund. Bildtext En Nanex-diagram som illustrerar Google mini - Blixtkrasch den 22 april i år. Vi tillåter människor att snabbare ansluta till plats och ta bort erbjudanden eller buda snabbare än ljusets hastighet kan leverera den informationen till de andra marknadsaktörerna. Och han är inte den enda som berörs av att vissa datoriserade handlare kanske är okej bra. Unfortunately the nature of markets is that there always is potential for abusive activity, and with very, very fast trading, these things can happen very, very fast, says Martin Wheatley, head of the UK s newly created Financial Conduct Authority. Frankly, for the regulator, it creates a problem trying to pick out from the vast amount of data trades that potentially might be abusive. A Dark Magic, presented by BBC Business Editor Robert Peston, will be broadcast on Radio 4 at 0900 on 8 July 2013, and will be available on the BBC iPlayer afterwards. Share this story About sharing.