+44(0)755 442 3099

©2018 by Triari Consulting Limited. Proudly created with Wix.com

The Multi-Party Open Banking Platform : An Enabler for Innovation and Competition in Financial Services

September 7, 2018

 

Background

Recent regulatory drivers such as the CMA Order and PSD2 and have provided the trigger for the opening up of banking services to third parties.  The regulator’s objective was to create a market place for increased competition from newly formed entities and to enhance the opportunity for innovation. 

 

These regulatory drivers, coupled with technology advances that enable collaboration between organisations, notably RESTful API’s, was to create a new marketplace, positioned as what has been termed the ‘API economy’. In this marketplace opportunities for new business models for intermediaries, interacting with several market participants through a ‘multi-sided online platform’, are now becoming prevalent. 

 

However, as implementations of the CMA Order and PSD2 have progressed, the limitations of the statutory obligations suggest that compliance with the regulation alone will not suffice in meeting customer needs.  Quite simply, the opportunities for more sophisticated business models based on ‘co-opetition’ that better support competition are somewhat limited due to the inherent flaws of the regulation. This in turn will stifle innovation and ultimately affect consumer propositions.   To this end, a layered model for the API economy has been highlighted by Triari Consulting that better enables such co-operative business models and hence innovation.  

 

This article introduces a concept specifically for the financial services eco-system - the ‘Multi-Party Open Banking Platform that will support the layered model of the API economy we have previously outlined for open banking.

Layered Eco-System Model for the API economy

Triari Consulting’s Eco-System model for Open Banking was originally defined as being comprised of three layers:

  1. Pure Compliance.  Participants use theavailable services dictated by the PSD2 regulation.

  2. Walled Garden.  A private Eco-System available for business partners that provides enhanced services over and above the basic compliant services.

  3. Full Data Sharing.  Collaboration with market participants within an entire Industry vertical.

In technology terms each of these layers is provided by a set of RESTful APIs accessible to those participants with a layer. 

 

A further layer (Layer 0) is now identified to support intra-organisational interactions.  The purpose of these interactions is to support the platform provider’s own internal business processes or system to system interactions. This layer does not extend outside the organisational boundaries of the platform provider, although these interactions may well extend across its actual geographic boundaries.

 

The full API Eco-System model is now depicted below.

 

 

Layered Model for API Eco-Systems and the supporting categories of APIs

 

The market participants within each layer and the scope and purpose of their interactions are summarised below:

 

 

For those intermediaries seeking both to provide API services and to consume them as part of new propositions, this layered model, with its multiple participants and different API standards, now presents a challenge.  Specifically, how can all the functionality required to support this API Eco-System be provided in a manner that consistent and interoperable for all collaborating participants?

 

Multi-party open banking platform concept

 

Multi-Party Open Banking Platform Concept.

 

Once it is accepted that the API Eco-System must extend beyond pure PSD2 compliance capabilities, the interaction between the market participants becomes more complex.  To support these wider interactions, the concept of the multi-party open banking platform (the ‘Platform’) is now introduced.  The interactions relating to each of the eco-system participants and the proposed multi-party open banking platform is shown in the diagram above.

 

Features

The key features of the multi-party open banking platform are:

  1. Supports both the supply side and demand side perspectives

    • Supply side perspectives are driven by the what the organisation wants to provide or is capable of providing

    • Demand side is driven by network effects or by a regulator constraining the market to behave in particular way representing consumer interests

    • In this respect the Platform supports both the provision and the consumption of API services

  2. Customer data is the key asset of the Platform

    • Contains the customer financial data that upon which the propositions are built

    • The data forms the basis upon which consumption and supply propositions are constructed

  3. Support for all identified Layers of the API eco-System

    • Provides the necessary infrastructure and collaboration frameworks for participants to collaborate, notably identity management and the constructs needed to transact securely

  4. Use of RESTful APIs.

    • All collaborations between participants are implemented using by RESTful APIs.

Why a Multi-Party Open Banking Platform?

Economies of scope

The avoidance of having to create dedicated solutions for each API layer or to implement point to point solutions between business partners, provides a number of opportunities for economies of scope:

  • Reduction in infrastructure costs through a single highly scalable operational Platform.

  • The consolidation of the technologies used and a reduction in their deployments across the organisation reduces costs.

  • Opportunities to reuse services from the different API Layers in different business contexts, again provides the opportunity to reduce costs.

  • Operationally structuring teams to support specific domains within an organisation (e.g. ‘Customer’, ‘Account’), supporting a concentration of expertise and empowerment of proposition development.

In this respect the economies of scope in adopting a multi-party open banking platform are potentially considerable.

 

Common Security Framework

A common security framework comprised of agreed security standards and protocols can be provided.  Similarly, there is the opportunity for a common trust framework between all parties.  However, the latter may be more of challenge as PSD2 regulation demands a specific trust framework as defined by the Regulatory Technical Standards.  This particular feature of the RTS is not considered not be suitable for generalisation and use within additional layers, although some of the inherent principles could be adopted.  

 

Consistent Identity and Access Management

Given the potential number of TPPs collaborating within the Eco-System and its inherent layering of the APIs, this creates challenges with respect to:

 

How to control the access to APIs within the layers of the Eco-System

The management of the volume of the TPPs as more propositions come to market

Achieving interoperability relating to the identity of TPPs, their role and how to control access

 

In this context, the Identity and Access Management discipline become extremely important. The multi-party platform can offer a core capability to manage identities of the participants and provide the necessary authentication and authorisation services.  The application of role-based access in the Platform can be achieved by a configurable centralised policy management and enforcement capability, simplifying the management of TPP identities and their access rights.

 

Operationally geared to support high delivery velocity

As discussed, the multi-party online banking platform can support both the consumption and provision of new API’s.  When publishing APIs, the ideal lifecycle is premised on iterative and incremental improvement.  Speed to market is therefore important to enable consumers of the APIs to explore and test their own proposition dependent on these APIs.  This allows for early refinement of the APIs based on feedback and to adjust to market need.   Similarly, for an API provider who, for example, has a new Layer 2 API providing a unique and chargeable capability, there are drivers to publish this quickly to gain first mover advantage. 

 

Consequently, high delivery velocity of API’s, enabled by the platform is a desirable feature for both providers and consumers of the API’s.

 

The implications of this are that, for an API Platform to support speed to market, it must provide the capability to develop and publish APIs into the market extremely quickly:

This is not considered purely an architectural issue, but also an IT operational one.

 

An Agile development approach is the therefore considered essential as the development paradigm for the multi-party open banking platform as a means to achieve speed to market

Similarly, an integrated DevOps team, empowered to deploy solutions into production, are also essential in gearing the Platform for speed to market.

 

In summary, a consolidated approach provided by the multi-party open banking platform provides the opportunity to gear an organization’s IT operational function, to achieve the necessary speed to market. 

 

ASPSP Considerations

As highlighted, the features of the Platform concept are such that it can support both supply side and demand side requirements.  The context of the platform is now considered from two perspectives:

  • When an ASPSP acts in the role of the platform provider

  • When a non-account servicing TPP acts in the role of the platform provider

In the case of the ASPSP acting in the role of the Platform provider, whilst they will most likely be still acting in the role of innovator and an intermediary, an additional consideration is that the they may also look to fulfil the regulatory requirements using the multi-party open banking platform.  In these circumstances they would implement the Layer 1 compliance API’s through direct integration with its core banking systems with the Platform rather than obtain the information through the compliance Layer 1 API’s. 

 

Conversely, in the case of a TPP acting as the Platform provider, direct integration with the core banking systems is not relevant as the TPP only has access to account information and payments initiation services provided indirectly via the compliance Layer 1 APIs.  The Core Banking Systems do not directly form part of the Platform context in these circumstances.

 

Conclusion

An Open Banking API eco-system, having services over and above the baseline regulatory capabilities inferred by PSD2, is already emerging to support the API economy within financial services. To support this API Eco-System, the concept of a Multi-Party Open Banking Platform has been presented. 

 

Architecturally, it provides an elegant solution that can support both supply side and demand side perspectives.  The Platform provides unified security standards and trust models within the API eco-system and also the capabilities to manage the identities of participants and to control access to all layers of the API eco-system appropriately.

 

Finally, the Platform supports the agile and DevOps IT development models considered essential for intermediaries to provide speed to market and hence compete in the new API economy.

How Triari Consulting Can Help your Organisation

Triari Consulting provides regulatory and technical consulting services relating to Open Banking, PSD2 and GDPR.  We can provide the consulting services to help you realise this conceptual solution for your organisation. 

 

Our way of working is not prescriptive, and we understand that all clients have differing needs.  In this respect, we work in a collaborative manner with stakeholders to make solution and technology choices that are right for your organisation.   

 

If you would like to explore our service offering in more detail.  Please contact Gary Farrow at gary.farrow@triari.co.uk or call +44(0)755 442 3099 to discuss.

 

 

 

 

 

 

 

 

 

 

 

Please reload

Our Recent Posts

The Multi-Party Open Banking Platform : An Enabler for Innovation and Competition in Financial Services

September 7, 2018

eIDAS does not work, especially for the UK, and it’s time to recognise it. Or: is eIDAS the worst idea to come out of Europe since Esperanto? For muc...

September 5, 2018

Is payments initiation under PSD2 going the wrong way? And what can be done about it? or, “If I was going there, I wouldn’t start from here.”

August 24, 2018

1/1
Please reload

Tags

Please reload