Background
The advent of the PSD2 mandates Account Servicing Payment Service Providers (ASPSPs) to provide their services to Third Party Providers (TPPs). These new market players are now able to exploit such services to develop innovative services for payments customers. For ASPSPs subject to the regulation, this creates a number of IT development and IT operational issues, specifically how to:
Achieve scalability of these mandated services as transaction volumes increase, potentially massively and unpredictably
Ensure the performance and availability of the dedicatedinterfacerequired to meet PSD2
Deliver solutions to market in the short timescales dictated by the regulatory timetable
Wouldn’t it be convenient if these issues can be solved with a dedicated platform, separated from the constraints of ASPSP core banking systems and associated traditional IT development lifecycles?
In this article we explore the concept of ‘Open Banking in a Box’ to provide such a platform. To this end the ‘box’ is envisioned as a cloud service, this being a complete deployment of the key components needed to support a regulatory solution.
Drivers for open banking in a box
Regulatory Background
The advent of the EU Directive, the PSD2, and the CMA Order in the UK, mandates Account Servicing Payment Service Providers (ASPSPs) – mainly Banks - to provide their services to Third Party Providers (TPPs). Specifically, three core tranches of banking capabilities are required to be provided to meet the Directive: Account Information. Providing a variety of information relating to a customer’s account including balances, standing orders and direct debit information.Account Transaction History. Providing a sequence of account transactions over an arbitrary specified period.Payment Initiation. Providing the capability to submit payments orders to an ASPSP. This capability includes a Funds Checking service to ensure that the payer has sufficient funds to cover the payment. The provision of these services is a massive disruptor for the financial services industry. New market players, in the form of Account Information Service Providers (AISP) and Payment Initiation Services Providers (PISPs), are now able to exploit these services to develop innovative services for payments customers (the Payment Service Users or PSUs), leveraging the capabilities of the ASPSP’s account information services and payment initiation services. Regulatory impact and the
IT challenges for ASPSPs From an ASPSP’s perspective, this creates a number of IT development and IT operational issues, notably:
How to achieve scalability of these mandated services to meet, potentially, huge increases in volumes of transactions
Similarly, since the innovation in the TPP space is subject to network effects, transaction volumes are subject to a high degree of variance which makes predictions difficult
How to ensure performance and availability of the dedicated interfaceto support the PSD2 services
How to deliver solutions to market in short timescales dictated by the regulatory timetable that dictates that immovable go-live dates must be met
The ability to get competitive services to market, building on the open banking regulatory requirements, that satisfy customers’ needs and establish a footprint in new market territories for the ASPSP
The performance and scaling challenge
Building on these points, the transaction volumes for ASPSPs will inevitably increase substantially as TPPs develop their services and these gain maturity in the marketplace. This in itself will result in customers interacting with their bank more frequently, albeit indirectly via the TPPs applications in ‘customer present’ scenarios. Also, there will be an increase in volumes driven from the TPPs themselves. TPPs, having obtained consent from the customer for specific account information, will exercise their right under PSD2 to access that information up to four times daily in ‘customer not present’ scenarios. There is another key factor that also drives the need for a cloud-based platform for open banking service – that is the desire for ASPSPs to avoid having to implement the PSD2 contingency interfaceover and above the prescribed regulatory interface. One of the criteria for an exemption relating to the contingency interfacerelates to the availability and performance. To qualify for an exemption, APSPSs are obliged to provide performance and availability SLAs that at least match those of the online channel. The underlying customer account information and transaction history will reside in a core banking platform. Typically, these fall into two categories:
A bespoke legacy system, developed over many years difficult to maintain and with rigid release cycles for enhancements
A vendor product solution, providing a complete or modular banking solution Both of these implementations present challenges in meeting the non-functional requirements of the PSD2 outlined above.
From a scalability perspective, scaling cost effectively is unlikely. Both legacy mainframe and vendor products pricing is very dependent on supporting hardware; cost breaks tend to be highly non-linear. This means over compensating to allow for sufficient headroom in the capacity. Mitigating the scalability risk in manner is likely to be highly cost inefficient.
Regarding performance, if account information data were to be provisioned directly from the core banking platform, a new technology stack would be required to support the PSD2 and GDPR services on the assumption these would be implemented using APIs. To map data from typically a core baking application SQL relational data base to, for example, a JSON object in an API endpoint could require a significant number of data format translations. Nor are the technologies to support API data formats necessarily readily available on a mainframe system.
This problem may be further compounded by previous efforts within the ASPSP to implement other architectural paradigms – namely Service Oriented Architecture which is based on an entirely different technology stack and protocols to API implementations. This could lead to an intensive sequence of data translations and gives rise to significant performance challenges and risk since there may be a number of data format transformation all the way through the technology stack from data storage through to API payload.
How using the cloud as a platform solves these issues
A cloud services solution offers the opportunity for a highly performant and scalable platform to support open banking services. Features that are relevant in this respect include:
Elastic scaling. As transaction volumes increase or decrease, cloud autoscaling technologies can scale the computing resource automatically as required.
Lightweight protocols. The use of REST APIs and JSON for data specification requires less computing resource in the supporting middleware versus other paradigms such as service-oriented architecture that are based on ‘heavyweight’ protocols such as SOAP and XML. This reduced computing resource requirements and makes the solution inherently more scalable.
No SQL database technology. ‘Document’ style storage databases allow for storing the data is the same format as which it presented. This requires no, or minimal, format translation from data store through to payload. Contrast this to a traditional legacy or vendor product technology stack requiring translation from SQL database tables, accessed possibly via SOAP services returning XML, and then a final format translation to JSON. The format translation and implied architectural layering are not conducive to a performant solution in this respect.
Similarly, from a development lifecycle perspective, the use of a microservice architecture in the cloud solution offers potential isolation of individual API services and a reduction in inter-dependencies between IT components, such as a single shared database and schema. This avoidance of dependencies then provides the basis to increase speed to market during the development cycle via Agile methods and the use of DevOps.
Implications for a cloud solution for open banking
In order to leverage the advantages of these cloud features in the context of a solution for open banking and PSD2, it is considered necessary to copy data from the core banking systems to support the account information and transaction history services. External services consumed by the TPPs will therefore have their data sourced from this copy of the core banking system data. No read transactions therefore need to be made to that touch the ASPSPs core banking platform to support the TPP information requests. This is key to the ability to scale at cost.
To support payment initiation, which is a ‘create’ transaction, this will still require integration with other key back end banking platforms, specifically the ASPSP’s Payment Engines or Payments Hub. In this respect, a real time integration with back end banking systems cannot be avoided and must be supported.
Also, in the context of PSD2 and specifically the concept of Strong Customer Authentication (SCA), one pattern that ASPSPs can choose to support is ‘Redirection’. For the purposes of the conceptual architecture overview presented here, this is assumed to be supported through an ASPSP’s application, such as the existing online banking application. In this respect, the open banking cloud platform is designed to be a ‘headless’ service only (i.e. one without any direct user interaction). Consequently, a further integration is identified to support this SCA pattern and obtain the consent and authorisation that has been given by the PSU.
The diagram shown below shows the context of an open banking cloud platform and the high-level IT connections required.
Conceptual Architecture
A reference conceptual architecture is now proposed that highlights the key components of the cloud solution to support open banking.
Key Concepts
All open banking interfaces are offered from the cloud platform. In the solution concept presented all open banking interfaces, whether to meet regulatory requirements or the ASPSP’s own competitive market initiatives, are offered via the cloud platform. The key to the success of this principle relates to the effectiveness of the integration between the ASPSPs and the cloud. The key concepts to support this architecture are presented below.
Data Replication of Account Information
To leverage the advantages of a cloud platform and achieve the necessary cost-effective scaling for an open banking solution, customer account data must be replicated to the cloud platform. By undertaking this replication, the open banking solution becomes readily scalable in a cost-effective manner. The consequence of this replication is that two styles of transactions are therefore apparent: Read only transactions associated with account information and transaction history request are supported from data stores on the cloudUpdates to the data stores within cloud from account data from the core banking platforms
Hydration Engine
To support the required data replication, the concept of a hydration engine is introduced. This component is responsible for:Integrating with the core banking systems to extract data or receive updates made to customer accountsMarshalling this data and streaming this to the cloud deployed via a dedicated interfaceReceiving the data streamed to the cloud and distributing this to the account information data stores In this respect the component is deployed within both the environment of the ASPSP’s core banking platform and within the cloud. What’s in the box?
Overview of the key components
API Gateway. This component hosts the API endpoints that will TPPs utilise to access the open banking account information services and payment initiation capabilities. PSD2 mandates that the identity of a TPP must be a known quantity and equate to an organisational entity that is regulated. It provides services to ensure the security of the APIs and supports the necessary application protocols in use by the open banking services.
TPP Identity and Access Management. This component maintains identities and their credentials. It provides the authentication and authorisations services of the TPPs and their roles in the context of the eco-system and supports the authorisation and identity protocols employed in the ecosystem.
Account Information Service. This component provides the set of capabilities to implement the Account Information APIs. This includes the business logic to process the information requests and retrieve data stores and the data stores containing the replicated account information.
Transaction History Service. This component provides the set of capabilities to implement the Transaction History APIs. This includes the business logic to process the transaction history requests and retrieve data and the data stores containing the replicated account information.
Payment Initiation Service. This componentprovides the set of capabilities to implement the Payment Initiation APIs. This set of capabilities relates primarily to the business logic to process the payment initiation submissions. For an ASPSP to accept a payment order, certain criteria must be met. Typically, the ASPSP will, as a minimum, seek to provide:
Firstly, validation of the formatting of the payment request
A pay-no-pay decision based on the PSU’s available balance
Validation of the beneficiary bank as a reachable destination via the schemes supported by the ASPSP
Transaction Risk Analysis, this being a mandated requirement of the PSD2 Regulatory Technical standards (RTS) relating to a qualification of the risk of undertaking the financial transaction.
A payments routing decision to determine the most appropriate scheme to use to deliver the payment. Other criteria may be applied or necessary depending on the risk appetite of the bank.
These capabilities will be provided by this component either by:
Using data stored in the cloud platform itself e.g. the account balance
Using reference data stored within this the cloud platform orIntegrating with specific business services provided locally by the ASPSP
Assuming successful acceptance of the payment order, this will be submitted to the ASPSPs payment engine for fulfilment or submitted to the ASPSPs payment warehouse in the circumstances of a payment not intended for immediate execution.
Consent and Authorisation Service. This component provides another key capability to the support the requirements of the PSD2 relating to PSU consent. Whilst consent is provided by the PSU to the TPP, a subset of the consent – termed here the authorisation - must be maintained by the ASPSP. This component provides the capability to interpret the consent and capture this as an authorisation. When subsequent requests for information are made by the TPP these must be checked in the context of the consent and authorisation originally provided by the PSU. The longevity of the authorisation must also be managed according to the requirements of the PSD2 that dictates that this can be a duration of 90 days before re-authentication is required.
Cloud Integration Services. This component provides the integration services in the cloud to support the Hydration Engine’s updates to the cloud data stores. It also provides real time integration services to local ASPSP components and services that are needed to provide payment initiation services to the TPP’s Local Integration Services. This component provides the integration services local to the ASPSP that support the Hydration Engine. Specifically, this relates to the integration with the ASPSPs core banking systems. Depending on the scope of accounts types offered by the ASPSP, there are likely to be a number of integrations to a variety of core banking platforms, notably for retail, business banking and credit card platforms.
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 architecture 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.