In the paragraph 3.2.1 at point 19 the authentication procedure is described to be within the sphere of competence of the ASPSP except when the PISP issues its own personalised security credentials to the user, in place of the credentials issued by the ASPSP.
It is not clear why this latter possibility would require a prior contractual agreement between PIS and ASPSP and such agreement be outside of the scope of PSD2.

In fact, the presence of wallet solutions unifying more payment methods under a single user interface and authentication today is allowing consumers to simplify their user experience and electronic transactions to grow.
Wallet solutions under PSD2 seem to be provided by PISs (if not, who provides?), for which the agreements with ASPSPs would be difficult and slow to be defined one by one, with the consequence of reducing electronic payment transactions.
As an alternative solution, the PIS could ask the ASPSP for the first authentication of the user in order to manage the payment method of the ASPSP to the PIS wallet and then for the following payments involving that ASPSP, the strong authentication could be provided by the wallet solution which would be fully compliant with strong authentication requirements of the Consultation Paper; in this case one to one agreements would not be necessary.
As a note, also an eIDAS strong authentication solution (for example eIDAS substantial and/or high assurance level) where also fulfilling strong authentication requirements of the consultation paper could be a promising strong authentication usable for a PSD2 wallet without one to one and slow agreements with ASPSPs.
In the case additional liability requirements could be put in place for PISs providing wallets which unify the strong authentication of the user.

The same mechanism could also be provided to link the wallet to a credit/debit card, where the issuer of the card could provide the first authentication and then the wallet strong authentication would be used for the following payment transactions.

In addition, it is not clear whether in the article 10 the storage of the PAN of the credit/debit card is made by the acquirer or by the payee and whether the strong authentication of the issuer (or of the bank) has to used or if it is allowed that:
1. the payees stores the PAN of the card and provides the user with a strong authentication provided directly by the payee, where the strong authentication is compliant with RTS.
2. the issuer at the point above has necessarily to request the ASPSP for knowing the availability of the amount on the bank account

In the paragraph 3.2.1 at point 26 seems that the channel where amount and payee are displayed is different from the channel used for initiating the payment.
However, in order to prevent from man-in-the-middle and man-in-the-browser attacks, at least in the case where the transaction signing is used as strong authentication, it could be possible to display amount and payee also on the channel used to initiating the payment to allow the user matching said information present on the two different channels.
In any case we agree with the fact that the means (for example a mobile app) used by the payer to authenticate must be different from the means (ecommerce web page, merchant app …) used to view goods to buy or manage banking accounts; in particular the authentication means shouldn’t allow SDKs to be integrated client side to provide segregation.

See our reply to the question Q1.
In addition it is not clear whether:
• card issuers have always to use ASPSPs strong authentication, even when it is not required to know the coverage of the payment amount in the user’s account.
• Usual home/mobile banking services not interconnected with PIS and AIS have to comply with the RTS

We do not agree with the fact that the implementation of the open standard will be different for all ASPSPs and this will cause the impossibility to realize an effective interoperability and a barrier to wallet solution which, instead, could offer the possibility to the ecommerce – mobile payment market to grow.

We agree as this is a standard and helps to get interoperability. It would be useful to define if communications have to use webservices or whatever else for interoperability.

We agree; everything which goes, where possible, towards convergence between eIDAS and PSD2 is agreed to simplify authenitcation rules.