From a conversation with our solution consultant Dr. Michael Thulke
There is a lot of talk and a lot of writing about Open Banking at the moment. However, we hear very little about how a real open banking project works. Which concrete projects has andrion worked on?
In the first mandate, we prepared a preliminary study including a project setup for the introduction of an open integration layer: Open Integration Layer; my boss introduced the handy acronym OIL for it. Besides data and message transfers, this integration layer also provides an API. In this case, "open" means that systems from other divisions of the bank and external systems can also interact through it. The customer was a major Swiss bank and - as I have heard - the project has now been implemented.
In the second, currently still ongoing mandate, we implement Open Banking and integrate it into the banking software solution of the manufacturer DXC Technology, which is used, among others, by a large cantonal bank. andrion has the technical lead in this project.
In addition, applications of external software manufacturers - mostly Fintechs - are to be docked to this mandate. And that's where it already starts to get tricky: Ideally, the API provider (which will be the bank or banking software manufacturer) should not have to make any adjustments when a Fintech application is to be docked. In practice, however, things often look different, especially if we are still in the early stages of onboarding Fintechs.
What kind of API is used there?
We rely on a standard, namely the Swiss NextGen API from the OpenBankingProject.ch consortium.
What is this all about?
It would be going too far to introduce the OpenBankingProject.ch initiative here. Just this much: OpenBankingProject.ch has set itself the task of developing standards in Open Banking that also cover Swiss specialities, for example in payment transactions. In my opinion, the wise approach chosen was to build on an existing standard, namely the Berlin Group standard, which is widely used in the EU and which in turn implements the PSD2 requirements (which are binding in the EU).
This definition work has been completed for the technical domain of payment transactions. The company adorsys, a software house from Nuremberg, has implemented this "Helvetized" Open Banking API and we are now in the process of integrating it into the banking software.
What makes an Open Banking project different from a "normal" project?
First of all, it must be emphasized that no matter how innovative and dynamic an Open Banking or Fintech project is, it is still a project. And that's why the (probably less cool) methods of project management have their justification here as well. But of course there are peculiarities, e.g. with regard to the stability of the requirements, with regard to the sensible procedure method, with regard to scope management and so on.
What should one expect in terms of requirement stability?
Because the topic is so hot, you will see that people from different parts of the organisation have new ideas or bring potential Fintechs to on-board your platform. You need a ranking of potential Fintechs. You will find that this list changes quite often, so - in short - your project scope and even your project goal is constantly being subjected to change requests.
And how do you deal with this?
First of all, it helps if the project manager*) understands that he is in tension with his implementation project: New creative change requests and ideas are constantly coming from outside, but his implementation project needs stable requirements.
It is important that he manages the scope and stakeholders properly - he should set aside some time for this purpose and for the necessary communication work.
Specifically, he should coordinate closely with the client or the business project manager in order to stay in sync with the project goal and scope. And if changes occur, he should manage them in the classic way: analyze and point out the impact, bring about a decision, communicate the decision, adapt plans/documents/backlog. And yes, sometimes it is also necessary to fend off unnecessary changes...
To what extent is there a risk of producing things for the wastebasket?
Yes, that is a significant risk - as is probably the case with all projects in a volatile environment.
In the early stages of the project, the art is to develop a sense of what requirements are most stable. That's where we started working on the project.
Which method of procedure did you decide on?
Just because Open Banking is new and innovative doesn't mean that you have to be agile. As with any project, you should decide which approach is best suited to your needs based on the general conditions. It also certainly helps if you are free in your choice of delivery dates and are not bound to rigid release grids; and furthermore, it is completely inappropriate to set a plan with a defined scope and defined deadlines right at the beginning of the project - as I have already mentioned, the subject is too volatile for that.
And what does this mean for the relationship with the client of the project?
Explain to him in detail that you have to fly on sight to a large extent. Also suggest to him that you work on a Times&Material basis instead of a fixed price basis - that is more appropriate to the situation.
Any other recommendations?
Be sure to include a sandbox. By sandbox I mean here an isolated running system, which basically consists of the Open Banking API including a small dummy corebanking, a small dummy e-banking, an administration interface and a developer portal, which provides test data and other tools for developers. These "playgrounds" can then be used by Fintechs, for example, to familiarize themselves with API behavior and to test whether your application interacts properly with the API.
Such a sandbox is provided much faster than a fully integrated Open Banking API, so it can be used at a very early stage. This reduces the number of negative surprises during later end-to-end testing.
What is the next step?
We will continue to implement the Open Banking API and connect it to the core banking system. Then we will onboard Fintech applications.
We are currently talking to the test team. If you are building an API, you will of course need a client for testing; make sure you have one available. And test automation is also an option here.
In any case, the situation remains dynamic - and also exciting. We're just about to open the door and a wide range of new possibilities lies ahead of us: connecting accounting systems, cash management systems, multibanking, new payment solutions, banking-as-a-service, etc.
- To be continued -
*) If the masculine form is used here, it also refers to the feminine form.