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/SectionLocationChangeReason for Change
1Checklist #8Do you gather consent in a clear, specific and straightforward manner as per the principles described in Sections 3.1.1 Account Information Consent  (AIS), 4.1.1 Single Domestic Payments – a/c selection @ PISP  (PIS) and 5.1.1 Consent for Confirmation of Funds (CoF)  (CBPII) of the Customer Experience Guidelines?Referenced to Section in CEG
2Checklist #9Can a PSU view and revoke on-going consent in a Consent Dashboard without obstruction (as per Sections 3.1.3 Consent Dashboard & Revocation and 5.1.4  CBPII Revocation of Consent of the Customer Experience Guidelines)?Referenced to Section in CEG
3Checklist #10aDo 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  3.1.4 AIS Access Dashboard & Revocation of the Customer Experience Guidelines)?Referenced to Section in CEG
4Checklist #10bDo you make available an access dashboard which allows PSUs to revoke access which has been previously granted (as per Section  3.1.4 AIS Access Dashboard & Revocation of the Customer Experience Guidelines)?Referenced to Section in CEG
5Checklist #13aDo you use the OBIE language shown under the Customer Experience Guidelines Section 3.2.3 Permissions & Data Cluster  to describe the data clusters when communicating with the PSU?Referenced to Section in CEG
6Checklist #13bDo you use the OBIE language shown under the Customer Experience Guidelines Section 3.2.3 Permissions & Data Cluster to describe the data clusters when communicating with the PSU and ensure to only request the data necessary for the provision of your account information service to the PSU?Referenced to Section in CEG
7Checklist #19For payments that do not require the display of supplementary information (as defined in the Customer Experience Guidelines 4.1.2 Single Domestic Payments – a/c Selection @ PISP (Supplementary Info) does your journey involve any further steps (as defined in the Customer Experience Guidelines 4.1.1 Single Domestic Payments – a/c selection @ PISP ) or screens following authentication?Referenced to Section in CEG
8Checklist #24Do 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
9Checklist #31Do 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 5 Card Based Payment Instrument Issuers (CBPIIs) )?Referenced to Section in CEG
Introduction
10Customer Experience PrinciplesDesign to maximise transparency to customers
  • Clarify rights and responsibilities describing and how the relationship works.

  • Investigate and answer additional questions raised.

  • Clarify the purpose of data collection and it  who  is responsible for the  use.

  • Offer detailed explanations for why specific data clusters are collected and used.

  • Clarify what happens after the period ends.

  • Clarify data use and removal after consent is revoked (e.g. what happens to past, present, future data).

    		• Typo fixed.
    OBIE Internal Review
    Authentication Methods
    11Authentication Methods
    Journey & Wireframe    		·       Minor changes to the text in Journey & Wireframes.
    12Decoupled Model A: Static PSU IdentifierA 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 identifiers .
    The exact type of identifier supported by the ASPSP must be published by the ASPSP.    		Typo fixed.
    OBIE Internal Review
    13Browser Based Redirection – PISNOTE:
    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.
    14App Based Redirection – PISNOTE:
    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.
    15ASPSP applies an available exemptionWhere all information for a complete payment order (including the PSUs’ account details) is passed from PISPs to ASPSPs, once PSUs have been authenticated, PSUs must be directed back to the PISP domain without any further steps taking place. This excludes the cases where supplementary information is required to be provided to PSUs as described in section Single Domestic Payments – Supplementary info).
    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
    16ASPSP applies an available exemptionNOTE:
    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.
    17ASPSP applies an available exemption·       Minor changes to the text in Journey & Wireframes.OBIE Internal Review
    18Using an Available Exemption with a Customer IdentifierNOTE:
    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.
    19Using an Available Exemption with a Customer Identifier·       Minor changes to the text in Journey & Wireframes.OBIE Internal Review
    20Using an Available Exemption with a Customer IdentifierWhere all information for a complete payment order (including the PSUs’ account details) is passed from PISPs to ASPSPs, once PSUs have been authenticated, PSUs must be directed back to the PISP domain without any further steps taking place. This excludes the cases where supplementary information is required to be provided to PSUs as described in section Single Domestic Payments – Supplementary info).

    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 any subsequent transactions a hint of the PSU’s identity by sending the customer identifier as part of the payment initiation request. This will enable the ASPSP to facilitate a journey with less friction, in instances where the ASPSP determines that SCA is not required based on an available exemption.  
    Note: This option may require a contract between the AISP and each ASPSP.     		OBIE Internal Review
    21Using 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)
    22Permissions & Data Clusters for AIS journeysData 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.
    It should be noted that the P15 Evaluation (Efficacy of Consent Dashboards) currently underway will consider the structure of data clusters and the language used to support them. These guidelines will be amended in line with the output of that evaluation exercise.     		OBIE Internal Review
    23Account Information Consent
    Journey & Wireframe
  • Minor changes to the text in Journey & Wireframes.

  •   Replaced CX Consideration 1 to CEG Checklist Requirement 1
    		• OBIE Internal Review
    24Account 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.
    If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP    		More clarity on TPP name and Agent Name usage.
    Barclays, item #2
    Consumer & SME Rep #2
    25Account Information Consent
    Wireframe CX Consideration #5    		Text on popup corrected.Consumer & SME Rep #1
    26Account 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.
    If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP. The customer-facing entity must also display the AISP’s full trading name.

    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 , who is acting on behalf of ..    		Barclays, item #1

    More clarity on TPP name and Agent Name usage.

    Consumer & SME Rep #2
    27Account 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 #45 be made aware of this within the consent journey.

    Please see details in requirements #2 and #45.

    For more examples on how to display, refer to Consent Dashboard & Revocation    		OBIE Internal Review
    28Refreshing AISP access
    Journey & Wireframe
  • Minor changes to the text in Journey & Wireframes.

  • Replaced CX Consideration 1 to CEG Checklist Requirement 1

    • Replaced CX Consideration 1 to CEG Checklist Requirement 1    		OBIE Internal Review
    29Refreshing 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.
    30Refreshing AISP access
  • Add new CEG Checklist #3

  • Change CEG Checklist #3 to #4, #4 to #5, #6 to #7

  • Change CX Consideration #5 to #6
    		• More clarity on TPP name and Agent Name usage.
    31Refreshing 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.

    If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP and must display the AISP’s full trading name.    		More clarity on TPP name and Agent Name usage.
    32Refreshing 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.
    If the customer-facing entity is acting as an agent for the AISP and this information is made available to the ASPSP, the ASPSP should make the PSU aware that the agent is acting on behalf of the AISP.

    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 , who is acting on behalf of     		Barclays, item #1

    More clarity on TPP name and Agent Name usage
    33Refreshing 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 #56  be made aware of this within the consent journey.

    Please see details in requirements #3 and #56.    		OBIE Internal Review.
    34Consent Dashboard & Revocation·   Minor changes to the text in Journey & Wireframes.
    Date changes as below
    Authorised - Access granted
    Last Authorised - Last access refresh
    Expires - Access expires    		OBIE Internal Review.
    35Consent Dashboard & RevocationAdd 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.
    36Consent 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.
    37Consent 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:

  • A description of the account information service that is being provided (including whether any other parties will have access to the information).  If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP.

  • Where the request is for multiple product types, the detail should explain to the customer the product type to which it applies or state that it is shared across multiple product types.

  • The date when consent was granted for the provision of the account information and the date when the service commenced.

  •   The date when consent was first granted. It is recommended to also show the date when the customer last refreshed their access as part of the 90 days re-authentication.

  • The length of time for which this consent is valid (e.g. one-off use, for a set period of time e.g. one year, or with no end date and the date of expiry).

  • The period for which the account information has been requested (e.g. transactions for the last 12 months).

    • The consent dashboard must allow a PSU to view or cancel the access they have given consent to. The functions “Cancel Consent Permission” and “back” should be displayed with equal prominence to the PSU.

    “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
    38CX Consideration  #6ASPSPs 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.
    39Consent Dashboard & RevocationExamplesMore clarity on TPP name and Agent Name usage.
    40AIS Access Dashboard & Revocation·     Minor changes to the text in Journey & Wireframes.
    TPP name examples explained on hover.
    Date changes as below
    Authorised - Access granted
    Expires - Access expires    		OBIE Internal Review

    Consumer & SME Rep #16,17,18
    41AIS 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.
    If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU should be made aware that the agent is acting on behalf of the AISP.

    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
    42AIS 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:

  • The status of the access e.g. Active/Inactive.

  • When the AISP's access to the account(s) will expire, if available.

  • The date the authorisation was granted.

    • 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
    43AIS Access Dashboard & RevocationExamples

    		More clarity on TPP name and Agent Name usage
    44AIS Access for PSUs from Corporate Entities
    Journey & Wireframe    		·       Minor changes to the text in Journey & Wireframes.OBIE Internal Review
    45AIS 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.

    If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP and must also display the AISP’s full trading name.    		More clarity on TPP name and Agent Name usage.
    46AIS 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
    47AIS Access for PSUs from Corporate Entities
    CEG Checklist #5    		The AISP should must confirm to the PSU:OBIE Internal Review
    4890 Days AuthenticationThe 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
    4990 Days Authentication
  • Minor changes to the text in Journey & Wireframes.

  • Add new CEG Checklist #3 with CEG Checklist Reference #8

  • Rename CX Consideration #3 to #4,

  • Rename CEG Checklist #4 to #5, #5 to #6, #6 to #7
    		• OBIE Internal Review
    5090 Days Authentication
    CEG Checklist #1    		AISPs should must alert the PSU when authentication needs to be performed to refresh AISP access.OBIE Internal Review
    5190 Days Authentication
    CX Consideration #2    		AISPs must should allow the PSU to select all the payment accounts across ASPSPs that may or may not be due for access refresh.  OBIE Internal Review
    5290 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.
    5390 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.
    If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP.     		OBIE Internal Review
    5490 Days Authentication
    CEG Checklist#7    		AISPs should must provide confirmation to the PSU that authentication has been successfully completed and access has been refreshed.OBIE Internal Review
    Payment Initiation Services
    55Single 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 1: if PSU payment Account identification is selected in item #2, PISPs should mask the PSU payment Account details on the consent screen. Otherwise, if the PSU payment Account identification has been input by PSUs in item #2, PISPs should not mask these details to allow PSUs to check and verify correctness.
    Note 2: if PSU payment Account identification is provided by PSUs in item #2, PISPs could use this to identify and display the ASPSP without having to ask PSUs.
    Item #4
    Example wording: "You will be securely transferred We will securely transfer to YOUR ASPSP to authenticate and make the payment“.    		OBIE Internal Review
    56Single 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
    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“.

    Wireframe items changes as follows:
    item#11 → item#10
    item#12 → item#11
    Check item#13 → item#12
    		OBIE Internal Review
    57Single 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:
  • Payment Reference, if it has been entered by PSUs or pre-populated by PISPs in item #1

  • PSU payment Account Identification and/or the selected ASPSP (based on item #2 options).

  • Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN)

    • ASPSPs could should  display the balance of PSUs payment account (see section Authentication methods for clarification on SCA requirements), provided that they are able to do so on the same authentication screen.
  • ·       It is up to ASPSP to consider relevant obligations relating to the FCA’s: Overdrafts consultation paper and policy statement (CP18/42)and High-Cost Credit Review: Overdraft policy statement (PS19/16)

    • ·       ASPSPs must ensure that they comply with their obligations relating to the FCA’s High Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42)     		Consumer & SME Rep #25
    Nationwide, item #6
    58Single 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
    59Single Domestic Payments – a/c Selection @ ASPSP·       Separated 'Available Balance' with Balance & Overdraft'.Change-related to HCC.
    60CEG Checklist #9Additional 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
    61CX Consideration #10Generic ASPSP to PISP redirection screen and message. Please refer to section Effective use of redirection screens.
    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
    62CX Consideration #11Generic ASPSP to PISP redirection screen and message. Please refer to section Effective use of redirection screens.
    As per Single Domestic Payments – a/c selection @ PISP, item #9.     		OBIE Internal Review
    63CX Consideration #12If PSUs provide their payment account identification details (as per item #2 options), the PISP could, with the consent of the PSU, save the account details for future transactions (such as making further payments or initiating refunds back to PSUs) where this is part of the payment initiation service explicitly requested by the PSU. For example, a merchant, upon request from the PSU, may initiate a refund back to the PSU, by instructing the same PISP that initiated the initial PSU transaction to use the saved PSU payment account identification details as the beneficiary details for the refund. This will be dependant on the same PISP being used by both the PSU and the merchant, their specific contractual terms and relevant regulatory obligations under GDPR/PSRs.
    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
    64Single 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
    65Standing Orders·       Minor changes to the text in Journey & Wireframes.
    Replaced 'Payment' with 'Payment Order' on PISP confirmation screen.
    		OBIE Internal Review
    66International Payments·       Minor changes to the text in Journey & Wireframes.
    Replaced 'Payment' with 'Payment Order' on PISP confirmation screen.
    		OBIE Internal Review
    67International PaymentsWhere 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
    68Bulk/Batch Payments·       Minor changes to the text in Journey & Wireframes.
    Replaced 'Payment' with 'Payment Order' on PISP confirmation screen.
    		OBIE Internal Review
    69Multi-authorisation Payments·       Minor changes to the text in Journey & Wireframes.
    Replaced 'Payment' with 'Payment Order' on PISP confirmation screen.
    		OBIE Internal Review
    70Multi-authorisation PaymentsChanged the last milestone in the journey from Transaction Confirmation  to Payment Initiation Pending AuthorisationOBIE Internal Review
    71Payment Refunds·       Minor changes to the text in Journey & Wireframes.
    Replaced 'Payment' with 'Payment Order' on PISP confirmation screen.
    		OBIE Internal Review
    72Payment RefundsSeparated 'Available Balance' with Balance & Overdraft'.Illustrative Change-related to HCC.
    Card Based Payment Instrument Issuers (CBPIIs)
    73All Journey & Wireframe·       Minor changes to the text in Journey & Wireframes.OBIE Internal Review
    Previous
    v3-1-5