En studie i kommunikationsprotokoll inom valutahandel

(1)

EXAMENSARBETE, AVANCERAD NIVÅ, 15 HP STOCKHOLM, SVERIGE 2019

En studie i

kommunikationsprotokoll

inom valutahandel

SANDRA STÅL

KTH

SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP

(2)

En studie i

kommunikationsprotokoll inom

valutahandel

SANDRA STÅL

Datum: 14 mars 2019 Uppdragsgivare: SEB

Engelsk titel: A study of communication protocols in foreign exchange

(3)

(4)

Sammanfattning

Ett kommunikationsprotokoll är en specifikation på hur kommunikation mellan två eller fler parter fungerar. Det kan specificera vilken typ av koppling parterna har till varandra, vilken sorts data som kan skickas, hur det datat skall formateras med mera. För att förbättra kommunikationen mellan SEBs interna system undersöker denna rapport vilka alternativ som finns och vad de kan ha för fördelar och nackdelar mot det existerande kommunikationsprotokollet. Intervjuer med de som arbetar i systemen och protokolldokumentation sammanställs för att hitta skillnader mellan protokollen och för att väga alternativen mot varandra. Det protokoll som används idag är enligt intervjuresultaten långsamt och svårt att underhålla. Det protokoll som enligt undersök- ningen har störst fördelar är ProtoBuf. Med binära, tydliga meddelanden kan ProtoBuf lösa många av de problem som finns i den existerande lösningen.

(5)

(6)

Abstract

A communication protocol is a specification of how a communication between two or more parties works. It can specify what type of con- nection the parties share, what data can be sent, how the data should be formatted, and more. To improve the communication between SEBs internal systems, this essay investigates alternative protocols and their pros and cons to the existing communication protocol. Interviews with those working in the systems and protocol documentation are com- piled to find differences between the protocols and to weigh the al- ternatives to each other. The protocol used today is slow and difficult to maintain according to the interview results. The protocol which, according to the essay, has the greatest benefits, is ProtoBuf. With binary, clear messages, ProtoBuf can solve many of the problems that exist in the existing solution.

(7)

Innehåll

1 Introduktion 1

1.1 Bakgrund . . . 1

1.2 Problem . . . 2

1.3 Syfte . . . 2

1.4 Mål . . . 2

1.4.1 Samhällsnytta, etik och hållbarhet . . . 3

1.5 Metoder . . . 3

1.6 Avgränsningar . . . 3

1.7 Disposition . . . 4

2 Bakgrund 5 2.1 Kommunikationsprotokoll . . . 5

2.2 FIX protokollet . . . 7

2.2.1 FIX-standard . . . 7

2.2.2 FIX-specifikation . . . 8

2.2.3 Branschstandard . . . 9

2.2.4 Kommunikationsexempel . . . 9

2.2.5 Binära implementationer . . . 11

3 Metoder 15 3.1 Kartläggning . . . 15

3.1.1 Intervjuer . . . 15

3.1.2 Undersökning av kommunikationer . . . 16

3.2 Alternativa protokoll . . . 17

3.2.1 Protokollval . . . 17

3.2.2 Litteraturstudie . . . 17

3.2.3 Analys . . . 18

(8)

INNEHÅLL

4 Kartläggning 19

4.1 Fördelar och problem med FIX som internt protokoll . . 19

4.2 Förberedande intervju . . . 19

4.3 Undersökning av kommunikationer . . . 22

4.3.1 Strängar: formatering av numeriska värden . . . . 22

5 Alternativa protokoll 25 5.1 FIX med binär kodning . . . 25

5.1.1 Protokollbeskrivning . . . 25

5.1.2 Analys . . . 26

5.2 ProtoBuf . . . 26

5.2.2 Analys . . . 27

5.3 ITCH/OUCH . . . 28

5.3.2 Analys . . . 28

5.4 Sammanfattning av protokoll . . . 29

6 Sammanfattning, slutsatser och fortsatt arbete 31 A Intervjufrågor 35 A.1 Intervju 1 . . . 35

(9)

(10)

Kapitel 1

Introduktion

Allt mer pengar investeras inom finansiell teknologi. Mellan 2013 och 2014 mer än dubblerades värdet av de investeringar som gjordes glo- balt inom området. Under 2015 ökade siffran med ytterligare 75% [13].

Med växande investeringar växer också antalet företag som rör sig i branschen och därmed även behovet av tekniker för att kommunicera med varandra.

1.1 Bakgrund

Ett kommunikationsprotokoll (kort. protokoll) är en specifikation på hur kommunikation mellan två eller fler parter fungerar. Det kan specificera vilken typ av koppling parterna har till varandra, vilken sorts data som kan skickas, hur det datat skall formateras med mera.

Många parter inom valutahandel idag använder sig av ett protokoll som heter Financial Information eXchange (FIX) för att kommunicera både mellan interna system och med varandra. FIX utvecklades till en början för aktiehandel men har blivit ett välanvänt språk inom många delar av den finansiella världen. När nya system utvecklas använder man ofta FIX för att kommunicera med andra, existerande system, detta eftersom protokollet används så frekvent in om branschen och det förväntas att externa kunder ha implementationer av FIX sedan tidigare. Om kunden redan har implementationer av FIX kan dessa relativt enkelt modifieras för att fungera mot de nya systemen.

1

(11)

2 KAPITEL 1. INTRODUKTION

1.2 Problem

På SEBs utvecklingsavdelning för valutahandel funderar man på om de interna systemen använder rätt protokoll för att kommunicera med varandra.

Som tidigare nämnt går det fort att sätta upp en ny FIX-koppling.

Det är dessutom lätt för externa kunder att koppla sig mot nya FIX- kopplingar, detta då kunderna ofta har implementerat FIX-kopplingar tidigare och kan använda dessa för att koppla till nya system. På grund av enkla installationer har SEB därför ofta valt att använda FIX, även till system som inte har några externa kopplingar och därmed inte behöver koppla till några kunder.

Detta betyder att ett protokoll som främst är utvecklat för att föra handel med, även används för interna frågor till data- och beräknings- system.

Denna uppsats undersöker om det finns några alternativ till FIX som kan användas mellan dessa interna system. Det som måste under- sökas för att svara på detta är:

• Vilka problem beror idag på användandet av FIX?

• Vilka andra protokoll skulle kunna ersätta FIX?

• Vad skulle bli bättre/sämre med de nya protokollen jämfört med det som finns idag?

• Vilket av FIX och de alternativa protokollen har störst potential?

1.3 Syfte

Syftet med uppsatsen är att beskriva en process för att kartlägga problem med ett existerande protokoll och med hjälp av den kartläggning- en hitta ett mer passande protokoll.

1.4 Mål

Målet med examensarbetet är att hitta nya lösningar för SEBs interna systemkommunikationer, att underlätta underhållet av dessa och ut- mana sättet dessa protokoll tidigare valts.

(12)

KAPITEL 1. INTRODUKTION 3

1.4.1 Samhällsnytta, etik och hållbarhet

När man talar om hållbarhet brukar man tala om tre delar: social, eko- nomisk och ekologisk hållbarhet. Ett stabilt protokoll innebär mindre underhåll vilket leder till att de anställda kan spendera tid på vidareut- veckling och förbättring av systemet. Det förbättrar företagets produkt och därmed företagets ekonomi. Stadiga protokoll minskar dessutom risken att support-anställda väcks mitt i natten på grund av kommu- nikationsfel, de anställda blir därmed piggare och gladare. På så vis kan arbetet ses som socialt hållbart. Ett projekt som endast undersöker mjukvara kan vara svårt att koppla till ekologisk hållbarhet men, att alla protokoll som undersökt i denna rapport kan implementeras på existerande hårdvara och därmed inte öka den ekologiska påverkan systemen har, betyder att projektet inte har en negativ effekt på miljön.

1.5 Metoder

För att hitta svaren på frågorna som ställdes i avsnitt 1.2 kommer kommunikationen mellan några av SEBs interna system undersökas. Ut- vecklare och personer som underhåller de undersökta systemen kommer intervjuas om problem och möjligheter i systemen. Dessa intervjuer kommer sammanställas för att lägga grunden till en specifikation på vad som krävs av ett protokoll för de aktuella systemen.

Ett antal protokoll kommer att undersökas mot denna specifikation för att avgöra om något av dem skulle passa att ersätta FIX som protokoll mellan de undersökta systemen.

1.6 Avgränsningar

En avgränsning var att endast titta på kommunikationen mellan någ- ra utvalda SEB-system. Alla system har egna utmaningar och möjlig- heter, därför är kartläggningen av dessa för de undersökta system- kopplingarna en viktig del i denna uppsats. För att applicera slutsat- serna från denna uppsats på en annan system-koppling än de som un- dersökts måste läsaren först kartlägga kraven för sina system och läsa undersökningen av protokoll med de kraven i tanke.

Det finns väldigt många protokoll och det är möjligt att specificera ett nytt protokoll för att passa systemens krav perfekt. Den här uppsat-

(13)

4 KAPITEL 1. INTRODUKTION

sen undersöker endast ett litet antal redan existerande protokoll. Pro- cessen att undersöka dessa mot de kartlagda kraven är dock densamma för andra (alternativt nya) protokoll och uppsatsen är därför applicer- bar på andra situationer än den undersökta.

Uppsatsen beskriver hur valet av protokoll vid ett protokollbyte kan utföras, eftersom processen beskrivs kan valet av undersökta protokoll och system-kopplingar ses som exempel.

1.7 Disposition

I kapitel 2 beskrivs grundläggande teori inom uppsatsens område. Här finns information om vad ett kommunikationsprotokoll är, och vilka delar av dessa protokoll som uppsatsen fokuserar på. Kapitlet beskriver också det protokoll som uppsatsen syftar till att hitta alternativ till.

Vidare presenterar kapitel 3 utförande och tanke bakom metoderna under arbetet och kapitel 4 resultatet från undersökningen av det existerande protokollet. Undersökningen av alternativ till det existerande protokollet beskrivs i avsnitt 3.2. Uppsatsen sammanfattas samt presenterar slutsatser och fortsatt arbete i kapitel 6

(14)

Kapitel 2

Bakgrund

I detta kapitel finns förklaringar och information som kan vara till hjälp för en läsare. I avsnitt 2.1 förklaras kort vad ett kommunikationsprotokoll är. I avsnitt 2.2 hittas information om FIX- protokollet.

2.1 Kommunikationsprotokoll

OSI-modellen är en standard för datorkommunikation som delar upp en kommunikation i sju olika lager [16], där varje lager specificerar en del av kommunikationen mellan parterna. OSI-modellens sju lager är det fysiska, datalänks-, nätverks-, transport-, sessions-, presentations- och applikations-lagret [16]. Dessa lager kan delas in i grupper eller paket som i figur 2.1. Grupperna grundas i hur ett meddelande packas när det skickas mellan parterna. Denna uppsats talar i första hand om data-gruppen.

Applikationslagret är det lagret där APIer och andra interaktions- vägar finns. I dessa protokoll specificerar man hur en användare eller externa processer kan använda kommunikationskanalen [15].

Protokoll i presentationslagret talar om hur meddelandet skall representeras i en kommunikation. Till exempel kan det definiera kryp- tering, kompression eller översättning mellan olika teckenkodningar [8].

Protokoll i sessionslagret specificerar hur parterna i en kommunikation pratar med varandra. Sessionslagret tillhandahåller bland annat synkronisering och felhantering [12].

I segment, nätverks, datalänk och det fysiska lagret specificerar protokoll hur datapaketet skickas. Dessa protokoll kommer som sagt inte

5

(15)

6 KAPITEL 2. BAKGRUND

Figur 2.1: De sju lagren i OSI-modellen

(16)

KAPITEL 2. BAKGRUND 7

Figur 2.2: De tre lagerna som beskriver FIX

undersökas i denna uppgift då banken har redan har väldigt specifika krav för dessa.

2.2 FIX protokollet

FIX-protokollet (Financial Information eXchange Protocol) är ett kommunikationsprotokoll som lanserades 1998 för aktiehandel. Sedan dess har FIX växt och breddats till att även innefatta bland annat valutahandel. Idag används FIX av många stora parter i finansbranschen.

FIX är ett strängbaserat protokoll vilket betyder att alla meddelanden skickas som ASCII-text [14]. Hur dessa strängar skall formateras och hur de skall skickas över en kommunikation beskrivs av tre lager.

I figur 2.1 visas dessa lager. FIX-standarden specificerar grundregler- na för protokollet och därmed även hur kommunikation skall fungera. Common practice (inom branschen vedertagna undantag, branschstandard) och företagets FIX-specifikation ’skriver över’ och komplet- terar en del av FIX-standarden för att skapa en helhet.

2.2.1 FIX-standard

FIX underhålls av FIX Trading Community, en organisation vars med- lemmar är stora företag inom finansbranschen [14]. De underhåller och uppdaterar bland annat FIX-standarden som specificerar en mängd fält och meddelanden. En fält-specifikation består av ett taggnummer som

(17)

används för att identifiera fältet, ett namn och en typ. Typen finns med för att all data skickas som strängar, därför behöver mottagaren veta vilken datatyp strängen skall läsas som. En meddelande-specifikation innehåller meddelandetyp, ett namn och ett eller flera fält. Ett meddelande kan alltså ses som en grupp av fält som tillsammans innehåller informationen som krävs för att ställa/svara på en fråga.

Det finns två nivåer av FIX-meddelanden, applikationslagermedde- landen och sessionslagermeddelanden[14]. Meddelanden på sessions- nivå innehåller information om parterna och andra data som används för att specificera kommunikationen. Exempelvis ”Logon” och ”He- artbeat” är sessions-meddelanden. De används för att starta en FIX- session och kontrollera att den fortfarande är igång. Om meddelanden på sessionsnivå skapar och underhåller FIX-sessionen, använder meddelanden på applikationsnivå sessionen. Meddelanden på appli- kationsnivå innehåller den information som systemen vill kommunicera.

2.2.2 FIX-specifikation

FIX är open source vilket betyder att det inte kostar något att använ- da sig av protokollet, det betyder också man vid en implementation får ändra protokollet för att passa situationen bättre. Det går till exempel att lägga egna fält i meddelanden och använda existerande fält på andra sätt än vad de är menade till. Detta betyder att många FIX- implementationer skiljer sig åt och att dokumentationen på alla änd- ringar i FIX måste underhållas så att nya parter som vill ansluta förstår kopplingen. Dokumentationen av dessa förändringar mot FIX standard kommer i denna uppsats benämnas som FIX-specifikationer. Specifi- kationen kan ändras även efter att den initiala installationen är klar.

Till exempel kan den första specifikationen säga att om det inte går att räkna ut ett pris för en fråga, skickas svaret tillbaka tomt. Alla kunder som kopplade sig till FIX-implementationen när den första specifikationen skrevs accepterar detta och låter bli att handla på tomma priser.

Om en ny viktig part ansluter en tid senare och får problem med att läsa ett tomt fält kan FIX-specifikationen ändras till att till exempel inte svara alls då det inte går att beräkna ett pris. På det sättet behöver inte den nya parten läsa ett tomt fält och anslutningen fungerar. Om specifikationen ändras för att passa den nya motparten kan de motparter som redan kommunicerar på FIX-sessionen få problem. En motpart

(18)

kan till exempel förvänta sig ett svar som inte skickas, det kan leda till att motparten tror att FIX-sessionen har gått ner och kopplar ifrån eller att motparten väntar på svaret för länge och låser andra processer hos kunden. Om detta är fallet kan FIX-sessionen ställas in att skicka tomma fält till parten som inte kan hantera saknade meddelanden och att inte svara parten som inte kan hantera tomma fält. Alla dessa änd- ringar måste göras både i en uppdaterad FIX-specifikation och i koden som rör FIX-sessionen.

SEB har bland annat modifierat ett fält som heter SettlDate (likvi- ditetsdatum). Fältet skall enligt standarden hålla det datum då en af- fär genomförs. Datumet skall formateras som YYYMMDD enligt standarden. När SEB skickar ett SettlDate-fält kan det innehålla likviditets- datumet formaterat som YYYMMDD, som förväntat, men det kan även innehålla strängen SPOT. SPOT är inom valutahandel ett sätt att säga

’den förväntade handelsdagen’, och alla motparter förstår vad SPOT är, men endast om de förväntar sig en sträng. Förväntar de sig endast datum är strängen SPOT väldigt svårtolkad. Det är därför viktigt att FIX-specifikationen är uppdaterad och har gått ut till motparter så de vet vad de kan förvänta sig av kommunikationen.

2.2.3 Branschstandard

Ett fåtal saker specificeras varken i FIX-Standarden eller i företagens FIX-Specifikationer. Detta är saker som alla länge gjort på samma sätt och som nu antas fungera på ett visst sätt trots att det inte längre är nå- gon som skriver det i sina specifikationer, dessa modifikationer kallas branschstandard (common practice). När man skriver en specifikation utelämnar man ofta denna del.

2.2.4 Kommunikationsexempel

FIX-protokollet används som tidigare nämnts inom bland annat valutahandel. avsnitt 2.2.4 visar ett exempel på några av meddelandena som skickas mellan två av de undersöka SEB-systemen. Till höger i figuren representeras ett system (system A) som används för att prissätta och göra valutaaffärer. Till vänster i figuren representeras ett system (Front) som används av handlare (en handlare är en person som hand- lar i åt banken med externa kunder) på SEB för att sälja och köpa valutor.

(19)

Figur 2.3: Ett Logon-meddelande

avsnitt 2.2.4 visar ett exempel på hur det första meddelandet (Lo- gon) kan se ut, de andra meddelandena är så stora att de är svåra att överblicka i en figur. Alla meddelanden följer dock samma struktur av Tagg=Data<Tabb>.

För att kunna sälja valutor startar handlaren sin applikation (Front) som i sin tur öppnar en FIX-session mot system A. Denna session initia- liseras med ett Logon-meddelande som innehåller information om hur kommunikationen skall anpassas och vem (i detta fall systemet Front) som vill öppna en session. Ett exempel på hur ett Logon-meddelande kan se ut visas i avsnitt 2.2.4. I den gröna rutan syns meddelandet så som det skickas. För att underlätta läsning av meddelandet har tabellen fyllts med TaggID och data från meddelandet men också taggnamnen.

Ett Logon-meddelande innehåller 10 fält som alla skickas från Front till System A. Logon-meddelandet i exemplet är 61 bytes långt och om System A godkänner inloggningen skickas samma fält tillbaka. Det betyder att med exempelmeddelandet i avsnitt 2.2.4 skickas 122 bytes för en inloggning. I FIX-specifikationen finns det dessutom fler (ej obliga- toriska) fält i ett Logon-meddelande, vilket betyder att meddelandet kan bli större.

Front måste kunna visa priser(marknadsdata) för handlaren för att hen skall kunna sälja, därför skickar Front en marknadsdataförfrågan (Market Data Request-meddelande) till system A. En marknadsdata-

(20)

förfrågan innehåller information om vilket pris som efterfrågas och vissa kunddata som används för beräkningen av priset. I exemplet i figur 2.2.4 får Front flera market-data-meddelanden tillbaka, de är bå- da svar på samma marknadsdataförfrågan. Det går att få strömmande svar på en förfrågan vilket betyder att det skickas ett uppdaterat meddelande då marknadsdatat ändras. FIX är alltså inte ett symmetriskt protokoll. Ett meddelande kan få ett, flera eller till och med inget svar.

Nästa meddelande i figur 2.2.4 är ett quote request-meddelande.

En quote request är en förfrågan om ett förslag på order. Att skicka en quote request innan ett köp krävs inte av FIX-standarden men det är så kallad branschstandard avsnitt 2.2.3. När systemet Front skickar en quote request säger det alltså ungefär ”jag vill göra ett köp, ge mig ett förslag på ett köp du skulle vilja göra”. System A svarar med en quote (orderförslag) som systemet Front sedan använder för att bygga ett order-meddelande (New Order) som det skickar tillbaka till system A. System A behandlar ordern och svarar systemet Front med en

I verkligheten är systemet Front alltså användare av system A och handlaren är användare av systemet Front. Handlaren interagerar med systemet Front med hjälp av ett grafiskt gränssnitt och systemet Front interagerar med system A med hjälp av FIX. Anledningen till att detta förtydligas är för att förklara varför handlarnas behov inte är med och lägger grunden för kravställningen på ett protokoll senare i denna uppsats. De är användare av ett system som i sin tur använder protokollet, de har inte själva någon direkt koppling till kommunikationen på samma sätt som de som utvecklar och underhåller systemen.

2.2.5 Binära implementationer

Som tidigare nämnt är FIX strängbaserat. Det betyder att alla meddelanden skickas som text. FIX går även att implementera tillsammans med andra produkter för att koda meddelanden. På så vis kan man behålla FIX specifikationen, taggstrukturen och på många sätt slippa ändra implementationen men ändå få en kommunikation som är snabbare och meddelanden som är lättare för en dator att läsa. Med hjälp av en binärkodad FIX kan meddelandets värden skickas i ett binärt format istället för att omvandlas till strängar.

Ett binärt meddelande har två stora fördelar mot ett strängbaserat.

Den första fördelen är att binära meddelanden kan koda olika typer av data på olika sätt för att minska storleken på värdet. Till exempel

(21)

Figur 2.4: Exempelmeddelande i FIX

skickas siffran 150 i ett strängbaserat värde som tre tecken: 1, 5, och 0.

Varje tecken representeras av 8 bitar, vilket leder till att strängen ”150”

är 3*8=24 bitar lång. Om 150 skrivs binärt representeras värdet av bi- tarna 10010110, = 8 bitar. Den andra fördelen är att när meddelandet skall hanteras måste ett strängkodat värde översättas till ett typat innan beräkningar och läsningar kan ske. Värdet ”150” måste omvandlas till en numerisk representation innan en numerisk beräkning sker. Den bi- nära representationen av 150 behöver inte omvandlas utan kan direkt användas för att utföra beräkningen.

Många har undersökt FIX prestanda, och många kommer till slutsatsen att FIX inte är så långsamt som det sägs.

Ett exempel på en sådan undersökning är en artikel skriven av Rolf Andersson. Artikeln ställer frågan om FIX är ’snabbt nog’ [2]. I artikeln presenterar han en jämförelse mellan två protokollimplementatio- ner. Det ena använder FIX over Fast, ett sätt att implementera FIX med hjälp av ett annat protokoll (FAST) för att uppnå en binär kommunikation. Den andra använder ITCH, ett protokoll som enligt Andersson är känt för snabb meddelandehantering och högt bandbreddsutnytt- jande. I artikeln hävdar Andersson att FIX visade sig vara snabbare än ITCH vid meddelandehantering och att FIX utnyttjade bandbred- den 50 till 65 procent bättre än ITCH. Andersson drog baserat på detta slutsatsen att FIX, korrekt implementerat, kan vara en snabb och stabil

(22)

lösning som inte skall väljas bort på grund av effektivitetsskäl.

De som undersöker prestanda använder ofta (som Andersson) implementationer där FIX utökats med binära meddelandekodningar för att komprimera meddelandena och därmed förbättra prestandan. Des- sa undersökningar pekar alltså mot att FIX kan fungera i låglatensmil- jöer om det implementeras väl och använder en binär kodning. På FIX- organisationens hemsida står dock att den strängbaserade meddelan- dekodningen är den ursprungliga och mest använda kodningen [2].

Denna uppsats syftar med ”FIX” på strängbaserade implementationer av FIX-protokollet då inget annat specificeras.

(23)

(24)

Kapitel 3

Metoder

För att avgöra om det fanns ett protokoll som lämpade sig bättre än den existerande implementationen kartlades först problemen med det existerande protokollet. Sedan gjordes en studie på andra möjliga lös- ningar. Resultaten från studien jämfördes med resultatet från kartlägg- ningen för att bestämma vilken implementation som skulle vara lämpa sig bäst för de undersökta systemen.

3.1 Kartläggning

För att samla och kartlägga problemen med det existerande protokollet och bedöma alternativa lösningar utfördes intervjuer med de som utvecklar och underhåller system som kommunicerar med hjälp av FIX idag. Svaren från intervjuerna användes som grund för att utföra tek- niska undersökningar av systemen.

3.1.1 Intervjuer

För att få en första bild av hur de som arbetar med FIX på SEB ser pro- tokollets fördelar och nackdelar hölls först korta öppna intervjuer där frågorna var breda och undersökte de tillfrågades helhetsbild av protokollet. Öppna intervjuer hålls för att den intervjuade skall berätta fritt om sina erfarenheter, frågorna ställs på ett sådant vis att den tillfrågade måste utveckla sitt svar och många motfrågor ställs för att få så mycket information som möjligt kring frågorna [5]. En sammanfattning av frågorna från de första öppna intervjuerna finns att läsa i Appendix A.

15

(25)

16 KAPITEL 3. METODER

Alla frågor ställdes dock inte till alla intervjuade och ytterligare följd- frågor ställdes då de intervjuade var otydliga eller fattade sig kort.

De personer som intervjuades var SEB-anställda som dagligen arbetar med att utveckla eller underhålla de system som undersöktes i arbetet. Under intervjun antecknades vad och hur de tillfrågade svara- de på frågorna. Anteckningarna sammanställdes och svaren samman- fattades sedan i en figur och beskrivs i kapitel 4.

Utifrån svaren från den första intervjun planerades en andra intervju där personerna fick ta ställning till det sammanställda materialet och till resultatet från en teknisk undersökning av systemen i fråga.

3.1.2 Undersökning av kommunikationer

För att hitta data för att stödja eller motsäga det utvecklarna och supporten sagt i intervjuerna undersöktes två av systemen som de intervjuade arbetade med. Tre saker vägdes in då system valdes för under- sökningen. Dessa var:

• Alla de intervjuade personerna har daglig kontakt med systemen

• Systemen använder idag endast Fix för att kommunicera

• Systemen har interna kommunikationer. (Det var vid tiden av un- dersökningen inte aktuellt att byta protokoll på externa kommunikationer, därför undersöktes inte dessa)

Vissa svar från intervjuerna var lättade än andra att stödja/mot- säga genom undersökning av systemen. Till exempel kan stabiliteten på systemen mätas men innan implementation av nya protokoll finns inget mätdata att jämföra dessa mätningar med. Då implementation av nya protokoll inte faller inom ramen för arbetet gjordes inga såda- na mätningar på systemet. Att FIX påverkar prestanda gick dock att stödja genom att undersöka de delar av systemen som relaterade till att skapa och läsa meddelanden. Att loggar är läsbara med strängbase- rade protokoll, och att modifierbara protokoll ger utvecklare frihet vid implementation är faktum. Därför undersöktes inte dessa påståenden från de intervjuade i systemen.

(26)

KAPITEL 3. METODER 17

3.2 Alternativa protokoll

Ett antal protokoll valdes ut för att jämföras med de problem och krav som identifieras vid intervjuerna. Litteraturstudier utfördes för att hitta information om protokollens för- och nack-delar. I de fall där protokollen fanns implementerade i banken sedan tidigare gjordes också en liknande genomläsning av kodfilerna som i avsnitt 4.3. Resultaten av dessa undersökningar jämfördes sedan med de från kapitel 4.

3.2.1 Protokollval

Tre protokoll undersöktes som alternativ till den existerande lösning- en:

• FIX med en binär implementation

• ProtoBuf

• ITCH / OUCH

Att undersöka binära implementationer av FIX valdes då undersök- ningar likt de som nämns i avsnitt 2.2.5 pekar mot att en binär implementation presterar bättre än en sådan som banken har idag. Om de problem som finns med den existerande implementationen kan lösas med en binär implementation kan det argumenteras att det är ett mindre arbete än att byta protokoll.

Ett antal FIX-kommunikationer i banken har redan bytts mot Proto- Buf. De system som kommunicerar via ProtoBuf idag verkar lovande och därför undersöktes ProtoBuf som en potentiell lösning på de problem som utvecklare och support har med fix.

ITCH/OUCH är, likt FIX, vanliga protokoll inom valutahandel. IT- CH och OUCH är två protokoll som används tillsammans för att kommunicera med handelssystem. ITCH/OUCH och FIX har många ge- mensamma fördelar, de är båda välkända och tagg-baserade. ITCH och OUCH är till skillnad från den existerande lösningen binära. Eftersom ITCH och OUCH är så vanliga inom branschen valdes dessa för under- sökningen.

3.2.2 Litteraturstudie

För att kunna jämföra de 3 protokollen med den existerande implementationen undersöktes tidigare arbeten och protokollens dokumen-

(27)

18 KAPITEL 3. METODER

tation. De egenskaper som gick att identifiera hos de alternativa protokollen kunde sedan jämföras mot de egenskaper som hittats i det existerande protokollet i senare steg.

3.2.3 Analys

För att kunna dra slutsatser om vilket protokoll som har bäst potential gjordes en analys av de egenskaper protokollen har vid implementation. ITCH/OUCH och FIX binärt undersöktes genom att läsa specifikationer och beskrivningar av protokollen. Banken har, som tidigare nämnt, system som använder ProtoBuf som kommunikationsprotokoll idag. Några av filerna relaterade till att läsa och skriva meddelanden i dessa system undersöktes därför på ett liknande sätt som undersök- ningen i avsnitt 4.3.

(28)

Kapitel 4

Kartläggning

Som det nämns i avsnitt 1.6 kan systems behov skilja sig mycket åt och därmed även kraven på protokollet. För att hitta ett lämpligt protokoll krävs därför en undersökning av kommunikationen mellan de aktuella systemen för att bestämma hur det nya protokollet skall se ut för att passa väl. Detta kapitel kartlägger kraven för de undersökta systemen och problem med den existerande lösningen.

4.1 Fördelar och problem med FIX som internt

protokoll

Idag används FIX-protokollet för många av SEBs interna kommunikationer. Man har valt FIX för att många av systemen har kommunikationer mot externa användare som talar FIX. Det betyder att det ofta finns bibliotek på den sidan för att hantera FIX sedan länge och dessa bibliotek behöver bara läggas till på den interna parten. Att välja ett annat protokoll hade betytt att båda parterna måste konfigureras.

Många gånger där man har valt FIX på grund av en snabb installa- tion har senare fått underhålls- och prestandaproblem och därför be- hövde man fundera på att byta protokoll. Det första steget var att kart- lägga fördelar och nackdelar med det existerande protokollet FIX.

4.2 Förberedande intervju

För att identifiera vad som fungerade bra och dåligt med det gamla protokollet hölls intervjuer med utvecklare och support som dagligen ar-

19

(29)

20 KAPITEL 4. KARTLÄGGNING

Figur 4.1: Svar från intervjuer

betade med system som använde sig av FIX. Tio personer intervjuades varav hälften underhåller de undersökta kommunikationerna (dessa grupperas i detta kapitel som support) och den andra hälften utvecklar systemen/kommunikationerna.

De tillfrågade fick beskriva vilka egenskaper hos FIX de tyckte un- derlättade respektive försvårade deras dagliga arbete. En sammanfattning av svaren på dessa frågor följer i text och återfinns även i avsnitt 4.2.

Många av de sakerna utvecklarna tyckte om med FIX grundas i att protokollet har funnits länge och används flitigt i branschen. Det är till exempel vanligt för en utvecklare som tidigare jobbat inom finans att redan ha en förståelse för protokollet och dess implementationer. Det betyder att upplärningstiden för dessa utvecklare kan kortas om systemen kommunicerar med FIX. En annan sak som följer med att FIX funnits med länge och att det är open source är att många mjukvaror som underlättar installationen och underhållet redan byggts och att en utvecklare därför kan få mycket stöd från existerande program. Alla dessa externa mjukvaror och faktumet att protokollet utvecklats under de senaste 20 åren har resulterat i en stadig, välkänd protokoll-standard.

Tack vare att protokollet är välkänt, att många utvecklare arbetat med det och att mycket mjukvara finns tillgänglig går det relativt fort att

(30)

KAPITEL 4. KARTLÄGGNING 21

Figur 4.2: Flöde vid hantering av SettlDate

installera en enkel FIX-kommunikation och resultatet blir ofta pålitligt.

Som nämnt i avsnitt 2.2.2 kan företaget modifiera FIX-protokollet.

Som utvecklare kan man därför till exempel bestämma att ett fält som enligt standarden innehåller datum även skall kunna innehålla sträng- ar. Detta kan underlätta mycket för en utvecklare som då kanske slip- per räkna, typa, eller modifiera datat innan det skickas vidare. Anta att någon använder ett program för att handla en SPOT (se avsnitt 2.2.2).

Programmet som använts behöver i sin tur fråga ett annat system om priset. Enligt FIX-standard skall fältet ”SettlDate” fyllas med det datum då köpet sker, då SPOT inte är ett datum måste programmet först räkna ut SPOT-datumet för att skicka det i formatet YYYYMMDD. När prissystemet får meddelandet måste YYYYMMDD tolkas på nytt för att systemet skall förstå att det är just SPOT som skall prissättas och sedan kan priset skickas tillbaka, med samma omvandling av datumet igen. En av SEBs modifikationer tillåter att fältet ”SettlDate” innehål- ler antingen ett datum eller strängen SPOT, med den modifikationen skickar man helt enkelt ”SPOT” i fältet. Som figur 4.2 visar, resulterar en förändring av specifikationen i detta fall att antalet beräkningar vid meddelandets skrivning och uppläsning minskar och att föränd- ringen därmed resulterar i en förbättring ur utvecklarnas prestanda- perspektiv.

De saker som utvecklarna tyckte sämre om med FIX grundas alla i att protokollet är strängbaserat. Strängoperationerna som krävs för att läsa in data till rätt typer och strukturer tar enligt utvecklarna myc-

(31)

22 KAPITEL 4. KARTLÄGGNING

ket tid vid läsningen av FIX-meddelanden och de verkar enade om att ett protokoll som skickar datat binärt vore att föredra. Det skulle dessutom, om fälten/liknande typades, eliminera situationer som den i SettlDate.

De intervjuade som grupperas som support i denna uppsats är de människor som underhåller systemen som använder FIX. De har bland annat hand om att uppdatera FIX-specifikationerna och ansvarar för att kommunikationerna inte går ner. De håller med utvecklarna om att en stor fördel är hur stabilt och välbeprövat FIX är. Det underlättar un- derhållet av kommunikationer om protokollet som används finslipats så länge som FIX har. Om något trots detta går fel med kommunikationerna är det dock ur ett supportsyfte positivt att meddelandena är strängbaserade, det är betydligt enklare att se ett fel i ett strängbaserat meddelande än i ett binärt. Här kommer alltså inte support och utvecklare överens. Supporten vill ha läsbara meddelanden i sina loggar och utvecklarna vill ha snabba binära meddelanden.

En annan sak utvecklarna och supporten inte kommer överens om är huruvida modifierbarheten i FIX-standarden är något positivt. Ut- vecklarna är glada över den ökade möjligheten att skräddarsy implementationen men supporten påverkas negativt då de ständigt måste hålla specifikationer uppdaterade.

4.3 Undersökning av kommunikationer

För att hitta data för att styrka eller motsäga utvecklarnas och suppor- tens åsikter gjordes undersökningar på system. Två system valdes ut för undersökning. Det som undersöktes var hur systemens meddelandehantering påverkades av att systemet kommunicerade med strängar.

Detta genom att filerna som hanterade strängbaserade meddelanden genomsöktes efter kod som skulle förändras vid ett byte till ett binärt protokoll.

4.3.1 Strängar: formatering av numeriska värden

Båda systemen arbetade med numeriska värden och dessa måste formateras om för att kunna skickas som strängar. Att formatera om numeriska värden till strängar är inte i sig tungt eller långsamt men det kan medföra vissa problem. Ett exempel är att det är lättare att jämföra

(32)

KAPITEL 4. KARTLÄGGNING 23

numeriska värden med varandra än att jämföra strängar med varandra eller strängar med numeriska värden. Det numeriska värdet 0,150 är detsamma som 0,15 men strängarna ”0.150” och ”0.15” är inte ekvi- valenta. Det är därför viktigt att vara tydlig med hur numeriska vär- den representeras i strängar så den som tar emot meddelandet vet hur strängen skall. FIX-standarden talar om vissa regler för hur numeriska värden skall representeras, till exempel att decimaler skall separe- ras från heltal med en punkt [3]. Som avsnitt 2.2 beskrev kan dock en utvecklare frångå denna standard och även om standarden följs talar den till exempel inte om hur avrundningar skall göras. FIX-standarden tillåter också både ledande och efterföljande nollor, detta betyder att

”000.1500”, ”00.150” och ”0.15” alla är tillåtna representationer av 0,15.

Detta kan som tidigare nämnt orsaka ekvivalensfel. Systemen hade felhantering i det fall en motpart formaterat ett meddelande felaktigt. Fel- hanteringen resulterade dock i att oväntade formateringar tog lång tid att läsa och kunde inte hantera alla typer av felformaterade meddelanden.

(33)

(34)

Kapitel 5

Alternativa protokoll

För att identifiera lösningar på problemen som finns med det existerande protokollet och för att hitta ett bättre lämpat protokoll undersöktes ett antal alternativ. Specifikationer och tidigare arbeten i området stu- derades för att sammanfatta de undersökta protokollens egenskaper, fördelar och nackdelar. Ett av protokollen som undersöktes, ProtoBuf, fanns även implementerat i ett av systemen som använts för att krav- ställa ett alternativt protokoll. Denna implementation genomsöktes på samma sätt som i avsnitt 4.3

5.1 FIX med binär kodning

Som tidigare nämndes i avsnitt 2.2.5 kan FIX-protokollet implementeras med stöd av andra protokoll för att kommunicera binärt. Detta innebär att man kan behålla många av fördelarna med FIX utan problemen som följer en textbaserad kommunikation.

5.1.1 Protokollbeskrivning

Med hjälp av FAST (se avsnitt 2.2.5), SBE (simple binary encoding) eller ett liknande meddelande-kodningsprotokoll kan system kommunicera med FIX-meddelanden som kodats binärt istället för text-baserat. Detta gör liten påverkan på specifikationer och meddelandestrukturen (tag- garna) behöver inte förändras. Som nämnt i avsnitt 2.2.5 kan binära meddelanden kan dock förbättra prestandan jämfört med en sträng- baserad lösning. Vissa binärkodningar ändrar inte bara hur värden i meddelandet representeras, till exempel kan en FIX over Fast imple-

25

(35)

26 KAPITEL 5. ALTERNATIVA PROTOKOLL

mentation använda värdets placering i meddelandet för att identifiera taggar istället för taggnummer för att ytterligare spara meddelande- längd[11]. Meddelandet kan alltså ändra utformning på fler sätt än att endast värden binärkodas, FIX-standarden skall dock följas som med strängbaserad FIX.

5.1.2 Analys

Binär FIX hanterar ett meddelande på samma sätt som strängbaserad FIX fram tills det är dags att skicka meddelandet. Då strängbaserad FIX översätter numeriska värden och datum till text för att skapa en med- delandesträng bygger binär FIX en bytearray eller liknande struktur där typer inte behöver översättas. Meddelandet kan skickas på samma sätt för båda FIX-typerna, den stora skillnaden mellan binär och sträng- baserad FIX är hur meddelandet ser ut. Att meddelandet definieras av FIXspecifikationen som ett vanligt FIXmeddelande betyder att de för- och nackdelar som följer med den lösa specifikationen och bransch- standarden att ändra och uppdatera FIXstandard även finns med en binär FIX implementation. Den fördelen en binär FIX har över sträng- baserad FIX är att läsandet, skrivandet och överföringen av meddelandet går enklare och fortare.

5.2 ProtoBuf

Googles protokoll ProtoBuf bygger på att utvecklaren beskriver objektmallar som kan skickas över en kommunikation. Enligt dessa objektmallar formateras det data som behöver kommuniceras. ProtoBuf till- handahåller utifrån dessa objekt-mallar metoder som utvecklaren kan utnyttja för att skriva och läsa meddelanden.[7]

5.2.1 Protokollbeskrivning

Flera objektmallar kan användas på samma ProtoBuf-kommunikation och eftersom utvecklaren själv definierar mallar kan FIX-meddelanden skickas som ProtoBuf-meddelanden. Det betyder att en kommunikation teoretiskt sett kan hantera binär data i de situationer då kommunikationen måste vara snabb och effektiv och skicka vanliga textkoda- de FIX-meddelanden då det lämpar sig. Utvecklaren kan också definiera en FIX-liknande standard med samma taggar och fält som den

(36)

KAPITEL 5. ALTERNATIVA PROTOKOLL 27

vanliga FIX-standarden men med binära numeriska fält för att minska storleken på meddelandet och spara tid vid skapande och läsande av meddelandet. Enligt FIX Trading själva är det senare ett vanligt till- vägagångssätt för företags interna kommunikationer [4]. ProtoBuf kan alltså användas tillsammans med FIX för att förbättra prestandan genom att binärkoda meddelanden och för att bygga en helt ny lösning.

5.2.2 Analys

Ett av de system som undersöktes under arbetet implementerade Pro- toBuf. De filer som relaterade till meddelanden genomsöktes efter lik- heter och skillnader mot de som undersöktes i avsnitt 4.3. Vid implementation av ProtoBuf måste utvecklaren först specificera hur ett meddelande skall utformas. Detta gör utvecklaren genom att definiera ett eller flera meddelandeobjekt (strukturellt lika Javaklasser) med variabler som motsvarar de fält som skall kunna skickas i meddelandet.

I systemet som undersöktes skulle ProtoBuffen ersätta en intern FIX- implementation. Det ledde till att meddelandeobjektens variabler var väldigt lika de fält som skickas över FIX. Se till exempel meddelandet i avsnitt 2.2.4, i ProtoBuf kan meddelandeobjektet se ut ungefär så här:

message Logon {

required String senderCompID = 1;

required DateTime sendingTime = 1;

required String targetCompID = 1;

}

När ett meddelande behöver skickas kommer meddelande-objektet fyllas med värden och serialiseras till en bytearray som kan skickas över kommunikationen. Mottagaren som vet hur objektet ska se ut kan då avserialisera meddelandet och använda det som ett vanligt objekt. Det- ta betyder inte bara att meddelandet skickas binärt utan även att det går att läsa utan sträng-bearbetning eftersom meddelandet behåller värde- na typade. Att objektet definierar vilka variabler som finns, vilka som kan upprepas och vilket serialiserat data som hör till vilken variabel gör att man inte behöver beräkna lika många värde- och meddelande längder. Att sådan information kan uteslutas minskar meddelande- storleken och därmed även bandbreddsanvändningen.

(37)

28 KAPITEL 5. ALTERNATIVA PROTOKOLL

5.3 ITCH/OUCH

ITCH/OUCH är två olika protokoll som utvecklats av Nasdaq för att användas tillsammans vid kommunikation med handelssystem. Enkelt förklarat används ITCH för kommunicera marknadsdata och OUCH för att handla[9][10].

5.3.1 Protokollbeskrivning

OUCH består av ett antal meddelanden för att lägga och modifiera ord- rar[10]. ITCH-meddelanden är utformade för att skicka marknadsdata så som vilka ordar som lagts, avbrutits och genomförts på marknaden, prisinformation eller statistik[9]. Eftersom OUCH inte kommunicerar marknadsdata behövs nästan alltid ITCH för att systemet som skall handla med hjälp av OUCH behöver kunskap om marknaden. Däre- mot kan ett system vilja ha information om marknaden utan att be- höva handla, så att implementera endast ITCH är inte ovanligt. Båda protokollen använder förutbestämda meddelanden med förutbestäm- da taggar som fylls i då ett meddelande behöver skickas. Precis som med FIX är det vanligt att företag förändrar standarden (med hjälp av specifikationer) för att passa den aktuella situationen bättre.

5.3.2 Analys

Protokollen är, som FIX, taggbaserade och skickade tidigare all information som ASCII-strängar. Sedan version 4.0 har dock båda protokollen uppdaterats till att binärkoda numeriska fält och att använda dessa numeriska fält för att representera priser och andra numeriska värden. Detta skall enligt en artikel från GlobeNewswire resulte- ra i högre genomströmning och underlätta uppdatering och anpass- ning av protokollen [6]. Enligt Irene Aldridges bok om algoritmer inom högfrekvens-handel är ITCH och OUCH effektivare än FIX. Detta då ITCH och OUCH är binärkodade och har fasta meddelande-längder.

Aldridge påstår att meddelanden som skickas med fasta längder kan överföras snabbare. De binära meddelandena är också enkla för en dator att läsa och skriva och minskar därför förseningar ytterligare. [1].

(38)

KAPITEL 5. ALTERNATIVA PROTOKOLL 29

5.4 Sammanfattning av protokoll

Påståendet i Irene Aldriges bok (se avsnitt 5.3.1) att ITCH och OUCH skulle vara fördelaktiga över FIX och Rolf Anderssons artikel som visar att FIX är snabbare (se avsnitt 2.2.5) motsäger varandra. Att de två undersökningarna kommer till så olika slutsatser beror troligt på att Andersson gjorde sin undersökning 2010, innan ITCH/OUCH över- gått till en binär kodning. Andersson använde alltså en strängbaserad ITCH implementation och en binär version av FIX, Aldrige talar om binär ITCH men strängbaserad FIX. Detta betyder att de två studierna hade mycket olika förutsättningar. Den slutsats vi kan dra från dessa två vitt skilda resultat är dock densamma, ett binärt, väl implementerat protokoll medför stora fördelar mot ett textbaserat.

Slutsatsen att binära protokoll är bättre än strängbaserade talar till att alla de alternativa protokollen vore bättre än det existerande FIX- protokollet. FIX-binär och ITCH/OUCH har samma problem som textbaserad FIX när det gäller meddelandestruktur. Nämligen att det finns en standard för meddelanden som skrivs över av företagens specifikationer och branschstandard. Meddelanden följer oftast bara standarden ungefärligt och anpassas med andra specifikationer. Detta att jämföra med ProtoBuf där det inte finns någon global standard. Ett ProtoBuf meddelande specificeras av ett enda meddelandeobjekt och följer sin specifikation exakt. Det resulterar i många fler specifikationer (en per meddelande), men varje meddelande följer en specifikation.

Att ProtoBuf har möjligheten att skapa helt nya meddelanden ger också en fördel mot de andra protokollen där man ofta utökar existerande meddelanden med inte skapar nya. Med ProtoBuf kan till exempel flera logon meddelanden specificeras så att interna och externa system loggar in med två olika meddelanden. Eller så kan svaret på en prisfråga innehålla fler parametrar om det är ett testsystem som frågar för att underlätta testning. Att kunna specificera fler meddelanden än ett som fyller samma funktion kan användas till mycket, men det skall också vägas in att alla nya meddelanden skall utvecklas och specificeras, risken finns att antalet meddelanden och specifikationer blir svåra att underhålla.

(39)

(40)

Kapitel 6

Sammanfattning, slutsatser och

fortsatt arbete

Syftet med uppsatsen var att undersöka om det fanns några alternativ till det protokoll som användes för interna kommunikationer. För att hitta vilka problem och fördelar den existerande lösningen hade intervjuades de som arbetade med att utveckla och underhålla kommuni- kationsdelarna i två olika system. Resultatet från dessa intervjuer och en undersökning av koden som skrev och läste meddelanden i systemen användes som grund för att beskriva hur ett protokoll behövde prestera för att förbättra kommunikationen med systemen.

Två av de fyra frågor som ställdes i denna rapport kunde besvaras efter intervjuerna. Vad orsakar det existerade protokollet för problem idag och vad kan förbättras/ riskerar att orsakas av ett annat alternativt protokoll. Det existerande protokollet var stabilt och enkelt att förändra för att passa nya situationer. Det var dock enligt utvecklarna långsamt och mängden ändringar och förbättringar av standard orsakade problem för de som underhöll systemen. Ett nytt protokoll skulle behöva uppnå samma stabilitet och flexibilitet utan att försvåra underhåll.

Två frågor återstod efter dessa intervjuer, vilka alternativ som fanns till det existerande protokoll och vilket, om något, av dessa alternativ som har potential över det existerande. För att besvara dessa under- söktes några protokoll som använts i liknande system. Tre protokoll undersöktes som alternativ till den existerande lösningen. Protokollbe- skrivningar och dokumentation sammanställdes för att skapa en över- blick över protokollen. Sammanställningen jämfördes mot de krav som ställts under tidigare intervjuer och undersökningsfas.

31

(41)

32 KAPITEL 6. SAMMANFATTNING, SLUTSATSER OCH FORTSATT ARBETE

Alla alternativa lösningar som undersöktes visade potential att för- bättra kommunikationen i systemen. En lösning stack dock ut, Pro- toBuf. Med hjälp av ProtoBuf kan systemen använda den existerande meddelandestrukturen där det passar och nya förbättrade meddelanden mot de system som kräver och kan stödja detta. På det sättet behö- ver inte alla specifikationer skrivas om och de system som inte behöver prestandaförbättringen behöver inte förändra lika mycket som om hela protokollet bytts. Samtidigt kan man förbättra den interna kommunikationen ännu mer genom att skapa nya, mer skräddarsydda meddelanden för viktiga flöden.

Slutsatsen av detta arbete kan sammanfattas i att det finns bättre lösningar än FIX och att man genom att byta protokoll skulle kunna underlätta utveckling och support. ProtoBuf visar potential att fungera bättre än det existerande protokollet men för att bestämma om ett byte av protokoll är lönsamt skulle ytterligare undersökning krävas.

Att implementera en del av kommunikationen med hjälp av ProtoBuf och undersöka hur den delen presterar kan hjälpa till vid uppskatt- ning av hur mycket tid och arbete som krävs för att helt ersätta FIX.

Skall externa kommunikationer bytas måste också alla externa parter godkänna ändringen och själva göra en del arbete.

(42)

Litteratur

[1] Irene Aldrige. High-Frequency Trading: A Practical Guide to Algo- rithmic Strategies and Trading Systems. John Wiley & Sons, 2013.

[2] Rolf Andersson. Low Latency Market Data: Are Proprietary Protocols Needed?http://fixglobal.com/home/low-latency-market-data- are - proprietary - protocols - needed/. Accessed on 2018-05-17.

Juni 2010.

[3] FIX Trading Community. FIX Family of Standards. https://www.

fixtrading.org/standards. Accessed on 2018-05-18.

[4] FIX Trading Community. Google Protocol Buffers (GPB). https://

www.fixtrading.org/standards/gpb/. Accessed on 2018-07-31.

[5] Monica Dalen. Intervju som metod. Gleerups Utbildning AB, 2015.

[6] GlobeNewswire. Migration to Binary versions of ITCH and OUCH.

https://globenewswire.com/news-release/2015/04/29/729733/

0 / en / IT - INET - Migration - to - Binary - versions - of - ITCH - and - OUCH-24-15.html. Accessed on 2018-07-27. April 2015.

[7] Google. Developer Guide.https://developers.google.com/protocol- buffers/docs/overview. Accessed on 2018-07-31.

[8] Michael Gregg m. fl. Hack the Stack. Elsevier, 2006.

[9] NASDAQ. Nasdaq TotalView-ITCH 5.0.http://www.nasdaqtrader.

com / content / technicalsupport / specifications / dataproducts / NQTVITCHspecification.pdf. Accessed on 2018-07-26.

[10] NASDAQ. O*U*C*H Version 4.2.http://www.nasdaqtrader.com/

content/technicalsupport/specifications/TradingProducts/OUCH4.

2.pdf. Accessed on 2018-07-26.

[11] OnixS. FIX FAST (FIX Adapted for Streaming) Decoder and Encoder.

https://www.onixs.biz/fix-fast-decoder-encoder.html. Acces- sed on 2018-10-04.

33

(43)

34 LITTERATUR

[12] Dimitrios Serpanos och Tilman Wolf. Architecture of Network Systems.

Elsevier, 2011.

[13] Julian Skan, James Dickerson och Luca Gagliard. Fintech and the evolving landscape.https://www.accenture.com/t20161011T031409Z_

_w__/us- en/_acnmedia/PDF- 15/Accenture- Fintech- Evolving- Landscape.pdf. Accessed on 2018-02-14. 2016.

[14] A V Stokes. Communications Standards. Elsevier, 1986.

[15] Michael Tooley och Steve Winder. Newnes Data Communications Pocket Book. Newnes, 2002.

[16] International Telecommunication Union. Information technology - open systems interconnecion - basic reference model: the basic model.

1994.

(44)

Bilaga A

Intervjufrågor

A.1 Intervju 1

• På vilka sätt fungerar kommunikationen mellan system A och system B bra?

• Vad är det med protokollet som fungerar bra för dig idag?

• Finns det några problem med kommunikationen idag?

• Finns det något som tar mycket tid på grund av hur kommunikationen är uppsatt?

35

(45)

TRITA -EECS-EX-2019:58

www.kth.se