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:
Pure Compliance. Participants use theavailable services dictated by the PSD2 regulation.
Walled Garden. A private Eco-System available for business partners that provides enhanced services over and above the basic compliant services.
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:
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
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
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
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 exists to solve the complex problems arising in payments system modernisation - issues facing clients both large and small. Our unique approach is not only what differentiates us, but also what makes us successful. We provide a focussed range of architecture and strategy services to help financial organisations facilitate changes in payments system processing, to achieve their vision and optimise their performance and productivity.
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.