Open APIs – The Need for Common Standards in Banking

The ripple effects of regulation such as the EU's Second Payment Services Directive (PSD2) and Open Banking initiatives in the UK and APAC, designed to stimulate increased competition in banking, are being felt worldwide. But what do these changes mean in practice for developers seeking to build new fintech apps to work with bank APIs?

While the UK's Open Banking organization has shared a set of open API specifications and data standards, PSD2 does not provide any technical blueprint for what the APIs should look like and how they are written. Even if there is consensus over HTTP, REST and JSON, there are still many things that remain open to interpretation. Even for a simple request like 'get account', there are differences in the way banks are implementing these instructions today which will require code to be adapted from bank to bank.

In addition, standards tend not to solve all problems and are often lacking things that cause people to abuse the standards or make one-offs. Mapping can be used to convert APIs, but while in itself it's not complex, it is prone to creating defects. Doing this couples two different systems through an intermediary party or technology which translates. If you've ever played the telephone wire game (or Chinese whispers) you know how this will end. Mappings and conversions are done out of necessity but it's always a kludgy architectural element. Standards do help to stabilize this interaction, however the fintech world lacks sufficient agreed standards today to go beyond simple consumer interactions.

New efforts in the market may change this in the future. But today a large part of a fintech's effort is spent managing integrations. As a result, developers must be aware of volatility. When integrating to a third-party API you have to adopt to any API changes as they come, and often you need to do that quickly.

Common standards

Consortiums such as STET in France and the Berlin Group are taking a similar stance to the UK's Open Banking in aiming to define more precise API standards. But there needs to be commonality between all – otherwise developers and fintechs looking to service banks across Europe (and beyond) will need to create interfaces to support every different flavor of bank API. Such an approach could become rather unwieldy.

In my view it's essential to create a set of common, industry standard APIs that can be used by all. A platform-based approach, underpinned by an extensive ecosystem of participants that all adhere to common standards, is crucial in enabling banks to quickly access, integrate and deploy new apps from Fintechs and developers.

As more banks and Fintechs adopt the Open API specifications and experiment, it's encouraging to see commonalities starting to emerge. But while the industry continues to debate the merits of different standards, it's essential not to forget the essence of building a good API.

My advice to banks, fintechs and developers building APIs is to treat the API like any other user interface or product, because that's what it is. It's important to do usability studies, shape it, and dress it up with great documentation to market it correctly.

Security should be incorporated in the full lifecycle of development. APIs create a new attack vector that many fintechs could neglect. Adoption of secure design, coding, and testing practices – a cultural shift for many organizations – needs to be leveraged before bringing APIs to market. Deploying the application and secure operations are always key for a service provider or a bank, but it all starts in product development. You can't sufficiently secure a product after it's been built. Security is everyone's concern. Without sufficient security and access controls, the APIs will not be able to be opened safely and will not achieve the goal of fostering innovation and rapid development.

A good API is intuitive. The best APIs succeed in making a complex problem simple. They do what you expect and nothing more. Good APIs have a logical structure with a naming convention that is descriptive and self-documenting. I often judge an API based on how many trips I have to make to the documentation.

A good API will be highly cohesive. When you send an update to one service domain, you don't really expect unrelated services to be affected, yet all too often this is the case. That sort of back end magic is impossible to see via the API and creates confusion.

Though there are a few good options out there, I recommend using REST. REST is pervasive; 99% of the developers out there are using it and it provides a clear, consistent and simple interaction model that is lacking in other RPC methods. As far as integration goes, remote calls using RPC methods will wane as microservice architectures become more common. And when the only way into the service is through REST APIs, interactions will coalesce to these APIs and render other remoting techniques irrelevant. For the instances where a state transfer model of interaction is awkward, there are several good, relatively new RPG methods to consider. Key to these critical choices has to be the developer. In every industry there will be various levels of capabilities of that target developer – remember that when you are choosing just how interesting to make your APIs, and what form and method they should embody.

Top tips in building APIs

  • Where consumer applications are concerned, adopt the standards. This will ensure maximum reuse and minimum volatility for an app developer
  • If you are exposing services and APIs, go with the market on key things such as oAuth, REST, JSON
  • Support at a minimum the key four verbs: GET, PUT, POST, DELETE, and do it properly. Everyone expects those to work
  • Model your domain properly and don't push RPC concepts into your REST APIs
  • Design the API with developers in mind. Note that every microservice you create should be exposable as a product and you should consider the developer persona even when you don't think you need the API exposed as a product. Sometime in the future, you will find out that people need it and you will save yourself rework. An added benefit is that it becomes a more supportable system.
  • Use the HTTP spec properly. For responses, if a system can't find a data row it should return a 404 not a 200 with a message that the data is not found. The same is true for system errors in 500s, auth errors in 401-3s, as well as things such as 'Pagination in Link' headers. Respect the content type header. When you support data download, use the content type to allow the user to tell you in what form he wants to receive the payload. Know and use the spec – this is probably the biggest problem for developers in implementing REST APIs, together with abuse or lack of proper use of verbs and response codes.

It's clear that APIs will play a key role in shaping the financial services industry of tomorrow. Our goal at Finastra is to help support and accelerate the process in creating common standards and industry best practice. Don't hesitate to get in touch if you want to learn more.

Be sure to read the next Banking article: Xero Launches Open Banking API to Bring Financial Data to Businesses

 

Comments (0)