Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Isabel Group is a Payment Initiation Service Provider and an Account Information Service Provider for the B2B market (Corporates). We provide our services exclusively to professional users. Consumers by default are not part of our customers base as they are covered by consumers oriented PISP’s and AISP’s.
Our contracted customers are legal business entities, who delegate payment initiation to natural persons acting on behalf of the legal entity (customer). In short, Isabel Group delivers payment initiation and account information services to business entities viz corporates.
In order to initiate payments from, and to consult information of the corporate’s bank accounts, permissions are delegated to the service users. Furthermore, the corporate’s policy rules for payment initiation, for payment authorization, and for viewing bank account information are expressed in terms of these permissions.
The corporates group their payment orders in “batches”. About 90% of the payment orders are part of a batch that contains more than one order. All payment orders contained in the same batch are handled in a transactional way (that is, in an “all or nothing” way).
Our Payment Initiation application enforces the corporate’s policy rules on every batch as that batch travels through the payment process. When the batch is transmitted to the bank, it is accompanied by a complete set of artefacts (currently those are digital signatures) which prove in a non-refutable way that the payment orders have been authorized in compliance with the corporate’s policy rules for payment authorization.
To generate that non-refutable proof, we apply strong authentication and we link specific characteristics of the batch to the authentication. However, depending on the number of payment orders in the batch, the individual amount and payee of every individual order may not be part of the characteristics linked to the strong authentication.
We issue the user’s personalized security credentials and each bank links those credentials to the identity of the concerned user in its own referential data. The bank does this in compliance with the KYC regulation.
In this response to EBA’s discussion paper, we focus on the topics that we believe to be specific for the corporate market.
Comment on paragraph 23.
Following the definitions of “payment transaction” and “remote payment transaction” as per Article 4(5) and 4(6), a remote payment transaction is not necessarily bound to a single amount nor a single payee. In the context of corporate payments, the definition of remote payment transaction matches best with the concept of “batch” and not with the concept of “individual payment order”. We refer to information about our business. Therefore it is not clear which specific amount and specific payee is referred by Article 97(2).
Comment on paragraph 27:
Our service users interact with our services “online”. However, we interact with the respective AS-PSPs in an asynchronous way:
- Account information is delivered asynchronously by the AS-PSP, and then securely stored in our infrastructure for online consulting by the service user
- Batches with payment orders are handled online by our service users, but they are transmitted to the respective AS-PSPs in an asynchronous way; the status evolution of the transport, as well as of the execution of the payment orders, is fed back to the service user
Given the above, it is not clear whether or not our service users “access their payment account online” when using our service.
Comment on paragraph 35:
Our service users handle batches with payment orders. Depending on the characteristics of the batch with payment orders, it may or may not be feasible to link a “specific amount” or “specific payee” to the authentication of the batch of payment orders. In a typical B2B use-case it is possible to dynamically link “certain characteristics” of the remote payment transaction to the authentication, but not necessarily a specific amount nor a specific payee.
Reply to question 1:
The management of users, user permissions and policy rules. Explanation by example. The consultation of account information is rightfully considered as a less risky operation compared to the initiation of payment orders. As an indirect consequence, if a device is not used to initiate payments, it might be “less secured”. Therefore it might be easier for an attacker to infect the device of a service user with only consultation permissions than to infect the device of a service user with payment permissions. The risk represented by this infected device increases dramatically if payment permissions can be granted to the user in question.
b) The (remote) transaction consists of a batch of payment orders. There is no obvious specific amount or specific payee related to the remote transaction. The strong authentication can nonetheless include other characteristics of the payment transaction.
Point C reads “transfers between two accounts of the same PSU held at the same PSP”. The meaning of the term “held at” should be clarified. We also refer to our comment on paragraph 27.
Comment on paragraph 44:
The factors that influence the reliability of an automated risk analysis vary substantially with the tool that is used, and may go beyond the factors listed in the discussion paper. For example, we use a tool which is based on “machine learning”. In order to learn, the tool needs feedback from its operators. The better the feedback, the better the reliability of future risk calculations.
Comment on paragraph 45:
We assume to understand which tools are referred in this paragraph, but we suggest to be explicit about it (“… such tools…”).
Reply to question 7:
Yes, because they set a general “line of thoughts”.
- What is the contractual agreement between the PSP and the PSU and what does it say about the procedure to give consent?
- What is the (business) risk of blocking the payment initiation, both for the PSU and for the PSP?
In our understanding, article 64 creates room for exemptions that are “agreed in a framework contract”. However, it is not clear to us whether such exemptions must be explicitly allowed in the RTS on strong customer authentication, or whether they are directly allowed by the text of article 64 alone.
- Using a third-party service which is compliant (i.e. the service provider has successfully gone through the certification / evaluation process)
- Using an end-to-end solution which is compliant (i.e. the solution supplier has successfully gone through the certification / evaluation process)
Paragraph 57.vi states that PISPs are not allowed to store sensitive payment data of the PSU. This is taken from article 66.3(e), whereas article 66.3(g) implicitly allows to store any data which is required for the provision of the payment initiation service.
Reply to question 15:
We find the clarifications comprehensive. With regard to their suitability, we share the following thoughts.
Building upon the re-use of the AS-PSPs “browser-based” implementation for the authentication of the user and for the authentication of the payment order will probably be a sufficient match for many use-cases. It suffices to add non-refutable proof of “who is requesting the authentication” to typical authentication solutions that are in widespread use today.
However, to enable innovative solutions without constraining them technologically, we believe that the PISP and AISP must be allowed to “own” the interaction with the PSU, including for the authentication of the user and for the authentication of the payment order. This ownership may necessitate the use of PSCs issued by the PISP or AISP. These PSCs must be unambiguously mapped on the identity of the PSU (possibly in combination with a payment account) as it is known in the referential dataset of the AS-PSP. We observe a resemblance with the enrolment process that several AS-PSPs have already implemented for authentication on their mobile solutions.
We believe that some standardized way of tokenization can be a good match for this latter use-case – for example based on an evolved version of OAuth.
b) We would expect EBA to go down to the specification level – at least for the artefact that proves (strong) authentication of the service provider, and for the minimum validation thereof by the AS-PSP. We would also expect this to be based on the directory services to be setup by the EBA
c)
d) For each atomic PI/AI functionality: (1) which data the PISP/AISP must provide in the request, possibly qualified as mandatory or optional; (2) how the AS-PSP must react in response to the request; (3) which data the AS-PSP must provide back to the requestor, possibly qualified as mandatory or optional. For the identification of the PSU and of the payment account, we refer to the thoughts shared in answer 15: authentication solutions, implemented by the AS-PSPs, should be usable for:
a. “one-off” authentication of a PSU
b. “one-off” authentication of a payment transaction
c. Enrolling the PSU in another authentication scheme, using tokenization. The token should include verifiable attributes such as its scope, its validity period, proof of authenticity
- The maturity of eID implementations versus the required maturity of solutions in the payment market
- The speed of evolution (innovation) in a commercial environment versus the evolution of a typical eID solution
- The user experience requirements for administrative applications versus the to be expected user experience requirements for (innovative) payment solutions
- Privacy constraints, sometimes disabling practical use of eID in a commercial context
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.
INTRODUCTORY INFORMATION – NECESSARY TO INTERPRET OUR REPLIESIsabel Group is a Payment Initiation Service Provider and an Account Information Service Provider for the B2B market (Corporates). We provide our services exclusively to professional users. Consumers by default are not part of our customers base as they are covered by consumers oriented PISP’s and AISP’s.
Our contracted customers are legal business entities, who delegate payment initiation to natural persons acting on behalf of the legal entity (customer). In short, Isabel Group delivers payment initiation and account information services to business entities viz corporates.
In order to initiate payments from, and to consult information of the corporate’s bank accounts, permissions are delegated to the service users. Furthermore, the corporate’s policy rules for payment initiation, for payment authorization, and for viewing bank account information are expressed in terms of these permissions.
The corporates group their payment orders in “batches”. About 90% of the payment orders are part of a batch that contains more than one order. All payment orders contained in the same batch are handled in a transactional way (that is, in an “all or nothing” way).
Our Payment Initiation application enforces the corporate’s policy rules on every batch as that batch travels through the payment process. When the batch is transmitted to the bank, it is accompanied by a complete set of artefacts (currently those are digital signatures) which prove in a non-refutable way that the payment orders have been authorized in compliance with the corporate’s policy rules for payment authorization.
To generate that non-refutable proof, we apply strong authentication and we link specific characteristics of the batch to the authentication. However, depending on the number of payment orders in the batch, the individual amount and payee of every individual order may not be part of the characteristics linked to the strong authentication.
We issue the user’s personalized security credentials and each bank links those credentials to the identity of the concerned user in its own referential data. The bank does this in compliance with the KYC regulation.
In this response to EBA’s discussion paper, we focus on the topics that we believe to be specific for the corporate market.
Comment on paragraph 23.
Following the definitions of “payment transaction” and “remote payment transaction” as per Article 4(5) and 4(6), a remote payment transaction is not necessarily bound to a single amount nor a single payee. In the context of corporate payments, the definition of remote payment transaction matches best with the concept of “batch” and not with the concept of “individual payment order”. We refer to information about our business. Therefore it is not clear which specific amount and specific payee is referred by Article 97(2).
Comment on paragraph 27:
Our service users interact with our services “online”. However, we interact with the respective AS-PSPs in an asynchronous way:
- Account information is delivered asynchronously by the AS-PSP, and then securely stored in our infrastructure for online consulting by the service user
- Batches with payment orders are handled online by our service users, but they are transmitted to the respective AS-PSPs in an asynchronous way; the status evolution of the transport, as well as of the execution of the payment orders, is fed back to the service user
Given the above, it is not clear whether or not our service users “access their payment account online” when using our service.
Comment on paragraph 35:
Our service users handle batches with payment orders. Depending on the characteristics of the batch with payment orders, it may or may not be feasible to link a “specific amount” or “specific payee” to the authentication of the batch of payment orders. In a typical B2B use-case it is possible to dynamically link “certain characteristics” of the remote payment transaction to the authentication, but not necessarily a specific amount nor a specific payee.
Reply to question 1:
The management of users, user permissions and policy rules. Explanation by example. The consultation of account information is rightfully considered as a less risky operation compared to the initiation of payment orders. As an indirect consequence, if a device is not used to initiate payments, it might be “less secured”. Therefore it might be easier for an attacker to infect the device of a service user with only consultation permissions than to infect the device of a service user with payment permissions. The risk represented by this infected device increases dramatically if payment permissions can be granted to the user in question.
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?
NA3. 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?
NA4. 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)?
NA5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
a) A corporate PSU initiates (remote) transactions from payment accounts held in different banks. The user experience would be “hell” if distinct devices and/or distinct mechanisms for strong authentication must be used. Therefore, we issue our own strong authentication solution to the PSUs, and every AS-PSP links the related PSCs to the corresponding user in its own referential data.b) The (remote) transaction consists of a batch of payment orders. There is no obvious specific amount or specific payee related to the remote transaction. The strong authentication can nonetheless include other characteristics of the payment transaction.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
NA7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Comment on paragraph 42:Point C reads “transfers between two accounts of the same PSU held at the same PSP”. The meaning of the term “held at” should be clarified. We also refer to our comment on paragraph 27.
Comment on paragraph 44:
The factors that influence the reliability of an automated risk analysis vary substantially with the tool that is used, and may go beyond the factors listed in the discussion paper. For example, we use a tool which is based on “machine learning”. In order to learn, the tool needs feedback from its operators. The better the feedback, the better the reliability of future risk calculations.
Comment on paragraph 45:
We assume to understand which tools are referred in this paragraph, but we suggest to be explicit about it (“… such tools…”).
Reply to question 7:
Yes, because they set a general “line of thoughts”.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
In the case of a corporate payment initiation, several aspects of the business context should be considered. Such aspects include:- What is the contractual agreement between the PSP and the PSU and what does it say about the procedure to give consent?
- What is the (business) risk of blocking the payment initiation, both for the PSU and for the PSP?
In our understanding, article 64 creates room for exemptions that are “agreed in a framework contract”. However, it is not clear to us whether such exemptions must be explicitly allowed in the RTS on strong customer authentication, or whether they are directly allowed by the text of article 64 alone.
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?
Other factors can additionally be considered, like for example the “ground speed” of successive user sessions or successive service requests issued by the same PSU. If service requests belonging to the same user session originate from different geographical locations, it can fairly be assumed that the session is being hijacked.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Risks resulting from insufficient information and education provided to the PSUs. Mitigating this risk requires a certain effort in “informing and educating” the PSU. As stated in paragraph 51(D), the PSU might unwittingly put his data and PSC at risk.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?
NA13. 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?
Most likely EBA’s suggestion is intended to include the following cases:- Using a third-party service which is compliant (i.e. the service provider has successfully gone through the certification / evaluation process)
- Using an end-to-end solution which is compliant (i.e. the solution supplier has successfully gone through the certification / evaluation process)
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?
NA15. 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?
Comment on paragraph 57:Paragraph 57.vi states that PISPs are not allowed to store sensitive payment data of the PSU. This is taken from article 66.3(e), whereas article 66.3(g) implicitly allows to store any data which is required for the provision of the payment initiation service.
Reply to question 15:
We find the clarifications comprehensive. With regard to their suitability, we share the following thoughts.
Building upon the re-use of the AS-PSPs “browser-based” implementation for the authentication of the user and for the authentication of the payment order will probably be a sufficient match for many use-cases. It suffices to add non-refutable proof of “who is requesting the authentication” to typical authentication solutions that are in widespread use today.
However, to enable innovative solutions without constraining them technologically, we believe that the PISP and AISP must be allowed to “own” the interaction with the PSU, including for the authentication of the user and for the authentication of the payment order. This ownership may necessitate the use of PSCs issued by the PISP or AISP. These PSCs must be unambiguously mapped on the identity of the PSU (possibly in combination with a payment account) as it is known in the referential dataset of the AS-PSP. We observe a resemblance with the enrolment process that several AS-PSPs have already implemented for authentication on their mobile solutions.
We believe that some standardized way of tokenization can be a good match for this latter use-case – for example based on an evolved version of OAuth.
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?
a) To be open: that clear and unambiguous documentation must be available to allow the implementation of a full-blown, correctly working “client application”; to be common: that the implementation is within the reach of the intended implementers, both on the technical and on the commercial levelb) We would expect EBA to go down to the specification level – at least for the artefact that proves (strong) authentication of the service provider, and for the minimum validation thereof by the AS-PSP. We would also expect this to be based on the directory services to be setup by the EBA
c)
d) For each atomic PI/AI functionality: (1) which data the PISP/AISP must provide in the request, possibly qualified as mandatory or optional; (2) how the AS-PSP must react in response to the request; (3) which data the AS-PSP must provide back to the requestor, possibly qualified as mandatory or optional. For the identification of the PSU and of the payment account, we refer to the thoughts shared in answer 15: authentication solutions, implemented by the AS-PSPs, should be usable for:
a. “one-off” authentication of a PSU
b. “one-off” authentication of a payment transaction
c. Enrolling the PSU in another authentication scheme, using tokenization. The token should include verifiable attributes such as its scope, its validity period, proof of authenticity
17. In your opinion, is 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?
NA18. 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)?
NA19. 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, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
From a purely theoretical point of view, we would agree. However, looking at both subjects (PSD2 and eIDAS), we perceive many “gaps” between the typical eID solution and payment solutions, listed below. These gaps cast a doubt on the suitability of eIDAS in the PSD2 context, at least in the foreseeable future.- The maturity of eID implementations versus the required maturity of solutions in the payment market
- The speed of evolution (innovation) in a commercial environment versus the evolution of a typical eID solution
- The user experience requirements for administrative applications versus the to be expected user experience requirements for (innovative) payment solutions
- Privacy constraints, sometimes disabling practical use of eID in a commercial context