Is the "screen-scraping" real issue under PSD2 ? Who's rebelling and who is trying to preserve "status-quo" ? The pitch delivered during #FintechFriday event by Squire Patton Boggs, Warsaw office, thanks to invitation by Jacek Wiśniewski. You can find me at LinkedIn and Twitter for more fintech & banking news.

1. Fintech Rebellion ?
“Screen-scraping” under PSD2
BANK
FINTECH
(R)EVOLUTION
MARIUSZ OŻGA
9th June 2017

2. Disclaimers
The opinions expressed in this article are the author's own and do not reflect the view
of the author’s employer (AliorBank).
The opinions expressed in this article do not constitute legal opinions and the author
shall not be deemed liable for any decisions undertaken assuming those opinions.

3. Legal framework & timeline
RTS
National regulation
Poland: Ustawa o zmianie ustawy
o usługach płatniczych
(projekt UC81)
Nov 2015
Jan 2018 ?
EU
Poland
3Q 2017 ?
SCA
CSC
1Q 2019 ?1Q 2018 ?you / we
are here

4. What do they want ? Who is rebelling ?
screen-scraping APIs
● direct access with credentials
transfer
● continue to use screen-scraping
● technologically proven
● protect fintechs business
models
● interface access, no credentials
transfer
● data protection and customers
security
● ban screen-scraping altogether
● provide countrywide standard

5. Current state of play: it’s not about Poland
effectively:
delay of RTS
Transition period, Art 109 of PSD2: explained by EC in 1 July RTS version
Western Europe:
screen-scraping
Poland:
screen-scraping banned
new law effectively not in
force right away?
IF screen-scraping stays
it will have an impact, but from 2019

6. SCA
Strong Customer Authentication - authentication based on the use of two or more
of the following elements:
● knowledge - ‘something only the user knows’ (eg. static password, code, PIN)
● ownership - ‘something only the user possesses’ (eg. token, mobile, smart card)
● inherence - ‘something the user is’ (eg. biometrics)
Items selected must be mutually independent, i.e. the breach of one does not
compromise the other. Procedure should be designed to protect confidentiality of
the authentication data.
A catalogue of notable exemptions: 90 days rule for AIS; contactless at POS;
parking fees; trusted beneficiaries; recurring transactions; same owner; low value;
corporate payments (+cards ?); risk analysis based.
Still valid when “direct access” applied.

7. When “direct access” applies
EC on RTS latest version as of 1 July:
“direct access” as a fallback scenario
as a result of
API inaccessibility
In other circumstances screen-scraping will not be allowed
30 secs rule
not delivering level of
performance/availability
performance rule

8. Direct access - appliance of rules
as of RTS, art 33
● PSP (TPP) needs to be identified (TTP access control
still valid)
● authentication procedures as for user
● PSP not allowed to access/store/process data for
purposes other than services requested by user
● documentation (logs) of data accessed shall be stored
and delivered to national authority (when asked)
● inform/justify to ASPSP (bank) & national authority

9. A number of outstanding issues
● who is entitled to determine and control the breach of
direct access appliance rules ?
● are TPPs allowed to ask their customers to share
credentials as preemptive measure (managing
expectations) ?
● how does it changes responsibilities of banks to protect
confidentiality of the authentication data ?
● how does that change responsibility for frauds ?
● does it apply to local API standards or banks alone ?

10. PolishAPI standard
set of
technological
standards
(Polish RTS):
compliance services
vs premium
countrywide
TPP access
control
(+blacklisting)
one-point
data entry access
(hub)
● no credential sharing
● voluntary participation for both banks and TPP
● customer opt-out possible

11. Bank strategies: battlegrounds vs cooperation
comply monetize
access
utilize
ext. data
Partner
ecosystem
business
model
API’s
PolishAPI
standards &
compliance
services
PolishAPI
standards,
compliance &
premium
services
PolishAPI
standards &
compliance
services; some
own APIs
PolishAPI
standards only;
amount of own
and specialized
APIs
compliant
only/fallback
(if required)
direct
access
compliance only monetize access
to data for extra
reve
bank as TPP (new
services/advice)
become ‘everyday
bank’; offer
non-financial services
with added value
compliant
only/fallback
(if required)
compliant
only/fallback
(if required)
compliant
only/fallback
(if required)

12. What do customers want ?
67%
willing to
share their data with
banks in return for new
benefits (Accenture)
93%
trust banks to keep
their money safe (EY)
User-experience: balance between utility and security
33%
customers of Polish banks
confirm utility as leading factor
for choosing finance
management tools
(PWC)
53%
happy for TPP initiating
payments on their
behalf (Accenture)
94%
stressed that any new
payment service at
least as secure as
method they use
(Accenture)
70%
would not trust TPP as
much as a bank with
their data (Accenture)

13. Thank you !
@MozgaOzga
Mariusz Ożga
BANK
FINTECH
(R)EVOLUTION