Proposition P13 - Multi-authorisation for SME

1. Version Control







OBIE API Delivery Team

Draft for information only



OBIE API Delivery Team

For industry consultation & feedback including RLWG, PMG, PAG, SWFG, DWG

V0.3 OBIE API Delivery TeamUpdate based on consultation feedback for approval at IESG. 


OBIE API Delivery Team

Final version for approval at IESG

V1.1 OBIE API Delivery TeamUpdated based on approach paper.
V1.2 OBIE API Delivery TeamUpdated version for approval at IESG
V1.3OBIE API Delivery Team

Updated based on FCA consultation

Update MoSCoW, Rationale and add Implementation for Detailed Product Requirements based on Categorisation of requirements for standards and implementation

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:




UC1 Payroll

As an accounts payable manager I want to use an accountancy tool to initiate payroll payments (batch) which require multiple directors to authorise through the bank.



UC2 e-commerce

As a procurement manager, I want to initiate a bulk purchase for office equipment from an online wholesaler using my company’s business bank account that requires multiple directors to authorise any payment through the bank.



UC3 Payments workflow tool  

As a manager in the treasury team I want to use an ERP package (which can create and manage payment workflows) to build a payment order and have it authorised through the package by the relevant signatories in my organisation so that I can then initiate this authorised payment with the bank for immediate execution.

Note: This is an example of payment initiation that requires single authorisation with the ASPSP. The multi-authorisation is managed in the TPP space.


UC4  Finance management tool

As an SME account signatory, I want to use a business finance manager tool to view and authorise all the payment orders awaiting my authorisation for the connected accounts in that tool.

Not met

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

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.





P19 alignmentImplementation


The OBIE's Solution(s) must allow a PISP to specify expiry or timeout on the length of time to obtain an authorisation.

For e.g. the PISP can specify immediate authorisation if they do not wish to wait for multiple authorisations




(No specific regulatory requirement for this capability; but has been perceived to be required by some TPPs to implement their proposition)


The OBIE's Solution(s) must allow a PISP to transmit or confirm the PSU's consent to the execution of a payment transaction, which requires multiple authorisations.





(Mandatory if ASPSP supports Multi-Auth on its existing channels)

3The OBIE's Solution(s) must allow an ASPSP to initiate a multi-authorisation workflow for a draft payment order submitted via a PISP, if a similar workflow exists when the PSU submits such a payment order directly through the ASPSP online channel. MCustomer

Refer to Customer Experience Guidelines

4The OBIE's Solution(s) must allow the ASPSP to return the status of the payment order (e.g. awaiting further authorisation) to the PISP immediately after the receipt of the draft payment order, submitted via the PISP, which requires multiple authorisations. MCustomer


(Mandatory if ASPSP supports Multi-Auth on its existing channels.The GET on the status endpoint is mandatory)


The OBIE's Solution(s) must allow the ASPSP to return the following statuses of the draft payment order at any further time after the receipt of the draft payment ordersubmitted via the PISP, which requires multiple authorisations 

  • Number of signatories the payment requires
  • An update each time an additional signatory approves
  • An update if the payment is rejected by any signatory
  • An update when the payment is fully authorised
  • An update if a payment is due to expire due to authorisation time-out

Note: The granularity of these statuses may differ across ASPSPs. However, ASPSPs must make available to the PISP all the status updates which they currently offer the first authoriser within their online channel.



(Mandatory if ASPSP supports Multi-Auth on its existing channels)


The OBIE's Solution(s) must allow the ASPSP to return the status of the payment immediately after the receipt of the payment order which the PISP has initiated after receiving the authorisation complete status from the ASPSP for all authorisations.



(The GET on the status endpoint is mandatory. Call-backs are optional for ASPSP & TPPs.)

7The OBIE solution(s) must allow from within the ASPSP online channel, any authoriser in a multi-authorisation payment flow to cancel a draft payment order which was initiated via a PISP, provided this functionality is offered by the ASPSP within their online channel.MCustomer
Refer to Customer Experience Guidelines

The OBIE solution(s) must allow the ASPSP,  to notify the PISP of any amendment to the draft payment order by a PSU in the chain of a multi-auth instruction.

This requirement has been redacted based on feedback from the FCA and agreement by IESG in June, 2018.
Refer to Customer Experience Guidelines

The OBIE's Solution(s) could allow a PISP to cancel a payment order which is not authorised by all the parties required to authorise.



Future Consideration

(There is no regulatory requirement nor any immediate propositional need for this capability)


The OBIE's Solution(s) could allow the ASPSP to return the status of payment execution to the PISP at any further time after the receipt of the payment order.

The implementation details will be covered by roadmap item P9 - Status of payment



Future Consideration

(To be covered under P9)


The OBIE's Solution(s) could allow the PISP to be notified when the PSU revokes a future dated payment order through the ASPSP. 

The exact design of the notification (push or pull) will be covered by roadmap item P2 - Two way notification of revocation.



Future Consideration

(To be covered under P2)


The OBIE's Solution(s) could allow the PSU to access information on payment orders awaiting their authorisation, through a AISP.



Future Consideration

(There is no regulatory requirement nor any immediate propositional need for this capability)


The OBIE's Solution(s) could allow each  PSU to provide  their consent for payment orders through a PISP.



Future Consideration

(There is no regulatory requirement nor any immediate propositional need for this capability)

10.2 Roadmap item definition

The following table is taken 'as-is' from the published roadmap: 



Aligns with

Scope Item description:

Extension of the OB R/W APIs to enable SMEs that require multiple parties to authorise AIS and PIS to use OB functionality in a simple and convenient workflow. Note the intention is to develop a set of messaging standards to update the TPP on the status of the multi-authorisation workflow rather than to standardise multi-authorisation workflow and transfer it to the domain of the TPP


Key activities:

A discovery phase by the OBIE to understand the variety of multi-auth models used in practice, understand gaps in existing functionality and create the business requirements for the standards

- The development of standards by the OBIE for the products and functionality referred to above

- The implementation of those standards by the CMA9 for Release 3

Regulatory alignment:

-Fulfils the requirements of the Order

Open Banking adoption:

-Extends coverage of OB Standards to a large SME population

Consumer / SME utility:

-Extends coverage of OB Standards to a large SME population

Security / Integrity:

-SMEs would be able to maintain multi-party processes rather than concentrate authority upon nominated individuals

CMA  Order

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:
  2. Ecommerce payment:

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