Article 1-3(c) should NOT apply to devices which have been previously registered with the ASPSP and which have not been compromised. Otherwise, you are allowing an attacker to lock me out of my account. Furthermore, since any well designed system would use strong cryptography, there is absolutely no benefit to lock someone out of an account for more than 1 second because there are so many combinations, a hacker could never breach the account. The simplest way to address this is that, if all authentication uses high entropy digital signatures for authentication, Chapter 1, Article 1, pgf 3(c) should not apply.

In article 2, you should clarify that the amount approved could be a maximum amount and that if the payee elects to capture a lesser amount, that should NOT require an additional authorization. For example, if I order 10 items at Amazon, I should only have to authorize the total amount of the transaction ONCE, and Amazon can capture funds several times so long as the total sum of all captured amounts are less than or equal to the approved amount. This might be the case if Amazon ships in several drop shipments instead of a single shipment.

Also, two questions arise that would be nice to clarify:

1) For 2FA, if push notifications to a mobile phone requesting approval is used, and the phone is locked, will unlocking the phone and tap approve" suffice to meet the 2FA requirements (possession of the phone and unlock code)? Or must the phone be unlocked and then again 2 factor authenticated?

2) If an ASPSP interacts DIRECTLY with a merchant so that the ASPSP is the same as the PSP, does SCA still apply?"

No, we STRONGLY disagree about channel separation if the dynamic linking is accomplished using digital signatures in which the amount and payee are signed by multiple private keys of the payer. In that case, use of different channels is unwarranted and leads to unnecessarly poor user experience. For example, I can have extremely secure 3 factor auth on a single mobile device using 3 digital signatures which provides BOTH multi-factor auth AND non-repudiation.

Your restriction would eliminate my ability to make secure purchases on my mobile phone. To meet your requirements, I would have to carry around a laptop with my phone. Or if SMS is considered a different “channel” then that would force us to use an insecure method.

Furthermore, this is forcing a code to be “displayed”. Token uses digital signatures to sign the transaction. The transaction is displayed to the user, but NOT the dynamic code itself (the digital signature) since this would look like random text to a user. Using digital signatures is the safest way to create unique codes that can be used to prove the user approved the transaction.

Our suggestion is that you encourage the use of digital signatures for authorization by exempting authorization codes done using digital signatures from both the “out of band” transmission requirements and the display requirement. It is nonsensical to display a digital signature to a user.

Modern, secure authentication systems should never use authentication codes because these codes require the use of shared secrets in order to authenticate the result by the relying party. Anytime you have shared secrets, you run the risk of a MASS BREACH at the relying party (the holder of the shared secrets used for code validation) and you also forfeit any non-repudiation ability as well.

By forcing the use of displayable authentication codes instead of digital signatures, you are creating a large security hole. An objective of PSD2 is to move the ball forward on security, not mandate the use of old fashioned, insecure methods.

Authentication codes prove nothing. What we want is unambiguous proof that the buyer actually approved the transaction. The best way to do that, by far, is through digital signatures of the payee and amount done with private keys that never leave the buyer’s device. The regulations should strongly encourage this method.

No. Everyone we’ve talked to says the 10/100 euro limit is ridiculously low. If you must set a hard limit, then start high and allow member states to lower it.

The ASPSP should be able to both enforce the PSP to do SCA anytime the ASPSP has good reason to believe there is fraud, and also to waive SCA anytime it believes the transaction is safe. This is reasonable because the ASPSP would bear the liability if it set the threshold too high.

It would be reasonable for the EBA to force SCA for very high dollar purchases, e.g., 1000 EUR or more. But below that, we believe that the ASPSP should be able to determine when a PSP is required to use SCA. The ASPSP will set the limit based on history of the PSU, the device, the payee, and the amount.

Because the ASPSP is liable for the loss in such a case, the ASPSP should be free to trade-off losses for lowering the friction of the transaction. Only in the event that there is a consistently unacceptably high level of fraud losses, should the ASPSP be forced by the regulator to lower the limits for SCA.

This provides strong incentive for the ASPSP to develop low friction ways to control fraud which benefits all parties.

The short answer is, let the free market work to reduce fraud at minimal friction and only enforce strict dollar limits on a particular ASPSP, if the ASPSP fails to keep fraud losses under a certain threshold. The ASPSP should report fraud losses to the regulator.

Such techniques (specifying the target fraud loss before sanctions are imposed) have been used with great success in the card business. If your chargeback % is above a certain threshold, a merchant may lose their merchant ID. This allows each merchant a wide range of options to control fraud losses.

The 10 / 100 euro strict thresholds are much too strict of a requirement to achieve the goal. The EBA has not referenced any studies in support of those threshold numbers.

It includes the “established relationship” exemption, which is good. But 10/100 hard limits are way too strict. If you must set absolutely hard limits, set them at 1000 EUROs, and give the ASPSP the ability to set the threshold to achieve a fraud threshold set by the regulator in that member state. That way, friction is minimized while keeping fraud under control and encourage innovation in reducing fraud that does not impact the purchase completion rate.

It’s OK, but the EBA should strongly encourage the use of public key cryptography to authenticate to the PISP, relieving the PISP of storing any secrets at all. Anytime a 3rd Party stores secrets, even if encrypted, there is the risk of mass breaches.

There are pros and cons with standards. For example, Oauth2 is a standard, but as correctly pointed out in wikipedia, “The protocol itself has been described as inherently insecure by security experts and a primary contributor to the specification stated that implementation mistakes are almost inevitable.”

The use of standards should be encouraged, but where there is a protocol that is clearly documented, demonstrably superior to official standards and adopted by several ASPSPs and thus a “de-facto standard”, those technologies should be allowed. It is critical for the development of better security protocols that such technologies can be deployed by ASPSPs without being official standards.

Our recommendation is that the EBA encourages standards, but doesn’t strictly require them.

ISO 20222 was designed for communication of payment instructions, not for authentication and authorization.

For example, Token’s system uses advanced digital cryptography using Ed25519. There is no provision in ISO 20022 for the communication and verification of such digital signatures.

It would be better to strongly encourage the use of standards like ISO 20022, but not require them. This gives member states the ability to tighten up this requirement IF NECESSARY to move the industry forward.

By requiring ISO 20022, you’d be excluding solutions that can offer greater simplicity to all parties. That would be a barrier to widespread adoption. For large enterprises and ERP systems, ISO 20022 makes perfect sense. But for smaller organizations, a lightweight JSON protocol that gets wide adoption would be a vastly superior solution for all parties.

Yes, but if there are no such providers available as noted in #74, a fallback to Option 2 should be allowed. When providers become available, there should be at least 6 months allowed for the switchover.

Token believes the upper limit should be defined by each ASPSP. For example, if the ASPSP charges for each information request, the ASPSP might WANT to set the limit to be very high and/or adjust it dynamically as required. This benefits all parties. Establishing that each ASPSP shall have a lower limit that it must support is reasonable. In this case, if an AISP has 12 users at a bank, it would be limited to 24 requests a day unless the bank chooses to allow more frequent access. This limit would be easy for a AISP to discover by making more than 2 API requests per day and seeing what happens or by making an API call to discover the limit.