To
The European Banking Authority
From
Payments UK
Financial Fraud Action UK
The UK Cards Association
8 February 2016
JOINT PAYMENTS UK, FFA UK & UK CARDS ASSOCIATION RESPONSE – EBA
DISCUSSION PAPER ON DRAFT RTS ON STRONG CUSTOMER AUTHENTICATION AND
SECURE COMMUNICATION UNDER PSD2
1
INTRODUCTION
Payments UK: Payments UK is a trade association launched in June 2015 (taking over from the
Payments Council) to support the rapidly evolving payments industry. Payments UK brings its
members and wider stakeholders together to make the UK’s payment services better for
customers and to ensure UK payment services remain world-class.
Payments UK’s main roles are:
• To be the payments industry’s representative body: providing an authoritative voice in the
UK, Europe and globally, and working with stakeholders to share payments knowledge
and expertise.
• To be a centre for excellence: supporting the UK payments industry to provide world-class
payments, building on the experience, thought-leadership and project delivery expertise
behind award-winning initiatives such as Paym, the Current Account Switch Service and
Faster Payments.
• To deliver collaborative change and innovation: working on behalf of our members to
benefit customers and UK plc, ensuring their needs are understood and met, both now and
in the future.
Financial Fraud Action UK: Financial Fraud Action UK (FFA UK) is responsible for leading the
collective fight against fraud in the UK payments industry. Its membership includes the major
banks, credit, debit and charge card issuers, and card payment acquirers. Through industry
collaboration FFA UK seeks to be the authoritative leader in defending consumers and businesses
from financial fraud, by creating the most hostile environment in the world for fraudsters.
FFA UK’s primary role is to drive collaborative action to reduce the impact of financial fraud and
scams both across the industry, and with partners in the public sector, private sector, and law
enforcement. It operates its own data and intelligence sharing bureau and sponsors a fully
operational police unit.
Payments UK 2 Thomas More Square London E1W 1YN
A Company incorporated in England No 6124842.
Registered Office as above
The UK Cards Association: The UK Cards Association is the trade body for the card payments
industry in the UK, representing financial institutions which act as card issuers and acquirers.
Members of the Association account for the vast majority of debit and credit cards issued in the UK
- issuing in excess of 56 million credit cards and 95 million debit cards - and cover the whole of the
payment card acquiring market.
The Association promotes co-operation between industry participants in order to progress noncompetitive matters of mutual interest; informs and engages with stakeholders to shape legal and
regulatory developments; develops industry best practice; safeguards the integrity of the card
payments industry by tackling card fraud; develops industry standards; and co-ordinates other
industry-wide initiatives such as those aiming to deliver innovation. As an Association we are
committed to delivering a card payments industry that is constantly focused on improved outcomes
for the customer.
2
OPENING REMARKS
•
•
•
•
1
We support the EBA’s aims: We support the aims of the EBA and appreciate the
opportunity to provide views to the EBA before the RTS consultation is published in Q2/Q3
2016. From the UK perspective we have a real interest in helping the EBA to come up with
a framework that will allow this ecosystem to flourish – the UK is becoming increasingly
digital. According to the Commission 89% of UK consumers use the internet compared to
75% of EU consumers; and 85% of UK internet users shop online. Meanwhile 19% of UK
1
SMEs sell online (versus 15% of EU SMEs) .
We understand that the EBA needs to find a balance between competing demands:
On page 9 of the discussion paper the EBA makes reference to several trade-offs and
competing demands. We appreciate the difficult task the EBA will have so we have tried to
keep our response positive and constructive. Where we do have clear views we have
provided these so that the EBA can get a clear picture of how we envisage this new
ecosystem forming and developing.
Fairness, clear risk/liability, technological neutrality: The RTS must facilitate the
creation of an environment that is fair, with clear delineation of risk and liability.
Technological neutrality and providing scope for innovation must also be ensured
wherever possible.
We would also emphasise that the EBA needs to create a framework that will work
for businesses as well as individual customers. Much of the discussion paper seems to
be focused on what is required to make this work for individual consumers. However, we
note that it must work equally well for businesses and corporates too. This is why
throughout this response we urge the EBA to put in place principles that enable flexibility
and risk-based decision-making.
Communication on the Digital Single Market: factsheet for the UK
Page 2
3
OVERARCHING POINTS
A. As the EBA identifies, there are trade-offs between prescription and convenience, and
between detail and flexibility. To achieve the objectives of PSD2 and balance the tradeoffs effectively the EBA should produce regulatory technical standards at a high level.
In addition, to ensure the safe development of a competitive third party provider market
the EBA should support the creation and adoption by the industry of open Application
Programming Interface (API) standards.
•
Security and integrity of the payment systems are of the utmost importance: The
payments industry believes that the security and integrity of the payments system is of the
highest importance, not only for general economic stability but in terms of ensuring
2
continued high consumer confidence . The industry works most effectively when it is able
to respond dynamically and quickly to new and emerging threats. Increasingly criminals
are taking advantage of the availability of customer data in order to effect fraud and other
criminal activities. To highlight this, we note that in the UK in Q3 2015 alone, there was a
147% increase in data hacks / compromise incidents. A top 4 UK retail Bank reported that
their organisation had seen a very significant increase (circa 50%) in card fraud that
emanated from data compromise. This is why we stress throughout this response the vital
importance of putting in place processes that can enable the legislative aims of PSD2 but
which nevertheless allow PSPs to maintain high levels of security, integrity, protection of
customer data and customer control.
•
The areas of security and authentication are highly complex and are constantly
developing. We believe the EBA should design the RTS at a high level and not try to
define detailed ‘technical implementation standards’: The risk of the EBA being too
prescriptive is that the industry will be hampered from responding and reacting to
cybercrime and fraud threats adequately and the requirements will be quickly outdated,
and it may be more difficult to innovate.
•
EBA principles: We believe that at a high level the EBA’s should produce principles
focused on openness, transparency, accessibility, usability, user control, security,
extensibility and interoperability.
•
Once the EBA has defined its principles, it should be for the market to implement
these at a technical level. Our view is that the market can best achieve the aims of
PSD2 through the use of open APIs (Application Programming Interface). The EBA
should support the industry to create and adopt open API standards. Overall our view
is that the interaction between customers, PISPs, AISPs (which we refer to collectively as
Third Party Providers i.e. TPPs) and ASPSPs as described in PSD2 is most effectively
achieved via an open API infrastructure. API technology is the accepted norm for secure
data-sharing and embedding functionality in an online environment. The use of APIs is
widespread and today there are more than 14,000 public APIs available. Alternative
technologies for sharing data exist, but are less robust and less secure than APIs.
2
The Commission Communication on the Digital Single Market: factsheet for the UK stated that 39% of the
UK (43% EU) are concerned about someone misusing their personal data and 49% of the UK (42% EU) are
concerned about the security of online payments
Page 3
•
We believe that the API standards should be ‘open standards’, developed and
maintained collaboratively and transparently. Two main types of standard will need to
be developed by the industry: data standards (rules by which data are described and
recorded) and API standards (specifications that inform the design, development, security
and maintenance of the API). But it is important to understand that API standards are not
rigid and unchanging. They can be highly open, flexible, and adaptable, with the ability to
be used differently by stakeholders depending on their business model and needs. They
will not prevent variation and innovation of new models, but rather enhance and encourage
them.
Where possible and practical the industry will seek to reuse existing standards,
taxonomies, etc. The open API standards will facilitate the delivery of the Commission’s
aims for increased access and innovation. A good ‘developer’ / TPP experience will be an
important aspect of ensuring that the new ecosystem works well. To agree this approach
an industry body where all types of industry participants have a voice will be required.
•
Importance of standardisation and interoperability: Any successful network business
depends on common standards. To create a strong network effect the users must be able
to interoperate – to communicate in a standardised way. For example, the collaborative
payment and clearing infrastructure is a network business which is dependent upon
technical and business interoperability. Industry standards are essential for the efficient
and resilient operation of the payments industry as well as ensuring that participants and
end users interact in a safe, dependable and predictable manner.
o In a global economy of rapidly emerging new technologies, standards help set the
rules. Standards can help set a baseline framework that can act as a springboard
for quick innovation, commercialisation, continuous change and innovation at less
cost and risk.
o If implemented well, standards can improve industry interoperability between
counterparties both within a particular jurisdiction as well as cross-border, both in
other markets and currencies.
o Standards also reduce the complexity, cost and risk of data manipulation and
conversion in the inter-bank space and between banks and their customers.
Standards enable competition and have been used as the basis for developing
new products and entering new markets (both domestic and external).
o Standards further enable competition by reducing barriers to entry to infrastructure
as they provide a common, level playing field for all participants. The
implementation of standards does not mean that it forces all participants to
conform identically. It creates a landscape that enables flexibility but also
consistency.
•
Avoiding fragmentation: There will always be a potential for fragmentation in the market.
However, we support the aim of reducing fragmentation as far as possible for the benefit of
consumers, businesses and providers. It will be a challenge for the market (i.e. all
stakeholders, including fintechs, banks and consumer bodies) to come together to design
common open standards that work on a pan-European basis, but it can be done with the
right support and backing of the regulators and authorities. Ideally, standards should be
Europe-wide, but if this proves difficult or slow to agree, it would be preferable to develop
national standards with a separate agreement on inter-operability between them.
Page 4
Recent related UK experience might be of interest to the EBA as it develops its thinking in
this area.
•
In Autumn 2014 a report titled “Data sharing and Open Data for banks” was published by
the UK Government (HM Treasury) to explore how competition and consumer outcomes in
UK banking could be affected by banks giving customers the ability to share their
transaction data with third parties using external Application Programming Interfaces
(APIs). As part of the work, the report also reviewed how these outcomes would be
improved if banks published non-personal data as ‘open data’. The Report set out a
number of recommendations:
o That banks should agree an open API standard for third party access.
o Independent guidance should be provided on technology, security and data
protection standards that banks can adopt to ensure data sharing meets all legal
requirements.
o An industry wide approach should be established to vet third party applications
and publish a list of vetted applications as open data.
o Standard data on Personal Current Account terms & conditions should be
published by banks as open data.
o Credit data should be made available as open data.
•
In February 2015 HM Treasury published a consultation on the Report. In the March
Budget, HM Treasury published its statement on the consultation and next steps:
o The Government committed to deliver an open API standard in UK banking;
o It proposed to set out a detailed framework for the design of the open API
standard by the end of 2015;
o It believed the development of an API standard that meets the requirements
around data protection and security, with reasonable cost, could be feasible in 1 to
2 years.
•
Following this, three trade associations (including Payments UK), working with
Government, set up a multi-stakeholder group (the Open Banking Working Group –
‘OBWG’) to come up with the framework for the design and delivery of an open API
standard in UK banking. The OBWG included a wide range of market participants
including Government, TPPs, other fintechs, consumer organisations, businesses and
banks.
The final framework report, which was published on 9 February 2016, provides a high
degree of detail on precisely the challenge that is posed by PSD2, namely how to create
an ecosystem utilising API infrastructure where customers can permission TPPs to access
account data and initiate payments.
We believe that the role of the EBA RTS is to provide the principles needed to ensure that
a standardised ‘communication’ ecosystem between all players (including ASPSPs and
TPPs) can emerge. The purpose of this standardised approach is not to force every player
to do business in the same way but to provide the common basis that enables
differentiation and innovation but with a clear view of rights and responsibilities.
•
•
3
3
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/382273/141202_API_Report_FINAL.
PDF
Page 5
o
o
In the UK our view is that this is best achieved via the implementation of an open
API infrastructure.
This work should also help to support the requirements of the Network and
Information Security Directive.
B. We acknowledge that the PSD2 text is set as regards making credentials ‘accessible’ to
TPPs (though it’s not clear what this means in practice). However, we do not believe
that the aims of PSD2 (i) to give customers control over what information they make
available and (ii) to create a multifactor authentication environment, can be properly met
by customers providing their credentials to TPPs who will log in on their behalf. Instead,
we highlight that by using an API approach there are technological solutions that mean
authentication takes place between the ASPSP and customer without introducing
friction to the process and yet TPPs will get the full functionality and information that
they need.
•
ASPSPs and TPPs should own and control the methods by which they authenticate
their own customers: PSD2 states that TPPs will ‘rely’ on the authentication methods of
ASPSPs for accessing customer account information. As a key principle, ASPSPs and
TPPs should own and control the method by which they authenticate their own users. So
when a customer is required to authenticate itself to the ASPSP in order to grant a TPP
access to its information, this authentication should happen directly between the customer
and ASPSP, in whatever way they currently use.
•
There are technical mechanisms that already exist and are in use that mean
customers don’t need to make their credentials available to any other parties.
Overall we recommend an approach of ‘delegation’ rather than ‘impersonation’: To
achieve the aims set out by the Commission we do not believe that TPPs (or any other
party) need access to a customer’s personalised security credentials. We do not believe
that ‘screen-scraping’/ ‘impersonation’ type approaches are appropriate or necessary
(crucially they do not allow the customer to have control over precisely what information is
shared) 4. We believe that our approach is in line with the PSD2 text under Articles 66 (3b)
and 67 (2b) which state that: "The payment initiation service provider/ account information
service provider shall … (b) ensure that the personalised security credentials of the
payment service user are not, with the exception of the user and the issuer of the
personalised security credentials, accessible to other parties and that [when] they are
transmitted by the [payment initiation service provider/ account information service
provider][, this is done] through safe and efficient channels”. Our position also reflects
comments made by the European Data Protection Supervisor in their report on the PSD2
proposals in 2013, stating that “the EDPS underlines the importance of implementing the
principles of "privacy by design" and "privacy by default" in all data processing systems
5
developed and used under the proposed Directive” . We also believe this approach is
4
Technology clearly offers an opportunity to provide flexible, tailored financial services, However it is clear that
customers are generally considered more financially included, and more confident when they have more ‘cash-like’
control over their financial services. This is also true of control over their data; research shows that consumers clearly
have concerns over the misuse of their personal data. Consumer control of their financial services and what data is
shared is imperative to the success of PSD2 http://www.financialinclusioncommission.org.uk/pdfs/fic_report_2015.pdf
5
Opinion of the European Data Protection Supervisor, 5 December 2013
Page 6
•
•
more appropriate in the context of the new General Data Protection Regulation which was
recently agreed.
The technical means now available (e.g. Oauth 2.0 and Open IDConnect, which are
predominantly used in the API environment) make it unnecessary for other parties to have
access to credentials. These solutions are used securely by some of the biggest
companies in the world like Facebook, Google and Amazon. This API approach also
enables a customer-driven experience. The customer is in control of what can and cannot
be shared with a third party, as the API is consent and permission-driven. With ‘screenscraping’, or making credentials accessible, the third party has the ability to access and
change any information the customer is able to see and edit, thereby removing the ability
for customers to have granular control over what information is shared and for how long.
Once authentication has occurred between the customer and the issuer of the credentials
(i.e. the ASPSP) encrypted ‘access tokens’ are exchanged between the ASPSP and the
TPP enabling the service to be carried out. This approach is one that customers will be
familiar with, and it will not require unhelpful mixed messages to customers about when
they can and can’t share their credentials. Importantly, this does not affect the customer
experience for TPPs (and any underlying merchants) as customers don’t have to be rerouted between websites.
Finally, and just as importantly, the EBA should recognise that ‘credentials’ as we currently
understand them are already changing. Lots of credentials being used by customers are
not capable of being accessed, used and stored by other parties (for example fingerprints
or behavioural-based characteristics). The API approach to authentication is therefore a
positive move for TPPs as it will enable them to continue to have access to customer
information without needing to rely on credentials in the future.
C. As well as the TPP authenticating itself to the ASPSP (a requirement of PSD2), there
must be a means for ASPSPs to verify the license/authorisation of that TPP in real time.
This would also be of benefit to customers.
•
•
•
Page 7
As laid out in PSD2 the TPP has a requirement to authenticate itself to the ASPSP. As well
as authentication, the ASPSP also needs to be able to verify that the TPP is indeed
licensed and able to carry out the services it is requesting access to. We therefore think it
is vital that the EBA Register is not a simple text description of accredited companies, but
that it has interactive functionality (that could be accessed via e.g. an API).
This functionality should include a ‘digital certificate’, which can also be attached to
communication messages between the TPP and ASPSP. Having a technical mechanism
in place to allow the API implementation to verify that the requestor is legitimate is
essential. In addition, having the ability to verify that each request is authorised by the TPP
is essential for auditing and accountability (using Message Authentication Codes (MACs)
is a way to achieve this). This helps to provide evidence for situations when each party has
a different view of what a transaction intended. If the EBA Register won’t support Digital
Certificates (PKI infrastructure) then something else (that is legally binding) needs to exist
that will (this links to the wider governance point below).
The register will need to be updated in real time and accessible to PSPs with instant
response functionality, so that e.g. an ASPSP receiving a request for a payment from its
customer and a PISP can immediately verify the PISP holds a current authorisation
without delaying the transaction. As such, a real time update of PISPs removed from the
•
•
register will be just as important an addition if liability is to be distributed, as the PSD2 text
envisages.
In an API environment there is other information that can usefully be stored in such
Registers. This could include for example descriptions of the ‘role’ of the firm. This
information would provide a description (against agreed parameters) of what that firm does
(e.g. accounting software) and what they are authorised to do. Such ‘roles’ can be another
powerful tool when used in conjunction with the granular ‘permissions’ that are possible
through APIs. When the information about a firm’s role is supplied digitally and in real-time
(via a secure digital certificate) to the holder of the data (e.g. an ASPSP) then the data
holder is able to have further confidence about the validity of the data/action being
requested on behalf of the customer (and importantly relay this information to the customer
as part of the permissions-granting process).
If the Register needs to be housed within another independent body, then this body could
act as a central point for dispute resolution/ liability claims which will otherwise be
cumbersome and expensive to administer.
D. Main missing elements from the discussion paper:
•
Governance: As indicated above, we believe that this new ecosystem will require
governance. While this may not be something the EBA explicitly opines on, we do believe
it is vital that the regulators and authorities publicly acknowledge the need for it and
recognise the importance of multi-stakeholder efforts to create an ecosystem that works
for all. Clearly there will be challenges, not least as a result of the short timescales and the
complexity of pulling together the views of all stakeholders in a comprehensive but
practical way. But we believe that effective governance is absolutely integral to successful
implementation of PSD2. In our view, at a high level the governance of this new
ecosystem should include:
o
o
o
•
Page 8
An overarching mechanism (an “independent authority”) to help to ensure the
rights and responsibilities of all participants. Higher standards will mean better
outcomes for new entrants and certainty will allow better planning. This body
should also help to manage disputes and claims. This is already a complex area
and will become more complex with the introduction of TPPs. We do not believe
an appropriate body exists at a pan-European level and therefore the industry
should seek to stand one up, representing all stakeholders, with the support of the
authorities.
A multi-stakeholder body to define the open standards, which fairly represents all
types of participants. Again, we are not sure that there is a body that is ideally
suited to this role at present, though we note that a body like ISO (the International
Standards Organisation) may have a role to play.
A certificate authority/PKI infrastructure to manage the digital certificates that each
firm should use. This could be linked to the EBA Register or managed at a
national/European level by another independent body (see above (point C) for
more information).
Customer education: Appropriate consideration needs to be given to the vital importance
of customer education. This will be very important to ensuring that customers are
protected and understand how they can use and benefit from these changes. It is
important that the provision of innovative payment services is both understood and
recognised to be secure otherwise products won’t be taken up.
•
Messaging to customers about credentials: We do not know how the banking industry
can give out updated customer advice about using their credentials with third parties. This
will go against decades of customer messaging and will conflict the message in nearly
every other industry. This is therefore another reason that we prefer the API approach that
does not require any other parties to use customers’ credentials but rather an encrypted
key.
•
Engagement with the retail industry: The EBA needs to consider that strong security is
not just a responsibility of PSPs but of all players in the market. Retailers play an important
role and it is crucial that this sector is engaged.
E. Customer views on data sharing envisaged by PSD2
•
Earlier this year, Ipsos MORI was commissioned to conduct research on consumer and
small business attitudes to data-sharing. While nearly 40% reacted positively to the
concept of sharing financial data (and aggregation was particularly popular), 30% were
wary of the idea, and the remaining nearly 30% were uncertain of the merits. One of the
main sources of consumer concern is around security and redress. Consumers demand
bank-grade security around their finances, expect some means of financial compensation
for security breaches and their bank to be involved in the administration of such claims.
Finally, consumers overwhelmingly (77%) believe that third parties accessing their
6
financial data should be regulated .
F. Enabling innovation
We respect policy makers and regulators’ desire to enhance consumer protection and guard
against fraud. We note that:
•
•
The methods employed by fraudsters change rapidly, especially as new attack vectors
open up. It is vital that those seeking to prevent fraud are equally able to adapt their
approach.
As the EBA recognises, there is a constant balance to be found between customer
experience and fraud prevention. There is considerable innovation in strong authentication
solutions, and it is important to ensure that the principles or standards do not inadvertently
stymie their development.
Principles, guidelines or standards naturally contain a degree of parameter-setting, and no matter
how high level, this has the potential to restrict new approaches. We encourage the EBA to retain
an ability to re-assess the landscape at intervals, and introduce further flexibility if there is a
demonstrable case for it.
6
Ipsos MORI Open API - Exploring the views of consumers and small businesses: https://www.ipsosmori.com/researchpublications/publications/1769/Open-API-Exploring-the-views-of-consumers-and-smallbusinesses.aspx
Page 9
4
OUR RESPONSES TO THE DISCUSSION PAPER QUESTIONS
Section 4.1 Considerations prior to developing the requirements on strong customer
authentication
1. With respect to Article 97(1) (c), are there any additional examples of transactions or
actions implying a risk of payment fraud or other abuses that would need to be considered
for the RTS? If so, please give details and explain the risks involved.
•
•
•
•
•
•
It should be acknowledged that all actions have a potential risk of fraud – the RTS can’t
describe every threat. This includes, but is not limited to:
o Change of address or other contact details such as mobile phone/number,
o Stopping and re-ordering a new token,
o Applying for an account,
o Amending white lists of trusted beneficiaries,
o Setting limits on payment functionality.
o Changing the mode of statement delivery or other communications.
o Requesting an overdraft facility or an increase in any existing facility or applying
for a new product within online banking.
o Adding new account holders, card holders or administrators to existing accounts
We want to ensure that the payments environment remains highly secure – PSPs must be
allowed to fulfil e.g. AML requirements and to innovate around security and authentication.
The EBA principles for the RTS need to be future-proofed and sufficiently flexible. New
services and functionality will constantly arise, leading to new types of data and risk, etc.
Ultimately our view is that there is not one single approach to strong customer
authentication that will work in all scenarios.
A layered/defence-in-depth approach is vital, no single authentication mechanism or
security tool can be relied on solely as these solutions or mechanisms may be
circumvented - the PSD2 RTS should require this kind of multi-faceted approach (the
experience of the UK banking sector has demonstrated this time and time again).
It’s not just ‘payment fraud’ on a single online channel that we need to consider, and the
outcomes are not limited to ‘financial loss’. For example, risks like ID theft are also key
considerations that firms need to mitigate against.
The EBA should recognise the difference, in particular the fraud risks, between card
transactions online and other online transaction types e.g. online banking. For card
transactions there is currently no opportunity/mechanism in place to go through strong
customer authentication (other than if 3D secure is used) and this is a decision of the
retailer/online merchant. We recognise that industry and card schemes will need to work
together to ensure some communality of experience (while enabling innovation). There is
clearly a need to ensure that retailers/online merchants, card schemes and card issuers
and other key stakeholders are also playing a part in ensuring appropriate security.
2. Which examples of possession elements do you consider as appropriate to be used in
the context of strong customer authentication, must these have a physical form or can they
be data? If so, can you provide details on how it can be ensured that these data can only be
controlled by the PSU?
Page 10
•
•
•
•
•
•
•
7
Generally speaking hardware elements do provide a good solution in the context of strong
customer authentication, in terms of proof-of-possession and independence. However,
they are not the only solutions. The direction of travel across financial services and other
sectors is away from the use of multiple devices. Many customers increasingly expect to
7
perform all aspects of authentication on a single device, e.g. a mobile phone or tablet .
Accordingly, it would not be appropriate for the EBA RTS principles to require separate
hardware tokens. Non-physical software/data tokens are more forward looking options;
and indeed these types of solutions have open implementations in the market – for
example, ‘Google authenticate’.
A software key can be regarded as ‘physical’, but will require specific security measures to
ensure only the intended user can use it. Where a soft token (authentication data) is stored
on a trusted device there should be strong authentication in place to create or migrate the
token.
In fact some banks in the UK already offer software tokens for customer use. Furthermore,
given the fact that we may increasingly move towards the use of cryptography and
distributed ledger solutions, it is clear that this approach needs to be recognised by the
EBA principles.
We believe that an ASPSP should be able to make its own risk assessment as to whether
to accept data as possession element but we greatly welcome its inclusion in the language
of the Discussion Paper and encourage the EBA to retain it. This wording provides the
basis for the use of innovative and secure strong authentication solutions. To ensure the
data can only be controlled by the user, it is important that PSPs introduce controls around
access to the data (e.g. to prevent trivial copying of the data and prevent reuse ‘out of
context’).
The RTS should define the characteristics such possession elements must meet. It should
not provide a limited list of approved possession elements, but could provide examples.
One characteristic should be that the possession element must be unique to a customer.
Examples include:
o Hardware tokens.
o ‘Software creating a One Time Passcode (OTP) in conjunction with the PSU
authenticating himself / herself with the software. Providing that there is an
adequately protected secret key provided to, or agreed with the customer, during a
suitably robust enrolment process.
The possession element must be some significantly secure item made available by the
service provider, or agreed with the user during a suitably robust enrolment process (i.e.
agreed or negotiated, not necessarily issued by the PSP). This is important for allow for
emerging authentication protocols. The possession element could also be a device the
customer uses, but in this case it is critical that is registered/enrolled via a robust process
with the ‘owner’ of the authentication (i.e. an ASPSP) and is authenticated/approved by
them. There are types of authentication that support a ‘bring your own device’ solution.
Under current Discussion Paper wording it is not clear whether they are permissible. For
example, paragraph 28 specifies that “at the time of registration for a payment service or
payment method, the provision of personalised security credentials involves the recording
In 2015 Consult Hyperion on behalf of Payments UK released a report, which forecast that within the next
five years, widespread mobile adoption aligned with up-and-coming biometric security improvements and
regulatory initiatives will lead to a growing emphasis on the mobile phone as the primary means of paying for
goods and services and managing accounts.
http://www.paymentsuk.org.uk/sites/default/files/The%20Future%20of%20Payments%20Aug%2015.pdf
Page 11
•
of authentication elements by the PSP”; but Recital 30 states that “the personalised
security credentials used for secure customer authentication by the payment service user
or by the payment initiation service provider are usually those issued by the account
servicing payment service providers”. We would welcome clarification to ensure these
methods are acceptable.
Possession elements should also include data whose lifecycle is managed by an ASPSP
e.g. mobile App, Internet of things (IoT) device enrolment under ASPSP control.
3. Do you consider that in the context of “inherence” elements, behaviour-based
characteristics are appropriate to be used in the context of strong customer
authentication? If so, can you specify under which conditions?
•
•
•
•
Behaviour-based characteristics are key in financial services. They can be used both for
the physical behaviour of the customer (e.g. location, type of device etc) as well as
spending patterns. They can be used before and after a transaction takes place and form
a key part of tiered authentication. By being able to assess whether the customer is at
home, on their home computer, making the same payment amount to the same payee as
last month ASPSPs are able to assess the risk and the level of authentication required.
This allows a balance to be reached between security and the ease of the customer
experience, which is key in supporting e-commerce. At present behaviour-based
characteristics are part of a risk assessment not an authentication factor. However, it is not
unreasonable to expect that there could be further developments in this space.
Behaviour based characteristics can be used to demonstrate inherence but they need to
be consistent over a period of time and resilient to changes in platform or application (e.g.
my behaviour needs to be the same even though I am using a different mobile device).
Behaviours that are truly inherent should be distinguished from preferences, which can
change at any time.
User behaviour is constantly changing, and will change further with the introduction of new
services and players (like TPPs). TPPs can themselves also introduce new behaviours
(i.e. machine behaviours).
The technology is developing fast and it has a number of very strong benefits. In particular,
because it acts as a kind of ‘invisible’ strong customer authentication, where customers
(and criminals) are not aware of what aspects of behaviour are being utilised.
4. Which challenges do you identify for fulfilling the objectives of strong customer
authentication with respect to the independence of the authentication elements used (e.g.
for mobile devices)?
•
•
Page 12
We strongly support the clarification that “For strong customer authentication the PSCs
can be either a valid combination of these elements themselves or something which is only
generated when all the elements have been provided” as this enables the use of OAuth
(discussed later in our response) which can be implemented in a highly secure way. We
encourage the EBA to retain this language.
A more dynamic and risk-based framework for strong customer authentication supports
future innovation and provides greater scope for customisation by the PSP. The weakest
point in the chain will be attacked first and the RTS need to consider the full lifecycle of a
user.
•
•
•
•
•
•
On point 32, we agree that independence is a crucial factor for ensuring strong security.
However, we do not believe that independence of devices is necessarily required, so long
as there is independence of communication channels on a device the risks can be
mitigated. Software-based isolation (e.g. encryption, operating system-based isolation of
applications) is secure and can in some instances be as secure as a separate hardware
based token. For example, for mobile devices independence can be achieved if the entry
of the password and the generation of the transaction code are done by different apps
which both exist on the same mobile device.
It is worth noting that the riskiness of a transaction merits different approaches which the
PSP would be best placed to decide upon. For example, if a customer is making a
purchase online, using their mobile phone browser, when they want to authenticate a
payment they log into a secure token on an app and receive a text message to their mobile
phone. The customer can then continue with the payment in the browser (though we note
that this will impact on the customer retail experience).
As previously mentioned under question 2, the market and consumers are increasingly
8
moving towards the use of mobile phones/tablets as their sole device. While there are of
course some challenges with this approach, we must accept this is becoming the new
norm. We are moving into mobile centric interaction for all aspects of finance. We believe
that as long as there is independence of communication channels and appropriate levels
of security within the device then it is possible to ensure the objectives of strong customer
authentication. We therefore feel it would not be appropriate for the EBA RTS to require
separate hardware tokens for authentication.
As an example, in a cards context offline PIN in EMV would violate the requirement for
independent devices, but done well it may be more secure than online PIN that is
executed badly.
However, it is clear that as customers move towards using a single device then firms need
to be more aware of the externalisation of certain security elements and of the reliance
they are placing on the security of other infrastructures (e.g. SMS), which need to be
considered fully in any risk analysis. For example, naïve jailbreaking/device rooting can
increase risk, and we would encourage device manufacturers to patch vulnerabilities more
readily than today, as the market would benefit significantly.
Finally, we note that there are multiple technologies which underlie a mobile device, for
example, NFC, Bluetooth, GPRS, LTE and other developing technologies, all of which are
governed and regulated differently. It is therefore worth noting that a mobile should not
necessarily be defined as one element in itself (there are multiple layers) and the PSP
should be able to decide their own risk-based approach to separate mobile technologies.
5. Which challenges do you identify for fulfilling the objectives of strong customer
authentication with respect to dynamic linking?
•
•
8
This is a difficult question to answer fully without a clear definition of dynamic linking in
PSD2.
One notable challenge is that in some contexts such as card transactions, strong customer
authentication would begin on retailers’ websites. We would advocate that the EBA
Research conducted by BAIN in 2014 (which surveyed roughly 83,000 consumers in 22 countries to reach
its conclusions) stated that “Banking customers now handle more of their banking interactions, on average,
via smartphones and tablets than through any other channel”.
http://www.bain.com/publications/articles/customer-loyalty-in-retail-banking-2014-global.aspx
Page 13
•
•
•
•
•
•
•
•
•
Page 14
engage more directly with the retail community, regarding their shared role (particularly in
the e-commerce space) in delivering a strong customer authentication environment.
The distinction between strong authentication and dynamic linking is important. While we
support strong authentication, dynamic linking is only relevant and helpful in limited
circumstances.
We would welcome clarity as to the purpose of dynamic linking to help us understand its
application to remote electronic payments. PSD2 text suggests that it should be used “to
make the user aware, at all times, of the amount and the payee of the transaction that the
user is authorising”. The EBA Discussion Paper suggests its purpose is to provide “a high
assurance that the PSU has been identified and is authorising a specific payment
transaction”. These appear to be different aims, which would therefore impact the kinds of
solutions and risk mitigants that would be acceptable.
If making the user aware of the amount and payee is the objective, we question whether
dynamic linking should ever be required for retailer-generated payments (like online card
payments), and would encourage the EBA to exempt them from scope. For example, if a
customer wishes to pay ‘Retailer x’ €200 for a flight; they will be very aware that this is the
transaction they are authorising. From a fraud perspective, there is also very limited scope
for a ‘man-in-the middle’ type attack.
We note that some solutions that enable dynamically linking provide the user with visibility
of the payee and amount, while others do not. Solutions where the user has to input this
data do not offer any fraud prevention benefit beyond the other kind (a nefarious actor
would just input the same data twice) but the customer journey contains far more friction
(so causes a negative impact on e-commerce). If some form of dynamic fraud protection is
required to prevent fraud (a different purpose to user awareness), a unique dynamic code
offers as much protection as a dynamically linked code, but has a far better customer
experience – and is therefore less detrimental to e-commerce.
In relation to mobile banking applications, the use of cryptographic keys should be
considered as a form of dynamic linking. These provide, by way of comparison,
considerably greater security than one-time passcodes.
With an evolving market, the RTS should provide discretion for PSPs to determine how
they implement dynamic linking of a transaction and also to determine whether the
dynamic linking of a transaction is made visible to the PSU.
A key exemption will be around “low risk transactions”. Some providers have sophisticated
tools for transaction and customer analysis which can be far more powerful than dynamic
linking in confirming the identity of the customer and the likelihood of fraud. The ability to
“step-up” authentication based on the risk of an individual transaction is key to the smooth
functioning of electronic payments whilst ensuring that customers are protected from fraud.
There is uncertainty around dynamic linking for bulk payments i.e. payment files that will
contain multiple individual payments and thus multiple payees and amounts. It is not
unusual for a bank to receive a batch payment file of 50,000 individual payments. Bulk
payments which are awaiting verification by a second authorizer requires consideration – a
relevant dynamic link may be beneficial but discussion on which values to employ is
required. With any additional requirements, the EBA should consider the degree of change
to customer experience and the impact this may have on the businesses concerned.
In terms of the comments in paragraph 35 regarding difficulties for dynamic linking where
the amount is not known, we suggest that if an amount is not available, this can be set by
default to zero.
•
We understand that the dynamic linking requirement applies to ‘remote electronic payment
transactions’, and that PSD2 states that a ‘remote payment transaction’ is a payment
transaction initiated via the internet or through a device that can be used for distance
communication (but excludes non-electronic payments such as mail, paper-based and
telephony). It is always difficult to define something by what it is not, therefore the
definition of a remote electronic payment is challenging. We believe, though would
welcome clarification, that the following are out of scope for dynamic linking:
o
o
o
o
•
Video-banking, as this would be considered in the same way as telephony;
Phone calls made from mobile phones (these could potentially be caught as a
device that can be used for distance communication, though we do not believe this
was the intention).
Payments initiated at ATMs. While the networks that support these machines use
phone lines, internet access and central computers to distribute information and
facilitate transactions, there are specific fraud protections that apply to ATMs. ATM
networks are walled ecosystems where operators have to adhere to robust
requirements to protect the physical security of their devices and user credentials.
This means that the risks associated with activity that happens on them are vastly
different, for example, to online activity (in the commonly used sense of the term).
The control environment around the operation of ATMs is extremely stringent and
we would encourage the EBA to seek assurance from the schemes with regards to
annual attestations to confirm the adequacy of the cryptographic control
environment. Due to the different risk profile ATMs present, we encourage the
EBA to consider excluding them from dynamic linking requirements. We would add
that the profile of customers who use ATMs is far wider than those who use online
banking, so the consequences of a big change in process (without a discernible
fraud prevention benefit) is worthy of consideration.
Point of Sale transactions, as these are not ‘remote’.
A more general point is that any dynamic code must not be able to be used to authenticate
further fraudulent activity or be of use if it (alone) is compromised.
6. In your view, which solutions for mobile devices fulfil both the objective of independence
and dynamic linking already today?
•
•
•
Page 15
No solution could ever be 100% secure. We appreciate the EBA’s recognition that there
are trade-offs between security and customer experience, and would caution that all
activity carries some form of risk. The challenge is to mitigate it in a proportionate way
rather than eliminate it completely. Total assurance that customers have sole control
and/or sole visibility of any communication from the PSP is simply not realistic; SMS,
email, voice calls and other forms of communications are all vulnerable to compromise.
There are different levels of independence and dynamic linking; generally higher levels of
independence and dynamic linking are used for ‘higher risk’ activity. It is important that this
tiered approach, in conjunction with a risk-based analysis by individual PSPs, is
maintained. Divergent approaches to methods of authentication by different PSPs ensure
that it is more difficult for fraud to take place.
Firms make decisions on which solutions to use based on individual risk assessments and
an understanding of their customer base.
•
It is for these reasons that any one particular solution for the authentication of mobile
devices should not be endorsed. This is both to maintain secure means of authentication,
but also to allow more innovative forms of authentication to continue to develop.
4.2 The exemptions to the application of strong customer authentication
7. Do you consider the clarifications suggested regarding the potential exemptions to
strong customer authentication, to be useful?
•
•
We broadly consider the clarifications suggested as useful.
However, in general, we would prefer the clarifications to be considered non-exhaustive
and based on principles, as this would support the ability for PSPs to take a risk-based
approach. Risk appetite is often dynamic and driven by the PSP and the environmental
considerations (e.g. high usage, heightened fraud activity, the emergence of new attack
vectors). At a principles level, the EBA could consider the following:
o
o
o
o
•
•
•
Page 16
Exemptions should balance the need for stronger authentication with minimal
customer friction.
Exemptions should include where stronger authentication has already been
achieved within the same session and there are no further opportunities for
fraudulent activity (e.g. a payment) – there is little value add to doing this again.
Exemptions should include where the customer is strongly recognised e.g. the
same device that is established for that customer (and not for any other customer).
Exemptions can include where no sensitive or risky transactional capability exists
post authentication (or where step up authentication is then required to perform
this sort of activity).
In terms of point 42B on whitelists, we think that this concept is already well-explained in
the Security of Internet Payments guidelines (7.1), allowing alternative customer
authentication measures for “outgoing payments to trusted beneficiaries included in a
previously established white list for that customer”. Transactions against a whitelisted
beneficiary should in themselves not require strong authentication (this exemption is part
of the Guidelines and the RTS should reflect that). Manipulation of the white list would
require strong authentication per PSD2 Article 97(1c).
We appreciate the EBA’s intention to exempt “low value payments”, and appreciate that
this is intended to be “as defined in the PSD”. We would welcome clarity as to the
interpretation. The PSD2 wording refers to low value payments “In cases of payment
instruments which, according to the relevant framework contract, concern only individual
payment transactions that do not exceed EUR 30”. We believe the intention is to provide
an exemption for both (i) payments below EUR 30 (or the level set by Member States) and
(ii) low value payment instruments (for example, contactless wearables).
While not an exemption as such, in terms of the EBA’s mandate to cover strong
authentication when logging in to online banking we would suggest that the RTS should be
clear that strong authentication at login should only be required for a login that gives
access to sensitive information and/or transactional capability (unless exempt). A riskbased authentication can give access to non-sensitive information. Sensitive information
should only be accessed after at least one strong authentication during the session (must
not be by default at login). A default of strong authentication might be acceptable if there is
•
•
•
•
•
Page 17
a sufficiently clear framework to allow exceptions where a clear rationale can be given
based on assessment of the risk and mitigation processes.
We would encourage the exemptions to be kept at a relatively high-level to enable PSPs
themselves to analyse what is deemed a low-risk transaction (we expand on this in our
response to Q9).
We would welcome clarity on the treatment of virtual cards. The Discussion Paper
suggests that the ‘setting up of limits or the generation of virtual cards’ are within scope.
We believe this means that the Administrator of a virtual card needs to be strongly
authenticated when they set up the log-in numbers for Users on the system; but that the
Users do not need to be strongly authenticated when they use the numbers. If this is not
the intention, we would suggest that virtual cards could be considered for exemption as a
“specific-purpose instrument”.
There is also a question as to whether the intention is to include ‘point of sale’
transactions. This is particularly relevant for contactless payments where ease of use is
the key customer benefit and innovative quality. There are safeguards in place to protect
the customer, including the requirement to put in a PIN after a number of transactions and
automatic refunds for any disputed payments; and of course higher value contactless
payments would be supported by PIN entry or, e.g. in the case of mobile phone based
solutions, a biometric authentication step. While we appreciate that low value payments
are out of scope, we would encourage the EBA to consider a broader exemption for
contactless payments.
Our reading of the EBA discussion paper is that direct debits are included within the
exemptions (albeit strong authentication may be required for the set-up of the direct debit
instruction/collection of the first direct debit). It would be useful if the EBA could clarify this
point; we note that direct debits offer other safeguards which mean the concept of Strong
Authentication may have less applicability in this type of payment than others. This often
includes, for example, a customer alert when a direct debit is first taken. There are
complexities in application of strong authentication to Direct Debits, even the first set up.
This is because a direct debit originator (e.g. a utility company) is the one to interact with
the customer - rather than the PSP - but they do not have the depth of customer
relationship that would enable them to easily strongly authenticate the customer. If a
change were required to bring the PSP into this process (or for originators to start
performing this kind of service), it would add friction to the customer experience and may
undermine the use of electronic direct debits and encourage the use of the paper version.
The impact on originators would need to be considered – i.e. the business community.
Aside from specific potential exemptions, we would welcome clarification on the liability
model for exempt activities. We appreciate that “where the payer’s PSP does not require
strong customer authentication, the payer shall not bear any financial losses unless the
payer has acted fraudulently. Where the payee or the PSP of the payee fails to accept
strong customer authentication, it shall refund the financial damage caused to the payer’s
payment service provider”. We would imagine that the liability model for exemptions would
clarify that where a PSP is exempted from requiring strong authentication, the provisions in
Article 4 (1) would apply.
8. Are there any other factors the EBA should consider when deciding on the exemptions
applicable to the forthcoming regulatory technical standards?
• There should be an exemption for recurring transactions. Although recurrence is
mentioned in paragraph 41 it is not listed in the exemptions in paragraph 42 (this may just
be an oversight).
• Generally speaking, we believe that the EBA Security Guidelines published in 2014
provide a good basis for the RTS, especially as the industry is already working towards
implementing these.
• Some of our members suggested that potentially the EBA could consider a tiered
approach. An example is given below:
o Transactions not requiring strong authentication, e.g., a mobile app only requiring
user-id user-password, allowing only small amount transfers (with a
weekly/monthly max); or, logging on when there is no ability to access sensitive
data.
o Transactions requiring strong authentication but no “dynamic linking”, e.g.,
payments to ASPSP-identified utility providers (e.g., electricity company) or
payments initiated via an ATM
o Transactions requiring strong authentication with “dynamic linking” e.g., ad-hoc
high value transfer
9. Are there any other criteria or circumstances which the EBA should consider with
respect to transaction risks analysis as a complement or alternative to the criteria identified
in paragraph 45?
•
•
•
•
•
Page 18
We don’t think the three points highlighted in paragraph 45 should be considered
exhaustive and don’t believe a prescriptive list is needed. Firms will take into account a
wide range of aspects when analysing risk and these will change and adapt as the
ecosystem changes. Firms need to constantly react to new and unforeseen changes in
circumstances. If the list is intended to be definitive, we would encourage the EBA to
clarify that firms may carry out their risk-based analysis by taking any of them into account,
and not all of them (‘or’ rather than ‘and’).
PSPs should take a risk-based approached to customer authentication and transactions, a
one-size-fits-all solution or procedure is not practical and will hamper innovation and
damage the customer journey (the experience of the UK banking sector has demonstrated
the benefits of this approach in the context of balancing customer experience with
security).
The principle around risk analysis should be that the processes must adhere to
generally/widely recognised/defined risk methodologies and could be demonstrated to an
auditor.
Other examples which could be added to the EBA’s points in paragraph 45 include, for
example, reference to lists of known fraudulent accounts, and the interplay with AML
requirements regarding transaction screening, which ASPSPs must already conduct, etc.
We are supportive of the language around ‘customer device used’. Mobile applications
(like mobile banking or person-to-person payment apps) can be specific to the device they
are installed onto – such that if a different device was used to attempt a log-in to the app
using the genuine PSU’s credentials, it would be refused. Where this protection is absent,
they often also involve the use of data that tightly binds the application to the device,
adding an extra layer of security. The ability of firms to consider the risk of the customer
device used is important.
4.3 The protection of the payment service users’ personalised security credentials
10. Do you consider the clarifications suggested regarding the protection of users
personalised security credentials to be useful?
•
•
•
•
•
•
•
Page 19
As noted in our introduction, we do not believe that the aims of PSD2 to (i) give customers
control over what information they make available or (ii) create a multifactor authentication
environment, can be properly met by customers making their credentials accessible to
TPPs who will log in on their behalf. Instead, we believe that by using an API approach
there are technological solutions that mean credentials are only used between the ASPSP
and customer and yet TPPs will get the full functionality and information they need.
As a key principle, ASPSPs and TPPs should own and control the method by which they
authenticate their own users. So when a customer is required to authenticate itself to the
ASPSP in order to grant a TPP access to its information, this authentication should
happen directly between the customer and ASPSP, in whatever way they currently use.
We do not believe that ‘screen-scraping’/ ‘impersonation’ type approaches are secure or
appropriate (they also do not allow customer to have a granular degree of control over
what information is shared).
There are technical means available that already exist and are in use that mean customers
don’t need to make their credentials available to any other parties. Overall we recommend
an approach of ‘delegation’ rather than ‘impersonation’.
These technical means now available (e.g. Oauth 2.0 and Open IDConnect, which are
predominantly used in the API environment) make it unnecessary for other parties to have
access to credentials. These solutions are used securely by some of the biggest
companies in the world like Facebook, Google and Amazon.
As an example, using the scenario of an API utilising OAuth 2.0, when the customer is on
the TPP website they would simply be presented with a pop-up window that allows them to
authenticate directly with the issuer of the credentials (in this case the ASPSP). Once this
has been done, authentication ‘access tokens’ are exchanged between the ASPSP and
the TPP enabling the service to be carried out. This approach is one that customers will be
familiar with (e.g. ‘login with Facebook’, and it will not require unhelpful mixed messages to
customers about the use of their credentials. Importantly, this does not affect the retail
experience for TPPs as customers don’t have to be re-routed between websites.
This API approach enables a customer-driven experience. The customer is in control of
what can and cannot be shared with a third party, as the API is consent and permissiondriven. With ‘screen-scraping’, or making credentials accessible, the third party has the
ability to access and change any information the customer is able to see and edit, thereby
removing the ability for customers to have granular control over what information is shared
and for how long. By using encrypted access tokens to authenticate the customer, this
removes the burden and security risk from the TPP, making it easier for new entrants
without an existing security infrastructure to provide payment services.
Finally, and just as importantly, the EBA should recognise that ‘credentials’ as we currently
understand them are already changing. Lots of credentials being used by customers are
not capable of being accessed, used and stored by other parties (for example fingerprints
or behavioural-based characteristics). The API approach to authentication is therefore a
positive move for TPPs as it will enable them to continue to have access to customer
information without needing to rely on credentials in the future.
o
o
o
o
Accepting the caveat above about the scope of the clarifications (see our answer to
question 12), we think the clarifications are generally helpful.
As noted in para 51D, one of the biggest threats to internet payments is criminals
using social engineering techniques over the phone to dupe customers into divulging
their authentication codes, PIN, Passwords etc and/or duping the customer to make a
9
fraudulent payment . The security recommendations from the EBA won’t ever fully
address this issue. Instead, firms (both ASPSPs and TPPs) must play an active role,
alongside national authorities, in providing education and ensuring that the system is
both simple and safe. Elsewhere in this response we discuss the challenges and risks
around customer education and mixed messages where customers are told not to
share their credentials but that they can make credentials accessible to certain other
parties. We don’t see how it is possible to develop a consistent and coherent message
on this basis.
Although not directly a responsibility of the EBA we believe there remains a
requirement for further clarity on liability, specifically in the space of TPPs having
access to customer data and (potentially) credentials. For example, whilst there are
existing compliance standards for Merchants and Acquirers in handling card and
customer data which falls under PCI DSS, one member reported that 70% of all their
E-commerce fraud is attributed to data and compliance breaches – yet no action /
liability shift is available (i.e. they take the full loss). This cannot be the case for the
TPP environment also.
However, some of our members have the view that allowance should be made for the
fact that some credentials can only be used for a specific purpose and therefore the
risk of misuse is lessened somewhat. For example, an electronic signature can only be
used to authorize a specific account/value transaction. If it was compromised, only the
intended transaction could be carried out. Therefore, in this case as the overall risk is
lower an argument can be made that there should be more flexibility (if desired) in how
these personalised security credentials are protected. In terms of the reference to
sensitive payment data in 52iii, we note that the EBA’s Guidelines on the Security of
Internet Payments already defines that access to sensitive payment data must be
protected by strong customer authentication. PSD2 Art 4(32) excludes name and
account number for AISP’s and PISP’s only, so should these pieces of data still be
regarded by ASPSP’s as sensitive information to be protected by strong
authentication? The definition of ‘sensitive payment data’ is important and may need
further clarification. A default requirement for strong authentication might be
acceptable if there is a sufficiently clear framework to allow exceptions where a clear
rationale can be given based on assessment of the risk and mitigation processes.
11. What other risks with regard to the protection of users’ personalised security
credentials do you identify?
•
9
New risks will emerge all the time as criminals adapt their techniques and targets, this is
why firms need to be free to innovate and adapt their own security.
https://www.youtube.com/watch?v=6yGvO-FefUc
Page 20
•
•
•
By making customers personalised credentials “accessible” to other parties new attack
vectors will be opened up, especially as the market begins to mature. This is why we
believe the RTS should require that personalised security credentials are transmitted
directly between the customer and the issuer of the credentials for authentication
purposes. It is the resulting access tokens that are produced (when using APIs) that can
be exchanged between the TPP and ASPSP.
In the UK in 2014, 47.9% of fraud related to identity fraud and Facility (account) Takeover
10
Fraud . We would expect that the use of credentials by TPPs could significantly increase
instances of facility (account) takeover fraud (even if that is not happening yet).
A ‘Cifas 2014 UK Fraud Trends’ report also noted the following:
o
o
o
o
o
•
10
With data driven fraud like Identity Fraud dominating, it is unsurprising that technology
played a major role in 2014. While the internet offers a fantastic opportunity for
fraudsters to attempt fraud on an industrial scale, technology is also the reason behind
several successes in preventing fraud.
The introduction of enhanced security procedures has made it far more difficult for
fraudsters to take over existing accounts – demonstrated by the reduction in Facility
11
Takeover Fraud , which is down by 38%.
When fraudsters are being successful they are most commonly using online channels,
often facilitated by a phone call. Banks and plastic card issuers have reported that
some fraudsters have accessed customer accounts by phoning the customer directly
and talking them through the logon process. They purport to be calling from the bank
or card issuer, and claim that in order to be able to verify that they are talking to the
right person; they need them to confirm their customer number, and so on. The
fraudster will then be logging onto their victim’s account as they are talking to them
and entering the security details as they are read out.
In this way, the fraudster can even obtain one time only passcodes from card readers.
Fraudsters adapt their methods – as one becomes more difficult, a number of other
avenues open up. The increased difficulty in gaining access to existing accounts has
occurred at the same time that Identity Frauds are increasing. This suggests that as
fraudsters find it more difficult to access existing accounts they have focused on
opening new ones instead. Additionally, their attention has been turning to convincing
their victims to just give them the money directly. This kind of fraud is often called
‘vishing’.
The Payments and Financial Services industries have worked very hard at reducing
instances of Facility Takeover Fraud, which has shown to be effective in relation to plastic
cards and bank accounts. There is a definite risk of a sharp increase in this specific type of
fraud if conflicting messages are given to customers, especially that they can make their
personalised security credentials accessible to other parties.
Cifas, Fraudscape – UK Fraud Trends, 2014: 2:
https://www.cifas.org.uk/secure/contentPORT/uploads/documents/External%20%20Fraudscape%20main%20report%20for%20website.pdf
11
Facility Takeover Fraud, also known as Account Takeover Fraud, is an identity crime which occurs where a person
(the facility hijacker) unlawfully obtains access to the details of their victim (namely an existing account holder or policy
holder) and fraudulently operates the account or policy for his or her (or someone else’s) benefit.
Page 21
12. Have you identified innovative solutions for the enrolment process that the EBA should
consider which guarantee the confidentiality, integrity and secure transmission (e.g.
physical or electronic delivery) of the users’ personalised security credentials?
•
•
•
First, as a point of clarification: Our reading of paragraph 52i is that the EBA is considering
providing guidance on the full end-to-end process of credential management, including
“creation”, “issuance” and “delivery to” the customer”. This would seem to go beyond the
remit actually intended for in PSD2 and would impact e.g. how banks issue their PINs to
customers, which in many cases is already defined elsewhere, for example, scheme or
industry rules. We had understood that the EBA’s remit was around the use of credentials
by customers in the context of AIS and PIS.
As noted elsewhere the RTS should be principles-based in this area to allow for
developing technology which may create new, safe methods of enrolment.
Generally speaking, for the full life cycle of the PSC all processes should be performed by
the ASPSP using secure processes.
13. Can you identify alternatives to certification or evaluation by third parties of technical
components or devices hosting payment solutions, to ensure that communication channels
and technical components hosting, providing access to or transmitting the personalised
security credential are sufficiently resistant to tampering and unauthorized access?
•
•
•
•
•
Page 22
As a general point we believe that appropriate security measures are a vital part of
ensuring integrity and wide customer adoption. As demonstrated by the recent Ipsos MORI
analysis (see introduction) customers place reliance on all actors in the payment chain to
have high levels of security.
Self-certification of technical components or devices hosting, providing access to or
transmitting PSCs is not sufficient. While there is some external inspection of certain key
components of the payments chain today (e.g. PIN security), in most cases evaluation of
these components by third parties is clearly an enhancement to what is required today, but
we think this is necessary. Any AIS/PIS solution should be certified and evaluated by third
parties analogous to pre-existing processes like GBIC (German Banking Industry
Committee) under EMVCo. ASPSPs are already regulated and therefore alternatives for
evaluation and certification, like internal assessments, already exist.
We do not believe that ASPSPs should be responsible for certifying/auditing TPPs.
However, we believe that the solution implemented by the industry around open standards
of communication can be designed to minimise the points at which PSCs are transmitted.
For example, through the use of APIs and methods like OAuth, the customer can
authenticate through a secure ‘pop-up window’ directly with their ASPSP. For TPPs using
this approach, any external audit would only need to confirm that this aspect of their API
connection is secure, rather than auditing their whole system where any credentials might
be stored.
Any external evaluations should be based on commonly agreed criteria (agreed openly
with a variety of stakeholders at industry level). The RTS should set characteristics only,
e.g., define the minimum encryption algorithm requirements.
14. Can you indicate the segment of the payment chain in which risks to the confidentiality,
integrity of users’ personalised security credentials are most likely to occur at present and
in the foreseeable future?
•
•
•
•
•
•
•
Generally speaking, there is high risk in the customer/device segment because customers
are the easiest part of the chain for criminals to target.
However, while it is useful to identify problematic segments we note that the problem has
historically been that segmentation of responsibility has taken place. The entire end-to-end
system should be considered in relation to protection of PSCs.
Third parties that collate and store data on behalf of users are likely to become a primary
target for criminals. A popular “main player” in this area could potentially hold a significant
amount of customer data across multiple ASPSPs. Compromising this single entity could
be easier and more lucrative than attacking multiple ASPSP targets. For this reason we
remain very concerned about any proposal to give third parties access to customer
credentials.
As a new technology and method of gaining access to customer data, it is likely that cybercriminals will specifically focus on a more open banking environment as a new attack
vector in the future. The ability to amend or make payments will be a specific driver.
Attacks are likely to include both exploiting any technical weaknesses that may exist in
implementations of the open communication standards, supporting applications and
services, or through social engineering of customers who will be unfamiliar with the more
open environment.
Details obtained may be leveraged to effect an account takeover or commit fraud through
other channels. This may also provide opportunities for bad actors to exploit users’ naiveté
or lack of familiarity with the processes surrounding the new environment to conduct
phishing or social engineering attacks.
In addition to embedding the appropriate structural safeguards including protocols,
processes, controls and governance, there is the additional challenge of increasing
awareness and “digital literacy” among users (i.e. individuals and businesses).
The EBA RTS will set high level principles, however they must be capable of recognising,
reacting and adapting to emerging risks and threats. We believe that as this ecosystem
develops, there should be principles requiring that TPPs and ASPSPs share information
on security incidents and fraud. However, this should be done via a central governance
authority and possibly anonymised to reduce the risk of further compromise to a particular
firm. This will facilitate recognition and help to ensure that any risks can be dealt with in the
proper manner.
4.4 Considerations prior to developing the requirements on common and secure open
standards of communication
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the
clarifications provided to be comprehensive and suitable? If not, why not?
•
Page 23
We broadly agree with the clarifications under paragraph 63. We especially welcome 63f
which requires each ASPSP to support at least one interoperable interface; rather than
mandating the support a myriad of different regimes.
Card-based Payment Instrument Issuers:
•
•
•
•
•
•
•
•
•
Page 24
We note that although Card-based Payment Instrument Issuers (PIIs) are mentioned in
paragraph 58. However, they are not mentioned in the questions or clarifications of this
section. We would welcome further thought and clarification regarding the EBA’s treatment
of these players, as they may require an alternative approach which hasn’t yet been
articulated fully by the PSD2 text. From our initial analysis of the provisions relating to PIIs
there are numerous challenges, costs, risks, and possible shortcomings with the model.
Ultimately, following the development of principles under the EBA RTS, the industry will
need to develop a standardised communication protocol.
We would welcome clarity on what extent some of the issues concerning consent,
communication and liability will be addressed through the EBA RTS or through the
framework contract established between the card-based payment instrument issuer and
the PSU. There is potential for an API delivered solution.
With PIIs, the service the ASPSP is providing is a “confirmation” rather than a typical
payment service. It is unclear how the PSU will be prompted to notify the ASPSP of his or
her consent when signing up to use a payment instrument issued by another provider (e.g.
will it be covered in the PIIs terms and conditions?) Is provision of such consent made
directly to the ASPSP or could/should it be conveyed via the PII? The extent to which the
latter would be feasible or appropriate may also depend on the ASPSP’s willingness to
accept consent received in an indirect manner.
Our interpretation is that any confirmation requests and responses between the parties
should be seen as distinct from both the card-based payment transaction (between the PII
and the PSU) and the subsequent payment order used to settle i.e. to debit the PSU’s
account. This distinction will also have an influence on the relevant responsibilities of the
different parties in terms of e.g. authorisation, authentication and liability.
According to Article 65(2) point (a), the PSP needs to have the payer’s explicit consent
before it may request the confirmation. Assuming a continuous authority is given by the
PSU when the payment instrument is issued, we think there would still be a need for the
ASPSP to verify on a transactional basis that the PSU has given consent.
In conventional card payments the payee (retailer) receives a payment guarantee when
the transaction takes place in contemplation that it will subsequently receive deferred
settlement. In many circumstances this would involve generation of an authorisation
request that the issuer would approve or decline. Furthermore, in a conventional card
payment transaction where the issuer receives and approves an authorisation request
transaction they will earmark funds in the account to meet the future transaction, because
once approved it is guaranteed. It is clear it is not the intention of the directive to replicate
this process.
Our understanding is that ‘earmarking’ of funds on the PSU’s account is not permitted. We
also take this to mean that the ASPSP should treat receipt of a subsequent settlement
payment order in the same way it would deal with any other payment order. Thus it would
apply its usual AML/sanctions and/or checking/financial crime assessment processes and
would also be able to return/refuse the payment if sufficient funds are no longer available
at the time the payment order is received even if the ASPSP gave a ‘yes’ response to the
original request for confirmation.
There are no provisions in PSD2 on the security of the payment instrument the PII
chooses to offer the PSU. As previously discussed, the ASPSP is required to apply its
•
usual AML and fraud checks. The ASPSP therefore needs to be able to rely on the
security of the payment instrument.
We assume that the EBA Register will need to list authorised PIIs.
16. For each agreed clarification suggested above on which you agree, what should they
contain in your view in order to achieve an appropriate balance between harmonisation,
innovation while preventing too divergent practical implementations by ASPSPs of the
future requirements?
•
•
•
Broadly speaking we agree that the areas of clarification suggested by the EBA are the
right ones. These are areas we covered as part of the work of the in the UK to design an
open API in UK banking (see introductory comments for background on this).
In terms of missing areas of clarification, the main one is the topic of ‘governance’.
Logically, if the RTS require common standards of communication, there will need to be a
layer of governance around this. This governance is not designed to limit or constrict the
ecosystem but rather to help it to flourish. Further details on this are provided below.
In terms of what each area of clarification should contain, we have provided an Appendix
at the end of our response detailing this (based on the work in the UK). Much of the detail
relates to the technical implementation of the API solution by the industry (rather than the
principles the EBA will set), nevertheless, we feel it is useful for the EBA to get a sense of
this in order to better shape the principles in the RTS. As previously mentioned, we
strongly encourage the EBA to read the Report that was published on the proposed open
API framework for the UK.
Missing areas of clarification:
•
We believe that this new ecosystem will require governance. While this may not be
something the EBA explicitly opines on, we do believe it is vital that the regulators and
authorities publicly acknowledge the need for it and recognise the importance of multistakeholder efforts to create an ecosystem that works for all. Clearly there will be
challenges, not least as a result of the short timescales and the complexity of pulling
together the views of all stakeholders in a comprehensive but practical way. But we
believe that effective pan-European governance is absolutely integral to successful
implementation of PSD2. In our view, at a high level the governance of this new
ecosystem should include:
o
o
Page 25
An overarching mechanism (an “independent authority”) to help to ensure the
rights and responsibilities of all participants. Higher standards will mean better
outcomes for new entrants and certainty will allow better planning. This body
should also help to manage disputes and claims. This is already a complex area
and will become more complex with the introduction of TPPs. We do not believe
an appropriate body exists at a pan-European level and therefore the industry
should seek to stand one up, representing all stakeholders, with the support of the
authorities.
A multi-stakeholder body to define the open standards, which fairly represents all
types of participants. Again, we are not sure that there is a body that is ideally
o
•
•
•
•
•
•
suited to this role at present, though we note that a body like ISO (the International
Standards Organisation) may have a role to play.
A certificate authority/PKI infrastructure to manage the digital certificates that each
firm should use to demonstrate their authorisation, and possibly role/status etc.
This could be linked to the EBA Register or managed at a national/European level
by another independent body.
While PSD2 states that contracts are not required between TPPs and AS PSPs, the
number and variety of obligations that will exist between players, on a pan-European
basis, will require coordination. We believe this is something that will greatly benefit
customers, new players and incumbents in terms of providing clarity on rights and
responsibilities, as well as greatly simplifying the number of bilateral relationships that will
need to exist.
In the UK, the open API Framework report also proposed that a system of governance
would be required. This would ensure the needs of all participants are adequately and
equitably addressed and that trust and confidence in the ecosystem is established and
maintained. Where personal data, and potentially commercially competitive data, is
involved it is particularly important that all parties understand their rights and obligations in
the context of that data. This applies not just at the point of transfer or receipt, but
subsequently when that data is retained, reused or even redistributed.
As discussed below, the open API Framework report proposed what new governance
entities would need to exist at both a functional level and an oversight level. As flagged in
paragraph 61, the EBA is not mandated to create the standards or appoint a body to do
so. Nevertheless, the EBA needs to recognise that a body of some kind will need to be
stood up to define and oversee the technical functionality of the API as well as the data
and security standards.
We cannot overstate the importance of TPPs adhering to appropriate security standards.
This is by no means intended to act as any kind of barrier to entry, but ensures protections
for customers, commensurate with the level of risk associated with the data.
We welcome the provision in PSD2 for PISPs/AISPs to hold professional indemnity
insurance. The overall success of the ecosystem will depend on high quality insurance
which is sufficient to cover PISP/AISP liabilities (these could be significant). We suggest
this is closely monitored by, for example, requiring PISPs/AISPs to provide evidence of
valid insurance cover to be listed as approved, and/or placing an obligation on insurance
providers to notify the competent authority in the event that insurance cover lapses.
Consideration should also be given to the possibility that the PISP/AISP’s insurer declines
to pay out. The consequence would be that a blameless ASP could be left without
recourse, though they will have already compensated the customer.
With any delivery mechanism, we note that further consideration should be given to how
business customers will give consent for a third party to make a payment on their behalf,
given that there is often more than one payment authoriser (and often a complex matrix of
a number). We would be pleased to give this further thought.
Further information on the recommendations of the UK API report on the issue of governance can
be found in the Appendix.
Page 26
17. In your opinion, are there any standards (existing or in development) outlining aspects
that could be common and open, which would be especially suitable for the purpose of
ensuring secure communications as well as for the appropriate identification of PSPs
taking into consideration the privacy dimension?
•
•
•
In the UK, the work that has taken place to create a framework for an open API has taken
a big step towards understanding how an ecosystem based on standardised access to
bank data and for making payments would work. The report that was published on 9
February 2016 is yet to be fully peer reviewed but we expect that the recommendations
put forward will form the basis of the implementation of this ecosystem in the UK ahead of
the deadlines for PSD2.
The open API report was written with full consciousness of the emerging requirements of
PSD2 and the need to develop a view that would enable UK PSPs to meet their
obligations under the Directive, although the scope is wider than PSD2. Furthermore, the
recommendations were designed with more than just the UK market in mind, with a
European and potentially global outlook. Finally, we note that the OBWG was a fully multistakeholder body, involving more than 100 representatives from FinTechs, banks, building
societies, consumer bodies, and business.
We suggest that work in the UK could be used as a template for the wider implementation
of the PSD2 ecosystem. The framework report, whilst not a fully comprehensive view,
made some significant inroads to understanding how to design and implement an open
API in banking and we suggest that the EBA make use of this work as far as possible.
18. How would these requirement for common and open standards need to be designed and
maintained to ensure that these are able to securely integrate other innovative business
models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own
credentials by the AIS/PIS)?
•
•
•
Page 27
As mentioned above, we believe technologically it is not necessary for customers to make
their personalised security credentials (i.e. their username and password/pin, etc)
accessible to anyone. The work in the UK on an open API suggests that through the use of
protocols like OAuth and Open IDConnect, customers can authenticate directly with the
issuer of the credentials. Based on this work, we believe that there is strong support for
designing the open standards such that making credentials available is not required and in
fact is gradually phased out as the functionality of the API improves.
We believe that over time new business models are likely to emerge. It is difficult (and not
advisable) to try to predict what these new models might be. Instead, we believe that the
approach we have outlined (see Appendix) regarding the development of an open
standard that is flexible, with a clear change management framework, will help to ensure
that as new innovations and models gain traction and consensus there is a means by
which they can be reflected in the standard.
Nevertheless, we are not asserting that the open API solution is the only solution (only that
it appears to us to be the most suitable approach). We respect that other solutions may
emerge. Regardless of this, however, the EBA principles should create an environment
that is safe and secure yet modern and forward-looking.
4.5 Possible synergies with the regulation on electronic identification and trust services for
electronic transactions in the internal market (e-IDAS)
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for
facilitating the strong customer authentication, protecting the confidentiality and the
integrity of the payment service users’ personalised security credentials as well as for
common and secure open standards of communication for the purpose of identification,
authentication, notification, and information? If yes, please explain how. If no, please
explain why.
•
•
•
•
•
As a general introductory point we think it is important that the EBA is clear on the
distinction between electronic identity and electronic authentication (e-IDAS Article 3.1 and
Article 3.5). Identification and authentication are two distinct processes and solutions
suitable for one are not necessarily interchangeable. Furthermore, distinction needs to
clearly be made between the different topics in the discussion paper i.e. "strong customer
authentication", "protection of the confidentiality and integrity of the PSC" and "secure
communication between participating service provider (AISP/PISP/ASPSP)".
The introduction of the e-IDAS Regulation has been valuable however we question
whether it is fully relevant to the implementation of PSD2. For example, we do see value in
the standardisation of levels of assurance (implementing act 2015/1502) and believe this
to be a positive and necessary step towards interoperability and pan-European integration
of digital identity services.
However, we believe that e-IDAS is not sufficiently equipped to provide an efficient
solution for customer authentication in its current state as required by PSD2. As far as we
understand, only four member states have so far signed up to e-IDAS. Also, e-IDAS is
aimed at public services and government. For example, in the UK, the Government has
launched a federated digital identity framework (GOV.UK Verify). Government has defined
the rules by which a number of providers can verify a citizen’s identity to an acceptable
level of assurance for use to gain access to Government department’s online services.
The scheme is not currently intended for use in the private sector.
The electronic identification mechanisms/schemes regulated by e-IDAS are not useful for
the realisation of strong customer authentication within payment services or account
information services. As proven by some industry evaluations in Germany the effort and
investment for the integration in banking services is very high without any significant
advantages. From the point of view of the PSU the usage is also not very convenient.
Furthermore, these identification mechanisms/schemes are not generally flexible, i.e. it is
not possible to enhance the authentication by elements that are dynamically linked to
transaction data.
Strong customer authentication based on "qualified trust services" like electronic
signatures may have some benefits, however, the decision to support/accept electronic
signatures should be made by the ASPSP based on its risk management and its business
requirements. The use of electronic signatures for strong customer authentication should
not be mandated by the RTS.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS
regulation could address the risks related to the confidentiality, integrity and availability of
PSC s between AIS, PIS providers and ASPSPs? If yes, please identify which services and
explain how. If no, please explain why.
Page 28
•
•
•
•
As stated previously, we believe the RTS should require that personalised security
credentials are transmitted directly between the customer and the issuer of the credentials
(i.e. the ASPSP) for authentication purposes. Any resulting access tokens that are
produced will be exchanged between the TPP and ASPSP. We therefore think it is more
helpful to answer this question by alluding to ‘sensitive payment data’ (PSD2 Article 4 (32),
instead of just personalised security credentials.
We believe that the definitions and principles from e-IDAS behind the use of ‘qualified trust
services’ (as distinguished from ‘trust services’) could be considered to address the risks
relating to the confidentiality, integrity and availability of sensitive payment data. For
example, the use of qualified electronic seals and qualified electronic registered delivery
services. In addition, the Qualified Certificates for Website Authentication could be useful
for a TPP user to identify that a website offering these services is genuine.
As we have previously mentioned, we believe that for the future ecosystem to function
effectively, firms will need to be assured digitally and in real time about the ‘status’ of TPPs
(whether this means their authorisation status under PSD2 or their status as regards to
utilisation of a common communication standard). The most obvious solution for this is the
use of some kind of ‘digital certificate’.
In order to establish a secure communication between an AIS/PIS provider and an
ASPSP, the firms have to be authenticated securely by each other. As part of this
authentication it has to be proven that the AIS/PIS provider has been registered/approved
by EBA and that this registration/approval is still valid. In addition, the status/role of the
provider should be demonstrated, i.e. whether it is an AIS provider or a PIS provider (since
the services an ASPSP has to provide depends on its status). The authentication of
PIS/AIS-Provider and ASPSP should be based on electronic seals based on qualified
certificates issued by qualified trust service providers under the e-IDAS regulation. For this
the EBA should define a policy to be implemented by the qualified trust service provider.
Compliance with this policy should assure that:
(a) Only a PIS/AIS provider registered/approved by EBA will get a corresponding
certificate,
(b) That a parameter contained within the certificate states the role of the
certificate owner (i.e. AIS provider or PIS provider or ASPSP),
(c) If the registration/approval of a PIS/AIS provider is withdrawn by the EBA or a
national supervision authority the certificate is then cancelled immediately (i.e. in
addition to the certificate owner also EBA (or a national supervision authority) has
got the right to cancel a certificate). For all other services the use of qualified trust
services under the e-IDAS regulation should be optionally and therefore not
regulated by the RTS to be prepared by EBA.
•
Page 29
Overall we do not believe that e-IDAS should be wholly relied on by the RTS. However,
some elements, for example, qualified trust services, trust marks, etc, could be concepts
referred to at a principles level. We do believe however, that as highly regulated entities
needing to conduct AML and KYC, PSPs are interested to play a role in understanding
how a more consistent approach to identity can be encouraged, which will benefit
customers and PSPs.
5
APPENDIX
Further to our comments under question 16, in this section we have provided more detail on each
of the areas of clarification indicated by the EBA.
a) Define what makes a standard ‘common’ and ‘open’.
• There is no universally accepted definition of an open standard. The definition we have
worked to in the UK in the context of the Open Banking Working Group (OBWG) is that an
open standard is one developed and maintained collaboratively and transparently, and that
can be accessed and used by anyone. We believe that the standard should be made
12
available under a CC014 licence (effectively public domain) to promote its use, reuse
13
and distribution. Failing this, CC-BY15 (attribution) would be recommended.
•
The standard should be designed according to the following principles:
o Openness – ensuring accessibility for all interested parties, across a wide range of
participants, thereby incentivising adoption, distribution and participation.
o Usability – facilitating ease of implementation and a smooth user experience for
participants.
o Interoperability – promoting and progressing towards an environment where data can
be exchanged between parties in a frictionless manner across organisational and
technological boundaries.
o Reuse – adopting and leveraging existing standards, taxonomies and data lists
wherever possible and practicable to avoid duplicative efforts and maximise
interoperability.
o Independence – promoting competition among and avoiding dependencies on vendor
solutions and technologies; preserving optionality in delivery models and
implementation technologies.
o Extensibility – establishing flexibility and encouraging adoptees to build upon the
standard and innovate locally, while providing governance mechanisms to
subsequently bring extensions “back to the core”.
o Stability – ensuring the provision of a stable environment for all participants where
change is communicated, actioned and governed in a transparent and consistent
manner.
o Transparency – providing visibility and clarity on issues pertaining to the standard and
the environment it operates in (for instance its design, specifications, and governance).
b) The way AIS, PIS providers will have to identify themselves towards the ASPSPs for access to
payment account information (e.g. exchange of electronic certificates, see as well chapter 4.5),
and every time a payment is initiated including the purpose for which the AIS and/or PIS is
authorised by the PSU and requesting access to the ASPSP upon each connection. Such
requirements could clarify whether or not trusted third-parties need to provide assurance (e.g.
in the form of security assertions) about the identification of entities involved in such
communication.
12
13
See https://creativecommons.org/about/cc0
See https://creativecommons.org/licenses/by/4.0/
Page 30
•
Authentication is an integral element of any communication standard. We envisage that
there are four key authentication scenarios:
o The user authenticating themselves to a TPP;
o The user authenticating themselves to an ASP (in order to authorise a TPP);
o The TPP authenticating themselves to an AS PSP (in order to access a user’s
account);
o The TPP authenticating themselves to a user.
•
As previously argued, we believe that ASPSPs and TPPs should own and control the
method by which they authenticate their own users. The methods by which a TPP
authenticates itself to an ASPSP, and a user may identify a TPP, should indeed form part
of the guidelines/principles devised by the EBA. As noted in our opening remarks, we
believe that as well as authentication, the ASPSP should have a way of confirming, in realtime, that the TPP is appropriately authorised (please see our comments on the EBA
Register (or other suitable alternative) in the ‘overarching comments section’). In addition,
having the ability to verify that each request is authorised by the TPP is essential for
auditing and accountability – using something called Message Authentication Codes
(MACs) is a way to achieve this. This helps to provide evidence for situations when each
party has a different view of what a transaction intended (e.g. transfer 1k vs transfer 100k).
In terms of what a solution might look like, we have described this below, in the context of
using an API.
The process by which a user authenticates themselves to an ASPSP in order to authorise
the granting of permissions to a TPP will be a tripartite process, which should be designed
in a way that minimises digital friction, to avoid discouraging or confusing users. It will
potentially involve a hand-off (e.g. pop up window) of user interaction from the TPP to the
ASPSP for the authentication to be carried out; the user remains on the TPPs website and
continues their interaction with the TPP once the authentication is completed. This
approach has the benefit of allowing the ASPSP to continue to own and control the
method for authenticating its users (thereby minimising the risk that a TPP could obtain
permissions without explicit approval by the user – something required by PSD2) and
avoids any complications associated with parties other than the user or ASPSP using the
credentials.
Separately of course, users may also need to identify and authenticate themselves to
TPPs in order to gain access to the services or functionality being provided (e.g. signing in
to the TPP website). The method used by both ASPSPs and TPPs to authenticate users
should be appropriate to adequately protect the data and functionality in question and
meet any separate requirements laid down by the EBA RTS in this respect.
In our view, the tripartite approach outlined above can be facilitated through use of the
14 15
‘OAuth 2.0 protocol’
. The OAuth 2.0 protocol supports a variety of different
interpretations and styles of interaction, with different security implications, and is used
•
•
•
•
14
http://oauth.net/2/
Wikipedia: “OAuth is an open standard for authorization, commonly used as a way for Internet users to log into third
party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password.
Generally, OAuth provides to clients a 'secure delegated access' to server resources on behalf of a resource owner. It
specifies a process for resource owners to authorize third-party access to their server resources without sharing their
credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access
tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third
party then uses the access token to access the protected resources hosted by the resource server”.
15
Page 31
•
•
1.
2.
3.
4.
5.
6.
•
•
widely by digital companies across the world. The open API standard (to be designed
openly and collaboratively by all interested stakeholders) will prescribe how authentication
and authorisation aspects of the standard are implemented, so the appropriate levels of
consistency, interoperability and security are achieved. For example, something like the
OpenID Connect authentication protocol (which provides an identity layer on top of the
OAuth 2.0 protocol) be considered as part of this process. More information on OAuth is
available in the UK Open API report.
Having been granted permission to access a customer’s account information and act on
the customer’s behalf, there must be a method whereby the TPP can authenticate
themselves to the ASPSP during subsequent interactions. OAuth 2.0 solves this through
the use of an encrypted access token that is provided by the ASPSP to the TPP at the
point at which permission to access an account is granted. The TPP then presents the
token to the ASPSP each time it wishes to access the account (this would be beneficial for
TPPs as they would not need to rely on re-using a personal credential, which may have
changed). ‘Permissions’ are the user’s informed consent for a TPP to obtain data stored by
the ASPSP (e.g. an account balance or a list of transactions) or to instruct the ASPSP to
carry out some function (e.g. make a payment). The access granted to TPPs should be
defined in terms of specific permissions to access data or functionality via the API (this
aligns with the overall PSD2 aim to ensure customers have full control over what data they
make accessible). Permissions should be mapped to one or more API calls so that, given
a specific permission (or set of permissions), it is clear to TPPs which API calls may be
accessed.
It must be remembered that there is a distinction between authentication and
authorisation. The OAuth 2.0 model would apply as follows:
o In the course of an interaction with the TPP, the user communicates intent to grant
the TPP access to account information held at an ASPSP:
The TPP requests access to the user’s account information from the ASPSP;
The ASPSP authenticates the user (using its own methods);
The ASPSP reviews whether the TPP is authorised to receive the access it is requesting
(e.g. via an API call to the EBA Register of by assessing a digital certificate presented by
the TPP);
The ASPSP displays to the user the access being requested by the TPP;
The user reviews the access being requested by the TPP and authorises the ASPSP to
grant the requested access to the account information and act on the user’s behalf;
The ASPSP grants the TPP the requested access.
Steps 5 and 6 should not involve the TPP; doing so would provide opportunities for a bad
actor to conceal the extent of the access being requested from the user, leading the user
to authorise more access than they intended.
The ASPSP must ensure that no permissions are granted to a TPP without first being
displayed to and authorised by the user. The user must have the opportunity to opt not to
grant the TPP any or all of the permissions being requested, or to apply relevant limits to
any permission (the AS PSP may opt to apply default limits but these should not be overly
restrictive).
c) The way PIS, AIS and AS PSPs communicate between themselves and with the PSUs in a
secure manner.
Page 32
•
•
•
Again, we will describe here how this could be facilitated via an open API approach.
The use of an open API to facilitate communication between parties is in our view an ideal
solution to address the challenges laid out by PSD2. As discussed in our opening remarks,
APIs are a mature technology and used widely in most other digital industries.
In terms of security for the API, again this is fairly mature and there are several means of
doing this. In the UK framework report, we recommend the use of HTTP Strict Transport
Security (to ensure that API connections should only be made using HTTPS, thus ensuring
that all data in transit is encrypted), and Perfect Forward Secrecy (to minimise the impact if
session keys are compromised). We also recommend that TLS v1.2 should be used as a
minimum, with a defined set of strong cipher suites.
d) The minimum functionalities requirements that the future common and secure open standards
of communication will have to provide. This includes for example what kind of
information/services can be requested via the standard of communication (e.g. information on
the availability of funds or initiation of a payment), how the identification of the account to be
accessed and consent of the PSU should be conveyed.
•
We do not believe that the EBA should define the detailed functionality of the
communication standards (i.e. an open API). Instead, this should be left to the industry to
implement through a broad-based governance mechanism. However, the EBA could set a
high level view of the functionality requirements for an open standard for secure and open
communication between players (i.e. the API) that assures the requirements of PSD2 are
met as a de minimis. This would include for example principles regarding:
o The technical functionality of the standard itself
o The data that can be accessed via the API
o Identifiers to be used
The UK open API report made the following recommendations in respect of technical functionality
and data:
Technical functionality
• The framework report provides a lot of detail about how an open API standard should be
designed and how it should function technically. The report states that the API should
comprise the following:
o Use of REST as an architectural style and HTTPS as the transport;
o Use of JSON as the resource format;
o Achievement of Level 2 from the Richardson Maturity Model;13
o Adoption of a vendor and technology independent definition.
o The API standard should comply with the following versioning requirements:
 Support for major and minor releases;
 Backwards compatibility for all minor – and as far as possible – major
releases;
 Prescription of minimum support time periods for major releases;
 Embedded flexibility/response speed for security or functional errors.
• The API standard should be designed with the following features:
Page 33
o
o
o
Data
•
•
•
A controlled core – hosting shared resources should be established and this
should represent the slowest-changing part of the standard;
Local extensions “at the edges” should be permitted, allowing for API provider
innovations with subsequent potential incorporation back into the core;
Specific characteristics allowing API providers to address scalability challenges.
We believe that an agreed data standard will be required (a reference data model). This is
vital to ensuring that common data is made available in a uniform and consistent manner.
A multi-stakeholder effort will be required to ensure that the data to be accessed is
described and defined appropriately.
Where possible, pre-existing data standards, such as the ISO20022 Financial Repository,
should be re-used.
e) The minimum security controls that the future common and secure open standards of
communication will have to provide related to the potential unauthorised or fraudulent access
to payment accounts or initiation of a payment transaction.
•
•
•
f)
The UK framework report on an open API in UK banking suggested that further security
would be required to protect this new ecosystem. In particular, a new security standard
would be required for the server-side (i.e. the protection of customer data at rest). The
report recommended a security standards approach be adopted based on the ISO/IEC
27000 series of standards, with a tiered risk-based approach. The report determined that
independent auditing against this standard would be required.
The ISO/IEC 27000 series of standards has achieved widespread adoption, with wide
availability of qualified auditors. This approach has the advantage that there is no need for
the regulatory authority to conduct audits; instead, it can define the standard that must be
met and take advantage of the existing ISO/IEC 27000 ecosystem.
The servers and infrastructure operated by TPPs and ASPSPs must be protected against
cyber-attack. Security standards should mandate security controls that are commensurate
with the nature of the data and functionality that is provided (in the case of AS PSPs) or
sought (in the case of TPPs). The EBA should define the principles that server-side
security should meet rather than any specific technological requirements.
the minimum technical requirements that could apply to the common and secure open
standards of communication, the minimum reachability requirements for each ASPSPs to
provide at least one interoperable interface serving all requirements of the RTS and compliant
with PSD2, while AIS and PIS would have to adapt their services to the respective
standardised interfaces used.
• As we have previously argued, we believe that, given the requirement for ASPSPs to
provide at least one interoperable interface serving all requirement of PSD2 and for
PIS/AIS to adapt their services to the respective standardised interface, the best solution is
an open API standard. The EBA should provide the principles for this in the RTS.
• The open API report published in the UK provides a detailed view of the technical
requirements of such an API. We strongly urge the EBA to review this report.
• The EBA does not need to focus on how the API would technically be designed – the
market will solve this. Instead, it should provide the principles required to ensure that API
Page 34
is open, safe and secure, delivers the functionality required under PSD2 and can continue
to evolve in order to allow innovation and to keep up with customer needs.
Missing areas - Governance
In the UK Report the governance recommendations were as follows:
•
An effective governance model will require an ‘independent authority’ with a clear mandate
to carry out its duties and sufficient funding to perform those duties effectively. The overall
role of the independent authority would be to ensure the effective set-up and subsequent
operation of the ecosystem. It would operate according to the following principles:
o Be independent of TPPs and data providers (e.g. ASPSPs) to ensure their and
customers’ confidence in the ecosystem;
o Act transparently;
o Enable innovation and participation from participants of all sizes;
o Promote the interests of customers in all of its activities;
o Facilitate evolution of the ecosystem in line with new technologies and customer
needs;
o Adopt a risk-based approach.
The independent authority should:
•
•
•
•
Oversee but not define the data, technical and security standards that apply to the
ecosystem;
Oversee but not define the standardisation of open data in the UK banking sector;
Create a clear process for issue resolution between participants and an escalation and
appeal process;
Establish a process through which interested parties can participate in an advisory
capacity to ensure the effective evolution of the ecosystem.
The ecosystem would thus include the following bodies alongside which the independent authority
would work:
•
•
•
•
Page 35
A Standards Governing Body, whose primary role would be to set and evolve the open API
data, technical and security standards that would apply to the ecosystem;
An appeals body, where the authority’s decisions could be challenged; and
A strategy forum where a broad range of stakeholders would input into the evolution of the
ecosystem as a whole.
In an ideal world, there would be a central EU body which would be able to establish the
independent and effective governance model to take account of multi-stakeholder views,
which would enable this ecosystem to take effect on a pan-European basis. The next best
option would be for a national level governance body with appropriate arrangements for
interoperability.