Primary tabs


Yes, the issuance and amendment of direct debit electronic mandates.
At stated by ERPB , while preserving the choice for debtors and creditors on the way they give and accept electronic mandates there is a need for an incentive for creditors to move generally towards solutions with proper debtor authentication and mandate authorization. This is also addressed by ECB where the issuance and amendment of direct debit mandates are supposed to be protected by strong authentication. The 91(1)(b) could be interpreted as not relevant to direct debit mandates, given a direct debit is actually not “initiated” by the payer but by the payee or by the payee’s PSP. Unless this point is address by the transposition workshops, AFEPAME recommends to include the issuance and amendment of direct debit mandates within the 97(1)(c), given these operations imply a risk of fraud or other identity theft abuses that can generate a lose of consumer trust in payment systems.

ERPB/2014/014 : Report on the pan-european use of electronic mandates for SEPA Direct Debit - November 2014
ECB : Recommendations for the security of internet payments – Jan 2013
AFEPAME strongly believes that data will become more and more the relevant appropriate possession element. The physical forms of possession elements have demonstrated with time their limitation with omniscient customer experience (continuous customer experience across different channels), and time to time unfair practices that are contradictory with the DSP objective to bring consumers with more choice (a physical form such as a EMV chip card issued by the ASPSP, will restrain consumer freedom to change, given a card is often associated with a minimum contract length).

Data has however an inherent sensibility to manipulation. We think that software technology will bring secure software solution that would make sure that data cannot be intercepted, such as randomly dynamic information that change on both side of a transaction (the PSU and the server) preventing any unexpected usage.

Two examples of technologies (existing today) that would fit the criteria above detailed are:
• Device fingerprinting. In further detail, technical implementation based on the identifiers provided by software elements can be cloned. Technical solutions based on the fingerprint generated by the electronic circuit can be considered Strong. In the aspect the “PUF technology” (Physical Unclonable Functions) is making big steps.
• User inherence detection. In further detail, the collection of data inherent to how a given user makes use of his computer (including, browser cookies, browser identification, add-ons or plugins installed, etc) make possible to characterize the user. Beyond this techniques, that are based on what the user has done, techniques base on what the user is doing at the same instant (i.e. keystroke jitter patterning) have been developed in the last years.
Yes, behavior-based characteristics are appropriate to be used. However the usage of this element shouldn’t exclude the intermediation of authentication by a PISP or AISP. The usage of a PISP or AISP, would probably alter the PSU behavior, and this should not be a cause of authentication reject.

Other “human” inherent elements could be appropriate to strong authentication, notably the ones related to the five senses (sight, hearing, touch, smell and taste). Again the use of such shoudn’t prevents PISP and AISP access to the market.
The main challenge is to avoid that the corruption of one element propagates itself to the corruption of the second element. AFEPAME is less worried by mobile theft, given such a theft is often detected by the owner very quickly, and remote locking of the device is now very familiar. AFEPAME is more worried by the fact phones are becoming small computers, and then more and more sensitive to software corruption.

We also understand that independence is a big challenge, on that aspect we consider and try to use as working hypothesis that two non-independent authentication elements are only one represented by the link between the first and the second authentication method. Guidelines shall be elaborated to clarify what independence means and how this can be objectively monitored. Otherwise we may fail again to implement strong customer authentication.
We feel the notion of dynamic linking comes from disconnect between the authentication and the transaction validation. Whatever the authentication, a corruption can make the user validate another transaction than expected. It would rather be pointed out that what requires a strong authentication is not the user but the transaction itself (or the validation of a series of transactions).
In addition, it seems that the need of dynamic linking is strongly influenced by legacy technology existing in the card industry (i.e. CAP readers, EMV transactions, etc.) allowing to bind the transaction amount to a code generated via an authenticator or card itself. We have also experimented the unacceptable conversion rates associated to these mechanisms when considering online scenarios.

Furthermore, scenarios in which the dynamic linking does not make real sense appear more and more every day. Those are typically associated to the new generations lifestyle were perpetual purchase business models are being changes by subscription based (i.e. video on demand, music, pay per view or pay per usage, etc.). Recurring payments where the payment details (card, bank based or other) are stored by the PSP would inherently lack of this dynamic linking, unless we are willing to go against the payment frictionless need that the market has raised.

We also consider that dynamic linking should exist but it shall be balanced against usability and need, i.e. define (user selectable) thresholds under which dynamic linking is not needed, narrow it to specific verticals or type of transactions, etc.

In a general word, we understand the need and we consider its use valuable. Technology independence is a must (it cannot be that we need a payment card or analogue virtual to achieve a transaction based on a Bank Account).
None that provides currently a satisfactory universality, user experience and independence from the card infrastructure (physical payment cards, mobile payment cards or cloud emulated payment cards). But technology moves fast.
Yes absolutely.
The development of multiple data point, machine learning and real-time risk assessment reduces risks and offer real alternative to strong authentication.
We consider that exceptions shall be granted to avoid interdependence of bank payments with card payments. That is, ensure that the need of strong authentication or dynamic linking of transactions for bank based transactions (i.e. using IBAN and not PAN details) can be fulfilled with other means than the ones provided by card instruments (or the virtualization of the latter, i.e. SE or HCE based card implementations).
AFEPAME notes that EBA clarifications are concerning PSU authentication. The PSD text mentions several time the notion of “Strong Customer Authentication”. It should be noted that in certain cases, the user is not the “customer” of the PSP that acquires or initiates a payment transaction. The notion of “customer” is too close to the definition of a business relation that calls AML checks. AFEPAME would like EBA to refer in the RTS to a “Strong User Authentication” rather than a “Strong Customer Authentication”.
At this stage we would like to refer to the FIDO Alliance ( providing standardized specification to implement strong authentication. In all cases it is based on a strong local authentication (i.e. biometric, password based or other) that relays the success or not of it to the Merchant requiring authentication. The local strong authentication provides access to a private key that is used for that purpose.
The current certification and security evaluation market is in the hands of few accredited laboratories and independent parties. While understanding the need of independent parties to assess the capabilities of the ecosystem, we would like to raise the interested for a self-regulated industry body that reduces the amount of eventual barriers that may appear to enter into this market.
The biggest risk is the User to deactivate protections if the user experience is too complex.
Yes, nevertheless we consider surprising the lack of emphasis put on standardization of those RTS. The SEPA regulation introduced (by force) the usage of the ISO20022 in the FI to Customer space, we would expect that the RTS continue with this tendency (even though at the current stage details about what would be added and how it would be added to the ISO are premature).

Additionally AFEPAME is very concerned by the fact the RTS will come into force almost 9 months after transposition of the PDS2, which pushes back the launch of the PIS and AIS services for at least the same 9 months, and may be much more. This issue is not addresses in EBA’s clarifications.
a- We have ISO20022 (for the actual data exchange) and we would suggest FIDO for the authentication (given the amount of players already implementing it).
b- -
c- Preferably this way shouldn’t create any barrier to AIS and PIS to set-up and use the communication, such as abusive qualification procedures or restricted accesses. The communication should create a level playing field between all players, notably shoudn’t give a advantage to ASPSP in setting up their own PIS or AIS compared to a Payment Institution willing to do the same.
d- ASPSP rejection of PIS instructions should be part of the minimum functionalities. The PIS or AIS should be able to understand why the ASPSP wouldn’t deliver the service, notably in case of reachability denial or technical failure.
It should be envisaged that the access on the availability of funds could not be anymore restricted to payment instruments that are linked to the issuing of a card, given this current restriction is difficult to understand in the context of making the payment market more competitive.
e- -
f- AFEPAME stresses the point that under no circumstances the PSU’s PSC delivered by the ASPSP for AIS or PIS should differ from the regular PSC to access the online banking. AFEPAME is concerned by the EBA’s 57(v) statement that says the PSC are « usually those issued » by the ASPSP. It would be very counterproductive of having two sets of PSC (one for online access and one for PIS /AIS), and could be a of source unfair access to the market.
AFEPAME suggests to make explicit reference to framework standards widely spread in the Financial Industry. Specific references that AFEPAME suggests are:
• ISO20022 covering the data exchanged between the PIS, AIS and the ASPSP. This aspect is not yet part of the ISO but we consider it shall be added to the latter by a working group (eventually fostered or supported by the EBA)
• FIDO U2F and UAF as globally agreed authentication initiative between most of the stakeholders active in this market.

We consider that failing to reference existing, open and appropriate standards may lead to an unclear playing field with a single consequence: advantage for the established parties and lack of effective competition.
e-IDAS is by far too complex at this stage to ensure SCA. e-IDAS requires that every PSU be granted with a personal qualified certificate, which will not be the case short term. Former experiences with qualified certificates proved it is particularly difficult to get a critical mass of users, and to deliver a frictionless user experience.
e-IDAS is indeed much better designed for business to business relations, and is indeed perfectly suitable to ensure the confidentiality, integrity and availability of PSCs between the AIS, PIS and ASPSP.
[Payment institution"]"
[Issuing of payment instruments and/or acquiring of payment transactions"]"