The Federation of Finnish Financial Services (Finance Finland, FFI)

The draft is not fully technology neutral, e.g. Article 1(2). Technical details should be left to service providers to decide in order to be able take e.g. device, channel and service into consideration. We would prefer more general approach to detailed lists. References to certain technologies (as examples) could be included in recitals. We suggest that EBA would consider to align requirements for SCA with the EU Commission’s Implementing Regulations on the Level of Assurance (EU 2015/1502, OJ 9.9.2015 L 235) and the Interoperability Framework (EU 2015/1501, OJ 9.9.2015 L 235) for electronic identification. Requirements to be imposed by the RTS should not substantially differ from general requirements under e-IDAS Regulation in order to enhance electronic identification (strong authentication) at the Union level. As to Article 1(3)(b), the payer should be informed to certain extent on what went wrong. For example, if the payer enters the wrong PIN for a card transaction, it is common practice to display “Wrong PIN” in the terminal. The article should therefore be revised.
PSD2 recital (96) states inter alia that “those measures typically include encryption systems based on personal devices of the payer, including card readers or mobile phones, or provided to the payer by its account servicing payment service provider via a different channel, such as by SMS or email.” The term “channel” in Article 2(2)(b) is ambigious. Usage of the same device for actual payment initiation and authorisation should be possible as far as initiation and authorisation are logically independent from each other. It should be possible e.g. to iniate a payment transaction online in netbank and authorise it via SMS. Respectively, it also should be possible to segregate initiation and authorisation at application or protocol levels.
No comment.
We should refrain from setting exemptions for SCA based on fixed amounts in order to maintain appropriate risk management measures and risk level. Requirements for authentication should be applicable dynamically according to the prevailing circumstances. In general, there should be an option for the PSP of the payer to apply exemptions to SCA based on its’ own risk analysis. In the same way, the exact criteria for such risk analysis should be based on criteria that the payer’s PSP deem relevant in order to reduce fraud and risk to an acceptable level. Such flexibility would allow for continued innovation in fraud prevention and analysis. Mandatory exemptions might also conflict with other Union and national legislation and regulations imposing requirements for e.g risk management or electronic identification.
Exemptions should not be exhaustive and mandatory, but the ASPSP, being primarily responsible for refunding the payer, should have a mandate to self-determine where to apply SCA. It should be considered if exemptions to SCA could also be based on transaction-risk analysis performed by PSPs. Predefined fixed rules are also cut out for weakening user experience and user convenience considerably in cases where SCA does not actually enhance payment security. This dilemma typically occurs in mobile P2P payments where account information is linked to a mobile phone number. It should be sufficient that the payer registers into the service using strong authentication and then uses the service with simpler means of authentication when intiating a single payment. Also for recurring card payment transactions, SCA of the payer should only be required for the first transaction. The RTS should be updated to reflect Rationale 17.
We would like to emphasize that mandatory and exhaustive exemptions preventing ASPSPs from implementing a higher security level would ultimately expose payment systems to unnecessary risks. If individual amounts are to be imposed, the amounts for remote payment transactions should be the same as provided for in Article 8(1)(b) in order to ensure the user convenience. Regarding cumulative amounts, individual transactions might be few and far between each other and not easily implemented in all payment channels and means of payment. We would also like to refer to our answer to Question 4.
Regarding Article 1, it should be clarified whether magnetic stripe card transactions are allowed under the RTS and whether it depends on the card verification used (e.g. PIN, signature) as well as whether it depends on if the magnetic stripe transaction is a fallback from chip. It also should be made clear in the RTS that measures apply to all PSPs including AISPs in order to ensure level playing field. The renewal or re-activation of PSCs should always be conducted following up-to-date security procedures.
Regarding Article 17, the requirement on bilateral identification between customer and acceptance devices is in need of a change or at least an explanation. For a card transaction, the identification today is done of the card to the terminal and no reciprocal identification of the terminal is made to the card. If “secure bilateral identification” should be interpreted as mutual authentication, this would create incompatibility with EMV card payments. Remote electronic payment transactions in “appstores” should also be taken into further consideration. Drawing the line between ”card present” and ”card not present” is rather vague. Regarding service level and assistance for third party PSPs, it should be sufficient for the ASPSP to provide appropriate technical and other specifications. Most likely the vast majority of customers will use internet banking services directly themselves and their service level should not be compromised at any circumstance. It should also be noted that test environment for internet banking might not be available at all because of risks for fraud.
There’s no technical barriers to use ISO 20022 -standards, however data elements should be agreed on, if necessary. However, ISO 20022 is not yet widely used in the card payment sector.
In general, website certificates might be suitable. However, their status is unclear at the moment. To our knowledge, the EU Commission is not going issue any regulations on website certificates under the e-IDAS Regulation Article 45(2). It’s not quite clear whether a third party PSP can be identified on the basis of website certificates. It’s also uncertain whether there be any website certificates issued by qualified trust service providers within next two-three years in the market.
Besides information requests, also amount of data should be restricted in order ensure usability and service level of online banking services. Recurring requrests for informa-tion and vast amount of data will likely to encumber and slow down the system. Most likely the vast majority of customers will use online banking services directly themselves and their service level should not be compromised at any circumstance. The ASPSP should be able to restrict usage of the system on the same prerequisites as the ones applicable to the customer himself/herself. These are e.g. DoS attacks and normal service breaks. If processing is based on batch files, the ASPSP should be able to apply normal time-windows.
[Credit institution"]"
The Federation of Finnish Financial Services (Finance Finland, FFI) represents the Finnish financial sector and the interests of its members, i.e. banks, life and non-life insurers, employee pension companies, finance houses, fund management companies and securities dealers operating in Finland. Our members also include providers of statutory insurance lines.
[Cash related services"]"
The Federation of Finnish Financial Services (Finance Finland, FFI) represents the Finnish financial sector and the interests of its members, i.e. banks, life and non-life insurers, employee pension companies, finance houses, fund management companies and securities dealers operating in Finland. Our members also include providers of statutory insurance lines.
Yes
essi.ruokanen@fkl.fi
(Ms.) Essi RUOKANEN or (Mr.) Peter JANSSON
+358207934246 or +358207934298
Yes