SCA Requirements - Agree
Dynamic linking - agree this should be independent. This would allow for the case where single transactions, multiple transactions and recurring transactions may be dependent on time-based valuations (for example, commodity and currency changes - pay $US100 on the 1st of each month for the next 3 months from a €-denominated account")."
Other threats - the use of inherence" features may be subject to "drift" over time - for example fingerprint and facial recognition false +ve and false -ve parameters could be adjusted (or attacked) to allow for impersonation. Mechanisms should be in-place to re calibrate inherence factors (recapture fingerprint / faceprint, etc..).
Many of the trust mechanisms rely on PKI infrastructure - SCA (as well as PSD2 overall) should not overly rely on any one trust chain. The compromise of a root or intermediary CA is possible and a recovery mechanism should be in place to issue new credentials as well as offer alternative trust chains to ensure against systemic failure. In a similar vein, compromise of user credentials is possible (and increasingly common) - mechanisms should be in place to ensure user credentials can be reissued and old credentials revoked on an individual, group and population level. (Article 21 says that users should be notified "without undue delay" - these notifications may be covered by GDPR)"
Specific values for individual and cumulative transactions should not be hard-coded" in the regulations. These need to be factored against the user profile and the current threats. Future inflation may make these values unrealistic. The user profiling should also take into account privacy issues - forcing one user to use SCA for a €50 transaction but not another, may expose the "wealth" profile of the user. Having a varying value would draw less attention to individual users."
Having hard-coded" values for SCA thresholds provides a known limit for fraudulent transactions to operate under. There should be some randomised trigger as well - possibly based on time, risk profile of the payer and payee and also the intermediaries."
Agree. However, the provisions in Article 16 around the review process, do not outline the processes that should or must be in place should any of the tests or reviews indicate the measures are not adequate.
We do agree. However, we would mention that such an open set of standards create the need for a common 'Testing' (and potentially certification) process for both API suppliers and consumers to enable the ecosystem to operate effectively without creating the burdensome need for all TPPs to test against Payment Institutions.
ISO 20022 can provide a useful starting point for the definition of the messages exchanged between PSPs, however the standard, in its current format, has significant technical constraints that, if not resolved, will prevent its adoption
In particular:
• The syntax of ISO 20022 is based on XML or ASN.1, while it is most likely that the PSPs will opt for exchanging messages in JSON, a format that is more efficient, better supported and more widely adopted for exchanging messages in the context of web API.
• The semantics of ISO 20022 define important base concepts for the financial services industry, however they do not cover the area of customer authentication and authorization that are key for the implementation of PSD2
In general ISO 20022, in its current format, seems to be fit for exchanging information over secure channels established between parties that trust each other, while PSD2 requires a more open model where trust and authorization levels can be established dynamically, through the message exchange.
Agree. The publication of the registration number, which is the same as the authorization number (Article 20(2)) is poor practice - the registration / authorization number should not be used in any security context.
ISPs may wish to provide premium" offerings that query accounts more frequently that the "2-times per day" - these should be allowed under the regulations subject to agreement between the parties, which may include payment for the premium service. Also the timing and rate of the requests should be skewed to prevent denial-of-service scenarios.
The AISP requests should differentiate between "live" and "automated" requests which would allow the PISP to decline automated requests to protect the integrity of the service.
PISPs should also offer "push" notifications where there is a change in account balance that the AISP may be interested in (balance falls below €x or balance exceeds €y, for example)."
[IT services provider "]"
In relation to this consultation paper IBM are a provider of leading security business advice, consultancy and technology products / services that support many or the worlds most secure environments. In considering our response to this paper we have focused on our business advice gained via experience with key institutional organisations in which we partner to deliver sound planning, design and management for social and business critical environments.