P21 • PSD2 in-scope accounts (multi-currency)

1. Version control

2. Roadmap item definition

This Roadmap item required OBIE to assess whether any changes to the OBIE standards were required in order facilitate AIS and PIS for “corporate” payment accounts, as required by PSD2. OBIE had originally been concerned only with PCAs and BCAs held by SMEs with a turnover of up to £6.5m; but following the expansion of the Roadmap to cover all PSD2 payment accounts it was recognised that some payment accounts held by businesses with turnover exceeding the £6.5m threshold may include account information or payment functionality that had not yet been catered for. 

In particular, some ASPSPs solutions require an additional field to allow the payer to enter a debtor narrative for reconciliation purposes. Moreover, additional requirements have been identified for larger businesses to facilitate the delegation of access to individual employees (or restrict such access) to enable that employee to give consent to a TPP. Keeping these two requirements in mind the Trustee’s Evaluation Letter for P22 dated (Oct 2018) included three actions that came out of the evaluation:

• P22 A1: Debtor narrative as part of PIS request.
• P22 A2: OB standards to support ASPSPs’ solutions which provide for additional approval being required by delegated customer employees for AISP access requests initiated by their colleagues.
• P22 A3: Update Customer Experience Guidelines to support P22 A1 and P22 A2.

P22 A1 has been actioned as part of OB standards release 3.1

This paper covers the capabilities to be introduced into the OB standards to facilitate P22 A2 and P22 A3 in the context of AIS access only.  Multi-authorisation for PIS and CBPII are covered as part of Proposition P13 – Multi-authorisation for SME

Please refer to the Appendix (10.2 Roadmap item definition) for the original definition of “P22: Corporate Accounts” within the “Notice of approval of changes to the Agreed Timetable and Project Plan”.

3. Market analysis

The evaluation exercise was completed with inputs from CMA9 members to assess whether “corporate accounts” (i.e. accounts offered to businesses with turnover exceeding £6.5m) were already fully catered for by the published propositions and API specs, or whether there were any gaps or required elements (i.e. account information or payment initiation capability) not currently supported. It was particularly noted that large corporates often have complex account access structures whereby multiple accounts are accessed by multiple employees each with different roles/permissions. For example, an employee may be able to only view an account or may be able to both view an account and make a payment up to a specified threshold. The three recommendations set out above aim to cater for this scenario as well as other identified gaps/requirements.

4. Product requirements

In order to support ASPSPs which would like to introduce access workflows to allow an individual employee/user of a corporate to grant a TPP access to account information, the Read/Write APIs will need to support the following functionality:

• A corporate is able to allow its individual employees/users to add/view corporate payment account(s) via AISP, where those individual employees/users have been sufficiently authorised to do so.  
• ASPSP to be able to support their workflow to grant approval to individual employees/users to add/view corporate payment account(s) via AISP as part of the AIS flow.

If an individual employee/user who does not have the authorisation to add/view the corporate account(s) via an AISP tries to access the corporate account(s) via an AISP, then ASPSP within the AIS flow after the employee/user authentication may trigger their own access grant workflow.  The exact journey to be experienced by such a employee/user after being authenticated is entirely in the ASPSP space based on how their access grant workflow is implemented. 

If as part of the AIS journey, an ASPSP’s multiauthorisation workflow can be triggered but it cannot enable each individual employee/user(s) with delegated authority to grant AISP access within the same session; then the AISP will have to wait until each user with delegated user authortity has approved the request prior to being granted access. 

However, if the ASPSP access workflow has the capability to enable the individual employee/user with delegated authority to grant AISP access within the same session, then the AIS journey should progress as a standard AIS journey. 

5. Customer use cases

The following are some example use cases which have been considered for this proposition. 

6. Regulatory considerations

The CMA Order is applicable only to PCAs and BCAs held by businesses with turnover not exceeding £6.5m. The PSRs however allow a PSU to give consent to a TPP with respect to all payment accounts (i.e. not just personal/business current accounts) held by all payment service users (i.e. there is no scope limitation based on turnover or some other threshold). As such, there is a need to ensure that the OB standards cater for all such payment accounts, including “corporate accounts” which may not have originally been catered for pursuant to the CMA Order. 

PSR, Reg.70(1) provides that a payment account is eligible for accessing by AISPs if it is accessible online – this includes corporate accounts accessible online. 

7. Evaluation criteria

Key evaluation criteria that OBIE have applied for this proposition (that respect the objectives of meeting regulatory requirements as well as being effective and proportionate).

1. Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
2. Is the proposition implementable at reasonable cost?
3. Does the proposition comply with all relevant regulations?

8. Considerations

8.1 Assumptions

• An ASPSP has their own workflow or will define a new workflow to grant view access via an AISP to an individual employee/user of a corporate.

8.2 Dependencies

• None

8.3 Constraints

• None

9. Measuring adoption

The following metrics will be required to measure adoption:

• Number of AISPs accessing “corporate account(s)” (i.e. accounts held by businesses) 
• Number of rejected access by ASPSP due to insufficient authority to view corporate account(s) via AISP

10. Appendix

10.1 Detailed Product Requirements

Requirements marked as ‘M’ (Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is ‘mandatory’, ‘conditional’ or ‘optional’ for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation.

10.2 Regulatory references

The following regulatory references are not directly relevant but considered in scope:

Access to payment accounts for payment initiation services.

PSR Reg.69

(1) This regulation applies only in relation to a payment account which is accessible online.

(2) Where a payer gives explicit consent in accordance with regulation 67 (consent and withdrawal of consent) for a payment to be executed through a payment initiation service provider, the payer’s account servicing payment service provider must:

(c) treat the payment order in the same way as a payment order received directly from the payer, in particular in terms of timing, priority or charges, unless the account servicing payment service provider has objective reasons for treating the payment order differently;

Access to payment accounts for account information services.

PSR Reg.70(1) This regulation applies only in relation to a payment account which is accessible online.

10.3 Roadmap item definition

The following table is taken ‘as-is’ from the published roadmap: (https://www.openbanking.org.uk/wpcore/wp-content/uploads/Open-Banking-Revised-Roadmap-July-2018.pdf)