PSD2

BITS PSD2-prosjektInternasjonale initiativerStatus på RTS og Guidelines

Brynjel Johnsen, Bits AS

1

2

▪ Status Norsk lovgivning▪ Finansforetaksloven – kommentarer

▪ Finansavtaleloven – prosess og innledende kommentarer

▪ RTS SCA▪ Prosess

▪ Siste status med konsekvenser

▪ Berlin Group▪ Presentasjon av arbeidet

▪ Status og prosess videre

▪ Katalogtjenester

12.10.2017

3

Tidslinje PSD2 og RTS (SCA/CSC)

2016

Både PSD2 og RTS har effekt i EU og Norge

PSD2 i effekt i Norge og EU

PSD2 i effekt i EU

Dagens dato

Teknisk gap

Lovgap

PSD2 iverksatt i nasjonal lovgivning i EU’s medlemsland

PSD2 iverksatt i nasjonal lovgivning i Norge

RTS høring og behandling

PSD2 vedtatt i EU, men 24 måneders effektueringstid

2017 2018 2019

RTS vedtatt, men 18 måneders effektueringstid RTS iverksatt i EU og Norge

Status og prosess Norsk lovgivning

4

5

Finansforetaksloven• Høring sommeren 2017 med frist 18. august

• Prinsipielt uheldig at høringen på Finansforetaksloven og Finansavtaleloven ikke skjer samtidig

• Implementering i Norge bør basere seg på at direktivet er innlemmet i EØS-avtalen, noe som bør skje snarlig

• RTS for Strong Customer Authentication and Common and Secure Communicationmå tre i kraft samtidig i Norge og EU• Myndighetene må veilede om overgangsperioden

• Det er behov for å avklare PSD2 opp mot taushetsplikt i finansforetakslovens § 16-2• GDPR er også en vesentlig faktor

• Begrepet «betalingskonto» må defineres presist, og tolkes likt i Norge som i Danmark og Sverige.• Her henviser høringsutkastet til Finansavtaleloven

6

Finansavtaleloven

• Forslag til ny Finansavtalelov ble publisert 7. september, med høringsfrist 15. desember

• Høringsutkastet inneholder bl.a. endringer som følge av de kontraktsrettslige delene av PSD2

• Finans Norge skal levere høringssvar på vegne av næringen

• Det var knyttet stor spenning til definisjonen av ‘betalingskonto’ i høringsutkastet, men etter det vi kan se så vises det til definisjonen av det tilsvarende begrepet i PSD1.

• Vi viser ellers til presentasjonen fra Justisdepartementet kl 13.25

Status og prosess RTSRegulatoryTechnical Standards onStrongCustomerAuthenticationand

CommonAnd SecureCommunication

7

RTS SCA / CSC

▪ Prosess i EU▪ Foreliggende utkast levert i slutten av mai

▪ RTS ligger nå hos visepresident i EU kommisjonen Valdis Dombrovskis

▪ RTS skal sendes på ‘Inter-Services Consultation’

▪ Estimert behandling ca 27. november 2017

▪ Med normal prosess kan RTS bli publisert mars 2018

▪ Dette innebærer at den trer i kraft pr September 2019

8

Signaler fra EU-kommisjonen

9

Screen Scraping eller ikke?

10

Utgangspunktet i RTS var at Screen Scraping skulle være forbudt• Tredjeparter skulle benytte seg av «dedikert grensesnitt»• Banker og IT leverandører utvikler API’er basert på RTS

Tredjepartsaktører stiller spørsmål ved om bankene kommer til å tilby gode nok API’er• Det stilles spørsmåltegn ved både oppetid og funksjonalitet• EU kommisjonen foreslår at TPP’er skal kunne benytte «fallback-interface» som i

prinsippet er en screen scraping med identifisering av TPP

I løpet av sommeren har det vært omfattende lobbyvirksohmet mot EU-kommisjonen• Banker på den ene siden som står hardt på «dedicated interface»• TPP’er på den andre siden som ønsker tilgang til brukerens grensesnitt• Det kan se ut som det går mot en kompromissløsning

11

Hvis banken tilbyr dedikert grensesnitt (API), så må TPP bruke det.

Dette betyr følgende

TPP’er kan ikke fortsette å bruke ‘Screen-scraping’ når RTS trer i kraft, så lenge API’et tilfredsstiller kravene til funksjonalitet og oppetid.

Banker som har velfungerende API skal dessuten kunne få unntak fra regelen om plikt til å tilby fallback (screen scraping med identifisering av TPP). Motivasjon for bankene til å gjøre en god jobb – og tilby det som TPPene ønsker.

Signaler fra EU-kommisjonen om endelig RTS

Hva er et velfungerende API?

12

API’et må ikke forhindre en TPP i å utøve deres forretningsmodell

Banken kan ikke fortolke hva som skal tilbys selv

De nødvendige data må være tilgjengelig i APIet

Behov for standardisering og koordinering

APIet må oppfylle krav til oppetid og tilgjengelighet

Driftsmessige forhold blir viktig

SCA må ikke være «komplisert»

Bankene kan ikke påtvinge «redirect» SCA

Mange banker i Europa og Norge har basert sin løsning på ‘redirect’ SCA. Disse løsningene kan bli problematisk å tilby som default, hvis banken ikke har en annen løsning basert på ‘decoupled’ eller API-basert ‘embedded’ SCA.

Prinsipp Konsekvens

Hva er et velfungerende API?

1313

Det skal ikke være nødvendig for en TPP å registerere seg (onboarde) hos en bank

Banker som har lagt opp til oboarding og registerering av TPPer kan sannsynligvis ikke regne med å fortsette med det.

Samtykkehåndtering skal gå via APIet – altså mellom TPP og bank

Håndtering av samtykke kan ikke gjøres utenfor APIet, dvs mellom PSU og bank uten at TPP er involvert.

Prinsipp Konsekvens

Implementering av RTS

14

Bankene og TPPene må vise at de kan samarbeide• 3 måneders teknisk testperiode• 3 måneders markedstestperiodeDette vil overvåkes nøye av tilsynsmyndighetene i landene og rapporteres til EBA

For å rekke fristen i september 2019 betyr dette at bankene i Europa senest må ha sine API’er, SCA-løsninger og eventuelle fallback-løsninger på plass i begynnelsen av 2019

Hvis en bank ikke oppfyller kravene til et velfungerende API kan tilsynsmyndighetene pålegge de å akseptere ‘fallback’ altså screenscrapingmed identifisering av TPP

‘Ris bak speilet’

ERPB har nedsatt en API expert Group

I det følgende vises det til de ‘kravene’ som TPPer har fremsatt i denne gruppen.

15

16

Samtykkehåndtering skal skje hos TPP

From a legal point of view, the PSU gives consent to the TPP per Article 64 PSD2 (confirmed by Article 80 (2) PSD2). TPP can access accounts on a non-discriminatorybasis vis-a-vis the payer itself per Article 66 (4c) and Article 67 (3b) PSD2. The ASPSP canblock AIS/PIS only per Article 68 (5) PSD2.

API’et må ikke innholde noen håndtering av Samtykke

• PSU gir samtykke til TPP• Banken skal ikke behøve å kontrollere dette• Banken skal ikke ha noen funksjon for å styre tilganger da dette er fullt

ut håndtert av TPP

Informasjon om gjennomføring av betaling

17

For Batch-betalingssystemer må API’et må gi følgende informasjon om gjennomføring av betaling:

• Saldo før initiering av betalingsoppdraget, som korresponderer til siste kjente saldo, forfallsregister og reservasjoner, og eventuell kreditt.

• Kontoutskrift (beløp, tekst og typer av betalinger) for samme periode som PSU selvkan se I nettbanken.

• Saldo etter at betaling er initiert og betalt.

TPP kan benytte kontohistorikk til å risikoen for at en betaling ikke blir gjennomført

• Om betaler pleier å ta ut mye penger på konto, eventuelt overføre• Lønnsinnbetalinger• Periodiske utbetalinger

Brukergrensesnitt

18

TPP skal «eie» hele brukeropplevelsen:

TPP’en har rett til å designe brukergrensesnittet for hele kundereisen, inkludert samtykke, innlogging, autentisering o.l. uten å måtte redirigerebrukeren til bankens grensesnitt.

API’et må ikke sette noen krav til enheten som benyttes av PSU og må kunne håndtere utveksling av data kun mellom TPP og ASPSP gjennom sesjonen. Løsningen må være fremtidsrettet, legge til rette for innovasjon og ikke være begrenset til web-baserte betalingsløsninger.

Sesjoner må dekke alle use-cases

19

Direktivet skiller mellom ulike use cases

ASPSP

PISP

AISP

PIISP

Use-casene må ikke være bindende for hvordan det dedikerte grensesnittet designes. Det må være mulig for en TPP å kombinere funksjoner for både AIS og PIS tjenester i en og samme sesjon.

ASPSP

PISPAISP

PIISP

Strong CustomerAuthentication

20

API’et må støtte alle SCA-mekanismer som banken tilbyr, men må ikke forutsette at TPP bruker redirect, dvs bankens tjeneste på en nettside

Prinsippet er at TPP må kunne designe brukergrensesnittet uten å måtte forholde seg til teknologivalg gjort av banken

ASPSP

PISP

AISP

PIISP

PSU

Redirect SCA

‘Betalingsgaranti’

21

PIS-tjenester i en batch-orientert betalingsinfrastruktur er avhengig av å kunne vurdere risikoen for at en betaling ikke blir gjennomført.

ASPSPBetaler

Batchsystem

ASPSPBetalings-mottaker

Payer

Payee

‘Betalingsgaranti’

PISP

Problem: Betaleren kan stanse betalingen før den går.Løsning: PISP må få tilgang til kontoutskrift, forfallsregister mv for å kunne vurdere risikoen

API for tilgang til konto

Standardiseringsarbeid

22

EU er ekstremt opptatt av konkurranse på like vilkår

23

24

TPP

TPP

TPP

TPP

TPP

TPP

TPP

TPP

ASPSP

ASPSP

ASPSP

ASPSP

ASPSP

ASPSP

ASPSP

ASPSP

Fryktet situasjon

12.10.2017Navn på presentasjon

25

Ønsket situasjon

TPP

TPP

TPP

TPP

TPP

TPP

TPP

TPP

ASPSP

ASPSP

ASPSP

ASPSP

ASPSP

ASPSP

ASPSP

ASPSP

Bits har vært med som deltager i Berlin Group sitt standardiseringsinitiativ

▪ Berlin Group sitt standardiseringsinitativ ble sendt på offentlig høring 2. oktober, med frist 17. november

▪ Det avholdes en PSD2 konferanse om initiativet den 25. oktober i Berlin▪ Dokumentasjon

▪ Operational Rules dokument som beskriver bruk av standarden

▪ Implementation Guidelines dokument som beskriver standarden

▪ Det vil komme endringer▪ Som følge av høringen

▪ Som følge av endelig RTS

▪ Publisering av endelig standard Q1 2018▪ Bits vil lage et generisk appendix for norske betalingstjenester som kan benyttes med Berlin

Group standard og andre standarder

26

Deltagere fra hele Europa

27

Elementer i standarden

▪ Støtte for PIS, AIS og PIISP betalingstjenester▪ Støtte for ulike typer former for SCA (redirect, decoupled og embedded)▪ Støtte for å håndtere samtykke, også ved hjelp av OAuth2

28

Støttede use-cases

▪ AISP▪ Establish account information consent

▪ Get list of reachable accounts

▪ Get balances for a given list of accounts

▪ Get transaction information for a given account

▪ PIISP▪ Get confirmation on the availability of funds

▪ PISP▪ Initiation of a single payment

▪ Status query

29

Tekniske standarder▪ Transport Protocol

▪ HTTP version 1.1

▪ TLS version 1.2 for communication between TPP and ASPSP

▪ Applicative Protocol▪ REST

▪ Authorization Protocol▪ OAUTH2 (optional)

▪ Character set▪ UTF-8

▪ Data structure▪ JSON & XML

▪ Data model origin▪ ISO20022

▪ Identifier naming convention▪ ISO20022 extended names

30

Katalogtjenester

Det er behov for mye informasjon om aktørene for å skape tillit i en åpent økosystem

▪ Nasjonale myndigheter skal etablere et autorisasjonsregister over tilbydere i egen hjemstat.▪ EBA skal etablere et europeisk autorisasjonsregister over tilbydere, men registeret blir ikke

komplett eller maskinlesbart.▪ TPP’er skal utstyres med et kvalifisert sertifikat som er koblet opp mot autorisasjon i hjemstaten▪ Banker er pålagt å informere om sine tjenester, tilgangspunkter, grensesnittspesifikasjon og

annen dokumentasjon▪ Både TPP’er og banker må kunne finne hverandre i avviks- og reklamasjonssaker

Det er flere aktører i Europa som jobber med å etablere katalogtjenester som skal tilby online grensesnitt for å søke opp informasjon om alle aktører, deres roller, autorisasjoner, tekniske tilgangspunkter mv. Bits støtter de norske bankene i arbeidet med å ta i bruk slike tjenester.

31

Takk for meg

32

▪ Brynjel Johnsen▪ E-post: brynjel.johnsen@bits.no▪ M: +47 48041048

▪ Bits AS▪ Hansteens gate 2

▪ P.O. Box 2644▪ N-0203 Oslo▪ www.bits.no