Guest Post — Open banking APIs from a developer perspective
The importance of Open APIs in general cannot be exaggerated — accessible APIs are changing the world. Open APIs within or across lines of businesses allows developers to combine functionality from services in various areas and create new user experiences. Combining functionality into new useful services for customers may lead to new business models.
Open Banking APIs
Open Banking APIs allows the creation of applications incorporating aspects that previously was difficult. These APIs makes it possible for applications to include payment etc. into a natural non-intrusive part of the applications and enabling the users to focus solely on the application. The financial information and functionality is made available in a natural way in the application.
Creating new applications and services
Developers in Fintechs or individual developers can utilize the Open Banking APIs and combine that with their knowledge about a particular segment of users to create new relevant contextual applications with a financial aspect as a part of that context and belonging services. I am expecting that some of these new contexts are so-called mash-up contexts between banking and other business domains as well as within a sole financial context. Looking at the latter, these contextual applications and services may extend the individual banks offering to their customers or to multi-bank customers — by creating applications, that creates value in the customers economic context across banks e.g. spending overviews, budgets, forecasts, detection and warning about transaction anomalies, payments, assembled and accumulated payments, savings overview, investment advice, economic insurance, insurance/lending-offers/leads, rating, contextual loyalty programs etc.
An ecosystem for co-innovation
Open Banking APIs also provides opportunities for the individual bank to bring new services to their customers and provide a better UX leveraging these new applications. APIs plays a significant role in the creation of an ecosystem benefiting fintechs and banks. That ecosystem provides the ability for Fintechs to create services that can be used across a multitude of banks and the same is true for decoupled services offered by banks in that ecosystem.
To maximize value from the Open Banking APIs, it seems that attracting the right kind of developer for innovation and attracting Fintech developers is going to be an essential part, in order to get a vibrant co-innovative situation. A critical point for bootstrapping this co-innovation, is having an easy way to find the APIs offered by the bank — e.g. when “googling the APIs” that should preferable return information for the developer to start trying the APIs out immediately. It should be really easy to get started with development and creation of application based on these API’s and get the first results back into a general client or an application — in order for getting a working prototype. APIs providing a good DX is key. Thus sandbox usage and guides for doing development using the services becomes very important — as well as having constructed and representative information available in the same formats and variance as the real information would have. Instantiating a “personal” sandbox must be easy.
The API specification should be concrete and follow the actual implementation from a consumer perspective. This means the API should include e.g. responses from the infrastructure as well as from the service itself imho. APIs should preferable be published in a standardised format such as Open API or API Blueprint in order to have the best tool support for development. Publishing repositories with sample clients ready for being forked and having e.g. npm modules for npm based web applications and e.g. client stubs may be important for making it easy to use the APIs from various platforms from a development perspective.
Looking at the APIs from another perspective — it is important that the services can be scaled, evolved and operated in a cost-effective fashion and of continues to be easy to consume. Additional self-onboarding service consumers and delivering targeted information to the consumer on his/her consumption etc. is important. The former part is about having services include support for certain status codes e.g. 301 for evolving services and e.g. 304 for being able to avoid serving the same information over and over again to the same client. It is important to be able to keep evolving the API without influencing the continued operation of the existing consumers.
Summary
Getting started must be easy, and quickly find out whether the services matches the needs of a new contextual application or service is very important. Documentation like “how to run with Open Banking APIs in 5 minutes” and examples on YouTube, blogs, GitHub etc. making it easy accessible for developers is great and having something working quickly gives confidence that this is the preferable API to continue working with. Having cool examples of applications already created and videos of those as they emerge is great and will get developers to look for the APIs and start developing applications that will drive new business and give customers new relevant functionality.
Conclusion
Looking at the current API offering from Nordea, it seems that most things are available already and I will be looking forward to coming back and working with the Open Banking APIs sometime in the future.
Happy Coding!
About the author
Allan Hojgaard Jensen has worked with software development 20+ years and have been working with improvement of development 10+ years.
Allan is specialized in service APIs and particular REST APIs and how these can be evolved fast whilst keeping existing consumers happy. Allan joined Oracle in 2017 as a Cloud Platform Architect and facilitates a practical architectural group under Dansk It as well as Meetups in the major cities in Denmark on topics such as REST, APIs and services. Allan participates in hackathons as participant and mentor.
