Proposition P22 - Corporate Accounts


1. Version control


Version

Date

Authors

Comments

V0.1

 

OBIE API Delivery Team

Draft for internal review

V0.2

 

OBIE API Delivery Team

Version for 1st round of public consultation

V0.3OBIE API Delivery TeamUpdate for second round of consultation based on feedback from 1st round of consultation
v1.0 


OBIE API Delivery Team

No changes from the second round of public consultation. Submitted for approval at IESG

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. 

ID
Use Case
Met
UC1

As a corporate customer, I want to only allow appropriately authorised employees to be able share corporate account(s) information with an AISP

Fully

UC2

As an ASPSP, I should be able to trigger our internal BAU workflow to grant approval to individual employees to view corporate payment account(s) via an AISP if they do not currently have those access permissions

Fully

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.

IDDescriptionMoSCoWRationaleRegulatory AlignmentImplementation
1

The OBIE's Solution(s) must enable an individual employee/user of the corporate to view corporate account(s) via an AISP, provided the individual employee/user has been delegated sufficient authority by the corporate at its ASPSP.

M

Customer

P22 Evaluation Letter Trustee-to-CMA

Conditional

(Mandatory if provided by ASPSP in existing channel)

2

The OBIE's Solution(s) must support ASPSP solutions for obtaining this additional authorisation from the corporate to grant access to an individual employee/user to view via AISP.

Note: The actual workflow after the individual employee/user is authenticated is in the ASPSP's competitive space. 

MCustomerP22 Evaluation Letter Trustee-to-CMAMandatory
3

The OBIE's Solution(s) must enable an ASPSP to reject an AISP request with appropriate error message if the individual employee/user does not have sufficient authority delegated by the corporate to grant access to corporate account(s) to an AISP.

 
MCustomerP22 Evaluation Letter Trustee-to-CMA

Conditional

(Mandatory if provided by ASPSP in existing channel)

4The OBIE's Solution(s) must update Customer Experience Guidelines to incorporate coverage of restricting corporate account(s) view access only if an individual employee/user has sufficient authority to view via AISPs.MCustomerP22 Evaluation Letter Trustee-to-CMAMandatory
5The OBIE's Solution(s) must allow ASPSPs to provide MI on metrics and adoption as per section 9 above.MRegulatoryCMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6

Mandatory

(if functionality is implemented)

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)

Description
Rationale
Aligns with

Scope Item description:

Evaluation of OB standards to facilitate AIS and PIS for SME’s with turnover in excess of £6.5m as required under PSD2.

Key activities: An evaluation phase by the OBIE to assess whether the functionality referred to above should be developed as a standard. Evaluation criteria are likely to include demand for standards from SMEs/ASPSP/TPPs, availability of alternative solutions, alignment to PSD2 regulation, anticipated market impact, technical complexity and cost to implement and prioritisation of other OB Items.(pending the outcome of the evaluation) The development of standards by the OBIE for the products and functionality referred to above(pending the outcome of the evaluation) The implementation of those standards by the CMA9 by Release 4.

Regulatory alignment:
  • Fulfils the requirements of PSD2.


Open Banking adoption:
  • Extends coverage to wider market.


Consumer / SME utility:

  • Extends coverage to larger businesses.


Security / Integrity:
  • Corporates would benefit from the OB security framework.
PSD2