openNPL 0.2 REST API implementation

openNPL 0.2 release

The open source openNPL platform supports the management of standardized credit portfolio data for non-performing loans. In this respect it implements the detailed European Banking Authority NPL loan templates. openNPL aims to be at the same time easy to integrate in human workflows (using a familiar web interface) and integrate into automated (computer driven) workflows.

The latest (0.2) release exposes a REST API that offers machine oriented access using, what is by now, the most established mechanism for achieving flexible online data transfers. The API allows both overviews at the relationship level and granular access to individual records.

About RESTful API’s

REST (Representational State Transfer) is a web services architecture that in recent years has grown enormously in popularity as a viable solution for large scale network applications. Confusingly, it is not a defined protocol, but rather a set of principles, or constraints (This leads to endless discussions as to whether a given implementation is RESTful or not). It should be clear though, that implementing client-server communications according to REST is a distinct alternative to the earlier approaches (such as via SOAP protocols).

REST provides a set of architectural constraints for distributed web services that results in benefits in terms of loose coupling, maintainability, evolvability, and scalability. These attributes are essential (but not sufficient) requirements for supporting the next generation of financial risk management architectures.

In practice (and simplified language) a REST API looks like a collection of web pages that provide direct access to the data. The top-most level (root) of the API is accessed by by pointing a browser to an address such as https://here_there_will_be_npl_dragons/api. This provides a list of available further collections to explore:

We see here the available API endpoints, which enumerate the different portfolio data categories that are being exposed (Counterparty, Loan, Collateral etc.)

If we click at the “eba_counterparty” collection: https://here_there_will_be_npl_dragons/api/eba_data/counterparties we will drill down to counterparty data. (In practice a computer would not click, but would make a new request to fetch the data.). This leads us to the following:

We are now one level deeper into the API structure, where we can see all the distinct entries available within the “counterparties” collection. Each entry displays its unique identifier and a further link which will take us to the data of an individual entry:

For example, we can see that data (obviously in the example only artificial data) the Data of Last Contact.

The role of the EBA NPL Data Templates

The above review and screenshots provide a quick introduction to the concept of REST API’s and how this technique can be adopted to enhance data interoperability.

Besides a common data transfer mechanism, some form of risk data, credit portfolio data and metadata standardization, e.g. common vocabularies or ontologies is another missing element in the quest to develop risk data infrastructures that can meet the demands of a safer financial system and a more liquid, transparent and efficient market for NPL’s in Europe.

An important boost in the quest to create a standard for such credit portfolio data interoperability has been the release by the European Banking Authority of the NPL Data Templates. The EBA NPL transaction templates are documented in detail at the Open Risk Manual.

The EBA has provided these detailed templates to allow banks / lending institutions to supply comparable and standardised data on NPLs to investors and other stakeholders. These templates are not a supervisory reporting requirement, yet they are designed in a way that they can act as a market standard, used by banks and others on a voluntary basis for NPL transactions, and potentially to form the foundation for NPL secondary markets initiatives.

The templates capture data loan-by-loan, i.e. at the most granular level. They are built on existing reporting, which should reduce implementation costs. Within the templates users should be able to identify the data needed, for example, by investors to fairly price an NPL portfolio and other support other credit portfolio management activities.

From Risk Data to Risk Data Ontologies and Linked Risk Models

A range of further technical concepts are already in place: The Semantic Web denotes a number of interlinked technologies including RDF, OWL, SPARQL which have been proposed quite some time ago as an extension of the “standard” Web that will enable more efficient identification and interaction of online resources. While early adoption was slow, practical imperatives have increasingly been working in favor of operationalizing semantic web concepts (e.g. the concepts are already in use by search engines).

The overarching objective is to evolve from today’s fragmented credit portfolio data ecosystem towards linked risk data and ultimately towards a risk model ontologies and linked risk models.

Next Steps

The first release of openNPL already included in its backend database a granular implementation of the EBA templates and a Docker build that makes use of the facility literally a matter of a few keyboard clicks.

This release exposes that information via a modern API. Follow-up steps for future releases include (on the data intake side) tools for data validation and on the data access side steps towards true hypermedia API’s