Open doesn’t mean easy – The complexity behind PSD2 and Open Banking

Open doesn’t mean easy – The complexity behind PSD2 and Open Banking

Open Banking the simple part – Open Security the difficult one?

Slowly the PSD2 API and SCA specifications become more concrete and available (e.g. BerlinGroup).
One is now able to developing first test cases against PSD2.
It becomes more and more obvious, how complicated Open Banking can become and probably will be in the future.

And it isn’t the core banking functionality that makes a developer’s live complicated.  It’s the security diversity behind this new PSD2 SCA API architecture.

If we in Germany wouldn’t know better (with HBCI and FinTS) one could believe security has to be that complex.

Compared to FinTS the security model  behind PSD2 seems to becoming a complexity monster and a danger for the whole Open Banking approach.

Dead on Arrival

In the end not only the developer and the integration and innovation party (TPP) might be disgusted. The user might become overwhelmed by the Open Banking based software and security usability. 

Probably he will reject Open Banking solutions. The Open Banking market will die before ever gone live.

If you like to feel and understand a litte of the given complexity go to the openpsd.org and download the first embedded SCA example (based on the BerlinGroup API). The embedded one is still the simplest one. But we will also work on the other SCA scenarios.

I’m still very optimistic for  the whole OpenBanking approach, but compared with the 20 years of experiences of usable APIs in Germany there still a long way to go. That’s why we are here at OpenPSD.

If you like to help let us know.

PSD2 – New BerlinGroup API Specification available

The BerlinGroup PSD2 working group has released a new PSD2 API specification – Version 1.2. 

This time The NextGenPSD2 Framework and Implementation Guide also includes an OpenAPI file:

The OpenAPI file integrated into a Swagger editor including documentation and examples can be tested at OpenPSD (http://specs.openpsd.org/).

We, from OpenPSD,  will use this new OpenAPI file to creating (at first) a PISP and then a AISP PSD2 test server.

If you like to contribute to OpenPSD please send us a DM.

Account Information Consent Flow

openpsd.org starts its first user story

Bootstrapping a new initiative is always amazing! You have to study specs and implementation guides, think about components you need and choose technology you want to use. In our case

we decided to provide a test server for Berlin Group’s NextGenPSD2 specification. You might think that we are going to provide yet another set of boring mock implementation of the rest API Berlin Group is currently specifying. And I tell you no, we won’t do that! What we want to have in place is a set of components which allow you go through a complex use case.

Consent
As consent is crucial to psd2 we decided to start with Account Information Consent Flow. This is a very complex multi-dimensional process both from business as well as technical perspective. From business perspective you need to consider that a consent itself has different information such as type of account service it is granting access to, frequency of its usage and its validity duration. Then there are different consent models like detailed, global and bank offered.

Technically Berlin Group defines redirect, OAuth2, decoupled and two different embedded strong customer authentication (SCA) methods with which a customer (PSU) may give its consent to the bank. Berlin Group’s implementation guide defines a sophisticated sequence diagram for each of those SCA methods.

Berlin Group Redirect SCA
[Source: Berlin Group's Implementation Guidelines]

Our approach is to have components in place which allow to go through all those steps in a complex test case. And that’s a lot more work to do than simple mocks for rest api interfaces.

PSD-Server, SCA-Server, Modelbank
We started to implement a modelbank, a psd-server and a sca-server. Our modelbank will simulate an Account Servicing Payment Service Provider (ASPSP) in this user story. Other roles a bank can take over will come in future. Our target is to have a simple model bank which can provide account servicing and simple payment processing services. PSD-Server provides the rest api and SCA-Server will provide different SCA approaches mentioned in Berlin Group’s implementation guide. Both PSD-Server and SCA-Server will use modelbank’s services.

Go, Go, Go
We decided to use golang for all of our component’s implementation. This is not because we hate Java, no. It is simply because of the dynamic progress golang is facing during last few years. We think it is one of the most promising programming languages for now. There are a lot of articles out there emphasizing golang’s strengths and comparing it with Java. We don’t want to go through this here.

Clean Architecture
In UHUCHAIN we already introduced our clean architecture approach in golang projects. We continued this approache in our components here as well. All of our components will separate technology dependent stuff in a provider layer. They have controllers, use cases and entitites separated from each other by using input and output ports in each layer.

Implementation is not completed yet but we have reached our first milestone to bootstrap everything and have a clear understanding of what is going to be done next.

GO to PSD2 – Be part of one of the hottest Topics and Technologies

GO to PSD2 – DO, deliver and learn!

The PSD2 regulation and the corresponding RTS require from every bank to provide a full functional PSD2 test server against every TPP can test and implement.

This server also needs to support the corresponding SCA and TPP onboarding flows.

The test server must be available 6 months before the first release of PSD2 APIs in September 2019.

We, from OpenPSD, decided and started to develop an Open Source PSD2 test server implementing the BerlinGroup standard.

And although the regulator did the mistake to not regulating the technical interface of PSD2 we assume the BerlinGroup API becomes the de facto standard, at least in Europe and Germany.

We decided to implement the test server with today’s most promising programming language GO. We believe GO will sooner or later replace Java due to its simplicity and robustness.

Be inside the castle and walls, don’t stay outside

So if YOU want to participate in our Open Source development you will not only learn a lot about PSD2.  You will also teach yourself with the hottest stuff technologies (GO, Docker, Kubernetes, DevOps etc.)

And of course every developer participating will receive its stake in OpenPSD and corresponding rights.

Please feel free to send us a direct message and apply as developer supporting our approach.

We are already a team of six very motivated and skilled people, but we need more of YOU to succeed.  The roadmap is challenging, but promising!

 

 

PSD2 – Really? Where the hell is the Open API?

PSD2 – Really? Where the hell is the Open API?

New Open API File for the BerlinGroup’s API definition available

Today we, from OpenPSD,  are proud to publish our updated version of the Open API definition for the BerlinGroup’s PSD2 API definition.

We are getting closer to where we should be, but we still have to expect major changes. In July very likely a version 1.2 of the BerlinGroup API specification will be published, what makes an amendment of the corresponding OpenAPI (Swagger) definition necessary again.

At the BerlinGroup API Implementation Group more and more participants are joining forces, but what me still worries most:

Smile if you can

We have created an regulation forcing the banks to open their doors, but the regulator has forgotten ‘to provide the keys’.

Even if we try to standardise the API within the BerlinGroup, every bank is still ‘allowed’ to implementing technically whatever follows the laws  – A nightmare for every developer.

If I consider Germany’s past we are much farer away from Open Banking than we have been the last 20 years with HBCI and FinTS.  Besides we are not allowed to using FinTS anymore.

Currently I’m in charge to implementing a  kind of TPPs Multibanking behaviour in a new core system.   This is a kind of ‘Rocky Horror Picture Show’ from a technical perspective.

I know the banks have to provide doors to enter their rooms, but everybody provides different keys. To use these keys in a sensible manner is  nearly impossible, today.

Hope for the future. Maybe the BerlinGroup API becomes a PSD2 part as well.

The ‘Open’ of Open Banking API – the first real open Banking API for download

PSD2 requires the banks to open the bank via APIs

PSD2 doesn’t say how the API from a technical perspective should look like.
Based on this approach a lot of different implementations have been deployed within the last months. This trend makes it really hard for a developer to interface with many banks.

From this perspective the PSD2 standard is much less open than the 20 years old FinTS standard. FinTS relies on only one technical specification.  Code once use with every bank.
This new technical diversity formed a new trend of building Fintech Aggregation companies to providing the developer with one technical API.
But aggregation has to be paid and is proprietary either. Finally an Open API is becoming a Closed API (again).

BerlinGroup NextGen API Spec

The BerlinGroup tries to changing this by providing one technical API specification. Additionally the BerlinGroup NextGen Implementation also aims at supporting this one interface approach by providing technical solutions or at least concreate specifications for tests and test servers.

Florian and I are member of the BerlinGroup Implementation. We are close to the current developments.

This Open Source Swagger API Technical Spec based on the BerlinGroup specification is one result based of our first activities.

What we try to achieve with the  OpenPSD initiative is to building software based on what we are learning and defining at BerlinGroup.
We would like to build OpenSource software which reflects our activities at BerlinGroup.

Everybody should benefit from OpenPSD and nobody should have to pay for ‘Open’.

The ‘Open’ of Open Banking!

Feel free to contribute, just drop us a mail!

A new open is born – OpenPSD

A new open is born – OpenPSD.
OpenPSD is about PSD2 and all its coming developments.

Like the Via Appia Antica was a long road to the open and modern Rome PSD2 is the new and open road to a different and new banking.

We, as a team, would like to contribute to this new European Banking movement by providing Open Source Software for PSD2 and beyond.

OpenPSD should be the API driven Open Banking Open Source Marketplace.

As we are bankers a first delivery will be a BerlinGroup test server implementation.

A first sneak preview can be found here.

Stay tuned for coming developments and let us know if you want to contribute.