Periodic Reporting for period 3 - OPE (Open Payments Eco-system)
Reporting period: 2017-03-01 to 2017-09-30
The aim of the Open Payments Eco-system (OPE) project was to enable safe and mutually profitable collaboration between developers and innovators, which are often SMEs with great creativity and motivation but limited resources, with financial institutions (e.g. banks) and their processing vendors that have historically tended to innovate in a slow and careful manner resulting in a limited range of solutions, especially those specifically designed for SME customers.
This broad aim translates to two impact-oriented objectives (described below) and to five technical objectives which we believed would result in delivering the impact:
1.1 Primary Objective
The primary objective was to enable the SME Developer community to disrupt the payments innovation in a fashion similar to the disruption of mobile application innovation in the last decade, namely through the emergence of independently-developed apps published via a centralized application store. This approach builds on the push for financial institutions to enable API (computer-to-computer) access to their services by providing an easy-to-use and secure development environment accessible to the global community of developers. As with mobile apps, independent and entrepreneurial developers can bring a wealth of innovative applications to underserved parts of the market. To achieve this, developers need access to a rapid application development capability which allows the execution of payment transactions coupled with the means to build compelling – but still secure – user experiences. The OPE directly addresses the key challenges of security, compliance, and the asymmetric impact of failure for banks and innovators that have prevented these financial institutions from publicly exposing their services until now.
This primary objective has been achieved in the OPE project by delivering the necessary tools and capability needed by:
- Developers to develop, test and publish payment applications as well as integrations (via artefacts called connectors) to financial processing gateways;
- Innovators of any type – developers, banks, third-parties (collectively termed programme managers) – to deploy and distribute new payment services based on these published applications and connectors;
- Financial services providers to review, support and oversee such payments services with tools to make such oversight efficient (since the labour-intensive job of ensuring security and compliance is one of the biggest operational and economic barriers to collaboration with start-ups).
1.2 Secondary Objective
A secondary objective was to enable SME businesses to have access to innovative electronic payments applications. For these businesses, the development of customised payments applications is usually cost prohibitive – OPE is poised to change that as it moves to exploitation.
The achievability of this objective (during the exploitation phase) was demonstrated by the OPE project by two demonstration payment services created on the OPE.
This broad aim translates to two impact-oriented objectives (described below) and to five technical objectives which we believed would result in delivering the impact:
1.1 Primary Objective
The primary objective was to enable the SME Developer community to disrupt the payments innovation in a fashion similar to the disruption of mobile application innovation in the last decade, namely through the emergence of independently-developed apps published via a centralized application store. This approach builds on the push for financial institutions to enable API (computer-to-computer) access to their services by providing an easy-to-use and secure development environment accessible to the global community of developers. As with mobile apps, independent and entrepreneurial developers can bring a wealth of innovative applications to underserved parts of the market. To achieve this, developers need access to a rapid application development capability which allows the execution of payment transactions coupled with the means to build compelling – but still secure – user experiences. The OPE directly addresses the key challenges of security, compliance, and the asymmetric impact of failure for banks and innovators that have prevented these financial institutions from publicly exposing their services until now.
This primary objective has been achieved in the OPE project by delivering the necessary tools and capability needed by:
- Developers to develop, test and publish payment applications as well as integrations (via artefacts called connectors) to financial processing gateways;
- Innovators of any type – developers, banks, third-parties (collectively termed programme managers) – to deploy and distribute new payment services based on these published applications and connectors;
- Financial services providers to review, support and oversee such payments services with tools to make such oversight efficient (since the labour-intensive job of ensuring security and compliance is one of the biggest operational and economic barriers to collaboration with start-ups).
1.2 Secondary Objective
A secondary objective was to enable SME businesses to have access to innovative electronic payments applications. For these businesses, the development of customised payments applications is usually cost prohibitive – OPE is poised to change that as it moves to exploitation.
The achievability of this objective (during the exploitation phase) was demonstrated by the OPE project by two demonstration payment services created on the OPE.
The final product for OPE is the public availability of a beta-quality platform which has been used to process live transactions with at least one third-party developer’s application. Iterations of this platform have been delivered to the EU in the form of demonstration videos showing the main elements of the working system; public access was made available at the end of June 2017, at which point any potential user was able to create a user and navigate through the system.
Achieving this required the following work:
1. System-wide design and definition of technology standards with full documentation encompassing functional boundaries and technical interfaces
2. Development of a User Experience Framework and associated secure client library allowing the easy creation of secure user screens for payment applications
3. Development of an API Framework including the support for validation, authentication and logging
4. Development of a real-time data warehouse and a Reporting Framework to enable generation of reports and access to other operational data
5. Extraction of existing core payment components into microservices that can be wired together to form new applications
6. Development of a new language (Payment Application Modelling Language - PAML) to define the flow and constraints of a payment programme
7. An OPE Administrator Portal to allow the management of OPE: Developers, Programme Managers, Service Providers, Applications and Connectors
8. A Developer Portal to allow the developer to create and upload Application Models and Connectors.
9. A Service Provider Portal allowing a service provider to register the services offered, approve its services to be used with specific programmes and to monitor compliance violations triggered by the programmes
10. A Programme Manager Portal to allow the programme manager to create programmes from applications, including the selection of financial service providers
11. Identification of the various regulations and risk checks that can be applied to the OPE, and formalisation for compliance checking. Formalisation of the regulations which can be further translated into business rules. Static (at application development time), and Dynamic (at run time), compliance checkers have been produced to interpret the rules
12. Further development of a service connector architecture and the creation of Account Issuing, Card Processing and Bank Transfer connectors
13. Development of a multi-tenancy architecture to support multiple programme managers operating in isolation without requiring OPE to deploy separate setups for each one
14. Widespread dissemination of the various beta stages, including conducting a public Hackathon, a Developer Competition, and the integration effort required to take the winner of the Developer Competition live in a Pilot Run
15. Execution of a Pilot Run, with the application developed by the winner of the Developer Competition and another application developed in-house, with Ixaris as the Programme Manager and partner IDT as the service provider.
Achieving this required the following work:
1. System-wide design and definition of technology standards with full documentation encompassing functional boundaries and technical interfaces
2. Development of a User Experience Framework and associated secure client library allowing the easy creation of secure user screens for payment applications
3. Development of an API Framework including the support for validation, authentication and logging
4. Development of a real-time data warehouse and a Reporting Framework to enable generation of reports and access to other operational data
5. Extraction of existing core payment components into microservices that can be wired together to form new applications
6. Development of a new language (Payment Application Modelling Language - PAML) to define the flow and constraints of a payment programme
7. An OPE Administrator Portal to allow the management of OPE: Developers, Programme Managers, Service Providers, Applications and Connectors
8. A Developer Portal to allow the developer to create and upload Application Models and Connectors.
9. A Service Provider Portal allowing a service provider to register the services offered, approve its services to be used with specific programmes and to monitor compliance violations triggered by the programmes
10. A Programme Manager Portal to allow the programme manager to create programmes from applications, including the selection of financial service providers
11. Identification of the various regulations and risk checks that can be applied to the OPE, and formalisation for compliance checking. Formalisation of the regulations which can be further translated into business rules. Static (at application development time), and Dynamic (at run time), compliance checkers have been produced to interpret the rules
12. Further development of a service connector architecture and the creation of Account Issuing, Card Processing and Bank Transfer connectors
13. Development of a multi-tenancy architecture to support multiple programme managers operating in isolation without requiring OPE to deploy separate setups for each one
14. Widespread dissemination of the various beta stages, including conducting a public Hackathon, a Developer Competition, and the integration effort required to take the winner of the Developer Competition live in a Pilot Run
15. Execution of a Pilot Run, with the application developed by the winner of the Developer Competition and another application developed in-house, with Ixaris as the Programme Manager and partner IDT as the service provider.
The OPE Project is taking the provision of payments applications beyond the state-of-the-art as follows:
3.1 Payment Application Modelling
The Payment Application Model Language (PAML), allows the formal definition of a payment programme, generalising constraints that are typically hard-coded per use case, and unlocking the use of formal methods of analysis such as model checking and runtime verification. This language is the first of its kind in the payments domain and serves as an unambiguous definition of the ownership and location of funds and ways of transferring, or making payments with, funds in a programme.
3.2 Automated Compliance Oversight
Automated compliance oversight allows the mass creation of payments applications without overloading the compliance department of the regulated financial service providers (i.e. banks).
3.3 Payment Application Security
This allows the mass development of payment applications by developers without requiring extensive auditing, while avoiding putting customers’ sensitive financial data at risk. This is a unique capability in the industry, which OPE accomplishes by providing tools which allow developers to create financial applications without having access to sensitive financial data, and instead, working with tokens.
3.1 Payment Application Modelling
The Payment Application Model Language (PAML), allows the formal definition of a payment programme, generalising constraints that are typically hard-coded per use case, and unlocking the use of formal methods of analysis such as model checking and runtime verification. This language is the first of its kind in the payments domain and serves as an unambiguous definition of the ownership and location of funds and ways of transferring, or making payments with, funds in a programme.
3.2 Automated Compliance Oversight
Automated compliance oversight allows the mass creation of payments applications without overloading the compliance department of the regulated financial service providers (i.e. banks).
3.3 Payment Application Security
This allows the mass development of payment applications by developers without requiring extensive auditing, while avoiding putting customers’ sensitive financial data at risk. This is a unique capability in the industry, which OPE accomplishes by providing tools which allow developers to create financial applications without having access to sensitive financial data, and instead, working with tokens.