Primary tabs

Lloyds Banking Group

All banks currently calculate availability of their direct channel in their own way, the requirement for comparison of the dedicated interface to direct interface availability data will be different comparisons across each ASPSP and therefore trying to standardise all service reporting metrics across industry would be a significant undertaking. LBG would also want to recognise the differences in types of transactions the direct or dedicated channels receive making it difficult to provide accurate comparisons e.g. webpage content being delivered through direct interface or a significant volume of historic data requested by a TPP on the dedicated channel. LBG supports the principle of parity between dedicated and direct channels and recognises that it is the banks responsibility to undertake adequate capacity planning. We would welcome confirmation that the comparison between channels will be done at a principle level.
With regard to the specific measure of downtime, if 5 transactions take longer than 30s to be responded to, LBG would like to highlight the complexities in delivering reporting at this level and the need to recognise the potential for other elements outside of an ASPSPs control to effect this also that would not be able to be captured. LBG would suggest a more objective measure would be to review all transactions received per second and if a certain proportion of these are not responded to within 30s or don't receive expected responses, this results in that second counting toward availability downtime.
No points to feedback at this time.
No points to feedback at this time.
LBG would want to get clarity from the EBA that as part of the on-boarding journey, where the bank replays the information received from a TPP for the type of access requested, this is not considered an obstacle and is a necessary step in the process of a PSU confirming the information LBG should be providing to the TPP going forward. Likewise, LBG believes that replaying the information to the PSU in a PISP journey is in the customers’ interests; it is robustly and repeatedly supported by customer research and by consumer advocates (i.e. customers consider it “necessary”; it replicates what the customer journey in our direct channel (i.e., we consider it “necessary”); it is the opportunity for the ASPSP to display balance or provide other useful information prior to initiating the payment.
LBG would welcome confirmation that the testing facility that will be needed to support TPP testing will be a functional test environment only based on the requirements under guideline 6.2 and each TPP and ASPSP will be responsible for conducting non-functional testing in their own environments independently. Each organisation is accountable for capacity planning in their own platform and there are consequences in regulation if they fail to deliver this appropriately.
No points to feedback at this time.
The dedicated interface is a service in its infancy and the TPPs are likely not going to fully understand its behaviours for some time and therefore there is a risk that there is a higher volume of incidents raised than on the direct channel creating a challenge in keeping parity in resolution times to that of the direct interface across all levels of incident. The direct interface is a mature channel within the bank and monitored by teams within LBG who understand the system at a deep technical level and therefore incidents raised are done so fully understanding that there is a system fault. LBG would want recognition from the EBA that this possibility could occur and give allowance where parity is not met for resolution times.
The form in the appendix suggests exemption is allowed at a bank's UIN level. Within LBG there is a number of sub brands who sit within a UIN that LBG is proposing to provide Screen Scraping + for due to the low volume of customers and demand seen to date on these platforms for OB. LBG are building APIs for the sub brands where highest demand has been seen to date and are where the majority of customers sit within the UIN. There is a similar situation within our Commercial area where some customers reside on fated systems due to their own organisational complexities and whilst the plan is to migrate these to applications which have had APIs built for them, and where the majority of clients sit, the plan is to only enable SS+ on these fated platforms. We would welcome confirmation that there will be the ability to specify which brands and/or channels are part of the exemption application under a UIN.
LBG is concerned about its ability to deliver the changes to the consent journey ahead of March 2019 due to the latest steer from the OBIE being received in the last month. Whilst LBG is targeting the delivery of App to app authentication within the Open Banking Implementation Entity (OBIE) R3 release, there is a degree of risk given the complexity of the delivery and remaining time available.
LBG would want to raise concerns regarding the requirement under the RTS 33 (7) for the contingency interface to be available within two months. Whilst LBG would be able to implement this option within the required timescales, it would be likely be a significant challenge for TPPs to be able to switch to such a channel within the required time period due to the differences between API and screen scraping interfaces. Therefore LBG would seek clarity from the EBA on the ability to provide assurance of system back up and disaster recovery capabilities in order that, should an exemption be granted, the contingency channel is a second API leg rather than requiring development of the SS+ channel.
Ian Weeks