Sj ¨alvst ¨andigt arbete i informationsteknologi 24 juni 2020
Ett digitalt ¨ovningsverktyg f ¨or simulering av finanskriser
Gustav B ¨orestam Gustav Eriksson Patrik Johansson Joakim Michalak
Civilingenj ¨orsprogrammet i informationsteknologi
Institutionen f ¨or informationsteknologi
Bes ¨oksadress:
ITC, Polacksbacken L ¨agerhyddsv ¨agen 2
Postadress:
Box 337 751 05 Uppsala
Hemsida:
https://www.it.uu.se
Abstract
Ett digitalt ¨ ovningsverktyg f ¨ or simulering av finanskriser
Gustav B ¨orestam Gustav Eriksson Patrik Johansson Joakim Michalak
Financial institutions around the world need to be well prepared for un- avoidable financial crises to minimize the negative effects which may follow. In the finance sector today, employees are trained in crisis ex- ercises to prepare themselves, but the amount of preparation required to deliver a good exercise is significant and costly. This might discourage institutions from running these exercises as often as they are desired, and the availability is limited.
In this project, an online platform for financial crisis exercises has been implemented, with the objective to simplify the preparation and execu- tion of exercises and make them available for a larger audience.
The result is a web application with a financial crisis scenario where several users can participate at the same time in the same or in different exercises. The participants roleplay as financial institutions and per- form, in a simulated financial crisis, the actions those institutions could perform in a real life scenario. The application will not replace the more elaborate exercises held by organizations such as the World Bank, but serve as a complement where time and resources are limited, for in- stance in universities as part of the course curriculum.
Extern handledare: Mikael Wendschlag, Uppsala Universitet Handledare: Bj¨orn Victor, Tina Vrieler och Mats Daniels Examinator: Bj¨orn Victor
Sammanfattning
Finansiella institutioner i hela v¨arlden beh¨over vara v¨al f¨orberedda p˚a finansiella kri- ser f¨or att minimera de negativa effekter som kan komma till f¨oljd av en finanskris.
Idag ¨ovar och utbildas anst¨allda inom finanssektorn p˚a finanskrishantering. Problemet
¨ar att det kr¨avs mycket f¨orarbete f¨or att tillhandah˚alla en bra finanskris¨ovning vilket g¨or dem dyra. Detta kan leda till att vissa institutioner avskr¨acks fr˚an att genomf¨ora dessa ¨ovningar eller att de bara blir tillg¨angliga f¨or en begr¨ansad grupp. I detta projekt har en onlineplattform f¨or finanskris¨ovningar utformats med m˚alet att f¨orenkla finans- kris¨ovningar och ¨oppna upp dem f¨or en bredare m˚algrupp.
Resultatet ¨ar en webbapplikation med ett ¨ovningsscenario, d¨ar flera anv¨andare kan delta samtidigt i samma eller olika ¨ovningar. Anv¨andarna rollspelar som finansiella institu- tioner och genomf¨or, i en simulerad finanskris, de handlingar dessa institutioner skulle kunna utf¨ora i en verklig situation. Applikationen har inte f¨or avsikt att ers¨atta de mer avancerade ¨ovningar som erbjuds av akt¨orer som V¨arldsbanken, men kan fungera som ett komplement d˚a tid och resurser ¨ar begr¨ansade, exempelvis p˚a universitet som en del av kursplanen.
Inneh ˚all
1 Introduktion 1
2 Bakgrund 2
2.1 Vad ¨ar en finanskris? . . . 3
2.2 Hur f¨orebyggs och hanteras finanskriser? . . . 4
2.3 Finanskris¨ovningar . . . 4
2.4 Hantering av kriser i virtuell milj¨o . . . 5
2.5 Intressent . . . 5
3 Syfte, m˚al, och motivation 6 3.1 H˚allbarhetsm˚al . . . 7
3.2 Etiska fr˚agor . . . 7
3.3 Avgr¨ansningar . . . 8
4 Relaterat arbete 8 4.1 V¨arldsbankens finanskrissimuleringar . . . 9
4.2 Toronto Center . . . 9
4.3 Doom (1993) . . . 10
4.4 Old School RuneScape (OSRS) . . . 10
5 Metod 11 5.1 Frontend . . . 11
5.1.1 TypeScript . . . 11
5.2 Backend . . . 12
5.3 Datalagring . . . 13
5.4 S¨aker datalagring . . . 14
6 Ovningen ur anv¨andarens perspektiv¨ 15 7 Systemstruktur 16 7.1 Spelklient . . . 18
7.2 Server . . . 19
7.3 Databas . . . 19
8 Krav och utv¨arderingsmetoder 19 8.1 Kompatibilitet med webbl¨asare . . . 19
8.2 Skydd mot SQL-injektion . . . 20
8.3 Anv¨andbarhet . . . 22
8.4 Intressentens utv¨ardering . . . 22
9 Ovningens gr¨anssnitt¨ 23 10 Hantering av scenarion 29 10.1 V¨arden, drag, och effekter . . . 29
10.2 Beroende v¨arden . . . 31
10.3 Att anpassa ett scenario . . . 32
10.4 Ber¨akning av drag med ber¨akningsenheten . . . 32
10.5 Nyheter och h¨andelser . . . 32
11 Meddelandefunktion f¨or kommunikation 33 12 Utv¨arderingsresultat 34 12.1 Kompatibilitet med webbl¨asare . . . 34
12.2 Skydd mot SQL-injektion . . . 34 12.3 Anv¨andbarhet . . . 34 12.4 Intressentens utv¨ardering . . . 35
13 Resultat och diskussion 35
14 Slutsatser 36
15 Framtida arbete 37
1 Introduktion
1 Introduktion
Finanskrisen 2008 var den st¨orsta ekonomiska krisen sedan den stora depressionen 1929 [DM13]. Finanskriser kan uppst˚a snabbt och ov¨antat, samtidigt som de kan orsaka stora negativa f¨oljder f¨or samh¨allet. Vi har skapat grunden f¨or en onlineplattform d¨ar anv¨andare kan ¨ova p˚a flera olika finanskrisscenarion. M˚alet ¨ar att plattformen ska g¨ora finanskris¨ovningar mer tillg¨angliga ¨an dagens alternativ.
Finanskris¨ovningar organiseras och genomf¨ors idag av flera akt¨orer, b˚ade privata och statliga, bland annat V¨arldsbanken [ACLT16] och Toronto Center [Tor20]. M˚alet med dessa ¨ovningar ¨ar att ge deltagare en m¨ojlighet att ¨ova p˚a kommunikation och besluts- fattande under tidspress. Deltagarna i ¨ovningarna best˚ar av anst¨allda fr˚an centralbanker, finansdepartement, finansiella tillsynsmyndigheter samt b˚ade stora och sm˚a banker. F¨or att g¨ora ¨ovningarna s˚a realistiska och relevanta som m¨ojligt skr¨addarsys ¨ovningarna spe- cifikt f¨or de deltagande finansiella institutionerna. V¨arldsbankens ¨ovning tar tv˚a dagar att genomf¨ora. Under f¨orsta dagen g¨ors f¨orst en genomg˚ang av hur ¨ovningen g˚ar till och sedan anv¨ands resten av dagen f¨or att genomf¨ora finanskris¨ovningen. Dag tv˚a samlas deltagarna igen f¨or att utv¨ardera besluten som togs och diskutera huruvida de anser att b¨attre ˚atg¨arder hade kunnat anv¨andas. Under V¨arldsbankens ¨ovning sitter alla deltagare i samma hus, men de olika deltagande institutionerna sitter i separata rum [The10].
Under ¨ovningen f˚ar institutionens deltagande personal information om sina respek- tive balansr¨akningar och andra ekonomiska indikatorer, som inflation, r¨antel¨age och v¨axelkurs. Baserat p˚a denna information ska deltagarna f¨ors¨oka h¨ava finanskrisen, sam- tidigt som de ska uppn˚a sina individuella m˚al. Centralbanken ska exempelvis f¨ors¨oka h˚alla inflationen till 2% och privatbankerna ska f¨ors¨oka g˚a med vinst. F¨or att uppn˚a sina m˚al har de tillg˚ang till samma ˚atg¨arder i ¨ovningen som de har i verkligheten. Exempel- vis kan centralbanken justera styrr¨antan och bankerna kan l˚ana pengar av centralbanken.
Institutionerna kan ocks˚a kommunicera med varandra f¨or att exempelvis f˚a information de beh¨over eller be om hj¨alp [The10].
Intressenten (l¨as mer om Mikael Wendschlag i avsnitt 2.5) ¨onskar att plattformen ska fungera f¨or alla typer av institutioner, men att m˚algruppen initialt ¨ar begr¨ansad till centralbanker, finansinspektioner, och banker samt l¨aros¨aten som utbildar studenter vil- ka senare kan komma att arbeta p˚a n˚agot av dessa institutioner.
2 Bakgrund
Det finns tre specifika omr˚aden som projektet adresserat f¨or att g¨ora finanskris¨ovningar mer tillg¨angliga. Det f¨orsta och enklaste problemet var att deltagarna inte ska beh¨ova re- sa till en adress f¨or att kunna ¨ova tillsammans. Eftersom plattformen ¨ar online beh¨over inte deltagarna befinna sig p˚a samma plats. ¨Ovningar kan genomf¨oras oberoende av deltagarnas ort f¨orutsatt att de har en internetuppkoppling. Enligt Wendschlag best˚ar det andra problemet med existerande ¨ovningar av att det l¨aggs mycket tid p˚a att f¨orklara hur
¨ovningen g˚ar till. Med v˚ar plattform kan deltagarna separat l¨asa p˚a hur ¨ovningen g˚ar till, eller om ¨ovningarna h˚alls tillr¨ackligt ofta kan de komma ih˚ag hur det g˚ar till. Det tredje problemet ¨ar att n¨ar b˚ade V¨arldsbanken och Toronto Center anordnar en ¨ovning har var- je deltagande institution funktion¨arer till sin hj¨alp fr˚an anordnaren. Dessa funktion¨arer m˚aste avs¨atta tid f¨or ¨ovningen vilket g¨or det ¨annu sv˚arare att schemal¨agga. ¨Aven f¨or att f¨orbereda ett realistiskt ¨ovningsscenario i detta projekt beh¨ovs det mycket tid, men alla scenarion som utvecklas kan ˚ateranv¨andas och det kr¨avs ingen handledande perso- nal f¨or att genomf¨ora ¨ovningen. Detta g¨or att priset f¨or en ¨ovning kan s¨attas l¨agre ¨an traditionella ¨ovningar vilket betyder att en bredare m˚algrupp kan anv¨anda dem.
En v¨aldigt stor del av en traditionell ¨ovning best˚ar av utv¨arderingsmomentet. Detta g¨or att det troligen ocks˚a kommer vara en stor del av en ¨ovning som genomf¨ors p˚a v˚ar platt- form. N˚agot verktyg f¨or att utv¨ardera en ¨ovning finns d¨aremot ¨annu inte implementerat i den l¨osning som projektet tagit fram. Det saknas ¨aven ett ekonomiskt komplext och realistiskt ¨ovningsscenario. Det scenario som ¨ar implementerat ¨ar avsett att testa platt- formens funktionalitet, men ¨ar inte tillr¨ackligt f¨or en riktig ¨ovning. Detta g¨or att platt- formen inte n˚ar hela v¨agen f¨or att m¨ota m˚algruppens behov vid projektets slut. D¨aremot har vi visat att det ¨ar m¨ojligt att bygga en digitaliserad ¨ovning f¨or att simulera och ¨ova sig p˚a att hantera framtida finanskriser.
2 Bakgrund
I december 2019 identifierades SARS-CoV-2 som ett nytt coronavirus i staden Wuhan i Kina, vilket senare spreds i den utstr¨ackning att det resulterade i en fullskalig pandemi [Duc20]. F¨or att begr¨ansa virusets framfart och dess belastning p˚a sjukv˚arden inf¨orde flera l¨ander n˚agon form av karant¨an, antingen hela eller delar av landet. P˚a kort sikt led- de denna karant¨an till en l˚angsammare spridning och genom det ett l¨agre d¨odstal bland smittade och st¨orre m¨ojlighet f¨or sjukv˚arden att behandla de sjukdomsfall som uppstod.
I samband med att dessa karant¨aner inf¨ordes minskade emellertid efterfr˚agan p˚a resor, hotell, restaurangbes¨ok, biobes¨ok med mera. Denna minskade efterfr˚agan ledde i sin tur till konkurser och upps¨agningar, antingen permanent eller tempor¨art, och d¨armed
¨okad arbetsl¨oshet. Konkurserna ledde till uteblivna hyresint¨akter, vilket p˚averkade and- ra branscher ¨an de f¨orstn¨amnda. Vidare ledde den ¨okade arbetsl¨osheten till minskad
2 Bakgrund
konsumtionsben¨agenhet vilket ¨aven den p˚averkade andra omr˚aden, exempelvis nybils- f¨ors¨aljningen [Syd20].
Det ¨ar utmanande f¨or en lekman att f¨orutsp˚a de kortsiktiga effekterna av denna pandemi, som kostnader f¨or arbetsl¨oshetsunderst¨od och minskade skatteint¨akter fr˚an l¨onearbete.
Det ¨ar ¨annu sv˚arare att f¨oruts¨aga de mer l˚angsiktiga ekonomiska effekterna. Hur kom- mer den ¨okade arbetsl¨osheten p˚averka ekonomin p˚a l˚ang sikt? Hur kommer f¨oretagens investeringsvilja se ut fram¨over? Hur p˚averkas konsumtionen om fondsparare ser sina besparingar rasa i v¨arde? Kommer detta leda till en ny finanskris?
2.1 Vad ¨ar en finanskris?
Fregert och Jonung beskriver i ”Makroekonomi - Teori, politik och institutioner”[FJ10]
vad som definierar en finanskris, n¨amligen ”ett exceptionellt stort fall i v¨ardet p˚a en eller flera finansiella tillg˚angar som aktier, valutor, obligationer eller fastigheter”. Eftersom definitionen ¨ar bred inneb¨ar det att en finanskris kan uppst˚a p˚a m˚anga olika s¨att. Till ex- empel orsakades finanskrisen 2008 av ¨overbel˚aning av amerikanska fastigheter, medan Greklands finansiella kris 2010 orsakades av en skenande statsskuld till f¨oljd av l˚aga r¨antor [Eur20].
Ett vanligt, men inte alltid f¨orekommande, f¨orlopp bakom finanskriser ¨ar en fas av kraf- tigt ¨okande priser p˚a en tillg˚ang av n˚agot slag, en bubbla [Min08]. Det kan vara p˚a fastigheter (som i fallet med finanskrisen 2008), eller aktier (som under IT-bubblan i slutet av 1990-talet). N¨ar priserna ¨okar leder detta till att fler och fler vill investera i tillg˚angen. Denna ¨okade efterfr˚agan fungerar som ett sj¨alvspelande piano: ¨okad efter- fr˚agan ger ¨okat pris som ger ytterligare ¨okad efterfr˚agan. Denna bubbla kan byggas upp
¨over en l˚ang tid, men f¨orr eller senare kommer den att brista n¨ar en kritisk massa av in- vesterare inser att priset p˚a tillg˚angen har ¨overstigit dess verkliga v¨arde. Detta leder till att investerare snabbt f¨ors¨oker realisera sina tillg˚angar genom att s¨alja dem. Ett nu ¨okat utbud leder till fallande priser om efterfr˚agan ¨ar fortsatt konstant [FB09]. N¨ar priserna b¨orjar dala vill ¨annu fler investerare s¨alja och priserna faller ¨annu mer.
Ett tidigt exempel p˚a detta f¨orlopp ¨ar den s˚a kallade Tulpanmanin under 1630-talets Hol- land. Peter Englund, historiker och f¨orfattare, har i en ess¨a [Eng15] beskrivit hur Tul- panmanin gick till. Att investera i tulpanl¨okar hade blivit det senaste modet. Tillg˚angen var god d˚a l¨okarna f¨or¨okar sig genom att producera nya dotterl¨okar. Det fanns en stor variation av l¨okar, fr˚an enklare och vanligare varianter till mer uts¨okta och exklusiva.
Viktigast av allt var att dessa l¨okar kunde s¨aljas i mycket sm˚a kvantiteter, s˚a lite som en enda l¨ok, vilket skapade investeringsm¨ojligheter inte bara f¨or den rika adeln, utan
2 Bakgrund
¨aven f¨or arbetarklassen. D˚a fler och fler lockades till denna form av investering steg pri- serna explosionsartat. Det fanns en s˚adan efterfr˚agan p˚a l¨okar att inte bara ˚arets sk¨ord s˚aldes, utan ¨aven kommande ˚ars sk¨ordar. Det uppstod en spekulationsbubbla d¨ar l¨okar som ¨annu inte fanns k¨optes f¨or l˚anade pengar, vilket ytterligare pressade upp priserna.
Runt ˚arsskiftet 1636-37 var priset som h¨ogst. ”F¨or en enda l¨ok ”Viceroy” betalade en k¨opare d˚a 2 lass vete, 4 lass r˚ag, 4 bastanta oxar, 8 grisar, 12 f˚ar, 79 liter vin, 425 ki- lo ost, 4 ton sm¨or samt en s¨ang, ett knippe kl¨ader och en silverb¨agare.” [Eng15]. Den tredje februari 1637 sprack bubblan. Investerare ville realisera sina vinster och f¨ors¨okte d¨armed s¨alja sina l¨okar. Det ¨okade utbudet ledde till s¨ankta priser vilket i sin tur ledde till att fler investerare f¨ors¨okte s¨alja. Till slut var alla tulpanl¨okar i Holland i stort sett v¨ardel¨osa och den finansiella krisen var ett faktum.
2.2 Hur f ¨ orebyggs och hanteras finanskriser?
F¨or att f¨orebygga finanskriser ¨agnar sig v¨arldens regeringar ˚at olika former av finans- politiska ˚atg¨arder. Huvudprincipen bakom dessa ˚atg¨arder ¨ar att j¨amna ut konjunktur- sv¨angningarna f¨or att h¨ogkonjunkturen inte blir f¨or h¨og och l˚agkonjunkturen inte f¨or l˚ag. I verktygsl˚adan f¨or att ˚astadkomma detta finns bland annat h¨ojning eller s¨ankning av r¨antor, ¨andring av skattesatsen och infrastrukturinvesteringar [Int11]. En l˚ag r¨anta leder till en ¨okad vilja f¨or f¨oretag att investera vilket i sin tur stimulerar ekonomin. Det- ta ¨ar ett exempel p˚a en expansiv finanspolitik, vilket anv¨ands f¨or att hj¨alpa ekonomin under en l˚agkonjunktur. En h¨ojd skattesats leder till att hush˚allen har mindre pengar att disponera. Allt annat lika leder detta till en minskad konsumtion vilket i sin tur anv¨ands f¨or att d¨ampa ekonomin under en h¨ogkonjunktur - ett exempel p˚a en kontraktiv finans- politik. Genom denna stabiliseringspolitik minskar riskerna f¨or att en ekonomisk bubbla uppst˚ar [Boo18].
2.3 Finanskris ¨ ovningar
F¨or att kunna f¨orbereda anst¨allda p˚a viktiga finansiella institut inf¨or en finansiell kris genomf¨ors idag finanskris¨ovningar. Deltagarna tar p˚a sig roller som olika beslutsfattan- de organ p˚a finansiella institutioner som till exempel Riksbanken, finansiella tillsyns- myndigheten eller en privat bank. Varje akt¨or har ett eget huvudm˚al som ska uppfyllas.
Riksbankens m˚al ¨ar till exempel att uppr¨atth˚alla ett fast penningv¨arde. Det betyder i praktiken att h˚alla den allm¨anna pris¨okningen av varor och tj¨anster, ¨aven kallat infla- tion, till runt tv˚a procent per ˚ar [Rik19]. En privatbank kan d¨aremot ha som m˚al att g˚a med h¨ogsta m¨ojliga vinst. Deltagarnas m˚al kan st˚a i konflikt med andra deltagares m˚al.
Deltagarna m˚aste d¨arf¨or kommunicera och kompromissa f¨or att uppn˚a b¨asta m¨ojliga
2 Bakgrund
utfall som m¨ojligt f¨or alla medverkande.
2.4 Hantering av kriser i virtuell milj ¨ o
I Walkers, Giddings och Armstrongs artikel fr˚an 2011 [WA11] beskrivs det hur tekno- logins framsteg har skapat f¨oruts¨attningar f¨or att kunna digitalisera kris¨ovningar. Be- gr¨ansningarna p˚a ¨ovningar som utf¨ors analogt, det vill s¨aga utan en digital plattform som hj¨alp, ¨ar att de kr¨aver mycket tid b˚ade att f¨orbereda och genomf¨ora. Alla konse- kvenser av en deltagaes drag m˚aste bearbetas manuellt av administrat¨orer. Resultatet blir ofta att varje deltagare har ett mycket begr¨ansat antal olika drag tillg¨angliga.
F¨orfattarna h¨avdar att mycket av det arbete som utf¨ors manuellt vid varje deltagares drag idag kan automatiseras och digitaliseras. En digitalisering skulle kunna f¨orb¨attra delta- garnas tillg˚ang till och visualisering av data vilket ger en b¨attre grund f¨or beslutsfattan- de. En digital ¨ovning har b¨attre f¨oruts¨attningar f¨or anpassning av till exempel ¨ovningens hastighet och typ av ¨ovningsscenario. M¨ojligheten att genomf¨ora exakt samma scenario flera g˚anger ger deltagaren st¨orre incitament att experimentera, vilket kan leda till nya strategier f¨or att hantera framtida kriser.
I artikeln lyfts vikten av realism fram. Det ¨ar viktigt att ¨ovningen presenteras och utfor- mas p˚a ett s¨att som liknar verkligheten f¨or att alla deltagare ska ta ¨ovningen p˚a allvar.
Realism kan uppn˚as genom att f¨ors¨oka efterlikna design och funktionalitet av riktiga sy- stem som anv¨ands f¨or krishantering. Ett annat f¨orslag f¨or att f¨orb¨attra realismen best˚ar av ett p˚ahittat nyhetsfl¨ode som l¨opande uppdateras med reaktioner p˚a vad som sker i
¨ovningen.
Ett problem med en digital ¨ovning ¨ar beroendet p˚a datamodeller och indata. En av
¨ovningens begr¨ansningar blir s˚aledes kvaliteten av datan och modellerna som ¨ovningen bygger p˚a. Sm˚a avvikelser i data kan ha stor p˚averkan p˚a beslut, h¨andelser i ¨ovningen och, d¨armed, ¨aven anv¨andarnas l¨ardomar. Det ¨ar d¨arf¨or av stor vikt att modeller och indata enkelt kan uppdateras f¨or att h˚alla ¨ovningen relevant.
2.5 Intressent
Intressenten f¨or projektet ¨ar Mikael Wendschlag, verksam p˚a institutionen f¨or ekono- misk historia vid Uppsala Universitet och forskare inom finansiell tillsyn och reglering, finanskriser och ekonomisk brottslighet. Han undervisar i kursen Ekonomisk historia A: Politik, kriser och konjunkturer p˚a Uppsala Universitet sedan 2013, som i stor ut- str¨ackning handlar om finanskriser [Upp]. Wendschlag har arbetat p˚a Finansinspektio-
3 Syfte, m˚al, och motivation
nen med en utredning av deras anv¨andning av sanktioner, och ¨aven p˚a Riksbanken f¨or att unders¨oka hur Riksbanken har organiserats genom ˚aren. P˚a Riksbanken har han ¨aven arbetat som g¨astforskare. Ut¨over det har han ¨aven g¨astforskat hos Swedish House of Finance och European University Institute. Hans l˚anga arbetslivserfarenhet inom natio- nalekonomi och finanskriser har varit h¨ogst relevant f¨or projektet och kommit till stor nytta d˚a regler f¨or simuleringen baserats p˚a hans kunskap som expert inom omr˚adet.
3 Syfte, m ˚al, och motivation
V¨arldsbanken uppskattar att en finanskris¨ovning tar mellan fyra och sex m˚anader att f¨orbereda. Detta kr¨avs f¨or att skapa skr¨addarsydda ¨ovningsscenarion till de deltagan- de myndigheterna beroende p˚a deras beslutsfattningregler och de r˚adande finansiella omst¨andigheterna i landet [The10].
Existerande finanskris¨ovningar kr¨aver ¨aven att samtliga deltagare samlas p˚a en och sam- ma plats, vilket inneb¨ar att deltagarna m˚aste resa till platsen d¨ar ¨ovningen genomf¨ors.
Det inneb¨ar inte bara kostnader f¨or deltagarna, utan ¨aven att regionalt och internationellt samarbete blir mer komplicerat. Vidare deltar representanter fr˚an ¨ovningssamordnaren, exempelvis V¨arldsbanken, i ¨ovningen som spelledare, vilket i sig medf¨or b˚ade kostnader och resursbegr¨ansningar, d˚a antalet utbildade spelledare ¨ar begr¨ansat.
Syftet med detta projekt ¨ar att utveckla en digital plattform d¨ar olika typer av finans- kris¨ovningar kan genomf¨oras. En digital plattform m¨ojligg¨or att m˚anga fler ¨ovningar kan genomf¨oras parallellt, eftersom de inte kr¨aver att deltagare och spelledare sam- las p˚a samma plats. I sj¨alva verket kr¨aver dessa digitala ¨ovningar ingen spelledare
¨overhuvudtaget, d˚a plattformen automatiserar de funktioner som spelledaren vanligen fyller.
Kommunikationen mellan ¨ovningsdeltagarna ¨ar v¨aldigt viktig. Det som i verkligheten
¨ager rum under flera dagar simuleras i ¨ovningen p˚a ett par minuter. Detta inneb¨ar att deltagarna upplever en tidspress som efterliknar den stress som de skulle uts¨attas f¨or i skarpt l¨age. Detta st¨aller h¨oga krav p˚a att effektivt kunna dela med sig och ta del av information p˚a plattformen. Det betyder att publik information ska vara l¨att¨oversk˚adlig samtidigt som det ska vara enkelt att kommunicera mellan ¨ovningsdeltagarna.
Det ¨ar inte bara sj¨alva ¨ovandet som ¨ar viktigt utan lika viktigt ¨ar att deltagarna i ef- terhand ska kunna utv¨ardera ¨ovningen genom att se alla beslut som fattades och vilka konsekvenser dessa ledde till. F¨or att deltagaren ska kunna dra l¨ardomar fr˚an en ge- nomf¨ord ¨ovning ¨ar det viktigt att kunna presentera relevant data i efterhand f¨or att se vilka ˚atg¨arder alla andra deltagare vidtagit och dess konsekvenser. Att utv¨ardera hur v¨al
3 Syfte, m˚al, och motivation
varje deltagare presterade l¨aggs p˚a anv¨andarna att sj¨alva bed¨oma och dra slutsatser fr˚an.
Projektets m˚al var att skapa en minimum viable product, det vill s¨aga en prototyp som kan verifiera en digital kris¨ovnings nytta som ett ¨ovningsverktyg inom den finansiella sektorn. D¨arf¨or var huvudm˚alet i detta projekt att implementera de mest fundamentala grundfunktionerna f¨or finanskris¨ovningar p˚a en digital plattform.
I grundfunktionerna ing˚ar:
• Skapa en ny ¨ovning
• G˚a med i en specifik ¨ovning
• Genomf¨ora rollspecifika drag, t.ex. ska centralbanken kunna h¨oja styrr¨antan
• Skicka publika meddelanden
• Skicka privata meddelanden mellan de olika deltagarna
• Dela finansiell data mellan deltagare
• H¨amta en sammanst¨allning av alla fattade beslut, skickade meddelanden och ¨ov- ningens h¨andelsef¨orlopp, vilket kan anv¨andas f¨or utv¨ardering.
3.1 H ˚allbarhetsm ˚al
Existerande finanskris¨ovningar kr¨aver fysisk n¨arvaro fr˚an samtliga deltagare och kan d¨arf¨or kr¨ava inresande deltagare. Ett av FNs globala m˚al f¨or 2030 [Uni] handlar om att bek¨ampa klimatf¨or¨andringarna, vilket bland annat inneb¨ar att resandet m˚aste minska d˚a stor del av klimatf¨or¨andringarna beror just p˚a flygtrafik [Nat20]. F¨or att minska resandet, och d¨arigenom klimatp˚averkan, kan en digital l¨osning vara ett steg i r¨att riktning, d˚a deltagarna inte beh¨over vara fysiskt n¨arvarande f¨or att delta i ¨ovningen.
3.2 Etiska fr ˚agor
Plattformen har byggts s˚a att m¨angden k¨anslig information som samlas in fr˚an anv¨andarna begr¨ansas. Ingen ¨overfl¨odig information, som betalningsmetoder eller personlig data ef- terfr˚agas. Den enda personuppgiften som lagras ¨ar e-postadresser. Valet att anv¨anda e-postadresser som anv¨andarnamn ¨ar f¨or att underl¨atta ˚aterst¨allandet av konton, men ocks˚a f¨or att p˚a ett enkelt s¨att kunna verifiera att kontona ¨ar unika. Ut¨over det sparas
4 Relaterat arbete
konversationer mellan anv¨andare p˚a plattformen f¨or att kunna utv¨arderas i efterhand.
Anv¨andarna f¨orv¨antas endast skicka information mellan varandra som ber¨or ¨ovningen.
N¨ar anv¨andarna skapar konton informeras de om att alla meddelanden i chatten kommer att delas med de andra deltagarna efter ¨ovningen. Anv¨andarna p˚aminns om detta igen n¨ar de ¨oppnar chatt-funktionen.
Eftersom e-postadresser lagras kr¨aver det att dataskyddsf¨orordningen f¨oljs f¨or att skyd- da anv¨andarnas integritet. Detta medf¨or att anv¨andarna ska informeras om vilka per- sonuppgifter som lagras [Dat]. Det ¨ar inte till˚atet att samla in mer information om anv¨andarna ¨an vad som kr¨avs f¨or systemets funktion. Personuppgifterna ska ¨aven skyd- das fr˚an otill˚aten anv¨andning. Plattformen kr¨aver godk¨annande fr˚an alla anv¨andare vars personuppgifter sparas. Anv¨andarna m˚aste godk¨anna ett avtal som beskriver insamling- en av personuppgifter. F¨or att f¨orhindra att obeh¨origa f˚ar ˚atkomst till personuppgifter l¨aggs stor vikt p˚a s¨akerhet genom att utnyttja kryptering. Datas¨akerhet beskrivs i mer detalj i avsnitt 5.4.
3.3 Avgr ¨ansningar
Aven om m˚alet med plattformen ¨ar att kunna simulera avancerade finanskriser valdes¨ att endast implementera en f¨orenklad ¨ovning med begr¨ansade handlingsalternativ f¨or de olika finansiella akt¨orerna. Syftet ¨ar att demonstrera den funktionalitet vi implementerat, snarare ¨an att skapa ett helt realistiskt scenario.
Plattformen anv¨ander inte ljud vilket g¨or att det inte beh¨ovs h¨orsel f¨or att kunna ge- nomf¨ora en ¨ovning. D¨aremot anv¨ander ¨ovningen m˚anga grafiska element f¨or att f¨ormedla information till anv¨andaren vilket g¨or att personer med synproblem kan f˚a sv˚art att anv¨anda plattformen. F¨or en del HTML-element finns beskrivande taggar som anv¨ands i text-till-tal-program men detta kommer inte implementeras under projektet.
4 Relaterat arbete
Kris¨ovningar ¨ar ett vanligt verktyg inom de flesta branscher, och likas˚a inom finans- branschen. I detta avsnitt presenteras hur andra ¨ovningar fungerar och hur de st¨aller sig i j¨amf¨orelse med v˚ar l¨osning.
4 Relaterat arbete
4.1 V ¨arldsbankens finanskrissimuleringar
Idag erbjuder bland annat V¨arldsbanken finanskris¨ovningar [The10]. V¨arldsbanken ¨ar ett FN-organ med 188 medlemsl¨ander vars uppdrag ¨ar att l˚ana ut pengar till utveck- lingsl¨ander f¨or att bek¨ampa fattigdom. Finanskris¨ovningarna ¨ar skr¨addarsydda till ett lands myndigheter, lagar, regler och finansiella situation f¨or att p˚a b¨asta s¨att skapa ett anpassat och realistiskt ¨ovningsscenario. Dessa ¨ovningar kr¨aver fysisk n¨arvaro fr˚an al- la deltagare samt personal fr˚an V¨arldsbanken som hj¨alper deltagarna med ¨ovningens regler.
En ¨ovning simulerar ett m¨ojligt scenario f¨or en finanskris, exempelvis att landets banker riskerar att g˚a omkull. Deltagarna i ¨ovningen ¨ar anst¨allda vid de finansiella institutioner som skulle vara p˚averkade av en verklig finansiell kris. I ¨ovningen antar deltagarna oli- ka roller som banker, tillsynsmyndigheter och centralbank. De beslut institutionerna kan fatta i ¨ovningen ¨ar samma beslut de har befogenhet att fatta i verkligheten, till exempel h¨oja eller s¨anka r¨antor. Effekten av s˚adana handlingar p˚averkar den simulerade eko- nomin och f˚ar denna att f¨orb¨attras eller f¨ors¨amras. Eftersom m¨angden valm¨ojligheter
¨ar stor och den simulerade ekonomin ¨ar komplex ¨ar det sv˚art f¨or V¨arldsbankens ar- rang¨orer att f¨orutse alla m¨ojliga scenarion, vilket bidrar till att dessa ¨ovningar tar l˚ang tid att f¨orbereda [The10].
4.2 Toronto Center
Toronto Center, TC, ¨ar en oberoende ideell organisation som erbjuder i stort sett samma tj¨anst som V¨arldsbanken n¨ar det g¨aller finanskrissimuleringar. De kan erbjuda anpassade simuleringar baserat p˚a regelverket som finns i landet och utifr˚an vilka roller som ska delta. ¨Aven TC anv¨ander personal f¨or att hantera helheten av simuleringen samt personal f¨or att hj¨alpa deltagarna med att ta emot och skicka information till andra deltagare eller spelledarna [Tor20].
TC har m¨ojlighet att h˚alla en i simulering d¨ar alla deltagare ¨ar p˚a samma plats men f¨oresl˚ar att alla parter ska vara p˚a sina vanliga fysiska kontor. Inte bara f¨or att det ¨ar l¨attare att organisera utan ¨aven f¨or att det ska fungera i h¨ogsta utstr¨ackning som det hade gjort vid en skarp situation [Tor20].
4 Relaterat arbete
4.3 Doom (1993)
N¨ar spelet Doom sl¨apptes 1993 var datorers resurser mycket mer begr¨ansade ¨an vad de
¨ar idag. Det var d¨arf¨or viktigt att spelet inte tog upp mycket minne. F¨or att kunna spara och utv¨ardera hur en spelare hade presterat i spelet sparades alla drag som spelaren hade gjort i en demo-fil [Dooa]. Filen redovisar drag f¨or drag exakt vad spelaren gjorde och n¨ar. En tidsenhet i Doom heter tick och varje sekund sker det 35 ticks [Doob]. Eftersom alla drag och i vilken tick de skedde har sparats kan spelmotorn l¨asa demofilen och anv¨anda informationen f¨or att ˚aterskapa hela spelarens spelomg˚ang.
I detta system anv¨ands en motsvarande l¨osning f¨or att spara alla deltagares drag vilket g¨or att ¨ovningen kan ˚aterskapas i efterhand. D¨aremot ¨ar motsvarigheten till en tick en hel simulerad dag. N¨ar en anv¨andare skapar en ny ¨ovning i systemet kan denne anpassa hur l˚ang en dag (en tick) ska vara i verkligheten.
4.4 Old School RuneScape (OSRS)
Old school Runescape (OSRS) ¨ar ett spel som tillh¨or kategorin Massive Multiplayer Online Role-Playing Game (MMORPG). Likt Doom bygger OSRS p˚a ett ticksystem f¨or att hantera tiden och i f¨orl¨angningen alla spelares drag. OSRS anv¨ander d¨aremot 100 ticks per minut ist¨allet f¨or 35 ticks per sekund [Old]. I OSRS styrs ticks av servern som kopplar samman alla spelare. D˚a OSRS ¨ar ett MMORPG spelar m˚anga spelare tillsammans och alla kan g¨ora olika saker p˚a samma tick. Allas drag som gjordes under en tick f¨ormedlas sedan till alla andra spelare f¨or att de kan se andra spelares handlingar.
d˚a spelarna har 600ms (100 ticks per minut) p˚a sig att v¨alja vad denna ska g¨ora under en tick hinner spelaren v¨alja flera saker innan n¨asta tick b¨orjar. Vissa saker g˚ar att g¨ora under samma tick, som att ¨ata och g˚a. Andra saker kan inte g¨oras samtidigt, som att g˚a till tv˚a olika st¨allen, d˚a dessa handlingar motstrider varandra. I detta fall v¨aljs det senare av de tv˚a handlingarna.
I v˚art system motsvarar varje dag en tick. Hur l¨ange en dag varar best¨ams n¨ar ¨ovningen skapas och styrs sedan, liksom i OSRS, av servern. Under en dag kan en deltagare till exempel s¨alja olika typer av v¨ardepapper, men kan inte k¨opa och s¨alja samma typ av v¨ardepapper samtidigt, d˚a dessa drag ¨ar motstridiga. P˚a samma s¨att som i OSRS v¨aljs d˚a det senare av dragen. Effekten av dragen som anv¨andarna valde att g¨ora under en dag syns f¨orst n¨asta dag. I systemet betyder det att konsekvenserna av dragen som deltagaren gjorde under en dag syns f¨orst n¨asta dag.
5 Metod
5 Metod
F¨or att utveckla prototypen har vi anv¨ant olika programmeringsspr˚ak f¨or frontend, back- end och datalagringen. I detta avsnitt diskuteras de valda spr˚aken och j¨amf¨ors med andra alternativ.
5.1 Frontend
F¨or att skapa en produkt som ¨ar kompatibel med flera plattformar och inte beroen- de av operativsystem valdes en webbimplementation. Inget beh¨over d˚a installeras hos anv¨andaren och anv¨andaren blir inte l˚ast till en enhet utan kan logga in och genomf¨ora
¨ovningar p˚a valfri dator. Det enda kravet ¨ar en webbl¨asare och en internetuppkoppling.
Anv¨andargr¨anssnittet skapas med hj¨alp av av HTML, CSS och JavaScript. HTML ¨ar ett m¨arkspr˚ak som anv¨ands f¨or att presentera information via en hemsida. M¨arkspr˚ak best˚ar av taggar som ¨ar osynliga f¨or anv¨andaren men som beskriver f¨or webbl¨asaren hur informationen p˚a en hemsida struktureras. F¨or att presentera informationen p˚a ett anv¨andarv¨anligt s¨att anv¨ands en stilmall som beskrivs i CSS. D¨ar beskrivs till exem- pel typsnitt, textstorlek och f¨arg. Till skillnad fr˚an CSS och HTML ¨ar JavaScript ett skriptspr˚ak som k¨ors lokalt i anv¨andarens webbl¨asare. JavaScript anv¨ands bland annat f¨or att visa relevant information f¨or deltagaren och f¨or att hantera de drag deltagaren vill utf¨ora.
Projektet anv¨ander inget ramverk som React.js, Angular.js, eller VueJS. De ramverken
¨ar mest fokuserade p˚a att kontrollera det som visas f¨or anv¨andaren p˚a hemsidan. I denna
¨ovning presenteras all data i balansr¨akningar och tabeller f¨or att efterlikna verkligheten.
D¨arf¨or ans˚ags det ta mer tid att l¨ara sig n˚agot av dessa ramverk ¨an den tidsbesparing det skulle ge under projektet.
5.1.1 TypeScript
JavaScript ¨ar ett svagt typat spr˚ak vilket betyder att variabler kan inneh˚alla nummer, text eller n˚agot helt annat utan att ber¨atta explicit vilken typ av data det ¨ar. Trots att en funktion bara hanterar argument av en specifik datatyp finns det ingen automatisk kontroll p˚a att r¨att datatyp anv¨ands i JavaScript.
Under utveckling betyder det att programmeraren inte kan vara s¨aker p˚a vilken typ av argument en anropad funktion kommer att kunna hantera. Om textstr¨angar skickas in till en funktion som ska multiplicera tv˚a tal kommer ett fel att uppst˚a. F¨or att undvika
5 Metod
att s˚adana fel uppst˚ar kan TypeScript anv¨andas.
TypeScript ¨ar ett spr˚ak som fungerar likadant som JavaScript men d¨ar variabler kan ges explicita typer, som exempelvis nummer. Funktionen som multiplicerar tv˚a tal kan d¨arf¨or kr¨ava att argumenten ¨ar av typen nummer. TypeScript till˚ater ¨aven mer kompli- cerade strukturer f¨or objekttyper. Exempelvis kan typen ”boll” definieras som att den m˚aste ha en radie och en f¨arg. Det betyder att programmeraren kan f¨oruts¨atta att varje g˚ang en boll hanteras har den alltid en radie och en f¨arg.
JavaScript kan k¨oras i de vanligaste webbl¨asarna [Sta19][DPW20]. TypeScript funge- rar d¨aremot inte i n˚agon webbl¨asare d˚a TypeScript endast ¨ar till f¨or att skriva kod, inte f¨or att exekveras. Ist¨allet kompileras TypeScript till JavaScript som sedan kan k¨oras i en webbl¨asare. Under kompileringen uppkommer fel om kraven p˚a typer inte upp- fylls. Om det till exempel skapas en boll som inte inneh˚aller en radie och f¨arg som har specificerats uppkommer ett felmeddelande. Programmeraren kan d˚a g˚a tillbaka till TypeScript-koden, ˚atg¨arda felet och kompilera koden igen. D¨armed underl¨attas utveck- lingsprocessen b˚ade f¨or en enskild programmerare, men framf¨orallt blir det l¨attare f¨or andra programmerare att l¨asa och f¨orst˚a koden. Av detta sk¨al valdes TypeScript f¨or att skriva all JavaScript-kod under projektet.
CoffeeScript ¨ar ett alternativ till TypeScript vid utveckling av JavaScript. CoffeeScript
¨ar syntaktiskt socker som ¨amnar att g¨ora JavaScript l¨attare att l¨asa och uttrycka, ge- nom att g¨ora JavaScript mer koncist [Cof]. Likt TypeScript kompileras CoffeeScript till JavaScript. Till skillnad fr˚an CoffeeScript, ¨ar TypeScript ett valfritt extra lager som anv¨ander mer syntax ¨an JavaScript, inte mindre. Po¨angen med den extra syntaxen ¨ar att g¨ora koden l¨attare att f¨orst˚a genom att f¨ormedla vilka datatyper variabler f¨orv¨antas vara.
CoffeeScript anv¨ander inte deklarerade typer till skillnad fr˚an TypeScript och p˚a grund av det valdes TypeScript ist¨allet f¨or CoffeeScript.
5.2 Backend
Backenden best˚ar av PHP-skript. PHP ¨ar ett skriptspr˚ak som anv¨ands f¨or att driva webb- servrar och leverera internetsidor med dynamiskt inneh˚all. I maj 2020 uppskattades 78,5 procent av alla hemsidor anv¨anda sig av PHP [w3tb]. Detta kan j¨amf¨oras med Node.js som lanserades 2009 och uppskattas finnas p˚a 0,8 procent av alla hemsidor [w3ta].
Crawford och Hussain j¨amf¨or i sin artikel fr˚an 2017 [CH17] flera serverspr˚ak, bland annat PHP, Node.js och Django. Eftersom PHP ¨ar popul¨art som programmeringsspr˚ak p˚a serversidan finns det mycket resurser och kunskap i form av inl¨agg och artiklar som underl¨attar att hantera och ˚atg¨arda fel i PHP-kod. Till f¨oljd av PHP:s popularitet finns det ¨aven stort utbud av webbhotell med st¨od f¨or PHP vilket g¨or att systemet vid behov
5 Metod
kan flyttas till ett annat webbhotell. Att servern ligger n¨ara anv¨andaren inneb¨ar generellt kortare svarstider vilket ¨ar viktigt f¨or anv¨andarupplevelsen.
I Crawfords och Hussains artikel [CH17] n¨amns ¨aven att PHP har st¨od f¨or flera olika typer av databaser utan behov av externa bibliotek eller ramverk, till skillnad fr˚an b˚ade Node.js och Django. Detta underl¨attar utvecklingen eftersom PHP:s viktigaste roll i det- ta system ¨ar att skicka f¨orfr˚agningar och ta emot svar fr˚an databasen. En av PHP:s st¨orsta svagheter ¨ar ber¨akningshastigheten. B˚ade Node.js och Django har h¨ogre kapacitet f¨or att g¨ora m˚anga ber¨akningar samtidigt [CH17]. Eftersom n¨astan alla ber¨akningar f¨or det- ta projekt g¨ors med JavaScript ¨ar det osannolikt att detta kommer begr¨ansa webbsidans upplevda hastighet. Baserat p˚a argumenten i Crawfords och Hussains artikel valde vi PHP ist¨allet f¨or Django eller Node.js.
5.3 Datalagring
SQL eller structured query language ¨ar ett programmeringsspr˚ak som anv¨ands f¨or att hantera data i en relationsdatabas. NoSQL betyder icke-SQL, allts˚a data som inte lag- ras i en relationsdatabas. NoSQL kan anses mer flexibelt eftersom NoSQL-databaser inte beh¨over f¨olja SQL:s str¨anga regler. NoSQL anv¨ands ofta f¨or att hantera big da- ta eftersom prestandan f¨or de flesta dataoperationer ¨ar betydligt b¨attre ¨an f¨or SQL [GGPO15]. MySQL, som ¨ar baserat p˚a SQL, har d¨aremot starkare s¨akerhetsmekanismer och mer tillf¨orlitligt dataskydd vilket s¨akerst¨aller datans integritet [Sin19]. Eftersom MySQL ofta anv¨ands i kombination med PHP och detta system inte hanterar stora m¨angder data f¨oll valet p˚a en SQL-baserad databas.
MariaDB ¨ar ¨oppen k¨allkod och en vidareutveckling av MySQL. Skillnaderna mellan MariaDB och MySQL ¨ar liten, vilket till˚ater applikationer att fungera p˚a b˚ada plattfor- marna med samma kod [Sar]. B˚ada ¨ar relationsdatabaser som anv¨ander SQL f¨or att styra och s¨atta in eller plocka ut data. Structured Query Language ¨ar v¨aldigt likt ren engelska f¨or att hantera data. ”V¨alj all data ifr˚an tabellen med alla anst¨allda d¨ar l¨onen ¨overstiger 35 000kr” ¨ar n¨astan en direkt ¨overs¨attning av SQL kommandot: ”SELECT * FROM
‘employee‘ WHERE ‘salary‘ >35000”.
MariaDB har st¨orre precision i sina tidsst¨amplar ¨an MySQL [Bar12]. MariaDB hanterar tidsst¨amplar i mikrosekunder och MySQL i sekunder. En h¨ogre grad av tidsprecision till˚ater st¨orre noggrannhet i ber¨akningar d¨ar datans inkomna ordning p˚averkar resultatet.
Ordningen av drag kan ha stor betydelse f¨or ber¨akningar av olika v¨arden och d¨arf¨or ¨ar h¨og tidsprecision en f¨ordel. En annan styrka ¨ar MariaDB:s prestanda, d¨ar en insert query exekveras 24 procent snabbare ¨an i MySQL [Gur]. F¨or detta system ¨ar dock databas- prestanda inte en avg¨orande faktor eftersom m˚alet i projektet ¨ar en prototyp som inte
5 Metod
kommer hantera stora m¨angder data. F¨ordelen med h¨ogre tidsprecision gjorde att valet f¨oll p˚a MariaDB.
5.4 S ¨aker datalagring
Systemet hanterar och sparar minsta m¨ojliga data g¨allande anv¨andarna, men e-post- adresser och l¨osenord m˚aste lagras f¨or att anv¨andare ska kunna logga in. L¨osenord lagras med hashning och saltning enligt modern praxis. I boken Computer security fundamen- tals[Eas19] g˚ar Chuck Easttom igenom b˚ade hashning och saltning.
Hashning ¨ar en matematisk funktion som g¨or om indatan till en str¨ang av bitar av best¨amd l¨angd, kallat hash-v¨arde. Samma inmatningsdata i en hashningsalgoritm ger alltid samma hash-v¨arde som resultat. Det inneb¨ar att l¨osenordet ”iloveyou” alltid resul- terar i samma hash-v¨arde. Hashade l¨osenord sparas i en databas. D¨armed kan anv¨andares l¨osenord kontrolleras utan att spara okrypterade l¨osenord. N¨ar en anv¨andare loggar in j¨amf¨ors hash-v¨ardet av det inmatade l¨osenordet med hash-v¨ardet p˚a l¨osenordet som spa- rats i databasen f¨or att avg¨ora om anv¨andaren uppgivit det r¨atta l¨osenordet.
Kvalit´en p˚a en hashningsalgoritm kan bed¨omas utifr˚an hur sv˚art det ¨ar att med hj¨alp av hash-v¨ardet kunna r¨akna ut vad hashningsalgoritmens indata var. Det vill s¨aga hur sv˚art det ¨ar att r¨akna ut ett l¨osenord fr˚an ett hash-v¨arde. Utifr˚an en lista p˚a de vanligaste l¨osenorden kan en angripare gissa att de vanligast f¨orekommande hasharna i databasen motsvarar de vanligaste l¨osenorden. S˚adana attacker kan f¨orhindras genom att anv¨anda salt.
Salt ¨ar extra data som l¨aggs p˚a datan som ska sparas. Saltet ¨ar unikt f¨or varje fragment data som sparas. N¨ar l¨osenordet ”iloveyou” ska sparas kan saltet ”123” l¨aggas till p˚a slu- tet s˚a datan som hashas blir ”iloveyou123” ist¨allet f¨or ”iloveyou”. Om en ny anv¨andare skulle anv¨anda samma l¨osenord ”iloveyou” f˚ar den ett nytt salt, ”ABC”, som l¨aggs till p˚a slutet av l¨osenordet n¨ar det hashas. Det som sparas i databasen ¨ar hash-v¨ardet av ”ilo- veyouABC” och saltet, ”ABC”. N¨ar l¨osenordet saltas med ”123” och ”ABC” ¨ar det inte l¨angre samma data som f¨ors in i hashalgoritmen vilket resulterar i tv˚a olika hash-v¨arden och en angripare f˚ar d˚a sv˚arare att utl¨asa m¨onster i databasen av l¨osenordshashar.
Att bygga en hash-funktion ligger utanf¨or projektets ramar och d¨arf¨or anv¨andes PHP:s inbyggda funktion password hash f¨or hashning och saltning.
6 Ovningen ur anv¨andarens perspektiv¨
6 Ovningen ur anv ¨andarens perspektiv ¨
P˚a plattformen kan ¨ovningar skapas som andra anv¨andare kan ansluta sig till. En ¨ovning ska spegla en finanskris och det finns olika scenarion att v¨alja mellan. F¨or att testa plattformen har ett enkelt scenario implementerats. Detta scenario ska spegla en bank- rusning. En bankrusning inneb¨ar att en ovanligt stor m¨angd kunder f¨ors¨oker ta ut pengar fr˚an en bank under en kort period. Vanligen sker detta om allm¨anheten av n˚agon anled- ning b¨orjar misstro banken och vill ta ut sina sparade medel. Om alltf¨or m˚anga kunder vill g¨ora detta vid ett och samma tillf¨alle p˚averkas bankens likviditet och den kan g˚a i konkurs, vilket skapar finansiell instabilitet i ¨ovriga marknaden. Det kan i v¨arsta fall utl¨osa en finanskris.
Detta scenario har tre deltagare: en centralbank och tv˚a aff¨arsbanker. Varje deltagare har ett antal finansiella m˚al som det ska f¨ors¨oka uppn˚a. Dessa m˚al best¨ams p˚a f¨orhand och
¨ar en del av scenariot. Exempelvis ¨ar bankernas m˚al i detta scenario att inte g˚a i konkurs.
Ut¨over den information som visas nedan har deltagaren ¨aven tillg˚ang till ett f¨orutbest¨amt nyhetsfl¨ode som ¨aven det ¨ar en del av scenariot. Deltagarna kan ¨aven kommunicera med varandra genom en meddelandefunktion. Beskrivningen nedan visar, n˚agot f¨orenklat, hur en ¨ovningsomg˚ang kan g˚a till, sett ur den ena bankens perspektiv.
Dag 1 i ¨ovningen
Ovningens utg˚angsl¨age visas i tabell 1. Till v¨anster finns bankens tillg˚angar och till¨ h¨oger finns skulder och eget kapital. Bankens ekonomi ¨ar i balans eftersom summan av tillg˚angarna ¨ar lika med summan av skulder och eget kapital.
Tillg˚angar Skulder och Eget Kapital
Kassa 400 Inl˚anade medel 400
Statsobligationer 600 L˚an 900
Ovriga tillg˚angar¨ 600 Eget kapital 300
Summa tillg˚angar 1600 Summa skulder och eget kapital 1600 Tabell 1 Bankens balansr¨akning dag 1.
7 Systemstruktur
Dag 2 i ¨ovningen
Bankens kunder b¨orjar ta ut pengar i stor utstr¨ackning. De inl˚anade medlen sjunker d¨armed kraftigt fr˚an 400 till 100 i balansr¨akningen som visas i tabell 2. Kortsiktigt tas dessa pengar fr˚an kassan som d˚a ocks˚a sjunker. Anv¨andaren m˚aste g¨ora n˚agot f¨or att f¨orhindra banken fr˚an att g˚ar i konkurs och best¨ammer sig d˚a f¨or att s¨alja statsobligatio- ner. Detta ¨ar ett av de drag anv¨andaren har tillg˚ang till.
Tillg˚angar Skulder och Eget Kapital
Kassa 100 Inl˚anade medel 100
Statsobligationer 600 L˚an 900
Ovriga tillg˚angar¨ 600 Eget kapital 300
Summa tillg˚angar 1300 Summa skulder och eget kapital 1300 Tabell 2 Bankens balansr¨akning dag 2.
Dag 3 i ¨ovningen
Banken har nu s˚alt statsobligationer och d¨armed st¨arkt kassan. Genom sitt snabba age- rande har banken avv¨arjt den annalkande krisen. Detta syns i tabell 3 d¨ar kassan har stigit med 300 och statsobligationerna har sjunkit med 300.
Tillg˚angar Skulder och Eget Kapital
Kassa 400 Inl˚anade medel 100
Statsobligationer 300 L˚an 900
Ovriga tillg˚angar¨ 600 Eget kapital 300
Summa tillg˚angar 1300 Summa skulder och eget kapital 1300 Tabell 3 Bankens balansr¨akning dag 3.
7 Systemstruktur
Systemet best˚ar av tre delar: spelklienter, en backend-server skriven i PHP och en MariaDB-databas. Denna struktur illustreras i figur 1.
7 Systemstruktur
Figur 1 ¨Oversikt av systemets komponenter och kommunikation dem emellan
H¨ogst upp i figur 1 syns anv¨andare som ¨ar kopplade till en ¨ovning genom sin spelkli- ent. Varje anv¨andare kan v¨alja roll i ¨ovningen. Rollen kan vara av olika typer, exem- pelvis centralbank eller privatbank. Det kan finnas flera aktiva ¨ovningar samtidigt. En anv¨andare kan delta i flera ¨ovningar samtidigt. Anv¨andarna kommunicerar bara med sin egen spelklient som i sin tur skickar drag och chattmeddelanden till servern. Servern sparar sedan b˚ade drag och chattmeddelanden i databasen. Mottagaren av meddelan- den har sin egen spelklient som ber servern att f˚a alla meddelanden relaterade till den aktuella ¨ovningen och anv¨andaren. Servern svarar med att h¨amta meddelandena fr˚an databasen och skicka dem till spelklienten. F¨or att veta vilka meddelanden, drag, delta- gare och andra h¨andelser som ¨ar relevanta f¨or en ¨ovning tilldelas ¨ovningarna ett unikt id-nummer n¨ar de skapas.
7 Systemstruktur
7.1 Spelklient
Gr¨anssnittet som anv¨andaren ser genereras av PHP och JavaScript. PHP anv¨ands f¨or att visa ˚aterkommande delar av gr¨anssnittet. Header och footer finns p˚a alla sidor och importeras till sidorna med PHP. ¨Aven koden f¨or att logga in, registrera sig, skapa och g˚a med i ¨ovningar anv¨ander PHP.
I figur 2 visas den virtuella tiden som ¨ar gemensam f¨or alla anv¨andare i samma ¨ovning.
H¨ar visas datum, klockslag, veckodag och hur m˚anga virtuella dagar som har passerat sedan ¨ovningens b¨orjan. Varje anv¨andare i ¨ovningen har tillg˚ang till sin egen ekono- miska data samt globala ekonomiska data som visas i gr¨anssnittet. I varje deltagares gr¨anssnitt finns ¨aven m¨ojlighet att utf¨ora olika drag som kommer att p˚averka den eko- nomiska datan.
Figur 2 ¨Ovningens virtuella tid
JavaScript fyller i balansr¨akningarna och skapar listan p˚a drag som ¨ar tillg¨angliga f¨or anv¨andaren. Vad som ska uppdateras i balansr¨akningen och vilka drag som ska synas sk¨ots ocks˚a av JavaScript i spelklienten. En utf¨orlig beskrivning av gr¨anssnittet finns i avsnitt 9.
M˚anga av ¨ovningens funktioner, som virtuell tid och ber¨akning av ekonomiska data, utf¨ors lokalt i spelklienten. Nackdelen med detta ¨ar att samma ber¨akningar g¨ors flera g˚anger p˚a olika spelklienter. Servern kan d¨aremot avlastas och beh¨over inte ha lika h¨og ber¨akningskapacitet eftersom ber¨akningar k¨ors i spelklienterna. Detta ¨ar framf¨orallt en f¨ordel om det i framtiden utf¨ors m˚anga fler ¨ovningar samtidigt och det d˚a st¨alls mycket h¨ogre krav p˚a ber¨akningskapacitet.
F¨or att f˚a tillg˚ang till roller, vilka drag ¨ovriga anv¨andare gjort, chattmeddelanden, och annan lagrad information kr¨avs kommunikation med servern. Under ¨ovningens g˚ang skickas AJAX-f¨orfr˚agningar via JavaScript till servern. En AJAX-f¨orfr˚agan ¨ar en metod f¨or webbl¨asaren att kommunicera med servern genom att g¨ora HTTP-f¨orfr˚agningar.
F¨or att ber¨akna alla ekonomiska v¨arden finns det en ber¨akningsenhet i spelklienten.
Spelklienten skickar en AJAX-f¨orfr˚agan till servern som efterfr˚agar alla deltagares drag.
Med den informationen kan ber¨akningsenheten ber¨akna hur dragen p˚averkar ¨ovningens ekonomiska v¨arden. Spelklienten i sin tur fyller i alla uppdaterade ekonomiska v¨arden i anv¨andarens gr¨anssnitt efter ber¨akningarna. D˚a alla ekonomiska startv¨arden som h¨amtas i b¨orjan av ¨ovningen alltid ¨ar samma och ber¨akningsenheten ber¨aknar alla drag exakt likadant varje g˚ang, kan v¨ardena garanteras vara identiska hos alla deltagare utan att
8 Krav och utv¨arderingsmetoder
beh¨ova spara och ber¨akna alla v¨arden centralt p˚a servern. Hur ber¨akningsenheten fun- gerar beskrivs i avsnitt 10.4.
7.2 Server
Servern agerar framf¨orallt som databas-API. D¨ari ing˚ar bland annat ing˚ar inloggning och skapandet av konton. Servern ¨ar inte aktiv i att skicka information till spelklienter utan svarar endast p˚a AJAX-f¨orfr˚agningar. N¨ar en AJAX-f¨orfr˚agan tagits emot h¨amtas relevant data fr˚an databasen och skickas tillbaka till spelklienten som JSON-data. Varje spelklient m˚aste skicka en egen AJAX-f¨orfr˚agan f¨or att f˚a ut information fr˚an databasen.
N¨ar anv¨andaren skriver ett meddelande eller skickar ett drag skickas det av spelklienten och tas emot av servern som sparar det i databasen.
7.3 Databas
Databasen ¨ar en viktig pelare i systemet d˚a detta ¨ar byggt som en plattform f¨or att fungera med m˚anga scenarion. Datan f¨or dessa scenarion finns inte i koden utan h¨amtas fr˚an databasen inf¨or varje omg˚ang. I databasen sparas bland annat ekonomiska v¨arden, roller, f¨orutbest¨amda scenarioh¨andelser och chattmeddelanden. Denna struktur beskrivs i mer detalj i avsnitt 10. Ut¨over det hanterar databasen ¨aven anv¨andaruppgifter som e-postadresser och hashade l¨osenord.
8 Krav och utv ¨arderingsmetoder
I detta avsnitt beskrivs olika krav som satts upp f¨or systemet. F¨or att utv¨ardera hur v¨al kraven uppfylls beskrivs ¨aven utv¨arderingsprocessen.
8.1 Kompatibilitet med webbl ¨asare
M˚alet med projektet var att ta fram en minimum viable product som sedan kan vi- dareutvecklas till en f¨ardig produkt. Den f¨ardiga produkten ska g¨ora det enklare att h˚alla i finanskris¨ovningar och i f¨orl¨angningen g¨ora dem tillg¨angliga f¨or en bredare m˚algrupp. Vid utvecklingen av produkten valdes en webbimplementation f¨or att ¨oka tillg¨angligheten d˚a den blir oberoende av operativsystem. D¨arf¨or ¨ar det ¨aven viktigt att webbsidan fungerar p˚a m˚anga olika webbl¨asare.
8 Krav och utv¨arderingsmetoder
F¨or att testa webbsidors kompabilitet med olika webbl¨asare finns LambdaTest som erbjuder m¨ojligheten att k¨ora olika webbl¨asare via deras onlinetj¨anst [Lam]. Genom LambdaTest utf¨ordes tester f¨or webbsidan i Chrome version 81, Firefox version 75, Sa- fari version 13 och Edge version 80. Dessa webbl¨asare utgjorde i oktober 2019 91,45%
av den globala anv¨andningen av webbl¨asare [Sta19] och valdes d¨arf¨or som avgr¨ansning.
Under testerna f¨or varje webbl¨asare genomf¨ordes f¨oljande grundfunktioner i webbsidan:
• Skapa en ny ¨ovning
• G˚a med i en specifik ¨ovning
• Genomf¨ora rollspecifika drag
• Skicka meddelanden mellan olika anv¨andare
Kravet f¨or testerna ¨ar att webbsidan ska kunna genomf¨ora grundfunktionerna och sidans gr¨anssnitt ska fungera felfritt. Under testerna granskades huruvida grundfunktionerna och / eller gr¨anssnittet fungerade. Kravet anses uppfyllt om inga funktionella fel hittades under testningen.
8.2 Skydd mot SQL-injektion
SQL-injektion¨ar en attack d¨ar den som attackerar injicerar egen SQL-kod i SQL-kom- mandon som k¨ors i ett program. Ett vanligt fel ¨ar att SQL-kommandon som tar in para- metrar fr˚an anv¨andaren konkatenerar parametern i sj¨alva kommandot utan att kontrollera vad parametern inneh˚aller. Exemplet nedan ¨ar ett s¨att att skapa ett SQL-kommando som stoppar in ett v¨arde name i tabellen students.
query = "INSERT INTO ‘students‘ (name) VALUES (’" + name + "’);";
Detta s¨att att skapa ett kommando medf¨or en k¨anslighet mot SQL-injektioner. Om v¨ardet namekommer fr˚an en anv¨andare kan denne mata in f¨oljande str¨ang.
Robert’); DROP TABLE ‘students‘;--
8 Krav och utv¨arderingsmetoder
Resultatet blir d˚a f¨oljande SQL-kommando.
INSERT INTO ‘students‘ (name) VALUES (’Robert’);
DROP TABLE ‘students‘;--);
Detta kommando utf¨or tv˚a handlingar i databasen. F¨orst f¨ors v¨ardet Robert in i tabellen students. Sedan tas tabellen students bort fr˚an databasen.
P˚a alla platser d¨ar webbsidan ber anv¨andaren om indata formaterad som fritext m˚aste denna inmatning skyddas mot SQL-injektion. F¨or projektet anv¨andes manuella tester d¨ar SQL anv¨andes i enlighet med Software Testing Helps guide [Sof]. De manuella tes- terna gick ut p˚a att injicera ett kommando som f¨ors¨oker ta bort tabellen ”purchaseshisto- ry” fr˚an databasen i alla fritextrutor som anv¨andaren har tillg˚ang till. Ett exempel p˚a en s˚adan ruta ¨ar rutan d¨ar anv¨andaren fyller i sitt l¨osenord n¨ar den loggar in. Det specifika kommandot som anv¨andes var:
’; DROP TABLE ‘purchasesHistory‘;--
Ut¨over de manuella testerna testades SQL-injektion med det automatiska testverktyget sqlmap. Sqlmap har ett l¨age d¨ar den letar efter l¨ankar p˚a sidan som testas och testar dem f¨or SQL-s˚arbarheter. F¨or att anv¨anda det l¨aget startas sqlmap med parametern - -crawl=X d¨ar ”X” ¨ar antal sidor djupt sqlmap ska leta efter nya l¨ankar. Det l¨aget anv¨andes b˚ade som inloggad och icke-inloggad anv¨andare f¨or att testa att webbsidan var skyddad mot b˚ada fallen. F¨or att testa med anv¨andaren inloggad anv¨andes parametern --cookie=PHPSESSID=Y d¨ar ”Y” v¨ardet som togs ifr˚an webbl¨asaren kakor, d¨ar webbl¨asaren hade loggats in manuellt. N¨ar testet utan inloggning utf¨ordes anv¨andes inte den parametern.
Sqlmap kan ocks˚a testa k¨anda s˚arbarheter som ¨ar specifika f¨or ett databassystem, exem- pelvis MariaDB. F¨or att spara tid testades endast s˚arbarheter f¨or databassystemet Mari- aDB version 10.1 genom att ange parametern --dbms MariaDB 10.1. S˚arbarheter unika till andra databassystem, som Microsoft SQL Server, testades inte. Hela komman- dot som anv¨andes f¨or att genomf¨ora testen f¨or en inloggad anv¨andare var:
python sqlmap.py -u X --forms --batch --crawl=10
--cookie=PHPSESSID=Y --level=5 --risk=3 --dbms MariaDB 10.1 --formsanger att m˚alet f¨or attackerna ¨ar HTML-element. --batch g¨or att sqlmap v¨aljer standardalternativ ist¨allet f¨or att be anv¨andaren ange dem. Alternativen det ber¨or
8 Krav och utv¨arderingsmetoder
¨ar saker som ska slumpgenererad data anv¨andas f¨or att fylla i f¨alten?”, d¨ar standardal- ternativet ¨ar ”ja”. --level=5 och --risk=3 ber¨or vilka tester som ska anv¨andas.
F¨or dess exakta inneb¨ord, l¨as sqlmaps manual [sql]. Det kan r¨acka med en s˚arbarhet f¨or att riskera att hela systemet saboteras. D¨arf¨or kr¨avs det att plattformen ¨ar skyddad i alla testfallen.
8.3 Anv ¨andbarhet
Anv¨andare m˚aste kunna genomf¨ora en ¨ovning med varandra. Tre anv¨andare m˚aste kun- na delta i en ¨ovning samtidigt f¨or att fylla de tre roller (en centralbank och tv˚a privat- banker) som finns i testscenariot. En anv¨andare ska ocks˚a kunna delta i flera ¨ovningar samtidigt. F¨or att testa det ska anv¨andaren skapa ¨ovningar och bjuda in andra anv¨andare till dem. Samma anv¨andare ska ocks˚a kunna ansluta till andra ¨ovningar som k¨ors pa- rallellt f¨or att kontrollera att handlingar som g¨ors i ena ¨ovningen inte p˚averkar den andra ¨ovningen. I detta test skapades tv˚a ¨ovningar av samma anv¨andare. Sedan gick anv¨andaren med i tv˚a andra ¨ovningar med hj¨alp av ¨ovningarnas unika kod. N¨ar anv¨andaren var inne i alla ¨ovningar parallellt genomf¨ordes drag i alla ¨ovningar. Om ¨ovningarna inte p˚averkar varandras ekonomiska v¨arden och om anv¨andaren kan ansluta till alla ¨ovningar samtidigt kan detta krav anses vara uppfyllt.
P˚a ett liknande s¨att testas chattfunktionen. Ett meddelande som skickas i ena ¨ovningen ska bara g˚a att l¨asa i just den ¨ovningen och inte i n˚agon annan ¨ovning. Det meddelan- det ska bara synas f¨or anv¨andaren som skickade meddelandet och anv¨andaren som ¨ar mottagare.
8.4 Intressentens utv ¨ardering
Inom projektets ramar ¨ar f¨orv¨antan att plattformen ska kunna demonstrera att en digita- lisering av en finanskris¨ovning ¨ar m¨ojlig. F¨or att avg¨ora detta n˚agot subjektiva m˚al de- monstrerades plattformen f¨or Wendschlag, projektets intressent. Om Wendschlag anser att plattformen har potential f¨or att bli ett konkret komplement till finanskrivs¨ovningar som finns idag har detta m˚al uppn˚atts. Det som utv¨arderades av Wendschlag var inte tekniska kriterier utan funktionella m˚al som beskrivs i listan i avsnitt 3. Sammanfatt- ningsvis ¨ar den listan de grundfunktioner som kr¨avs f¨or att flera anv¨andare ska kunna utf¨ora en finanskris¨ovning tillsammans.
9 Ovningens gr¨anssnitt¨
9 Ovningens gr ¨anssnitt ¨
Tj¨ansten ¨ar ˚atkomlig via en webbsida som kr¨aver internetuppkoppling och en webbl¨asare.
N¨ar en anv¨andare ska b¨orja anv¨anda tj¨ansten beh¨over den f¨orst skapa ett konto som kr¨aver e-postadress och l¨osenord som inloggningsuppgifter. Anv¨andare m˚aste vara in- loggade f¨or att kunna genomf¨ora ¨ovningar, som p˚a webbsidan kallas games. Gr¨anssnittet f¨or registrering och inloggning kan ses i figur 3, d¨ar inloggningen finns l¨angst upp och registreringen under.
Figur 3 Registrering och inloggning.
Efter inloggning kan anv¨andaren v¨alja mellan att skapa en ny ¨ovning, ansluta till en existerande ¨ovning, eller forts¨atta en ¨ovning som anv¨andaren redan ¨ar ansluten till, vil- ket kan ses i figur 4. Under ”Your current games” kan anv¨andaren v¨alja mellan olika
¨ovningar som anv¨andaren redan har anslutit sig till. F¨or att ansluta till en ¨ovning beh¨over anv¨andaren en ¨ovningskod som fylls i under ”Join an existing game”. F¨or att skapa en
¨ovning finns l¨anken ”New game” l¨angst ner.
9 Ovningens gr¨anssnitt¨
Figur 4 Alternativ mellan att v¨alja, g˚a med i och skapa ny ¨ovning.
I figur 5 visas gr¨anssnittet vid skapande av ¨ovning. Anv¨andaren kan v¨alja hur m˚anga dagar, mellan 7 och 21, som ska simuleras, hur l¨ange ¨ovningen ska p˚ag˚a och vilket scenario som ska k¨oras. Plattformen ¨ar t¨ankt att kunna hantera flera olika scenarion som speglar olika finanskriser. ¨Ovningen skapas med de valda inst¨allningarna n¨ar anv¨andaren trycker p˚a knappen ”Start game”, varefter andra anv¨andare kan ansluta sig till ¨ovningen.
Figur 5 Alternativ vid skapande av ¨ovning.
I figur 6 visas en ¨ovningskod som syns h¨ogst upp i ¨ovningens gr¨anssnitt. ¨Ovningskoden
¨ar en unik str¨ang med tecken som identifierar en ¨ovning. Den kan anv¨andare dela med andra anv¨andare f¨or att de kan ansluta till ¨ovningen.
Figur 6 Koden f¨or ¨ovningen samt tiden i ¨ovningen.
9 Ovningens gr¨anssnitt¨
N¨ar en anv¨andare har anslutit sig till ¨ovningen f˚ar den v¨alja sin roll fr˚an en lista med tillg¨angliga roller f¨or det valda scenariot. Detta illustreras i figur 7. Bank One ¨ar i detta fall otillg¨anglig och visas d¨arf¨or i gr˚a text. Varje roll kan maximalt tas av en anv¨andare.
Figur 7 Lista av m¨ojliga roller f¨or anslutna anv¨andare.
I figur 7 finns ¨aven knappen ”Start Game” som endast syns f¨or skaparen av ¨ovningen.
N¨ar skaparen trycker ”Start Game” startas ¨ovningen f¨or samtliga anv¨andare. I ¨ovningen ser alla anv¨andare samma gr¨anssnitt, fast med ekonomiska v¨arden och drag som ¨ar an- passade efter deras roll. Ett exempel p˚a en implementerad roll ¨ar en bank som har en balansr¨akning och olika nyckeltal d¨ar bankens v¨arden redovisas i tabeller som kan ses i figur 8. Anv¨andaren kan se sina tillg˚angar (assets), skulder (liabilities) och nyckeltal i varsin tabell. I tabellen f¨or tillg˚angar finns bland annat cash som visar bankens pengar.
Deposits i tabellen f¨or skulder visar hur mycket pengar kunder har insatt i banken. I detta exempelscenario finns det uppsatta m˚al f¨or vissa nyckeltal som anses vara viktiga f¨or scenariot. Dessa m˚al som ben¨amns ”target” i bilden ¨ar procentm˚al som s¨atts enligt scenariot. I figur 8 ¨ar ett av bankens m˚al en avkastning p˚a eget kapital (return on equity) p˚a 15 procent.
Figur 8 Tillg˚angar, skulder och nyckeltal f¨or en bank.
9 Ovningens gr¨anssnitt¨
Anv¨andarna ser ocks˚a vilka drag som finns tillg¨angliga f¨or dem att genomf¨ora. Detta gr¨anssnitt kan ses i figur 9. Varje anv¨andare kan g¨ora flera drag under samma dag i
¨ovningen, d¨ar ber¨akningen av dragen senare kommer ske i samma ordning som an- v¨andaren valde dem. En anv¨andare kan d¨armed se olika resultat av samma drag beroende p˚a i vilken ordning dessa valdes.
De olika rollerna v¨aljer sina olika drag genom att trycka p˚a bocken f¨or ¨onskat drag.
D¨arefter fyller anv¨andaren i v¨ardet f¨or det draget i f¨altet ”value”. Till h¨oger om det f¨altet finns enheten f¨or draget, i detta fall dollar. K¨opa och s¨alja v¨ardepapper hanteras i enheten dollar medan till exempel justera styrr¨anta hanteras i enheten procent. Under
”Action summary” kommer alla valda drag listas f¨or anv¨andaren. Sedan kan anv¨andaren trycka ”submit” f¨or att genomf¨ora dragen.
Varje simulerad dag varar mellan klockan 09 och 17 enligt den virtuella tiden f¨or att spegla en vanlig arbetsdag. Virtuella tiden kan ticka olika snabbt mellan ¨ovningar bero- ende p˚a ¨ovningens inst¨allningar, det vill s¨aga hur m˚anga dagar som skulle simuleras p˚a hur l˚ang tid. N¨ar den virtuella klockan sl˚ar 17 g˚ar ¨ovningen ¨over till n¨asta dag, genomf¨or alla drag och uppdaterar all ekonomisk data.
Figur 9 Drag som kan v¨aljas av bank A.
Vid skifte av dag uppdateras ¨aven nyhetsfl¨odet, som kan ses i figur 10. F¨or varje scenario kan det finnas olika f¨orutbest¨amda h¨andelser. Exempelvis kan en tidningsartikel om allm¨anhetens dalande f¨ortroende f¨or banken komma ut, vilket kan ses under ”Financial News” i figur 10. Det kan vara nyttig information f¨or de olika anv¨andarna som p˚averkar hur de utf¨or sina n¨asta drag, mer ¨an att bara titta p˚a data.
Figur 10 Nyhetsfl¨ode som visas f¨or alla anv¨andare.
9 Ovningens gr¨anssnitt¨
F¨or att underl¨atta samarbete mellan deltagarna finns det en chatt som kan ses i figure 11. Genom denna kan deltagarna kommunicera med varandra och utbyta viktig infor- mation. Detta exempel visar vyn f¨or chatten fr˚an Bank 1:s perspektiv. En anv¨andare kan endast se egna skickade meddelanden och vad andra anv¨andare skickat till en. Samarbe- te mellan olika institutioner ¨ar en v¨asentlig del av finanskris¨ovningar. Anv¨andaren kan v¨alja vilka anv¨andare den vill kommunicera med.
Figur 11 Chatt mellan centralbanken och en privat bank
En ¨overblicksvy ¨over hela ¨ovningen kan ses i figur 12. Till h¨oger om sidans logotyp finns en navigeringsmeny. Under sidans logotyp finns ¨ovningskod och ¨ovningens virtuella klocka. I tabellerna under redovisas ekonomisk data f¨or anv¨andaren. De gr¨ona f¨alten ¨ar de m¨ojliga dragen f¨or anv¨andare. L¨angst ner till v¨anster finns chatt f¨or att kommunicera med andra anv¨andare, och ett nyhetsfl¨ode till h¨oger.
9 Ovningens gr¨anssnitt¨
Figur 12 Sk¨armbild p˚a en deltagares vy.
10 Hantering av scenarion
10 Hantering av scenarion
Plattformen ska kunna k¨ora m˚anga olika typer av finanskrisscenarion som ska vara enkla att implementera. I detta avsnitt beskrivs scenariostrukturen.
10.1 V ¨arden, drag, och effekter
N¨ar anv¨andaren kommer till ¨ovningens webbsida h¨amtas alla m¨ojliga drag fr˚an databa- sen. Oavsett vilken roll deltagaren v¨aljer laddas alla drag f¨or att ber¨akningsenheten ska kunna ber¨akna effekterna av alla drag. L¨as mer om ber¨akningsenheten i avsnitt 10.4.
moveID roleTypeID moveName moveEffects value Effect multiplier
2 1 K¨op statsobligation Statsobligation 1
2 1 K¨op statsobligation Pengar -1
3 1 K¨op AAA-obligationer Pengar -1
3 1 K¨op AAA-obligationer AAA-obligationer 1
1 2 F¨or¨andra styrr¨antan Styrr¨antan 1
Tabell 4 Sammanst¨allning av drag och deras effekter
I tabell 4 visas en sammanst¨allning av drag och de effekter som ¨ar kopplade till det dra- get. Alla drag h¨amtas fr˚an databasen oavsett vilket scenario som deltagaren har valt att genomf¨ora. Dragen med moveID 2 och 3 ¨ar b˚ada f¨or rolltypen med roleTypeID 1. I det h¨ar fallet motsvarar roleTypeID 1 en bank. Med rolltypen bank vet spelklienten att deltagaren ska kunna utf¨ora dragen med moveID 2 och 3. B˚ada de dragen har tv˚a effekter kopplade till sig medan drag med moveID 1 bara har en effekt. Draget med moveID1 h¨or till rolltypen centralbank.
Effekterna beskriver vilket f¨alt som kommer p˚averkas i kolumnen moveEffects va- lue. Exempelvis p˚a f¨orsta raden av tabell 4 beskrivs en effekt som ¨ar kopplad till draget
”K¨op statsobligation”. Effekten p˚averkar f¨altet ”Statsobligation” med Effect mul- tiplier, h¨ar med v¨ardet 1, multiplicerat med antalet statsobligationer som deltagaren valde att k¨opa. Effect multiplier lagras i MariaDB som decimal(10,2) d¨ar 10 anger totala antalet siffror f¨altet kan inneh˚alla och 2 anger antalet decimaler [Mar].
I tabellen ¨ar priset f¨or 1 statsobligation 1 enhet pengar, men priset kan vara ett av alla giltiga v¨arden som f˚ar plats i decimal(10,2).
10 Hantering av scenarion
scenarioID valueName roleID Starting value
1 Statsobligation 1 500
1 Statsobligation 2 300
1 Pengar 1 600
1 Pengar 2 200
1 AAA-obligationer 1 100
1 AAA-obligationer 2 900
1 Styrr¨anta 999 3,7
Tabell 5 Startv¨arden per scenario
Namnet i kolumnen moveEffects value i tabell 4 korresponderar med valu- eName i tabell 5. Dragen som kan v¨aljas ¨ar universella f¨or alla scenarion. F¨alten i valueName ¨ar ocks˚a universella men varje instans av f¨altet har ett eget numeriskt v¨arde. Exempelvis ¨ar f¨altet ”pengar” anv¨ant m˚anga g˚anger i samma scenario men alla roller som har en instans av f¨altet b¨orjar med ett eget numeriskt v¨arde. I tabell 5 finns det tv˚a instanser av ”pengar”. Deltagaren som har roleID 1 b¨orjar med 600 enheter av
”pengar” och deltagaren med roleID 2 b¨orjar med 200 enheter. De numeriska v¨ardena i tabell 5 ¨ar ¨ovningens startv¨arden. De numeriska v¨ardena ¨ar alltid samma n¨ar en ¨ovning med samma scenarioID p˚ab¨orjas.
Exempel:Deltagare g˚ar med i en ¨ovning d¨ar scenariot som har valts har scenarioID 1. Deltagaren valde rollen bank 1 som har roleID 1. All data som beh¨ovs h¨amtas redan n¨ar deltagaren laddar sidan f¨or ¨ovningen. N¨ar alla beroende v¨arden har ber¨aknats presenteras alla oberoende och beroende v¨arden i balansr¨akningen f¨or deltagaren. De oberoende v¨ardena syns i tabell 5. D˚a deltagarens roleID ¨ar 1 b¨orjar deltagaren med 500 statsobligationer, 600 pengar, och 100 AAA-obligationer. Namnet p˚a enheten finns i kolumnen valueName och m¨angden finns i kolumn starting value, b˚ada i tabell 5. Baserat p˚a det deltagaren ser i sin balansr¨akning v¨aljer deltagaren att g¨ora draget
”k¨op statsobligationer” och v¨aljer att k¨opa 100 enheter. Detta drag g˚ar igenom n¨ar n¨asta dag b¨orjar och ber¨akningsenheten ber¨aknar effekterna av draget ”k¨op statsobligationer”.
Effekterna av ett drag ber¨aknas i den ordning som de finns i databasen, i det h¨ar fallet tabell 4. F¨orst ber¨aknas antal statsobligationer deltagaren ska f˚a genom att multiplicera vald m¨angd statsobligationer att k¨opa, 100, med Effect multiplier, 1.
V ald m¨angd ∗ Ef f ect multiplier = P˚averkan p˚a v¨ardet av valueN ame
100 ∗ 1 = 100 (1)
Produkten av vald m¨angd och Effect multiplier adderas sedan till m¨angden statsobligationer deltagare redan har. Deltagaren hade redan 500 statsobligationer och
