INTRODUCTORY INFORMATION – NECESSARY TO INTERPRET OUR REPLIES

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.

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.

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”.

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.

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.

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.

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)

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.

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 level

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

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