An article written by Dumitru Taraianu, Co-founder & CTO Finqware
The August release of Finqware API is our first public alpha. Here are some random thoughts around what we’ve been building for the past months, some architectural decisions and our technology stack.
This project started last year with a simple prototype showcasing few PSD2 Account Info APIs. At that time our backend would be consumed by a cool mobile app only. It was our first dive into Open Banking.
Around December we took a bold decision – focus on the backend and make it our central product. Another important step was to stretch the Open Banking concept and build a story that not only includes cases enabled by PSD2, but expands to any function made available by platform banking.
Fast forward ~eight months and we now have our first MeTP (minimum externally-testable product 🙂 that includes the alpha versions for the power combo that any API product should have: the backend, the docs and an interactive dev portal.
We’ve gone through a major core migration from Node.js to Elixir, a compiled language that runs on the Erlang VM. Erlang’s speed and ability to scale is almost legendary. Besides the underlying beast of a runtime, Elixir is a beautiful language. It literally takes few days from ‘hello world’ to becoming productive. But more importantly, it fits perfectly our use case: a data-driven middleware exposed externally via APIs. The code is deployed continuously via our CI/CD pipeline to Google’s Kubernetes Engine.
Our developers portal is a major piece of the puzzle. At the moment a registered user is able to check the docs, generate API keys and subscribe to different banking APIs (skills) that we integrated. Dev support is available through our chat widget. You’ll find us online pretty much any time during the day for feedback.
Being such a critical component (billing, monitoring, tenant app security) with a code base expected to grow pretty fast, it was important to make a good choice for the tech stack. At the moment I’m fascinated by the OCaml ecosystem so I could not help giving ReasonML & ReasonReact a try. According to Airbnb, static typing could have prevented 38% of their bugs in the front end app. For me that number is already equivalent to at least one additional engineer. ReasonML has a completely sound type system and it really feels like a second brain – invaluable tool for a small team.
We’ve been constantly testing PSD2-based Account Info APIs provided by various banks. With Finqware, each API that we integrate becomes a skill. Therefore, each sandbox API that we integrate becomes a skill. Hence our sandbox is in fact a catalog of sandboxes and our users can test whichever they feel so – eg: ING Bank’s, Raiffeisen’s. This is powerful because when you decide to develop on top of a certain’s Bank API, you want to know as soon as possible (eg: while using the sandbox) what are the specifics around strong customer authentication or what kind of data is included with each transaction. You also want to migrate from sandbox to production just by changing the skill name!
The skills are available over a simple conversational API that fits the way frontend apps are developed. Account Info (AIS) data that we get from Bank’s sandboxes is already normalized into a more generic format inspired by Berlin Group and OB UK. We’ll evolve that format based on feedback and our research.
You’ll notice that each skill (production or sandbox) is versioned. That reflects the lifecycle of the backend API that we’re integrating. If Bank XYZ decides to upgrade their AIS API from v1.0 to v1.2, the respective skill will reflect that change, but attempting to keep both versions online for a transition period.
Some of the AIS APIs we integrated do not have enough test data, making it difficult for app devs to work on useful interfaces. That’s why for most of the sandbox APIs we have a 2.x version published already with our own enriched account transaction format. If you want to play with the 2.x versions, keep them as experimental. There is a lot of information there that no bank is sharing yet.
Versioning is not only important for technical reasons. We envision a moment when certain skills will be enhanced by being backed by commercial APIs. Say for example that Bank XYZ will make an API available at a certain price. Finqware, as an API distribution channel will take that information, wrap it into a new or existing skill and present it further as an enhanced version, priced differently. Using this upgraded version will be a choice based on each user’s needs. Open Banking has to be fuelled by incentive in order to evolve and so, banks that decide to pursue the platform banking model will need to make money out of it.
During the next few weeks we’ll be testing and integrating more PSD2-based APIs, including payment initiation. Feel free to join our alpha testing program.
Happy coding!
About the author – Linkedin profile
Banking 4.0 – „how was the experience for you”
„So many people are coming here to Bucharest, people that I see and interact on linkedin and now I get the change to meet them in person. It was like being to the Football World Cup but this was the World Cup on linkedin in payments and open banking.”
Many more interesting quotes in the video below:
