- Den første moderne API-en vår ble implementert i 2012. Da bestemte vi oss for å bygge våre egne nettløsninger API-basert, forteller digitalsjef Terje Løken i Storebrand til kode24.
- Det var en fornuftig måte å bygge egne løsninger på. Samtidig hadde vi en liten baktanke om at API-ene kunne bli brukt til andre ting.
Den ble de, også. For i 2015 lanserte Rema 1000 sin egen forsikring – med Storebrand som leverandør, og API-ene deres som livsnerve.
Tidligere i år ble den svenske spareappen Dreams lansert i Norge – også denne med Storebrand som partner, og med deres API-er for å styre pengestrømmen.
Siden har Rema 1000 lagt ned forsikringen sin, og Dreams står i dag alene som tredjepartsbruker av Storebrands rikholdige utvalg av bank-API-er. For REST-endepunktene er ikke åpne for hvem som helst.
Men i løpet av 2019 kan både Storebrands og alle andre bankers API-er åpnes opp med tvang. PSD2-direktivet skal nemlig snu opp/ned på hele finansbransjen.
Angular, React, Kotlin, Docker
API-ene til Storebrand utvikles av en avdeling på rundt 35 utviklerne på Lysaker, like over Akershus-grensa. Og nøyaktig hvordan de gjør det, skal være mye opp til teamene selv.
- Vi er ikke så rigide på metode. Minst mulig seremoni og prosess, men akkurat nok til å vite hva som skal skje og ha oversikt, forteller Løken.
Noen kjører daglige standup-møter, noen gjør det én gang i uka, andre tar det over Slack, mange organiserer jobben med Trello. Noen skriver frontend med Angular, og noen i React.
- Her er det nok rundt 60 prosent Angular og 40 prosent React. Det er ingen styrt beslutning; vi lar det være opp til teamene. Så lenge det fungerer for dem, er det greit for oss, forklarer Løken.
Storebrand har blitt glad i Docker, og API-ene og backend-koden skrives ofte i Kotlin, med mye gammel Java i kodebasen.
- Det er av historiske grunner. Men det er ingen forskjell for oss om de nå skriver straight Java eller bruker Kotlin, så foreløpig sier vi at de som vil bruke Kotlin får lov, sier Løken, og ser på sidemannen; utvikler Lars Lech-Hanssen.
- Det synes vi er fint. Vi spør om å få lov til å bruke noe, og får som regel beskjed om at «jaja, kjør på», smiler Lech-Hanssen.
API-er ga kundeflom
Akkurat nå er det altså bare spareappen Dreams som bruker Storebrands API-er – i tillegg til Storebrand selv, såklart.
Bouvet advarer mot microservices
Dreams-appen prater med Storebrand gjennom microservices på en Linux-løsning, hvor API-ene, BankAccept og Storebrands kjernesystemer sys sammen med Dropwizard, Spring, og Kotlin,
Spareappen skal ha omlag 74.000 brukere i Norge. Og alle disse må opprette en konto hos Storebrand for å få spart pengene sine.
- Så deres jobb med API-ene har på mange måter sikra Storebrand potensielt 74.000 nye kunder, da?
- Ja, man kan vel si det, smiler Løken.
API for de få
Men der andre åpner API-ene sine for alle utviklere som vil eksperimentere med dem, stenger Storebrand dørene. Uten en avtale får du ikke tilgang på noe som helst.
«Vi foretrekker at folk kommer og snakker med oss.»
- Det er litt fordi vi vil vite hvem som bruker dem. Det kunne vært fint å gi folk en sandkasse, men vi har ikke prioritert å få en full infrastruktur på plass for å automatisk godkjenne brukere med vilkår og API-nøkler. Så vi foretrekker at folk kommer og snakker med oss, og da er vi veldig interesserte i å snakke med dem, forsikrer Løken.
- Men det kommer nok til å ta en stund før vi kommer dit at vi slipper løs alle ukjente tredjeparter på alle produksjons-API-ene våre.
- Hvorfor ikke? Andre banker, for eksempel Sparebank 1, gjør jo nettopp det, med vidåpne API-er.
- Joda, det er jo mulig, ved å slippe veldig begrensede subsets. Så det er interessant, og noe vi kunne gjort, men det er ikke alltid så lett å finne tid til.
Må åpne med PSD2
Men snart må Løken, Lech-Hanssen og de andre Storebrand-utviklerne finne denne tiden enten de vil eller ei.
2019 blir trolig året da EU-direktivet PSD2 trer i kraft i Norge. Veldig kort fortalt må blant annet banker da åpne opp dataene sine, slik at bankkontoene våre blir mer sammenliknbare med epost-kontoer.
Slik skriver de testene sine i Sparebank 1
Informasjon om for eksempel saldo og transaksjoner skal nemlig bli tilgjengelig for flere enn banken selv, og pengene skal kunne flyte fritt fra bank til bank. Med andre ord: Mange av API-ene må åpnes.
- Rent regulatorisk er september 2019 fristen for å ha dette på plass. Men personlig tror jeg det blir en ganske lang innkjøringsperiode, sier Løken til kode24.
For hvordan skal malverket til API-ene se ut? Skal bankene få en slags hub for å lettere snakke sammen? Må en app kalle på hundrevis av bankers API-er for å selv finne ut hvor en bruker er kunde? Og hvordan sikrer man en god, universell autentisering?
- Det er fortsatt mange ubesvarte spørsmål, mener Løken.
Tror ikke på gullalder
Med PSD2 på plass, kan utviklere trolig koke sammen massevis av nye apper og tjenester. Misfornøyd med mobilbanken? Last ned en ny. Vil du bruke spareapper, men få penga til din gamle bankkonto? Åpne API-er fikser biffen.
Noen spår derfor en ny gullalder for fintech, finansteknologien, i kjølvannet av PSD2.
- Selv tror jeg ikke det blir en ny gullalder, men det åpner for noen nye muligheter, sier Løken.
Selv mener han nemlig at PSD2 krever en relativt begrensa åpenhet, og at det uansett er begrensa hvor mange tjenester man trenger for å ha kontroll på daglig forbruk og betaling.
- Du sier ikke bare det fordi du frykter konsekvensene av PSD2, da? Litt av poenget med direktivet er vel at den etablerte bransjen skal skjelve litt i buksene.
- Økt konkurranse må jo alltid være en trussel for noen. Men vi er en liten bank, som selv kan ha mye nytte av å bruke PSD2, for eksempel for å gi mer helhetlige råd om sparing og pensjon, svarer teknologisjefen.
- Så vi har masse tenker om gode tjenester vi kan levere framover.
- Utviklere liker open source fordi det gir bedre kode!
Prosjektlederen til Entur mener open source var nøkkelen til suksess.