Compliance Checking in the Open Payments Ecosystem

Abstract

Abstract. Given the strict legal frameworks which regulate the movements and management of funds, building financial applications typically proves to be prohibitively expensive for small companies. Not only is it the case that understanding legal requirements and building a framework of compliance checks to ensure that such legislation is adhered to is a complex process, but also, service providers such as banks require certification and reporting before they are willing to take on the risks associated with the adoption of applications from small application developers. In this paper, we propose a solution which provides a centralised Open Payments Ecosystem which supports compliance checking and allows for the matching of financial applications with service providers and programme managers, automatically providing risk analysis and reporting. The solution proposed combines static and dynamic verification in a real-life use case, which can shed new insights on the use of formal methods on large complex systems. We also report on the software engineering challenges encountered when analysing formal requirements arising from the needs of compliance to applicable legislation.

Control-Flow Residual Analysis for Symbolic Automata

“…It is worth noting that due to the differences in the analysis techniques, our tool does not build directly on Clara, although it uses the Soot [19] tool for Java program analysis. The tool was evaluated them on a simple financial transaction system with users connecting to a proxy in order to enable communication with a transaction server inspired by the industrial systems we have previously used runtime verification on [8]. The proxy and the transaction server can be two different services (the client and provider), possibly provided by different providers, with the property specifying the behaviour that the transaction server expects out of the proxy.…”

“…The need for verification of a system to be able to make some guarantees about execution paths, and going beyond sampling of such paths (as done in testing), is required for critical or sensitive software (e.g. financial software [8]). The literature can be largely split into two main approaches: (i) full a priori verification of all possible execution paths through model checking, static analysis and similar techniques, and (ii) on-the-fly verification of execution paths to ensure that any potential violation can be immediately truncated as in runtime verification.…”

A Foundation for Runtime Monitoring

“…The technique has fostered a number of verification tools such as [30,12,19,10,16,37,21,18,39,27,20,6,38], to name but a few. It has also been used for a variety of applications, ranging from checking the executions of the NASA Mars Rover software [12] and other autonomous research vehicles [28], to more mundane tasks such as checking for rule violations in financial systems [8], video games [40] and electronic examinations [29]. At its core, RV generally assumes a logic describing the correctness specifications that are expected to be satisfied by the SUS.…”

Runtime Verification using VALOUR

“…Twelve of these can be verified statically at compile-time (see [1,2] for more information), while eleven are done at runtime, i.e. checked using Valour.…”

“…Over the past two years, we have been working on techniques to integrate runtime verification technology into the Open Payments Ecosystem (OPE) [2], an industrial system developed by Ixaris Ltd., which is planned to handle high volumes of financial transactions across different user applications and financial institutions. Compliance to legislation and correctness are critical in this domain, and the risk of failure due to the runtime verification module had to be mitigated.…”