Good Practice

Change Log v3.1.11

This version is:

This is the latest version Published 9 months ago 31 May 2023

A summary of changes from v3.1.10 to v3.1.11

Changes that has been removed is struck out and copy which has been added is in blue.

Other pages in this section

Good Practice Changes: v3.1.10 to v3.1.11

IDSection/LocationChangeReason for Change
VRPs for sweeping
1General considerationsAll SSPs using VRPs would typically be conducting a combination of Account Information Services (“AIS”) and Payment Initiation Services (“PIS”) activities and so would be regulated by the FCA. For sweeping services the actors in the payment chain will be largely/wholly regulated by the FCA and/or the Prudential Regulation Authority. Therefore, firms offering sweeping services must conduct their business activities in a fit and proper manner, ensuring that their customers’ interests are adequately protected. This impacts not only the products and services offered by SSPs but also how those products and services are designed, managed and delivered. Consumer protection should demonstrably be at the forefront of an SSP’s product design process for any VRP-enabled sweeping proposition. FCA regulated activity in the UK is underpinned by the FCA’s 1112 Principles for Businesses. These are set out below.
2FCA’s Principles for Businesses - Table 112. Consumer Duty A firm must act to deliver good outcomes for retail customers
3FCA’s Principles for BusinessesPrinciple 12 is the new Consumer Duty which requires FCA regulated firms to put consumers at the heart of their business and focus on delivering good outcomes for them. This will replace Principles 6 & 7.
4TCF Consumer OutcomesTo support thisthe principles, the FCA has provided clarity on the consumer outcomes they expect as a result of businesses adhering to Principle 6 and this will include providers of sweeping services.  These are outlined below.[1]See the FCA Handbook for more information 
5Introduction - SummaryIn summary, the FCA expects regulated firms to put the wellbeing of customers at the very heart of how they run their business and how they design, manage and deliver their products and services (including products and services that use VRPs for sweeping purposes).
VRPs are a new product offering and SSPs who intend to provide this service to their customers should undertake a robust new product development process. SSPs must put their intended consumers at the heart of the decision making process when developing new products and services and consider issues such as:
• What is the target market, and why would the intended customers choose to use the services of the SSP?
• How will the SSP determine whether or not the needs of its intended and actual customers are met?
• What does the end to end customer journey look like (including the role of any other firms etc. that might play a role in proposition to the customer). What kinds of risks are posed, and how will the SSP keep this under regular review?
• Might the intended sweeping service use evolve or customer change? How will the SSP keep this under review to ensure protections etc. remain appropriate?
• How might the service impact vulnerable customers? Can protections be designed into the service offering?

Placing the needs of customers at the heart of new product development should enable SSPs to identify and consider the potential risks to customers when using sweeping-related products and services and what can be done to mitigate those risks.
An example of something that SSPs should consider and take into account when developing sweeping propositions is the nature of the destination account. Are transactions easily reversible? Are there risks associated with the destination account and will the intended customer be adequately informed of those risks? E.g. if the SSP is providing sweeping to an investment account, has the user been adequately informed that their capital might be at risk? Can the SSP demonstrate that it is sufficiently clear that e.g. investments might not be readily reversible and even if they are, that any sums returned might be less than the amount “swept” (or indeed be zero)?
This is just one example, and a

E.g. if the SSP is providing sweeping to an account with a potentially volatile interest rate has the user been adequately informed of this risk.
All SSPs should ensure they fully understand the legal and regulatory implications of providing sweeping services using VRPs and take appropriate advice.
SSPs should assess whether they need to seek individual guidance from the FCA when designing their sweeping propositions using VRPs.
6Payment Services Regulations 2017 In addition, PSPs TPPs are subject to various governance and prudential conditions, including the need to hold professional indemnity insurance to cover business activities in relation to payment services, including PIS and AIS. Again, this requirement applies to all TPP PSP activities, including VRPs.
In addition, the PSRs provide consumer protections, including: the need to obtain customer consent and the right to be refunded in the case of unauthorised payment transactions (regulations 67 and 76 respectively); redress in the case of defective payments initiated through PIS (regulation 93) and liability on PSPs for fees and charges incurred in connection with defective payments (regulation 94). These protections cover all forms of recurring payments, including VRPs.
7Need to obtain customer consent - Ref [9] footnoteParagraph 8.151, FCA Approach Document
Paragraph 8.152, FCA Approach Document
8Need to obtain customer consentOnce the PISP has obtained the PSU’s explicit consent, in order to set up the VRP it must successfully complete the VRP Consent Setup process. Practically this requires the PISP to redirect the PSU to the domain of the ASPSP for the application of strong customer authentication (“SCA”). Following this, subsequent VRP payments can usually be made without the PSU being present by relying on the application of available exemptions by the ASPSP under the UK-RTS. For the majority of sweeping payments, OBIE believes that the UK- RTS Article 13 “trusted beneficiary exemption” is likely to be the most suitable (as the destination account will can be established as a trusted beneficiary during VRP Consent Setup). There may be instances when payments are swept into accounts held at the same ASPSP and the account is in the name of the payer, in which instances UK – RTS Article 15 “payment to self” exemption may be more suitable.
9Right to be refunded - i. Unauthorised PaymentsCustomers that lose out as a result of unauthorised VRP payments will be entitled to a refund from their ASPSP without having to wait for the resolution of any dispute between the ASPSP and the PISP, in the same way that they would for any other unauthorised payment type within the scope of the PSRs. The ASPSP has a right to request compensation from the PISPs for the amount refunded to the customer if the PISP cannot prove that they were not at fault. Where an unauthorised, non-executed or defectively executed transaction is initiated through a PISP, it is the ASPSP’s responsibility to provide a refund in line with regulation 76 and regulation 93 of the PSRs 2017 and this guidance. If the PISP is liable under regulation 76 or regulation 93 of the PSRs 2017, the ASPSP can then seek compensation from the PISP which must, on request, provide that compensation immediately. The amount of compensation should cover the full amount which the ASPSP was required to refund to the customer.
10Right to be refunded - ii.    Defective TransactionsAll of the CMA9 and many other ASPSPs and TPPs use the OBL's Dispute Management System platform for information sharing but there is no requirement to use this system and other options are available.
11Setting the appropriate consent parametersProspective SSPs should bear in mind that where inappropriately broad VRP Consent Parameters have been set (e.g. a relatively high maximum payment value per payment), then it may be more likely that a question could arise as to whether or not the consent is sufficient for the purposes of the PSRs, even if a payment transaction is executed within those VRP Consent Parameters. In this respect, the PSRs refer to the payer having given “explicit consent” or “explicitly requested” (under regulation 6967) and so if the consent parameters are not sufficiently narrow it may be reasonable to conclude in the event of a dispute/regulatory action that the consent is not valid because it does not adhere to the guidance in the FCA Approach document about consent being clear, specific and informed. If the transaction was deemed unauthorised because the PISP had not set the VRP Consent Parameters were not sufficiently narrow, the PISP may need to must compensate the ASPSP, if they have refunded the customer in these circumstances as per the PSRs (regulation 76).
12Visibility and ControlThe SSP will determine exactly how it provides visibility and control to its customers. For further guidance on revoke consent refer to VRP consent revocation journey and VRP access revocation journey. See Figure 2. for an example from the Customer Experience Guidelines on how a user might revoke consent for a VRP they had set up.
13Visibility and Control - Figure 2The Customer Experience Guidelines provide further guidance on OBIE’s expectations on ASPSPs (Access Dashboards) and TPPs (Consent Dashboards).
14Other considerations / InsuranceIn addition, PSPs TPPs are subject to various governance and prudential conditions, including the need to hold professional indemnity insurance to cover business activities in relation to payment services, including PIS and AIS. Again, this requirement applies to all PSP activities payments and would include VRPs.
15Examples of customer protections - Customer disputes the amount of a sweeping transaction.If transaction is outside of the VRP Consent Parameters, then it is an unauthorised transaction and customer entitled to a full refund. (See section Right to be refunded)

If the transaction is within the VRP Consent Parameters but these were not set sufficiently narrow then the transaction may be unauthorised and the PSU could be entitled to a full refund. then it is unlikely that the transaction would be considered unauthorised under the PSRs unless the consent parameters were not set sufficiently narrow by the PISP. (See section Setting the appropriate consent parameters).
16Examples of customer protections - Customer advises that money has been moved to an account that they do not own.the payee account is not in their name (as they input incorrect destination account details when setting up the sweeping service).Customer can complain to the ASPSP. If the destination account is not in the customer’s name but consent to make payments to this account was given by the customer to the PISP it is unlikely the transaction will be considered unauthorised under the PSRs. However, the customer is likely to have a claim against the SSP as the transaction is not sweeping and so the ASPSP may advise the customer to contact the SSP. If the destination account defined in the VRP consent is correct but the ASPSP has sent the funds to a different account, this would be considered an unauthorised transaction under the PSRs and the ASPSP would be expected to refund the customer no later than the business day following the day on which it becomes aware of the unauthorised transaction as soon as possible


Customer can complain to the SSP. As the destination account is not in their name is it not a Sweeping transaction and so the consumer could claim that that this is an unauthorised transaction and the SSP must refund the customer.


If the PSU was not satisfied with how the complaint was dealt with, they could refer the complaint to the FOS for independent consideration. (See section Redress framework)


This guidance does not override any obligations to refund customers who are victims of APP Fraud.


17Across all Other Guidelines pages


VRP for Sweeping Guidelines
Change Management
Testing
Issues and Disputes
Contract Supplier Management
Replaced "OBIE" references with "OBL"

or Open Banking Ltd (OBL)

or Open Banking Standard
Internal review to change organisation name from Open Banking Implementation Entity(OBIE) to Open Banking Limited (OBL)
18Issues and DisputesCustomer Enquiry, Complaint and Dispute Process
Customers that engage in any open banking enabled transactions such as account information services (AISPs) and payment initiation (PISPs)l may inevitably have enquiries, complaints and disputes particularly when an issue arises as a result of the transaction.
In this scenario, the customer may choose to contact the TPP or Account Servicing Payment Service Provider (ASPSP) to address their case, however, the said TPP or ASPSP may not have all the required information in hand to assist the customer. In this instance, it may be necessary for the TPP or ASPSP to need to connect to request or exchange information in the interest of supporting the customer. TPPs and ASPSPs are encouraged to engage via the OBL Dispute Management System (DMS) platform.
The DMS platform forms part of a wider solution offered by OBL to enable TPPs and ASPSPs to securely connect with one another, not least of which with the CMA9, and case manage the customer’s matter from initiation to arriving at a conclusion.

Should the customer be dissatisfied with the outcome presented to them, the TPP or ASPSP interfacing with the customer may be able to refer the customer to the financial ombudsman service (FOS), alternative dispute resolution (ADR) or in some cases, to litigation.


Operational Excellence: Dispute Management
The DMS enables TPPs and ASPSPs who have received a customer enquiry, complaint or dispute from engaging in open banking enabled payment or account information services to connect, share information and drive the case to an outcome for the customer.
DMS itself cannot solve the customer issue but it does provide a safe and secure tool by which members can connect to share information and provide a speedy and successful outcome for their mutual customer. It is up to the members themselves to make every effort to share information on a timely basis to maximise the likelihood of a successful customer journey. Using the platform as intended and adhering to the DMS Code of Good Practice can assist members in reaching the best outcome for the customer.
Introduction
DMS 2.0 is a managed service that offers all regulated entities a Software as a Service (SaaS) solution comprised of:
• A case management workflow tool (“DMS 2.0 platform”) for organisations signed up for DMS to manage customer cases from creation to outcome;
• Ability to securely share customer evidence and sensitive information in the DMS platform to drive cases to an outcome
• Access to a network of other TPPs and ASPSPs to collaborate or obtain information to support the customer case
• Reporting that provides management information and insight into the cases raised and managed within the DMS 2.0 platform
The DMS 2.0 platform is designed to be self-serving so users can access and perform all functions offered by the platform on their own. The platform will not be monitored by OBL; however it encourages operational excellence through promotion of the DMS Code of Good Practice, provision of frequently asked questions, training videos for those new to the platform and other useful information stored in a dedicated DMS Confluence page.
Dispute Management: Sign up and Manage Account
To become a member of DMS or to change the details previously used to sign up, please refer to the DMS website: https://www.openbanking.org.uk/providers/dispute-management-system/
Dispute Management: Code of Good Practice
All members signed-up to the DMS platform are required to acknowledge the DMS Code of Good Practice encouraging users to be responsible, transparent and supportive of other members of the DMS platform.
The Code of Good Practice can be found in the dedicated DMS Confluence page.
Dispute Management: Confluence Page
For more information about the DMS, please login to Open Banking Confluence where you can find a dedicated DMS page and access:
• Frequently Asked Questions (FAQs).
• Training videos.
• Other information such as technical readiness guide, data protection, information security.
• Announcements.
Removed reference of DMS

References

References
1 See the FCA Handbook for more information