Customer Experience Guidelines
This version is:
Published 5 years ago 31 Mar 2020A summary list of changes from V3.1.4 to V3.1.5. Changes are indicated as follows. Copy…
Other pages in this section
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 | Checklist #8 | Do you gather consent in a clear, specific and straightforward manner as per the principles described in Sections | Referenced to Section in CEG |
2 | Checklist #9 | Can a PSU view and revoke on-going consent in a Consent Dashboard without obstruction (as per Sections | Referenced to Section in CEG |
3 | Checklist #10a | Do you make available on all channels an access dashboard which allows PSUs to view access which has been previously granted and is it easy and intuitive for PSUs to find and use (as per Section | Referenced to Section in CEG |
4 | Checklist #10b | Do you make available an access dashboard which allows PSUs to revoke access which has been previously granted (as per Section | Referenced to Section in CEG |
5 | Checklist #13a | Do you use the OBIE language shown under the Customer Experience Guidelines Section | Referenced to Section in CEG |
6 | Checklist #13b | Do you use the OBIE language shown under the Customer Experience Guidelines Section | Referenced to Section in CEG |
7 | Checklist #19 | For payments that do not require the display of supplementary information (as defined in the Customer Experience Guidelines | Referenced to Section in CEG |
8 | Checklist #24 | Do you offer the PSU at least one of the available options for selecting the payment account during the payment initiation as defined in the Customer Experience Guidelines Section Payment Initiation Services (PIS)? | Referenced to Section in CEG |
9 | Checklist #31 | Do you, prior to receiving the first request from each CBPII, obtain explicit consent from the PSU to provide confirmation of funds in response to CBPII requests (as shown under the Customer Experience Guidelines Section | Referenced to Section in CEG |
Introduction | |||
10 | Customer Experience Principles | Design to maximise transparency to customers | Typo fixed. OBIE Internal Review |
Authentication Methods | |||
11 | Authentication Methods Journey & Wireframe | · Minor changes to the text in Journey & Wireframes. | |
12 | Decoupled Model A: Static PSU Identifier | A decoupled authentication flow, where the PSU provides a static identifier to the TPP (AISP/PISP/CBPII) which is used by the ASPSP to notify the PSU, such that the PSU can authenticate using the ASPSP app on a separate device. This enables the PSU to use the same app-based authentication method with the ASPSP they use when accessing the ASPSP mobile app directly. This model is best suited to TPP apps with good user input options (e.g. website on PC/laptop) but also where POS terminals can scan debit card numbers and automatically resolve the ASPSP if these are used as a customer identifier The exact type of identifier supported by the ASPSP must be published by the ASPSP. | Typo fixed. OBIE Internal Review |
13 | Browser Based Redirection – PIS | These details must be displayed as part of the authentication journey on at least one of these screens without introducing additional confirmation screens (unless supplementary information is required, refer to section Single Domestic Payments – Supplementary info). | OBIE Internal Review Duplicate text. |
14 | App Based Redirection – PIS | These details must be displayed as part of the authentication journey, on at least one of the following screens without introducing additional confirmation screens (unless supplementary information is required, refer to section Single Domestic Payments – Supplementary info). | OBIE Internal Review Duplicate text. |
15 | ASPSP applies an available exemption | SCA- RTS includes a number of available exemptions which permit an ASPSP not to apply SCA based on the availability of certain criteria, which consider factors such the amount, the beneficiary and the risk analysis of the transaction. When the ASPSP determines that an available exemption is applicable to the payment order submitted via the PISP, they may choose not to apply SCA. The SCA and the application of exemptions are solely within the domain of the ASPSP. | OBIE Internal Review |
16 | ASPSP applies an available exemption | These details must be displayed as part of the authentication journey on at least one of the following screens without introducing additional confirmation screens (unless supplementary information is required, refer to section Single Domestic Payments – Supplementary info). | OBIE Internal Review Duplicate text. |
17 | ASPSP applies an available exemption | · Minor changes to the text in Journey & Wireframes. | OBIE Internal Review |
18 | Using an Available Exemption with a Customer Identifier | These details must be displayed as part of the authentication journey on at least one of the following screens without introducing additional confirmation screens (unless supplementary information is required, refer to section Single Domestic Payments – Supplementary info). | OBIE Internal Review Duplicate text. |
19 | Using an Available Exemption with a Customer Identifier | · Minor changes to the text in Journey & Wireframes. | OBIE Internal Review |
20 | Using an Available Exemption with a Customer Identifier | This Journey can be used for subsequent transactions after an initial payment has been successfully made and details held for future use See Single Domestic Payments – a/c selection @ PISP, item #11. After the PSU has successfully initiated a payment initiation through a PISP, and details were held for future use (as per Single Domestic Payments – a/c selection @ PISP, item #11), this Journey can be used for initiating subsequent transactions. The PISP will provide to the ASPSP in all Note: This option may require a contract between the AISP and each ASPSP. | OBIE Internal Review |
21 | Using an Available Exemption with a Customer Identifier CX Consideration #4 | PISPs should provide messaging to inform PSUs that they will be taken to their ASPSPs to complete the payment. Example wording: “You will be securely transferred to YOUR ASPSP to authenticate and make the payment“. Note: In the case of a journey where the ASPSP will determine that an SCA exemption can be applied, this point would have been the PSUs’ “point of no return” for making the payment. However, as PISPs are not in a position to know whether that would be the case or not, they cannot really inform the PSUs about being at the “point of no return” for making the payment. PISPs may decide to provide some additional messaging to PSUs to address this. | OBIE Internal Review |
Account Information Services (AIS) | |||
22 | Permissions & Data Clusters for AIS journeys | Data Clusters OBIE customer research found that grouping permissions together and adding another layer of description aided the PSU's understanding of the data they were being asked to consent to share. This approach also allows a consistency of language across AISPs and ASPSPs to provide additional comfort to PSUs that they are sharing the data they intended to. If consistent language is used across all Participants this will drive PSU familiarity and adoption. These groups of permissions are known as Data Clusters. Data Clusters are not reflected in the API specifications, they are purely a presentational layer on top of permissions to aid PSU understanding. | OBIE Internal Review |
23 | Account Information Consent Journey & Wireframe | OBIE Internal Review | |
24 | Account Information Consent CEG Checklist #2 | AISPs must provide PSUs with sufficient information to enable PSUs to make an informed decision, for example, detail the purpose for which the data will be used (including whether any other parties will have access to the information) the period over which it has been requested and when the consent for the account information will expire (consent could be on-going or one-off). AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the AISP is only trading with its registered company name then it must display that name to the PSU. If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the AISP and must also, display the AISP's full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP. AISPs must also, populate the Agent company name in the 'On behalf of' field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU (please refer to item #5). Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the ' On behalf of' field with the details of their TSP. The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off). For examples of what names should be displayed, please refer to Consent Dashboard & Revocation, Examples. | More clarity on TPP name and Agent Name usage. Barclays, item #2 Consumer & SME Rep #2 |
25 | Account Information Consent Wireframe CX Consideration #5 | Text on popup corrected. | Consumer & SME Rep #1 |
26 | Account Information Consent CX Consideration #5 | ASPSPs must display the TPPs' trading name/brand name (i.e. the Client Name in the software statement) to the PSU during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the TPP even if it is different. If there is an Agent acting on behalf of the TPP, ASPSPs must also display the Agent company name (as captured in the 'On behalf of' field of the software statement) to the PSU. (Please note that ASPSPs can show the Agency/On Behalf field only in cases where this information has been provided by AISPs). For examples of what names should be displayed, please refer to AIS Access Dashboard & Revocation, Examples. This can be presented to the PSU by displaying both the agent’s name and the regulated AISP name as: Select and confirm account(s) to share information with | Barclays, item #1 More clarity on TPP name and Agent Name usage. Consumer & SME Rep #2 |
27 | Account Information Consent Note | Note: “Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services. When an agent acts on behalf of the AISP, the PSU must in the case of requirement #2 and should in the case of requirement # Please see details in requirements #2 and # For more examples on how to display, refer to Consent Dashboard & Revocation | OBIE Internal Review |
28 | Refreshing AISP access Journey & Wireframe | Replaced CX Consideration 1 to CEG Checklist Requirement 1 | OBIE Internal Review |
29 | Refreshing AISP access CEG Checklist #3 | 1. Add checklist reference no 8 2. Below change to the table AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the AISP is only trading with its registered company name then it must display that name to the PSU. If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the AISP and must also, display the AISP's full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP. AISPs must also, populate the Agent company name in the 'On behalf of' field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU (please refer to item #5). Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the ' On behalf of' field with the details of their TSP. The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off). For examples of what names should be displayed, please refer to Consent Dashboard & Revocation, Examples. | More clarity on TPP name and Agent Name usage. |
30 | Refreshing AISP access | More clarity on TPP name and Agent Name usage. | |
31 | Refreshing AISP access CEG Checklist #4 | AISPs must present a high-level summary of the data that is being requested and make it clear that this data and the purpose for which it will be used are the same as when originally requested. This should be done using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below). AISPs must ensure that this request is specific to only the information required for the provision of their account information service to the PSU. AISPs should only present those data clusters relevant to the product type in question. Where the request is for multiple product types then the detail shown in the data cluster should explain to the customer the product type to which it applies or state that it is shared across multiple product types. | More clarity on TPP name and Agent Name usage. |
32 | Refreshing AISP access CX Consideration #6 | As part of the authentication journey, the ASPSP could have a call to action, for example, to an expandable section that the PSU can click on for information purposes only. If the ASPSP provides this option for the PSU as supplementary information, it will enable the PSU to view the data they have chosen to share with the AISP. This should be done using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below). ASPSPs must display the TPPs' trading name/brand name (i.e. the Client Name in the software statement) to the PSU during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the TPP even if it is different. If there is an Agent acting on behalf of the TPP, ASPSPs must also display the Agent company name (as captured in the 'On behalf of' field of the software statement) to the PSU. (Please note that ASPSPs can show the Agency/On Behalf field only in cases where this information has been provided by AISPs). For examples of what names should be displayed, please refer to AIS Access Dashboard & Revocation, Examples. This can be presented to the PSU by displaying both the agent’s name and the regulated AISP name as: The information will be shared with | Barclays, item #1 More clarity on TPP name and Agent Name usage |
33 | Refreshing AISP access Note | Note: “Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services. When an agent acts on behalf of the AISP, the PSU must in the case of requirement #3, and should in the case of requirement # Please see details in requirements #3 and # | OBIE Internal Review. |
34 | Consent Dashboard & Revocation | · Minor changes to the text in Journey & Wireframes. Date changes as below | OBIE Internal Review. |
35 | Consent Dashboard & Revocation | Add new CEG Checklist #2 Change CEG Checklist #2 to #3, #4 to #5 Change CX Consideration #3 to #4, #5 to #6 | More clarity on TPP name and Agent Name usage. |
36 | Consent Dashboard & Revocation CEG Checklist #2 | AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the AISP is only trading with its registered company name then it must display that name to the PSU. If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the AISP and must also, display the AISP's full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP. AISPs must also, populate the Agent company name in the 'On behalf of' field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU (please refer to item #5). Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the ' On behalf of' field with the details of their TSP. The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off). For examples of what names should be displayed, please refer to Consent Dashboard & Revocation, Examples. | More clarity on TPP name and Agent Name usage. |
37 | Consent Dashboard & Revocation CEG Checklist #3 | AISPs must describe the data being shared through each consent using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below) and ensure this request is specific to only the information required for the provision of their account information service to the PSU. AISPs should present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission. The Consent Dashboard should also, describe: The consent dashboard must allow a PSU to view or cancel the access they have given consent to. The functions “Cancel “Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services. | More clarity on TPP name and Agent Name usage. OBSD-13253 - Authorised on Date for AISP consents. CLOSED Consumer & SME Rep #6,10 |
38 | CX Consideration #6 | ASPSPs should inform the PSU that no further account information will be provided by the ASPSP to the AISP as the PSU has withdrawn its access given to the AISP. After the Delete endpoint is called by the AISP to remove the account-access-consent resource, the ASPSPs are advised to inform the PSU via their own channels (for example via SMS or via a notification on their mobile phone) that AISP will no longer have access to their account. This is an additional confirmation to the PSU that the AISP has completed the delete endpoint process correctly. | Clarification. |
39 | Consent Dashboard & Revocation | Examples | More clarity on TPP name and Agent Name usage. |
40 | AIS Access Dashboard & Revocation | · Minor changes to the text in Journey & Wireframes. TPP name examples explained on hover. Date changes as below | OBIE Internal Review Consumer & SME Rep #16,17,18 |
41 | AIS Access Dashboard & Revocation CX Consideration #1 | ASPSPs must display the TPPs' trading name/brand name (i.e. the Client Name in the software statement) to the PSU during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the TPP even if it is different. If there is an Agent acting on behalf of the TPP, ASPSPs must also, display the Agent company name (as captured in the 'On behalf of' field of the software statement) to the PSU. (Please note that ASPSPs can only show the Agency/On Behalf field in cases where this information has been provided by AISPs). For examples of what names should be displayed, please refer to below table Examples. You may also refer to FAQs on Which name must TPPs display to the PSU. This can be presented to the PSU by displaying as: both the agent’s name and the regulated AISP name in the list of providers, where applicable. “Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services. | More clarity on TPP name and Agent Name usage. Consumer & SME Rep #15 |
42 | AIS Access Dashboard & Revocation CEG Checklist #3 | ASPSPs must describe the data being accessed using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below). ASPSPs should present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission. The Access Dashboard should also, describe: And may include the date of last access. ASPSPs must make available on all digital channels an access dashboard which allows PSUs to view access which has been previously granted and it must be easy and intuitive for PSUs to find and use. | OBIE Internal Review Consumer & SME Rep #22 Santander, item#6 |
43 | AIS Access Dashboard & Revocation | Examples | More clarity on TPP name and Agent Name usage |
44 | AIS Access for PSUs from Corporate Entities Journey & Wireframe | · Minor changes to the text in Journey & Wireframes. | OBIE Internal Review |
45 | AIS Access for PSUs from Corporate Entities CEG Checklist #2 | The AISP must provide the PSU sufficient information to enable the PSU to make an informed decision, for example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be on-going or one-off). AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the AISP is only trading with its registered company name then it must display that name to the PSU. If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the AISP and must also, display the AISP's full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP. AISPs must also, populate the Agent company name in the 'On behalf of' field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU. Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the ' On behalf of' field with the details of their TSP. The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off). For examples of what names should be displayed, please refer to Consent Dashboard & Revocation, Examples. | More clarity on TPP name and Agent Name usage. |
46 | AIS Access for PSUs from Corporate Entities CX Consideration #4 | ASPSPs must display the TPPs' trading name/brand name (i.e. the Client Name in the software statement) to the PSU during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the TPP even if it is different. If there is an Agent acting on behalf of the TPP, ASPSPs must also display the Agent company name (as captured in the 'On behalf of' field of the software statement) to the PSU. (Please note that ASPSPs can show the Agency/On Behalf field only in cases where this information has been provided by AISPs). For examples of what names should be displayed, please refer to AIS Access Dashboard & Revocation, Examples. | More clarity on TPP name and Agent Name usage |
47 | AIS Access for PSUs from Corporate Entities CEG Checklist #5 | The AISP | OBIE Internal Review |
48 | 90 Days Authentication | The PSRs require Strong Customer Authentication (SCA) to be performed each time the PSU accesses its online payment account, either directly or using the services of an AISP. The frequency of authentication can be reduced if an ASPSP applies the exemption relevant to account information access (RTS, Article 10), however, this will still require the PSU to be authenticated at least every 90 days. Moreover, the 90-day exemption doesn’t apply if the AISP wants to access more than the last 90 days’ worth of transactions. A PSU having given long-lived consent to an AISP to avail account information services, has to undergo SCA if it is accessing its account information via the AISP online for the first time, or if more than 90 days have elapsed since the last time the PSU accessed the information and SCA was applied. Irrespective of the duration of the consent agreed between the AISP and the PSU for the provision of the account information service, the PSU would still need to undergo SCA with their ASPSP at least every 90 days. This frequency may also increase if the PSU holds multiple payment accounts with various ASPSPs as they would need to undertake SCA for each of those ASPSPs on an individual basis. (It should be noted that the API specification allows the AISP to inform the ASPSP that the request is a refresh rather than a new request). SCA by AISP on behalf of ASPSPs In the case where the AISP requires the PSU to undergo SCA within or at the expiry of the 90 day period for account information access, the AISP will alert the PSU either within the session or outside of it (e.g. via SMS or push notification) that specific payment account(s) access across multiple ASPSPs are due for a refresh. The PSU will then undergo SCA at the AISP, as per the agreed parameters with the ASPSP(s). The AISP will then send a message to each ASPSP confirming that SCA has been performed successfully and requesting the ASPSPs to reset the 90-days re-authentication counter for the selected payment account accesses. This reduces the friction of the PSU going through multiple re-authentication journeys with multiple ASPSPs for the same AISP. Note: This option is likely to require a contract between the AISP and each ASPSP. Please also note that the proposition of SCA being performed by AISP on behalf of ASPSPs is subject to the applicable commercial arrangements between the parties. | OBIE Internal Review Nationwide, item#4 Barclays, item#6 |
49 | 90 Days Authentication | OBIE Internal Review | |
50 | 90 Days Authentication CEG Checklist #1 | AISPs | OBIE Internal Review |
51 | 90 Days Authentication CX Consideration #2 | AISPs | OBIE Internal Review |
52 | 90 Days Authentication CEG Checklist#3 | AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the AISP is only trading with its registered company name then it must display that name to the PSU. If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the AISP and must also, display the AISP's full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP. AISPs must also, populate the Agent company name in the 'On behalf of' field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU. Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the 'On behalf of' field with the details of their TSP. The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off). For examples of what names should be displayed, please refer to Consent Dashboard & Revocation, Examples. | More clarity on TPP name and Agent Name usage. |
53 | 90 Days Authentication CX Consideration #4 | AISPs should make it clear that the PSU is being asked to authenticate to extend the AISP access to their account data and that no other element of the consent (e.g. the data permissions required, the purpose for which it will be used etc.) will change. | OBIE Internal Review |
54 | 90 Days Authentication CEG Checklist#7 | AISPs | OBIE Internal Review |
Payment Initiation Services | |||
55 | Single Domestic Payments – a/c selection @ PISP | · Minor changes to the text in Journey & Wireframes. · Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. Item #3 Note Item #4 Example wording: " | OBIE Internal Review |
56 | Single Domestic Payments – a/c Selection @ PISP (Supplementary Info) | · Minor changes to the text in Journey & Wireframes. · Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. item#7 Supplementary Information ASPSPs must be able to introduce a step as part of the authentication journey to display supplementary information associated with that payment if required. If the supplementary information screen is displayed ASPSPs must display as minimum the Payment Amount, Currency and the Payee Account Name to make the PSU aware of these details. ASPSPs must allow PSUs to review as a part of the authentication process any supplementary Information. The PSU can either proceed with the payment or cancel it on the same screen with items #7 & #8,using options with "equal prominence“. item#10 The PSU can either proceed with the payment or cancel it on the same screen with items #7 & #8,using options with "equal prominence“. Wireframe items changes as follows: item#11 → item#10 item#12 → item#11 Check item#13 → item#12 | OBIE Internal Review |
57 | Single Domestic Payments – a/c Selection @ PISP (Supplementary Info) CX Consideration #8 | ASPSPs should display to PSUs any additional payment instruction information received from PISPs together with the supplementary information. This information may include the following: ASPSPs · | Consumer & SME Rep #25 Nationwide, item #6 |
58 | Single Domestic Payments – a/c Selection @ ASPSP | · Minor changes to the text in Journey & Wireframes. Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. | OBIE Internal Review |
59 | Single Domestic Payments – a/c Selection @ ASPSP | · Separated 'Available Balance' with Balance & Overdraft'. | Change-related to HCC. |
60 | CEG Checklist #9 | Additional Parameters ASPSPs must allow PSUs to select the payment account to complete the payment order for execution. It is up to ASPSP to consider relevant obligations relating to the FCA’s High Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42) & (PS19/16)”. | OBIE Internal Review Nationwide, item #6 |
61 | CX Consideration #10 | ASPSPs should inform PSUs about their “point of no return” for making the payment and that their payment will be made after pressing the Proceed button. Example wording: “Press Proceed to make payment“. | OBIE Internal Review |
62 | CX Consideration #11 | As per Single Domestic Payments – a/c selection @ PISP, item #9. | OBIE Internal Review |
63 | CX Consideration #12 | Moreover, PISPs can use this consent to provide a hint of the PSU’s identity using the customer identifier as part of the payment request to enable the subsequent payment journey contemplated in section Authentication methods. PISP Confirmation: As per Single Domestic Payments – a/c selection @ PISP, item #10. | OBIE Internal Review |
64 | Single Domestic Scheduled Payments (Future Dated) | · Minor changes to the text in Journey & Wireframes. Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. | OBIE Internal Review |
65 | Standing Orders | · Minor changes to the text in Journey & Wireframes. Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. | OBIE Internal Review |
66 | International Payments | · Minor changes to the text in Journey & Wireframes. Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. | OBIE Internal Review |
67 | International Payments | Where applicable, consideration should be given to relevant obligations in relation to REGULATION (EU) 2019/518 amending Regulation (EC) No 924/2009 as regards certain charges on cross-border payments in the Union and currency conversion charges. | Nationwide, item #7 |
68 | Bulk/Batch Payments | · Minor changes to the text in Journey & Wireframes. Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. | OBIE Internal Review |
69 | Multi-authorisation Payments | · Minor changes to the text in Journey & Wireframes. Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. | OBIE Internal Review |
70 | Multi-authorisation Payments | Changed the last milestone in the journey from | OBIE Internal Review |
71 | Payment Refunds | · Minor changes to the text in Journey & Wireframes. Replaced 'Payment' with 'Payment Order' on PISP confirmation screen. | OBIE Internal Review |
72 | Payment Refunds | Separated 'Available Balance' with Balance & Overdraft'. | Illustrative Change-related to HCC. |
Card Based Payment Instrument Issuers (CBPIIs) | |||
73 | All Journey & Wireframe | · Minor changes to the text in Journey & Wireframes. | OBIE Internal Review |