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.
Other pages in this section
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”.
There are some key challenges identified around consent process where multiple parties are required to authorise
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.
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:
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.
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)
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:
The following is not considered to be in scope for this proposition:
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.
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
The requirements for payment initiation from a PISP in a multi-authorisation scenario are based on the following assumptions:
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.
The following metrics will be required to measure adoption:
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.
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)
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
The research was specifically conducted to test the journeys for
The overall feedback from larger organisations who have a multi-auth setups within their organisation’s online banking is as follows
Detailed findings from the customer research conducted by OBIE can be found in the attached report below