Change Log
A summary list of changes from V3.1.4 to V3.1.5.
Changes are indicated as follows. Copy which has been removed is struck out and copy which has been added is in blue.
| ID | Section/Location | Change | Reason for Change |
|---|---|---|---|
| 1 | Performance | EBA Guideline 2.3 sets out a minimum of four KPIs for performance that an ASPSP should have in place for each of its dedicated interfaces. The following table explains these KPIs in greater detail and provides guidance on how they should be calculated. The OBIE Standard defines a number of endpoints which should be made available by ASPSPs in their dedicated interface. | EBA WG-API clarifications |
| 2 | Performance PISP response time | Added new section Payment Initiation Payment Initiation  Technical flow/PSU present:
Optional:
| EBA WG-API clarifications |
| 3 | Performance PISP response time | OBIE calculation guidelines OBIE recommends that the following elements are reported as an average response time in ms for each day:
The following API endpoints should be included when calculating PISP response times Avg Ta & Avg Te: Average Time Periods a & e The following OIDC endpoints should be reported to be included in the calculation for the response time of time periods Ta & Te:
The average response time of all endpoints in time periods Ta & Te shown above should be calculated as follows: Avg Ta = Avg Te = (Ta & Te) / (Va & e) where Va & e is the total volume of calls made to the end-points listed for time periods Ta & Te Avg Tb: Average Time Period b The following API endpoints relevant to the payment consent staging should be included in the calculation for the response time of time period Tb:
The average response time of all endpoints shown above should be calculated as follows: Avg Tb = (Tb) / (Vb) where, Vb is the total volume of calls made to the end-points listed for time period Tb Please note that in the case of payment staging API endpoints from the above list (i.e. POST endpoints), the response time must include “the time it takes for any checks that the ASPSP may choose to make on the authorisation/registration of TPPs”. This may include validation of access token, validation of the request payload, authentication/validation of the request etc. Avg Tc: Average Time Period c PSU Authentication time (PSU involvement) (OPTIONAL) This is the total time taken for the PSU to complete the authentication process. For the avoidance of doubt, this is the time measured in seconds from the point in time the PSU, after being redirected to the authentication screen of the ASPSP Authorisation Server, submits the credentials for authentication, completes authentication and any other actions such as selecting account(s), until control is passed back to the ASPSP to start the process of generating the authorisation code. The average response time of all endpoints shown above should be calculated as follows: Avg Tc = (Tc) / (Vc) where, Vc is the total volume of PSU authentications that generated the total response time Tc Avg Td: Average Time Period d The following is not an OIDC endpoint as such but it is an entry to be used for measuring the time period (d) of the authorisation code generation by ASPSPs:
The average response time of all endpoints shown above should be calculated as follows: Avg Td = (Td) / (Vd) where, Vd is the total volume of calls made to the end-points listed for time period Td Avg Tf: Average Time Period f The following API endpoints relevant to the payment consent staging should be included in the calculation for the response time of time period Tf:
The average response time of all endpoints shown above should be calculated as follows: Avg Tf = (Tf) / (Vf) where, Vf is the total volume of calls made to the end-points listed for time period Tf Avg Tg: Average Time Period g The following API endpoints relevant to the payment consent staging should be included in the calculation for the response time of time period Tg
The average response time of all endpoints shown above should be calculated as follows: Avg Tg = (Tg) / (Vg) where, Vg is the total volume of calls made to the end-points listed for time period Tg Avg Th: Average Time Period h The following API endpoints relevant to the payment consent staging should be included in the calculation for the response time of time period Th:
The average response time of all endpoints shown above should be calculated as follows: Avg Th = (Th) / (Vh) where, Vh is the total volume of calls made to the end-points listed for time period Th The ASPSP’s signed response to the POST will inherently act as proof of receipt of the payment order by the ASPSP, which will enable the TPP to log a reference and the date of this receipt. Both the POST and the GET endpoints contain all information relating to the payment, which, depending on the payment type, should include reference, amount, exchange rate, charges, and status (which may change between POST and any subsequent GET). The POST endpoints above cater for the requirements of PSD2 Article 66(4)(b), RTS Article 36(1)(b), i.e. for the ASPSP to make the information available to the PISP immediately after receipt of the payment order, and the FCA PSRs Approach Paragraph 17.29, i.e. the provision of all information on the initiation of the payment transaction and all information accessible to the ASPSP regarding the execution of the payment transaction. The GET endpoints cater for the requirements of the PSRs Approach Paragraph 17.30, i.e. for the ASPSP to provide confirmation to the PISP that payment initiation has been successful, in order to enable the PISP to provide this information to the PSU. | EBA WG-API clarifications Nationwide, item#2 RBS, item#1 |
| 4 | Performance AISP response time | Added new section Account Information Account Information  Technical flow/PSU present:
| EBA WG-API clarifications |
| 5 | Performance AISP response time | OBIE calculation guidelines OBIE recommends that the following elements are reported as an average response time in ms for each day:
The following API endpoints should be included when calculating AISP response times Ta & Te: Time Periods a & e The following OIDC endpoints should be reported to be included in the total response time:
Where an ASPSP cannot separate calls to the OIDC token endpoint based it the scope parameter, the ASPSP should apportion the total OIDC calls in the same ratio as AIS, PIS and CBPII consents. Tb: Time Period b The following API endpoints relevant to the account access consent staging should be included when calculating AISP response times:
Please note that in the case of account information consent staging API endpoints from the above list (i.e. POST endpoints), the response time must include “the time it takes for any checks that the ASPSP may choose to make on the authorisation/registration of TPPs”. This may include validation of access token, validation of the request payload, authentication/validation of the request etc. Avg Tc: Average Time Period c PSU Authentication time (PSU involvement) (OPTIONAL) This is the total time taken for the PSU to complete the authentication process. For the avoidance of doubt, this is the time measured in seconds from the point in time the PSU, after being redirected to the authentication screen of the ASPSP Authorisation Server, submits the credentials for authentication, completes authentication and any other actions such as selecting account(s), until control is passed back to the ASPSP to start the process of generating the authorisation code. The average response time of all endpoints shown above should be calculated as follows: Avg Tc = (Tc) / (Vc) where, Vc is the total volume of PSU authentications that generated the total response time Tc Td: Time Period d The following is not an OIDC endpoint as such but it is an entry to be used for measuring the time period (d) of the authorisation code generation by ASPSPs.
Where an ASPSP cannot separate calls to the OIDC token endpoint based it the scope parameter, the ASPSP should apportion the total OIDC calls in the same ratio as AIS, PIS and CBPII consents. Tf: Time Period f
Tg: Time Period g
Vg: Volume of calls g Total volume of calls made to the end-points listed in Tg | EBA WG-API clarifications |
| 6 | Performance Confirmation of Funds (CoF) response time (CBPII and PISP) | Added new section Confirmation of Funds (CoF) for CBPII Confirmation of Funds (CoF) for CBPII  Technical flow/PSU present:
| EBA WG-API clarifications |
| 7 | Performance Confirmation of Funds (CoF) response time (CBPII and PISP) | OBIE calculation guidelines OBIE recommends that the following elements are reported as an average response time in ms for each day:
The following API endpoints should be included when calculating CoF response times for CBPII: Time Periods a & e The following OIDC endpoints should be reported to be included in the total response time:
Where an ASPSP cannot seperate calls to the OIDC token endpoint based it the scope parameter, the ASPSP should apportion the total OIDC calls in the same ratio as AIS, PIS and CBPII consents. Time Period b The following API endpoints relevant to the CBPII CoF access consent staging should be included when calculating CBPII response times:
Please note that in the case of CBPII CoF consent staging API endpoints from the above list (i.e. POST endpoints), the response time must include “the time it takes for any checks that the ASPSP may choose to make on the authorisation/registration of TPPs”. This may include validation of access token, validation of the request payload, authentication/validation of the request etc. Avg Tc: Average Time Period c PSU Authentication time (PSU involvement) (OPTIONAL) This is the total time taken for the PSU to complete the authentication process. For the avoidance of doubt, this is the time measured in seconds from the point in time the PSU, after being redirected to the authentication screen of the ASPSP Authorisation Server, submits the credentials for authentication, completes authentication and any other actions such as providing consent, until control is passed back to the ASPSP to start the process of generating the authorisation code. The average response time of all endpoints shown above should be calculated as follows: Avg Tc = (Tc) / (Vc) where, Vc is the total volume of PSU authentications that generated the total response time Tc Time Period d The following is not an OIDC endpoint as such but it is an entry to be used for measuring the time period (d) of the authorisation code generation by ASPSPs.
Where an ASPSP cannot separate calls to the OIDC token endpoint based it the scope parameter, the ASPSP should apportion the total OIDC calls in the same ratio as AIS, PIS and CBPII consents. Time Period f
Vf: Volume of calls f Total volume of calls made to the end-points listed in Tf
| EBA WG-API clarifications |
| 8 | ASPSP Reporting Template | New version of ASPSP Reporting template uploaded to the standards website | EBA WG-API clarifications |
| 9 | The Operational Guidelines Checklist | Changes in Operational Guidelines Checklist xls file. Iterm #11.6 Have you successfully run all FAPI conformance tests for the security profile for redirect flows New version of Operational Guidelines Checklist xls file uploaded to the standards website. | OBIE internal review |
| TPP Guideline Changes | |||
| 10 | Data Ethics - GDPR General | To help you consider how to ‘operationalise’ data ethics, we recommend you start with an existing framework. You will find useful links in the box at the foot of this section. Open Banking enabled services facilitates the transfer of high-quality datasets from the consumer to the TPP. How you collect, collate, draw insight and inference from the data, and how you store it, use it and share it and for what purpose, all have ethical implications. Data is a company asset which requires proper and effective handling to create value. It also something which must be handled ethically with regards both to individual consumers the company is there to serve and the wider society to which it contributes. Therefore, data governance should ensure value creation for the company and risk minimisation for consumers and society. Data governance is important in ensuring all aspects of the asset is well managed for the company. Data ethics ensure the decisions you make about how to manage your data are in keeping with your overall purpose and social responsibilities. Data governance and ethics are closely linked. Data governance requires fulfilment of the law and regulatory requirements. However, data may also create new ethical or moral dilemmas which you address through appropriate data governance mechanisms. The way in which you govern data will be a direct expression of your ethical norms as a group of people and an organisation. For any TPP, it is essential to understand: (1) The data you collect, collate, draw insight and inference from, how you use it, for what purpose and how it is shared. It is important to have a clear approach to personal data, including data which may be considered personal, sensitive, commercial, as well as, data that may be pseudonymised and/or anonymised. (2) How the data interplays with the algorithmic system and the models you use, particularly in regard to how data is weighted or attributed in the algorithmic system to produce the outcomes. (3) What impact the combination of the data and the algorithmic system has on your end result. (4) What outcomes your data-driven service is achieving for your customers and wider society. (5) What consequences (both intended and unintended) will this have on customers and society in the short, medium and long term? Your evaluation of the above will help you identify not only legal and PR risk, but also potential ethical risks. To help you consider how to ‘operationalise’ data ethics, we recommend you start with an existing framework. Readers can refer to Ethical Data and Information Management, O’Keefe & O Brien, 2018. You will also find useful links in the box at the foot of this section. | Consumer & SME Rep #1 |
| 11 | Data Ethics - Framework | The approach should be collaborative and participatory. It should reference the key regulatory authorities, appropriate independent advocacy groups and deeply engaged customers. It engages all functions of a business. Implementing such a framework will help your organisation align your data principles and operational procedures to your purpose and values and enable you to meet your legal and regulatory obligations. In simple terms, a Data Ethics Framework helps ensure that your organisation’s moral commitments are upheld and well evidenced. This is a long term commitment to do what is right for customers and society, and what is good for people is also good for business. An ethical framework ensures that you have provided for the consideration of ethics within and across your organisation at all levels and functions. A data ethics framework provides principles for the acquisition, collection and collation, accuracy, cleansing, analysis, use, and sharing of personal data. It would also provide for a consistent process and document procedures through which an organisation decides, documents and verifies that its data processing activities are (1) lawful and (2) generating fair and good outcomes for both the individual and wider society.” Having a data ethics framework in place can, therefore, be a powerful risk mitigator and value creator. Your approach to implementing a data ethics framework and operationalising data ethics in your organisation should be one which is collaborative, diverse, and transparent. This walkthrough of a hypothetical (industry agnostic) Data Ethics Framework will introduce you to the concept and key components of a framework. | Consumer & SME Rep #2 |
| 12 | Data Ethics - Information Governance | There is no widely agreed definition for Information Governance. Broadly speaking, Information Governance sets information strategy, whilst effectively identifying and managing information risks. Your board or organisational governance body must become accountable for this function and should have representation of the appropriate expertise. This matters because boards have to sponsor the authorising environment for action, and this may result in uncertainty and new risks. By explicitly incorporating an operational Data Ethics Framework into information strategy, boards create the environment for Data Ethics to become an integral function of their enterprise. | Consumer & SME Rep #3 |
| 13 | Data Ethics -Data Governance and Oversight | Data Governance and Oversight Data Governance sets an information strategy, whilst effectively identifying and managing information risks. Your board or organisational governance body must become accountable for this function and should have a representation of the appropriate expertise. This matters because boards have to sponsor the authorising environment for action, and this may result in uncertainty and new risks. By explicitly incorporating an operational Data Ethics Framework into information strategy, boards create the environment for Data Ethics to become an integral function of their enterprise. Oversight (including Decision Making Authority and Accountability) • This will depend on the size and requirement of the firm, but consider implementing an ethics oversight mechanism for this purpose. • An ethics advisory board, committee or panel (EAB) should ideally combine representative views of both internal and external stakeholders. It is feasible to have a wholly external EAB, a wholly internal EAB, or a combination of the two. It will depend on what the purpose and role of the EAB are, and what structure best suits the firm. Size, culture, values, transparency, and cost, are factors playing a determining role so the approach should be proportionate to the size of the TPP. • Conducting “social preferability testing” with existing customers and other potentially impacted stakeholders may be a way of gaining that all-important external viewpoint insight into your EAB, as well as engaging societal dialogue before implementing new and improved TPPs services; • The constitution of the EAB should be (so far as possible) be interdisciplinary, and align with your governance processes and procedures to further embed oversight touchpoints in your existing ways of working. • Those involved in the EAB should represent diverse thinking and a diverse group of people (particularly including representation of the protected characteristics). • Consider how the views of representatives from wider society (such as through social preferability testing) are included in the oversight mechanism. • The authority and decision-making ability of the EAB should be clear. You need to be clear on each parties’ role and responsibility. This will determine to what degree the EAB functions in an advisory or active decision-making capacity. • The oversight mechanism should (so far as possible) be transparent, demonstrating how the ethical risks were identified, abated and/or mitigated. • Accountability and responsibility for the ethical decisions ultimately responded to by the firm ( whether by action or inaction) needs to be clear. • Consider how ethical decisions will be communicated to the TPP’s end users. • Consider what redress for the impact of ethical decisions looks like for end-users and whether this falls within the current remit of the Financial Ombudsman Service. | Consumer & SME Rep #4 |
| 14 | Data Ethics - Social Preferability Testing | Social Preferability Testing challenges what is ‘normal’ today by proposing those data processing activities, the intent behind them and the real life impacts, are ‘socially preferable’ rather than merely ‘socially acceptable’. This is an important distinction. It’s about finding ways to make what is good for people and society at large great for modern information businesses. For a firm wanting to consider itself as operating at a best practice level, it should be doing this kind of analysis. | Consumer & SME Rep #6,7 |
| 15 | Data Ethics - Useful Links | • UK Government National Data Strategy has published principles and supporting workbooks. • The Centre for Data Ethics and Innovation • The Open Data Institute (ODI) Data Ethics Canvas and supporting materials. • The European Commission ‘Ethics guidelines for trustworthy AI’ • OECD Data Ethics Principles • DEON command line tool that supports ‘ethics checklists’ • Data for Democracy’s, ‘The Global Data Ethics Project’ • The Ethics Centre • The Institute of Electrical and Electronics Engineers (IEEE),Ethically Aligned Design • The Information Commissioner; ico.org.uk • The European Protection Board; https://edpb.europa.eu/edpb_en • The European Commission; https://ec.europa.eu/info/index_en Start with the Information Commissioner’s Office • The Information Commissioner; ico.org.uk Information about the importance of Data Ethics and considering ethics in the context of AI: • The ethical and societal implications of AI Nuffield report • UK Finance Data Ethics White Paper produced in conjunction with KPMG • IAPP article on establishing Data Review Boards Principles and Guidelines: • DataEthicsEU principles: https://dataethics.eu/data-ethics-principles/ • UK Government National Data Strategy has published principles and supporting workbooks. • OECD Data Ethics Principles Useful tools • The ICO draft AI Auditing Framework (there is a generic link to the ICO but this is more useful) • Dot Everyone provides a range of possible different tools • The European Commission High-Level Expert Group produced AI Assessment Toolkit • The Personal Data Protection Commission of Singapore Second Edition of their Model AI Governance Framework (published January 2020) Other sources of information and guidance: • The Alan Turing Institute for more information on data ethics and data science • The Centre for Data Ethics and Innovation • The Open Data Institute (ODI) Data Ethics Canvas and supporting materials. • DEON command line tool that supports ‘ethics checklists’ • Data for Democracy’s, ‘The Global Data Ethics Project’ • The Ethics Centre • The Institute of Electrical and Electronics Engineers (IEEE),Ethically Aligned Design • The European Protection Board; https://edpb.europa.eu/edpb_en • The European Commission; https://ec.europa.eu/info/index_en | Consumer & SME Rep #8,9 |
| 16 | Data Privacy - GDPR | One of your Compliance with data privacy laws and GDPR requires a risk based approach tailored to the nature of personal data and the type of processing employed. The checklist below provides signposts to the relevant sources. It is not provided as legal advice, so should not be relied upon as intrinsically compliant with applicable data protection laws. Importantly, an organisation needs to evidence its compliance with data protection laws. Ensure the firm has clear policies and procedures in place to achieve compliance. These should be periodically reviewed and amended so that they meet the regulations and the requirements of the organisation. It is imperative personal data it is handled with utmost care. Ensure that everyone within your organisation understands their role in protecting customer data. Controls should be implemented that ensure standards are met, with appropriate action taken for failure to comply. GDPR is clear – an organisation must only hold personal data necessary and compliant with the purpose for which it was requested. When it is no longer necessary, organisations must have clear protocols in place to purge that data permanently from its access. Finances have traditionally been a very private thing, and therefore needs to be treated with extra caution. Recent research by the Financial Services Consumer Panel revealed the following: Among Non-TPP users in our research, most at best skim-read the terms and conditions of online services: 45% said they had not read them, a further 41% said they had only skim-read them. The main reasons why participants did not read the terms and conditions were: text too long (42%); not enough time to read them all (23%); or an assumption that an online service would comply with the law (31%). Over half of TPP user participants in the qualitative research said they did not read any terms and conditions for products and services that they had signed up for, including services that access their financial data. Many said that privacy policies were full of ‘legal jargon’ and not written with consumers in mind.” [https://www.fs-cp.org.uk/sites/default/files/final_position_paper_-_consenting_adults_-_20180419_0.pdf ] | Consumer & SME Rep, Data Privacy #1,2,3 |
| 17 | Data Privacy - SAR Subject Access Request Procedures | The process for recognising a SAR and how to effectively respond: what needs to be provided, what exemptions if any should be applied? Please read the ICO guidance: Right of access | Consumer & SME Rep, Data Privacy #7 |
| 18 | Data Privacy - SAR Subject Access Request Procedures | Consumer & SME Rep, Data Privacy #10 | |
| 19 | Data Privacy -How do you Know it’s Working? | Evidence that your procedures are being implemented in practice includes: • Deleting/redacting personal data. • Responding to a • Keeping a • Managing and reporting a data breach to the ICO, and/or where applicable, customers. • Active Training and Awareness programme. | Consumer & SME Rep, Data Privacy #10 |
| 20 | Data Privacy - The Data Privacy Checklist | This checklist summarises the most important data privacy issues. Organisations need to demonstrate that compliance is fundamental to their culture. • Establish lawful bases for processing personal data. These must align with Article 6 and where applicable Article 9 of GDPR (Special Category Personal Data). • Have a clear and transparent Privacy Notice. Please read the ICO guidance: Privacy notice • • Understand what privacy information should • Ensure you have the appropriate suite of data privacy policies and procedures. • Also, refer to Protecting Against Data Breach Section under Security. | Consumer & SME Rep, Data Privacy #9,11 OBIE Infosec #2 |
| 21 | Data Privacy - Useful Links | Institute and Faculty of Actuaries – A Guide for Ethical Data Science | Consumer & SME Rep, Data Privacy #12 |
| 22 | Issues and Disputes - Service Request | OBIE have recently extended ticket types to include Conformance Certifications and Known ASPSP Issues. A service request can be made through the Open Banking Service Desk https://openbanking.atlassian.net/servicedesk/customer/portal/1. When using the OBIE Service Desk to communicate with other participants and raising, TPP must ensure that they do not share customer personal data or any data which may be considered confidential or commercially sensitive. The ticket types for this are listed below:- • Access request:For Confluence and other services. • General query:Information requests about the open banking ecosystem. • Incident:Report anO issue. • Known ASPSP Issues:Report a known ASPSP issue. • API Downtime – For reporting API downtime. • Conformance certification:If you are an enrolled ASPSP and have signed T&Cs. • Premium API Submission: To submit a request. • Programme Management Change Request (PMG):To raise a change request relating to CMA Amended Order/Roadmap and / or related artefacts. | LBG #2 |
| 23 | Issues and Disputes -Customer Enquiry, Complaint and Dispute Process | Customers that engage with open banking enabled Third Party Providers (TPPs) will inevitably have enquiries, complaints and disputes, particularly when an issue arises around a transaction. In this scenario, the customer may choose to contact the TPP or Account Servicing Payment Service Provider (ASPSP), however these entities may not have all the required information to assist the customer. Customer Enquiry, Complaint and Dispute Process Should the customer be dissatisfied with the outcome presented to them, the TPP or ASPSP may refer the customer to the Financial Ombudsman Service (FOS), alternative dispute resolution (ADR) or in some cases, litigation. 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 OBIE Dispute Management System (DMS) platform. The DMS platform forms part of a wider solution offered by OBIE 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. | Consumer & SME Rep, Other Sections #4 Internal DMS Team |
| 24 | Issues and Disputes -Introduction | DMS 2.0 provides a means for participants to manage disputes, enquiries or complaints electronically. DMS 2.0 is a managed service that offers regulated entities a Software as a Service (SaaS) solution comprised of: • A case management workflow tool (DMS 2.0) 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 platform. 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 OBIE due to its position with data protection; 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. | Internal DMS Team |
| 25 | Issues and Disputes -How to get a DMS Account | A PSU or customer will raise queries, disputes or complaints with their bank (i.e. ASPSP) or payments / account information provider (i.e. TPP). A DMS 2.0 members will use the DMS system to log, investigate and manage communications between ASPSPs and TPPs to resolve issues. To get an account on the 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/ The DMS 2.0 platform is designed to be self-service so users can access and perform most functions on their own. The platform is not monitored by OB for data protection reasons. However we take an active role in encouraging operational excellence, outlined in the following sections. | Internal DMS Team |
| 26 | Issues and Disputes -Dispute Management: Code of Good Practice | 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. | Internal DMS Team |
| 27 | Issues and Disputes -Dispute Management: Confluence Page | Dispute Management: For more information about DMS, please log in to the Open Banking Confluence page where you can find a dedicated DMS Confluence page and access the following materials: • Frequently Asked Questions (FAQs) • Training videos • Other information such as technical readiness guide, data protection, information security • Announcements | Internal DMS Team |
| 28 | Issues and Disputes -Dispute Management: Website | Dispute Management: Website 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/ | Internal DMS Team |
| 29 | Security – ISO27001 | Changed to Information Security | OBIE Infosec #2 |
| 30 | Testing - Introduction | OBIE would like to ensure all Participants This is known as Launch Support. The purpose of this Section is to provide a brief overview of the Testing approach and act as a ‘hub’ from which participants can access relevant support documentation. | Consumer & SME Rep, Other Sections #5 |
| 31 | Testing - The Approach | The recommended approach is based on OBIE’s published Launch Support testing document [link]. It is designed to ensure that your TPP service operates effectively within the Open Banking OBIE Ecosystem, supporting your journey from participating in the ‘test ecosystem’ to operating in the ‘production ecosystem’. We • Integration testing - Testing against Model Bank APIs in the Directory Sandbox • Ecosystem testing* - Sandbox only. • First Occurrence Validation (FOV) - via coordination of voluntary buddy relationships with ASPSPs. These phases are also covered further in the Launch Support document. Testing requirements vary – therefore TPPs are encouraged to work with their designated OBIE representative to agree the most effective approach based on adapting the general approach described here | OBIE Internal Review |
| 32 | Testing - Participant Journey | Service Desk The Service Desk supports participants through enrollment and provides level 1 support for participant tickets. If you have a query and wish to contact the Service Desk to ask how to maintain your entity in the Directory, it is worth consulting the following guide first which is likely to contain the answer: Guide to Viewing & Updating your Entity Participant On-Boarding The OBIE Participant On-Boarding Team provides technical support relating to issues raised, Directory integration, integration/dynamic registration with Model Banks, running of Conformance Tool, etc. Questions can be raised by creating a Jira ticket, the guide for which is below. Jira Service Desk Testing Launch Support is an enduring activity designed to provide support to Participants during their testing journey and on to go-live, where applicable. During Launch Support, OBIE will assist in the coordination of TPP / ASPSP voluntary buddying TWG ALL Additionally, OBIE will provide customer communications examples such as use of common language and promotion via the Open Banking Website. | OBIE Internal Review |
| 33 | Testing - TPP/ASPSP Coordination | This section describes: • Ways in which TPP’s can come to market with services that meet customer needs, and that are tested and robust. • How a service can maintain consistent quality of service throughout its lifecycle. • How to coordinate information between Participants, so that all parties understand the impact of forthcoming changes. This applies throughout the service’s life cycle, not just the pre-launch phases. As the ecosystem evolves, assurance of change within the Production ecosystem becomes increasingly important. Requirements analysis and risk-based testing principles Open Banking have a wealth of expertise in testing services in the OB ecosystem. This is available to Participants, to assure the quality of their services – both for new and existing service extensions. Participants should coordinate testing with their Central Testing rep to support: • Use of Risk-Based testing principles to target the testing areas and avoid excess or misplaced testing. • The ‘Buddying’ process to link you up with appropriate ASPSP Participants. | OBIE Internal Review |
| 34 | Testing - Ecosystem communications | The Open Banking ecosystem consists of a large number of separate organisations collaborating to provide a unified experience to the customer (PSU). • No surprises. All Participants who may be impacted by a change or are involved in its delivery should be aware of the plan, insufficient time for necessary action. • Constant communication. Many changes happen gradually, over time e.g. traffic growth. These too can impact the ecosystem performance, so sharing of information on volumes and other behaviour is vital to inform predictions of future growth and the ecosystem adjustments required. • Respect confidentiality. All information | OBIE Internal Review |
| 35 | Testing | • Guidance around principles for robust application design. • Guidance on assuring usability (in conjunction with the Customer Experience Guidelines). • Assessing likely usage volumes | OBIE Internal Review |
| 36 | Testing | Preparation for service launch • • Where a new participant is planning to release a new offering into the market the Central Test team will coordinate and liaise with the OBIE ecosystem around any significant uplift in expected volumes of traffic on the specific APIs utilised by the new offering. • Endpoint monitoring and feedback. • Ecosystem engagement. • Open Banking Management Information. Participant Roles and Responsibilities Participant can enter the OBIE Ecosystem with a variety of roles. This section is a brief guide for TPP Participants to the appropriate style of testing required by their role, as outlined in the Launch Support document (see also the table of URLs at the end of this Section). The actual approach applicable to the participant’s circumstances shall be agreed with your OBIE representative. | OBIE Internal Review |
| 37 | Testing - Ecosystem Roles | Ecosystem Roles • TPP – Third Party Provider • TSP – Technical Service Provider • Agent – Where another business provides an AISP’s services. • CBPII – Card-Based Payment Instrument Issuers TPPs within the OBIE Ecosystem operate in one or more roles on the basis of their permissions granted by the FCA/ NCA: The roles granted by the NCA are: AISP – An Account Information Service provides account information services as an online service to provide consolidated information on one or more payment accounts held by a payment service user with one or more payment service provider(s). PISP – A Payment Initiation Services Provider provides an online service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider. CBPII – A Card-Based Payment Instrument Issuer is a payment services provider that issues card-based payment instruments that can be used to initiate a payment transaction from a payment account held with another payment service provider. UK entities should use the FCA website for applications To register with the FCA, use their Connect system In addition to the three types of permissions granted by the FCA/NCA, there is also a class of participant who does not provide information directly to customers – Technical Service Providers (TSP) provide technical support to ASPSP, AISP, PISP and CBPII participants. This can include providing an API gateway which consolidates interfaces from all ASPSPs through to the provision of customer-facing systems for use by participants. All links correct at time of publishing. OBIE takes no responsibility for any errors or omissions in the information hosted by third parties. | OBIE Internal Review |
| 38 | Testing - Software Statement Assertions and Consent Dashboards | Software Statement Assertions and Consent Dashboards The various roles, and their interaction with other Participants, can impact on: • Who owns the Software Statement Assertion (SSA) and the appropriate entry (if any) in the ‘on behalf of’ field of the SSA, in the Directory. • The identity of Participants displayed In the ASPSP access dashboard visible to the PSU. These topics continue to evolve, therefore you must check with either your Central Testing team contact or by raising a Jira ticket contact the OBIE Standards team. Further information can be found in the below links: • Open Banking Directory Usage (Production) • Open Banking Directory Usage (Sandbox) | OBIE Internal Review |
| 39 | Testing -TPP Consent Management | On occasion, TPPs have managed PSU consents in a way that makes it difficult for ASPSPs to provide accurate consent dashboards to their customers. This resulted in OBIE Decision 208, issuing guidance on avoiding duplicate consents. | OBIE Internal Review |
| 40 | Testing - eIDAS Certificate Management | eIDAS Certificate Management Following the conclusion of the FCA adjustment period on 14 March 2020, TPPs must identify themselves to ASPSPs using an eIDAS certificate. ASPSPs must be able to accept an eIDAS certificate from the TPP directly. Additionally, TPPs may use an alternative identification certificate issued by OBIE, provided that those TPPs have registered their eIDAS certificate with OBIE and OBIE continues to perform checks of the status of the eIDAS certificate. When a TPP technically onboards with an ASPSP, they will usually be asked to share some basic contact details to facilitate future communications. TPPs are encouraged to include this information to make ensure that they can be easily contacted and be kept informed of any updates that may be important. The four activities associated with obtaining and utilising an eIDAS certificate are outlined below: | Nationwide #1 |
| 41 | Testing - Managing your eIDAS Certificates | Managing your eIDAS Certificates eIDAS certificates expire after a period of time, usually 2 years. It is essential that a replacement certificate is acquired and uploaded to the OBIE Directory before the existing certificate expires. Not having a valid certificate in place could result in the inability to create new OBIE Certificates and loss of service. | OBIE Internal Review |
| 42 | Testing - Useful Links | New Table with Useful links has been inserted. | OBIE Internal Review |
| 43 | TPP Guidelines - Guidance on Change Management | Introducing Change ASPSP will provide TPPs with at least three months notice prior to introducing new changes or any updates to any component of the Open Banking Standard, regardless of whether these are major, minor or patch updates. However, there could be additional emergency implementation changes by ASPSPs (e.g. for reported security issues) without any such notice. All changes reported by ASPSPs to OBIE will be will be communicated to the ecosystem by OBIE. TPPs should then make relevant changes to their code. TPPs should also ensure that thorough and effective testing of any change is done using the test facilities of ASPSPs. For more details on Change Management, please refer to Sections Implementation of a new Open Banking Standard, Changes to an ASPSP’s Infrastructure, Configuration or Software and Notification of a Change of the OBIE Operational Guidelines. | Consumer & SME Rep Other Section #1 |
| 44 | Change Management -Notification of change | ASPSPs should provide notice to TPPs of a change (within the time frames outlined above) via the ASPSP's own website or developer portal. When informing TPPs of an anticipated change, an ASPSP should confirm: • Date notice is given • Details of the change that will be made (e.g. implementation of new version) • Reason for the change (e.g. new version to be implemented, old version to be deprecated, etc) • Details of ASPSP system(s) affected (e.g. test facility, production interface) • Details of how any change will be made available in the test facility in advance of the production interface • Indication of the likely impact for a TPP, including any action required by TPPs (e.g. requiring PSUs to re-authenticate) • Rating of the impact on the TPPs service: • Start time/date the change is anticipated to take effect and the end date/time (if applicable). OBIE Support Services offers support to ASPSPs and TPPs, | Consumer & SME Rep Other Section #1 |