Community Research and Development Information Service - CORDIS


OPE Report Summary

Project ID: 666363

Periodic Reporting for period 2 - OPE (Open Payments Eco-system)

Reporting period: 2016-05-01 to 2017-02-28

Summary of the context and overall objectives of the project

The aim of this project is to create an Open Payments Eco-system (OPE) to enable innovation in payment applications through participation of developers and financial institutions. In particular, the OPE significantly enables the participation of Small, Medium Enterprises (SMEs).

The primary objective is to enable the SME Developer community to disrupt the established manner of payments innovation in a similar fashion to the recent disruption of mobile application innovation. This takes advantage of the recent trend for financial institutions to open up access to their services through APIs. The OPE directly addresses the key challenges of security and compliance that have prevented these institutions from opening up their services due to lack of trust.

A secondary objective is to enable SME businesses as target customers to have access to innovative Internet payments applications for whom the provision of customised payments applications is usually cost prohibitive.

Work performed from the beginning of the project to the end of the period covered by the report and main results achieved so far

The second reporting period deliverables build upon the results of the OPE Alpha phase. They will be delivered in the form of three demonstration videos. The videos provide a walkthrough of each area covered below together with snapshots of the working platform.

Development Environment
The Development Environment enables SME Developers to create new financial applications. The deliverables that have been developed include:
- PAML (Payment Application Modelling Language): a custom DSL allowing the developer to identify the components operating within the application (identities, instruments and transactions) together with component relations, flows of funds and associated constraints. UX Framework: allowing the developer to build application interfaces in a consistent and efficient manner using UI component libraries and also offering development aids such as multi-lingualisation handling.
- API Framework: allowing the validation of API requests and responses against API definitions, authentication functions and logging functions.
- Report Framework: providing a transformation of the platform operational data into an application-friendly format that can be used by the application developer to generate application reports or to provide the application with complex operational data.
- Developer Zone: a website providing the developer with all the overview documentation, user manuals and API documentation required to develop an application with full knowledge of the functions available.
- Developer Portal: a portal providing an application repository to registered developers where applications under construction and ones in production can be managed, updated and maintained.
- Developer Sandbox: a test area providing the developer with the means to test an application under different configurations and scenarios. The sandbox offers the developer functions related to the setting up of test programmes, management of configurations and instance data together with the simulation of events that would normally happen outside the platform

Execution Environment
The Execution Environment provides the secure, run-time environment for the new applications. The deliverables to achieve this that have been developed include:
- Multi-tenanted architecture: architecture to support multiple programmes and multiple VPPCs (tenants) running on same environment instance.
- Microservices infrastructure: financial components and services have been developer as micro-services allowing the individual services to be bolted on together to achieve running applications in a way that is scalable and resilient.
- Services: several services have been developed (fully or partially) including utility services such as Cryptography, Accounting, Administrators, Forex, Configuration, Authorisation, Audit, Passwords, Statement and Transaction Batches. Other services include those related to the construction and execution of financial applications and include Application, Developer, Connector, Programme Manager, Programme and VPPC services.
- Paylets: the financial components that the developer uses to construct the application. The application is built in terms of the API façade related to each paylet. The set includes Corporate Identity, External Account, Managed Account, Managed Card, Deposit, Withdraw and Transfer transactions.
- Programme Manager Portal: a portal providing a Programme Manager with the functions to browse through the available applications, set up and configure a programme using an application and service providers and manage the configuration and the instance data (identities, instruments and transactions) generated by the programme.

Compliance Management Subsystem
The Compliance Subsystem ensures that the new products and applications conform to the appropriate financial and legislative regulations. The deliverables related to this area are as follows:
- FSRCVL (Financial Service Regulations Controlled Natural Language): a custom DSL used to encode regulatory compliance rules and third party risk mitigation requirements.
- PAML Model Static Check: a static check performed by the compliance engine to validate that the PAML model including all specified configuration conforms to the rules coded in FSRCVL.
- Service Provider Match: the compliance engine can identify third parties that satisfy the requirements as set out through the PAML configuration, including the matching against the third parties’ risk appetites.
- Programme Runtime Check: Based on the PAML model of the application and the FSRCVL regulations that apply, the compliance engine can initiate a set of runtime monitors ensuring that the regulations are not broken through the real-time transactions and state updates.

Progress beyond the state of the art and expected potential impact (including the socio-economic impact and the wider societal implications of the project so far)

The OPE Project is taking the provision of payments applications beyond the state-of-the-art as follows:

• Creation of the Static Compliance Checker allows the mass creation of payments applications without swamping the compliance department of the regulated entities (ie banks). The Static Compliance Checker will provide an element of certification meaning that banks can apply trust to an application that has been developed on OPE. They will still need to do final manual checks before formally approving a Payment Programme for live use.

• Creation of the Dynamic Compliance Checker allows payment programmes to be monitored in real-time. The Checker will provide alerts when violations are detected. Compliance departments typically monitor payment programmes manually using data provided by the system. Risk can be significantly lowered meaning the banks will be more ready to open up their services.

• Creation of the Development Environment. The OPE has rich domain-specific functionality that can be used by developers using the new frameworks and portals. It significantly lowers the cost of development and allows SMEs to participate. This complements new regulatory developments such as XS2A within PSD2. XS2A banks can be more easily connected to the OPE using a single connector.

• High level design of the Security Architecture. This allows the mass development of Payments applications by uncontrolled developers without putting consumers' sensitive financial data at risk. This is a capability that we do not think currently exists in the industry. It does this by providing a tagging language which allows the developers to create financial applications without having the capability to see or manipulate financial data.

Related information

Record Number: 190381 / Last updated on: 2016-11-15