P13 • Multi-authorisation for SME

1. Version Control

2. Roadmap Item Definition

Open Banking API’s v1.1 allowed a payment initiated by via a PISP to be authorised with the ASPSP by a single PSU. For certain payment accounts, for example, SMEs could have complex workflows around authorisation of a payment order, which may require multiple parties with delegated user authority to authorise a payment order. 

The OB R/W APIs need to be extended to enable SMEs, which require multiple parties to authorise a payment order with their ASPSP, to use OB functionality in a simple and convenient way.

This paper defines the overall proposition to support this extended write capability, so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) have a common understanding about what is and is not in scope, and how this proposition will support regulatory requirements and key use cases.

Please refer to the Appendix (10.1 Roadmap item definition) for the complete definition of “P13 – Multi Authorisation for SME” within the “Notice of approval of changes to the Agreed Timetable and Project Plan”.

3. Market Analysis

There are some key challenges identified around consent process where multiple parties are required to authorise

• Complexity of individual user mandates and payment workflows setup by organisations, varies across ASPSPs
• Complexity of standardising across Commercial banking and Retail business banking customers within same ASPSP

According to data from the CMA9 665,400 Business Current Accounts(BCAs) have multi-authorisation arrangements in place, roughly 14% of all BCAs and significantly higher % of payments.

The OB APIs need to enable these SMEs to be able authorise such payments via a PISP.

4. Customer Use Cases

The following are a few example use cases:

This proposition is not limited to the above use cases and applies to all payment types supported under following roadmap items, where the payment requires multi authorisation within the ASPSP:

• P5a – Future dated payments and standing orders
• P10 – International Payments
• P11 – BACS, CHAPS, Bulk and Batch payments
• P21 – PSD2 in scope accounts

5. Regulatory references

The OBIE interpretation of the key regulatory requirements is that in relation to payment accounts that are accessible online, the ASPSP should allow PSU to initiate, via a PISP, the same payments which the PSU can initiate directly via the ASPSP online interface.

These include payment initiations that require multiple parties to authorise the payment order.

The functionality available to a PSU directly may vary from account to account depending on the online functionality provided by the ASPSP to the PSU.

The regulatory references relevant to each detailed requirement listed in table 10.1 are mapped in the column P19 alignment column.

6. 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?

7. Product requirements

In order to allow all ASPSPs to comply with the regulatory requirements and meet key customer use cases, the Read/Write APIs will need to support the following functionality:

• Ability for a PSU to start the initiation of a payment through a PISP that requires multiple parties to individually authorise the payment order with the ASPSP.
• Ability for ASPSP to notify or make available to the PISP information relating to the different statuses during the authorisation workflow.
• Ability for the ASPSP to provide or make available information as per Reg 69(2)(b) to the PISP, after final authorisation of payment order.

The following is not considered to be in scope for this proposition:

• OB APIs to standardise multi-authorisation workflows across all the ASPSPs and transfer the management of the ASPSP authorisation flows to the domain of the TPP.

TPPs in their competitive space can offer tools that can create and manage payment workflows for organisations where signatories authorise payments within the tool. A payment authorised through the tool can then be initiated with the ASPSP via the tool where a single person may be able to authorise this payment with the ASPSP.

8. Considerations

8.1 Constraints

• Standardising multi authorisation workflows was considered out of scope due to the following constraints.
• Complex business workflows and user mandates for SMEs are in the competitive space of the ASPSPs.
• Technical complexity around standardising workflows.

8.2 Dependencies

    This proposition should support a PSU payment initiation via a PISP for all payments supported by the ASPSP within their online channel.  Detail requirements for these payments types are covered under

• P5a – Future Dated Payments and Standing Orders 
• P10 – International Payments
• P11 – BACS, CHAPS, Bulk and Batch payments 
• P21 – PSD2 in scope accounts

8.3 Assumptions

The requirements for payment initiation from a PISP in a multi-authorisation scenario are based on the following assumptions:

• a PISP should be able to do whatever an individual user can do in terms of initiating a payment;
• a PISP may therefore start a payment initiation with the consent of the first PSU in a chain of required authorisations;
• all subsequent required authorisations are obtained by the ASPSP directly from each relevant PSU in the chain; and
• initiation is completed only once the instruction has been fully authorised.

This allows the customer to take advantage of the existing authorisation workflow as agreed between them and the ASPSP. After the authorisation by the final PSU in the chain, the payment is then ready for execution by the ASPSP with no further input required from the PISP.

Other assumptions

• PSU access through a AISP should not require multiple authorisations to a payment account as view access is generally based on a single, view mandate by any party with designated user authority.
• If the PSU (employee for a Commercial customer), leaves that organisation (or their Channel access is withdrawn by their administrator), then all associated AISP consents will be revoked by the ASPSP.
• We note that there could be a requirement to cater for CBPII for multi-auth whereby more than one PSU is required to provide consent at their ASPSP prior to a CBPII confirmation request.
• This is distinct from PSU consent for confirmation of funds for CBPII, which should not require multiple authorisations as access to payment account for confirmation funds(Yes/No) should be generally based on a single, mandate by any party with designated user authority.
• Although this roadmap item caters specifically to SMEs, the proposition should be applicable to the following cases:
  • Payment initiation from Personal joint Accounts where more than one parties are needed to authorise a payment (e.g joint account operating with a dispute)
  • Payment initiation by corporate customers where a payment needs multiple parties to authorise when the corporate customer make such payment within the ASPSP online channel

9. Measuring Adoption

The following metrics will be required to measure adoption:

• Volume of successful and failed payment initiations through PISP for payment orders requiring multi-authorisations.

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.

These are stated as requirements of the OBIE solution to enable implementers to meet regulatory compliance and/or customer use cases.

10.2 Roadmap item definition

The following table is taken ‘as-is’ from the published roadmap: 
(https://www.openbanking.org.uk/wpcore/wp-content/uploads/2017/11/FAO-CMA_Proposed-Amendments-to-Agreed-Arrangements_v_final-1.pdf)

10.3 Customer Research

Open Banking has conducted quantitative and qualitative research to gauge the customer feedback on a few payment journeys for this proposition and to identify areas of improvement. 
The following prototypes were tested

1. Batch payment: https://invis.io/XFHS64C2VG8
2. Ecommerce payment: https://invis.io/GXHS6BI3KMF

The research was specifically conducted to test the journeys for

• Ease of use, clarity and to identify frustrations
• Review specific features
• Understanding terms used

The overall feedback from larger organisations who have a multi-auth setups within their organisation’s online banking is as follows

• Multi-Authorisation was reassuring, esp for large payment amounts 
• There were no concerns around convenience as the users were accustomed to the additional authorisation step
• State of payments/authorisation and esp. failures required to eliminate risk – updates on progress sought (including dates)
• Would be an overkill for small payments in an ecommerce scenario 

Detailed findings from the customer research conducted by OBIE can be found in the attached report below