Is your API an asset or a liability?

A touchy API topic is data ownership and liability, regardless of whether the APIs are open or protected. Obviously, depending on your business model and needs, you will choose to expose the APIs and the underlying assets to your developers, partners, public developers, your consumers, or others that I am forgetting. While almost everyone talks about the API business relationships, the liability concern brings the legal relationship to the forefront.

APIs are considered a contract between the data supplier (or API provider) and the app provider. If you have different API providers that publish APIs from a central place, and multiple third parties use that API catalog to build apps for their consumers (end users), then it becomes complicated. While you can fix some of this by writing detailed contracts and making the app providers and end customers agree to the terms of usability before they use those APIs, as a provider, you are also responsible for implementing controls around your APIs to mitigate most, if not all, of the risks involved.

Your internal developers are generally not a concern, but opening up your APIs and assets to outside developers/agencies can cause some serious issues down the road if you don’t do it properly. I was engaged in such a conversation with a major corporate banking client (top 3 in the world) just last week.

Obviously, compliance and liability is a different monster when it comes to regulated industries, such as healthcare, energy, insurance, banking, etc. But it is even more pronounced in the banking industry — after all, you’re playing with people’s money. Global corporations need to worry about international consequences too. For example, countries generally have more stringent rules and regulations about customer data processed, distributed, and accessed from outside their geo-boundaries. Your platform should be flexible enough to enforce those regulations by identifying the customer data, region, user base, and other factors.

And your liability doesn’t end when the data leaves your API. In most cases, especially in regulated industries, you own the data for its life cycle. If your organization collected the data, then it is your responsibility to care about it. Given the mass data exposure capability of APIs, this could become a major liability issue. And I’m not just talking about misuse of data or accidental exposure; data quality, data cleanup, and data integrity can all be potential liabilities as well.

So how do you solve this?

First, you need to have proper controls around your API. Having a completely open API with absolutely no controls around it and allowing it to access your liable data directly will lead to disaster.

You need to identify the developer base, consumers, and purpose it is used for. You also need to classify and control who can use the API and the data and for what purpose. By layering in the country/region specific needs, this can get complicated very quickly. For example, hypothetically speaking, your German user data cannot be exposed to a French company, and, more importantly, it cannot be processed on foreign soil. This means the APIs need to be aware of the location of the processing too.

You also need to know what happens to the data after it is used for the purpose it was intended for. You’ll need to consider proper storage, disposal, usage time limitation, usage purpose limitation, etc.

We all know about the Snapchat fiasco. It stayed in the headlines for a few days and then disappeared into the sunset. I heard the company valuation has sky rocketed because of the publicity that came with it. While I am not saying it was a deliberate act, it worked in the company’s favor. Now, if it happens to a banking API it will be taken as lightly? Not only will every regulatory body be interrogating them, but their business partners are going to take a closer look to see if it is worth continuing the business relationship. And they’ll certainly take a branding hit with their customer base.

Unlike in the social world, where losing a few thousand, or even few million customers, because of a fiasco doesn’t hurt that much financially (maybe your branding will take a hit), you can’t say that in a regulated industry. If a bank loses user confidence because its platform/strategy/technology didn’t live up to its expectations, the consequences will be severe. The same thing applies if your partner/developer or an outside agency used your API for malicious purposes.

As an API provider, you need to be thinking forward about mitigating these issues: governing the data access, controlling the APIs, protecting the data, and, more importantly, managing the life cycle of both data and the APIs.

I would love to hear your opinion on this. Reach out to me on Twitter @AndyThurai to continue this conversation.

(Disclaimer: I work for IBM which has solutions in this space. The views and opinions expressed above are my personal and not of my employer’s).

Andy Thurai is Program Director – API, IoT and Connected Cloud with IBM, where he is responsible for solutionizing, strategizing, evangelizing, and providing thought leadership for those technologies. You can find more of his writings at www.thurai.net/blog or follow him on Twitter @AndyThurai.