a) VocaLink’s concern is how will a specific payee be identified, by name or sort code and account? The issue of fraud remains since banks don’t check the name of payees, and if it’s by numbers then it would facilitate frauds whereby the target account is owned by the fraudster. Should the banks build an entirely new way to validate identity if sort code/account number and name is not seen as sufficient? The non-banks would argue that the bank view of identity is relatively poor, and open to fraud? Although different banks take very different approaches to risk. Arguably there is a role for the Government owned digital identity scheme here, to provide more robust validation, but it seems more likely that it will follow industry standards such as OAuth, in due course.

Sort code and account number is not used to for strong customer identity online but might well be used for identifying where a payment is going to via the TPP. Creating a new mechanism for routing the payment is pointless as these two things are required to route a payment via whatever mechanism underlies the bank transfer (i.e. faster payments, CHAPS, BACS). There is no appetite for a government owned digital identity scheme (and in fact the government is looking to piggyback bank strong customer authentication for their own services in the future).

a. Electronic payments are rapidly moving to tokenisation for their security; this protects the underlying and static financial instrument (e.g. PAN number, bank details) while providing a one-time transaction code that can be linked back to the originating device. This underlies newer contactless payment transaction such as Applepay, Google wallet and Samsung pay via mobiles.

b. It is clear that any solution should provide a layer of abstraction which hides the underlying account details, for example Pay by Bank app™ (Zapp).
Zapp does hide the account details from the merchant. It leverages the users mobile bank app. The merchant generates a code, via Zapp, that the user puts into his bank app. The bank retrieves the payment details from VocaLink using the code and makes a faster payment, at which point the merchant is informed that it has been paid.
The user experience is as follows: Clicking the Pay by Bank app™ symbol online will automatically open a consumer’s bank app on their phone. Once securely logged in, they can quickly complete their payment. Consumers will be able to see their account balances before they pay and choose different accounts to pay from, thereby staying more in control of their finances.
NB it provides a layer of abstraction like apple pay and others which hides the underlying account details.

c. PayM, for example uses Dynamic Linking to confirm the amount and payee before releasing the payment instruction.

d. MyPINpad, for example is provided for this purpose, to obtain confirmation by a payer that the specific transaction is indeed approved by the payer: i.e. the PIS has not created a spoof transaction.

a. The key issue which seems to be omitted is that in a transaction, involving a TPP and an ASPSP, is they will each need to independently make their own subjective risk judgement. There is no reason that these should be the same for each transaction. In fact there is every likelihood that they will differ.
b. It is no longer adequate to authenticate just the user; best of breed banks authenticate the user, the device and the actual transaction to ensure that none of them are anomalous or have been tampered with during the course of the authenticated session (e.g. session hijack, payment modification, device takeover).
It is impossible to separate the issue of risk judgement and acceptance of risk from liability. For example, a TPP might want to provide a consistent user experience to a PSU and be prepared to take the risks of this. E.g. in permitting lower security for a transaction. But this may exceed the ASPSP’s risk appetite. This risk should be very clearly for the account of the TPP. The way that an ASPSP is left having to pursue a TPP for the reimbursement of unauthorised transactions will lead to transaction costs and credit risk. It would seem only logical that a TPP that wanted to take such an approach should enter into enforceable contractual commitments to reimburse the ASPSP. There should be regulation on passing through of adequate device and transaction context details to make a risk based decision (not contact details as stated). Banks need to be able to authenticate and risk score the customer, the device used and the transaction and not just the customer which has tended to be the focus.

a. The view a TPP and an AS PSP would have of each of the factors in para 45 would differ unless a PSU used only one TPP and one ASPSP and initiated all of its transactions via the TPP.
b. Device recognition is a key cornerstone of fraud prevention for online banking – however, often TPP’s do not pass details of the device initiating a transaction through which impedes risk based decisions by the bank.

a. The major risk that TPP potentially creates is if PSUs are to reuse their ASPSP-issued credentials when initiating transactions via TPPs. This is particularly concerning since “An AS PSP which provides a mechanism for indirect access should also allow direct access for the PIS providers” recital 32 has been interpreted by many TPPs and some authorities to effectively mandate overlay services whereby consumers can use their bank credentials at TPPs to initiate payments at ASPSPs. Presumably on the basis of additional protections that TPPs need to identify when they are initiating payments, and TPPs being regulated.

b. VocaLink believe the concept of tokenisation (for example OAuth tokenisation) or one time access credentials which protect the underlying bank online credentials is a valid one, and means the logon credentials ideally should not be shared with ASPSP or PIS.

c. Even if recitals 32 and 30 were interpreted as mandating a PIS being able to directly submit payment instructions to an ASPSP, it should be possible for an ASPSP to be able to satisfy this obligation by saying that a PIS could directly initiate payments, albeit with better controls (instead of reusing bank issued credentials). For example:
1. By having the TPP have its own credentials with the ASPSP that the TPP can use to initiate payment on behalf of the consumer (so the bank issued consumer credentials do not need sharing with the TPP); and/or
2. Requiring some sort of transaction authentication code that the ASPSP issues to the consumer is key, perhaps by phone or a dongle, included in the TPP’s payment instruction to the ASPSP, so the ASPSP has evidence the specific transaction has really been authorised by the consumer.

a. VocaLink believe the concept of tokenisation (for example OAuth tokenisation) or one time access credentials which protect the underlying bank online credentials is a valid one, and means the logon credentials ideally should not be shared with ASPSP or PIS.
b. Solutions based upon such tokenisation would be more elegant and give legally enforceable roles and boundaries, deciding where the risk lies.
c. If TPPs ONLY submit payment via such a medium it would seem reasonable to argue that a PIS did not give rise to any risk and therefore did not have to obtain insurance as a pre-condition to authorisation. So giving a route to avoiding one of the major potential barriers to entry for many PISs.

a. CAPS will have elements of fraud scoring, confidence score and trigger codes. It will also offer connectivity options for TPP’s and ASPSP’s above internet (bank API). All parties (TPP’s, ASPSP’s and intermediaries) should have up to date and relevant security protocols. Re TPP’s, a check of this should be done on registration. This may benefit from increased definition of standards, with policing via appropriate bodies, e.g. schemes.

There are a number of points where security credentials are vulnerable:
a. At the end users’ own device
b. anywhere credentials are stored en route
c. the point at which the credentials are processed i.e. PSP systems in memory while being passed onto the bank, there is already malware which does memory scraping for card details in point of sale devices that captures it while it is in flight.
d. Typically the TPP is the weakest link.

a. Whilst standards need to be “common” and “open” consideration must be given to “how” they know it’s an approved solution?

b. The point in para f would seem to support CAPS as a bank’s preferred access point for TPPs that they would have to adapt to, as long as CAPS was demonstrably compliant with the minimum technical requirements, for example OAuth tokenisation,
c. On point C, CAPS will provide a central routing service including which services each of the participants use/offer.

a. It would reasonable to suggest that the over-arching standards should be maintained within an appropriate standards body, or perhaps using OAuth standard fields
b. The particular standards could be policed by being required to adhere to PFMI style open membership and governance, a ‘scheme’ issue, with APIs being defined as standard(s).

a. It may be considered as a possible solution but should not be mandated. e-IDAS would create an artificial dependency and delaying factor. The obvious and most appropriate identification to build to would seem to be to bank’s KYC/CDD systems, which are specifically linked to payments accounts. e-IDAS is designed more with respect to government services use cases. The use of this identity by TPPs might also be a seen as creating a risk to the e-IDAS credentials.
b. Also, despite the e-IDAS, EBA’s SecuRe Pay and work on the Government identity schemes, they are currently not interoperable and don’t support cross border payments. Again the role / development of OAuth needs to be considered further.

As for 19,
a. It may be considered as a possible solution but should not be mandated. e-IDAS would create an artificial dependency and delaying factor. The obvious and most appropriate identification to build to would seem to be to bank’s KYC/CDD systems, which are specifically linked to payments accounts. e-IDAS is designed more with respect to government services use cases. The use of this identity by TPPs might also be a seen as creating a risk to the e-IDAS credentials.
Also, despite the e-IDAS, EBA’s SecuRe Pay and work on the Government identity schemes, they are currently not interoperable and don’t support cross border payments. Again the role / development of OAuth needs to be considered further.