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. While aA ll supported endpoints shown in the table below should be included by ASPSPs when calculating error rates, for and reporting response times. < the consent endpoints should be ignored, as these are not considered part of the process of ‘providing the information requested’ to the TPP for payment initiation, account information or Confirmation of Funds.	EBA WG-API clarifications
2	Performance PISP response time	Added new section Payment Initiation Payment Initiation Technical flow/PSU present: Step 1: PISP consent stage Step 2 - Setup of Payment order consent: PISP initiates client credentials grant. (a) ASPSP validates identity of PISP to establish a secure connection and responds with access token. PISP submits payment request. (b) ASPSP responds with consent ID. Step 3: Authorise Consent: PISP redirects the PSU to the domain of the ASPSP for authentication. (c) ASPSP performs SCA, this can include account selection and supplementary information. (d) Once authentication is successfully completed, the ASPSP will send authorisation code to the PISP. PISP exchanges authorisation code. (e)The ASPSP responds with access token. Step 4: COF (Optional for PISPs) – reported separately (GL 2.3 (c)) PISP requests COF. (f) ASPSP responds to COF request. Step 5: Create Payment Order: The PISP will submit the payment order. (g) ASPSP send all information to the PISP relating to the payment order (Reg. 69(2)(b)). Optional: Step 6: Get Payment Order Consent PISP requests payment status (h) ASPSP responds with payment status.	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: Average PIS response time = Avg Ta+Avg Tb+Avg Td+Avg Te+Avg Tg (Mandatory) Average PSU authentication time = Avg Tc = (Tc) / (Vc) (Optional) Average PIS Y/N confirmation = Avg Tf = (Tf) / (Vf) (Separate Reporting) Average PIS status response = Avg Th = (Th) / (Vh) (Separate Reporting) The “time taken per request” should be calculated for each day using the mean value of Time to Last Byte (TTLB) measured in milliseconds, starting from the time that each endpoint request has been fully received by the ASPSP and stopping when the last byte of the response message has been transmitted to the PISP. The following API endpoints should be included when calculating PISP response times, for each endpoint supported by the ASPSP: 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: OIDC endpoints for token IDs 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: POST /domestic-payment-consents POST /domestic-scheduled-payment-consents POST /domestic-standing-order-consents POST /international-payment-consents POST /international-scheduled-payment-consents POST /international-standing-order-consents POST /file-payment-consents POST /file-payment-consents/{ConsentId}/file 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: Generated OIDC Authorisation code 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: GET /domestic-payment-consents/{ConsentId}/funds-confirmation GET /international-payment-consents/{ConsentId}/funds-confirmation GET /international-scheduled-payment-consents/{ConsentId}/funds-confirmation 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 POST /domestic-payments POST /domestic-scheduled-payments POST /domestic-standing-orders POST /international-payments POST /international-scheduled-payments POST /international-standing-orders POST /file-payments 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: GET /domestic-payments/{DomesticPaymentId} GET /domestic-payments/{DomesticPaymentId}/payment-details GET /domestic-scheduled-payments/{DomesticScheduledPaymentId} GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}/payment-details GET /domestic-standing-orders/{DomesticStandingOrderId GET /domestic-standing-orders/{DomesticStandingOrderId}/payment-details GET /international-payments/{InternationalPaymentId} GET /international-payments/{InternationalPaymentId}/payment-details GET /international-scheduled-payments/{InternationalScheduledPaymentId} GET /international-scheduled-payments/{InternationalScheduledPaymentId}/payment-details GET /international-standing-orders/{InternationalStandingOrderPaymentId} GET /international-standing-orders/{InternationalStandingOrderPaymentId}/payment-details GET /file-payments/{FilePaymentId} GET /file-payments/{FilePaymentId}/report-file GET /file-payments/{FilePaymentId}/payment-details 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. We note that because different endpoints will have different payload sizes for request and response (especially relevant for file payment endpoints involving large files), and in order to facilitate a ‘like for like’ comparison with PSU interfaces, OBIE recommends that ASPSPs also report on the average time per megabyte (MB). This can be calculated by dividing the total response time in milliseconds by the total payload response size in MB, across all API calls for all API endpoints for each day.	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: Step 1: AISP consent stage Step 2 - Setup of Account Access consent: AISP initiates client credentials grant. (a) ASPSP validates identity of AISP to establish a secure connection and responds with access token. AISP submits the Account Access consent request. (b) ASPSP responds with consent ID. Step 3: Authorise Consent: AISP redirects the PSU to the domain of the ASPSP for authentication. (c) ASPSP performs SCA, this will include account selection. (d) Once authentication is successfully completed, the ASPSP will send authorisation code to the AISP. AISP exchanges authorisation code. (e)The ASPSP responds with access token. Step 4: Request Data: AISP requests list of authorised accounts. (f) ASPSP responds with a list of authorised accounts and IDs. AISP requests account information data either per account or in bulk. (g) ASPSP responds with account information data	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: Average AIS response time = (Ta+Tb+Td+Te+Tf+Tg) / (Vg) (Mandatory) Average PSU authentication time = Tc Avg = (Tc) / (Vc) (Optional) The “time taken per request” should be calculated for each day using the mean value of Time to Last Byte (TTLB) measured in milliseconds, starting from the time that each endpoint request has been fully received by the ASPSP and stopping when the last byte of the response message has been transmitted to the AISP. The following API endpoints should be included when calculating AISP response times, for each endpoint supported by the ASPSP: Ta & Te: Time Periods a & e The following OIDC endpoints should be reported to be included in the total response time: OIDC endpoints for token IDs 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: POST /account-access-consents 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. Generated OIDC Authorisation code 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 GET /accounts Tg: Time Period g GET /accounts/{AccountId} GET /accounts/{AccountId}/balances GET /balances GET /accounts/{AccountId}/transactions GET /transactions GET /accounts/{AccountId}/beneficiaries GET /beneficiaries GET /accounts/{AccountId}/direct-debits GET /direct-debits GET /accounts/{AccountId}/standing-orders GET /standing-orders GET /accounts/{AccountId}/product GET /products GET /accounts/{AccountId}/offers GET /offers GET /accounts/{AccountId}/party GET /party GET /accounts/{AccountId}/parties GET /accounts/{AccountId}/scheduled-payments GET /scheduled-payments GET /accounts/{AccountId}/statements GET /accounts/{AccountId}/statements/{StatementId} GET /accounts/{AccountId}/statements/{StatementId}/file GET/accounts/{AccountId}/statements/{StatementId}/transactions GET /statements We note that because different endpoints will have different payload sizes for request and response, and in order to facilitate a ‘like for like’ comparison with PSU interfaces, OBIE recommends that ASPSPs also report on the average time per megabyte (MB). This can be calculated by dividing the total response time in milliseconds by the total payload response size in MB, across all API calls for all API endpoints for each day. 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: Step 1: CBPII CoF consent stage Step 2 - Setup of CBPII CoF Access consent: CBPII initiates client credentials grant. (a) ASPSP validates identity of CBPII to establish a secure connection and responds with access token. CBPII submits the CoF Access consent request. (b) ASPSP responds with consent ID. Step 3: Authorise Consent: CBPII redirects the PSU to the domain of the ASPSP for authentication. (c) ASPSP performs SCA, this will include providing consent. (d) Once authentication is successfully completed, the ASPSP will send authorisation code to the CBPII. CBPII exchanges authorisation code. (e)The ASPSP responds with access token. Step 4: Request CoF Response: CBPII requests CoF response for amount (f) ASPSP responds with a Y/N response to the CoF request for the amount	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: Average CBPII CoF response time = (Ta+Tb+Td+Te+Tf) / (Vf) (Mandatory) Average PSU authentication time = Avg Tc = (Tc) / (Vc) (Optional) The “time taken per request” should be calculated for each day using the mean value of Time to Last Byte (TTLB) measured in milliseconds, starting from the time that each endpoint request has been fully received by the ASPSP and stopping when the last byte of the response message (i.e. the ‘yes/no’ conformation) has been transmitted to the CBPII or PISP. 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: OIDC endpoints for token IDs 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: POST /funds-confirmation-consents 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. Generated OIDC Authorisation code 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 POST /funds-confirmations Vf: Volume of calls f Total volume of calls made to the end-points listed in Tf The following API endpoints should be included when calculating CoF response times for PISP: GET /domestic-payment-consents/{ConsentId}/funds-confirmation GET /international-payment-consents/{ConsentId}/funds-confirmation GET /international-scheduled-payment-consents/{ConsentId}/funds-confirmation	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 (or alternatively the OBIE tests for conformance to the OB Security Profile) (including app-to-app tests)? New version of Operational Guidelines Checklist xls file uploaded to the standards website.	OBIE internal review
TPP Guideline Changes
10	Data Ethics - GDPR General	The issue of data ethics is surfacing for financial firms with the release of the General Data Protection Regulation (GDPR) and the acceleration of AI. It is an emerging field in which clear answers lag behind the questions being raised by the technology. Organisations want to maximise the value of data, but have to balance that against high standards of transparency and accountability. Developers should be aware of the principles, to avoid mistakes where reinforced biases and unintended uses can result in customer harm and litigation. 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. and non-personal data. Not all data used may be personal data. In some cases, it might 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	A Data Ethics Framework provides principles for the acquisition, analysis and sharing of personal data. It is the consistent process through which an organisation decides, documents and verifies that its data processing activities are socially ‘preferable’. It can therefore be a powerful risk mitigator and value creator. 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	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	You may not have heard the term ‘socially preferable’ before. It challenges what is ‘normal’ today by proposing that 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. 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 The most valuable asset is your customer's you hold is personal data. 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	SAR Subject Access Request (SAR) 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 SAR Subject Access Request. • Keeping a SAR Subject Access Request log or central record of processing. • 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 • What privacy information should we provide? • Understand what privacy information should we be provided. The ICO link provides guidance on what needs to be included in a Privacy Notice. Please read : Privacy notice checklist • 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	Dispute Management 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 In the event the TPP or ASPSP need to request or exchange information in supporting the customer, they are encouraged to engage via OB’s Dispute Management Service (DMS) platform. The DMS is part of a wider solution offered by OB to enable TPPs and ASPSPs to securely connect with one another, and manage the customer’s case from initiation to conclusion. 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	Dispute Management System 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	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/ How it works 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: Further Information Confluence Page 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 - ISO27001	OBIE Infosec #2
30	Testing - Introduction	OBIE would like to ensure all Participants and Technical Service Providers (TSPs) looking to operate within the Open Banking OBIE Ecosystems do so in a supported manner. This includes supporting TPPs with the ability to test their products and services (both at initial launch and also through subsequent changes) by providing a number of key tools and infrastructure to ensure that their products have been sufficiently tested prior to go-live. This helps continue to promote the culture of openness that was instigated developed during the initial Managed Roll-Out period from January to March 2018. 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 recommend suggest participation in OBIE test phases, as appropriate: • 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 * TPPs obtaining QTSP issued eIDAS Test QWAC and QSEAL certificates can be uploaded onto the OBIE Sandbox Directory. TPPs can also generate OBWAC and OBSEAL certificates which contain eIDAS like attributes from the Open Banking. ASPSP Test Facilities (Sandboxes) are expected to support TPP registration with both certification types OBIE eIDAS like and eIDAS. This is a mirror approach to production.	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 to ensure dynamic allocation of volumes on a best efforts basis to balance the interest of TPPs and ASPSPs. Participants will also get access to an assigned central test team representative to assist and guide them through the appropriate testing process. and access to Testing Working Groups (TWG). The same approach can apply to upgrades and enhancements of existing services in Production. This has the added benefit of enabling more effective communication across the ecosystem regarding any potential impact of new services. They will also be invited to Testing Working Groups (TWG) where current challenges and hot topics are discussed as a community. A link to the TWG Confluence page for all participants is below. TWG ALL Communications 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	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). This cannot happen without information sharing and coordination, along these principles: To facilitate this the Central Test team will encourage information sharing and coordination while ensuring these principles are maintained: • 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. Open Banking OBIE can facilitate this communication. • 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 shared shall be with the consent of the Participant and respect will be treated with consideration in relation to confidentiality.	OBIE Internal Review
35	Testing	Determining and addressing non-functional needs • 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 • Advise the ecosystem of plans, timescales, volumes. • 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. Post launch monitoring and communications • 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 TPPs within the ecosystem operate as defined in the Account note issued by the FCA. Their roles are within the scope of FCA regulations. The roles defined are: • 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	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  available to the ecosystem on the central noticeboard  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, via the central noticeboard tool which publishes by communicating  all notifications of change received from ASPSPs to the Open Banking ecosystem.	Consumer & SME Rep Other Section #1