Open API, an unmixed blessing that stirred licensed promiscuity turning into a quicksand.
Let’s try to find answers of these questions before it’s too late; Is it truth or fallacy that Open API, for Fin-Tech startups, have been proved to be a booby trap? Will it spoil the tranquility of customer privacy ? What would be impacts on Value Chain ? where is the solution for this awaiting menace?
.
Genesis
Circa 2015, a name emerges on the horizon; OpenAPI Initiative, a company under the sponsorship of the Linux Foundation gets launched by SmartBear who had Swagger API specification under their wings from Tony Tam’s Reverb Technologies. SmartBear pledges Swagger Specifications aka OAS, gets shelved in Git Hub, with the newly formed group of heavy weight companies included Apigee, 3Scale, Capital One, Google, IBM, Intuit, Microsoft, PayPal, and Restlethad, who were founding members. Although MuleSoft joins this party quite late, it ramps up to be top contributor of what we now call RAML, API modelling Framework tool. If anybody could see this little sport, in farthest stretch of imagination, underpin a paradigm shift in BFSI realm later on, Regulatories like BIAN, PDS2 or GDPR would have etched their commandments on the stone by now in 2020, I believe. Financial Institutions would have opened their APIs, Architectures and most importantly their data without muddling through social precipice.
.
What happens actually in the kitchen
Well, basically in the simplest terms, an API allows one piece of software to interact with another piece of software, whether within a single computer via a mechanism provided by the operating system or with an internal or external TCP/IP-based or non-TCP/IP-based network. In the late 2010s, many APIs are provided by organisations for access with HTTP. APIs may be used by both developers inside the organisation that published the API or by any developers outside that organisation who wish to register for access to the interface. OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenAPI Specification removes guesswork in calling a service. Use cases for machine-readable API definition documents include, but are not limited to: interactive documentation; code generation for documentation, clients, and servers; and automation of test cases. OpenAPI documents describe an API’s services and are represented in either YAML or JSON formats. These documents may either be produced and served statically or be generated dynamically from an application. The OpenAPI Specification does not require rewriting existing APIs. It does not require binding any software to a service — the service being described may not even be owned by the creator of its description. It does, however, require the capabilities of the service be described in the structure of the OpenAPI Specification. Not all services can be described by OpenAPI — this specification is not intended to cover every possible style of REST APIs. The OpenAPI Specification does not mandate a specific development process such as design-first or code-first. It does facilitate either technique by establishing clear interactions with a REST API.
.
The emerging quicksand
As per an F5 Security report, “The highest percentage (70%) of the breach reports for Q1 2018 were web injections that stole customer payment card information”.It is also expected that by 2022, API attacks are going to be a major attack vector.The majority of banks in Australia have not exposed their APIs.This picture will change in 2019.Online banking applications are one of the most lucrative targets for cybercriminals, and credential stuffing attacks are causing havoc across the industry.In fact, across APAC as a whole, cross-matching techniques and credential-stuffing bots are costing businesses up to $28.5 million per year, according to Akamai’s latest figures.Once banks expose their customer data APIs in Australia, it is very likely that credential abuse attacks will increase significantly.The APIs are mostly availed for use by developers and other users with relatively few restrictions. Restrictions might include the necessity to register with the service providing the API. Normally either they are restricted by Open Data which is freely available for everyone to use and republish as they wish, without restrictions from copyright, patents or other mechanisms of control. An Open API may seem to be free to use but the publisher may limit how the API data can be used, based on an open standard. it is imperative to be mindful that opening back end information to the public can create a range of security and management challenges. For instance, publishing open APIs can make it harder for organisations to monitor and control the experience end users have with their information assets. Open API publishers cannot assume client applications built on their APIs will offer a best user experience. Furthermore, they cannot fully ensure that client apps maintain the standard look and feel of their corporate branding. A huge surge, Increase application content routes to market in an effort boosts revenue potential. The increased routes to market adds to the potential load on the core application or service being exposed through the open API. Without careful consideration, the potential load from a third-party application could disrupt the company’s own, likely business-critical, use of the application or service. For example- a major U.S. retailer whose IT department built and exposed an API to its product catalog as a skunk-works project. Nobody knew the degree to which the API would be used or the extra load to expect on the product catalog service, a business-critical IT asset.Here is how dangerous a scenario can get when the capability of companies to expose their services to the outside world, so that external partners or even competitors can use these services to bring added value to their customers. This trend is made possible by the technological evolution of open APIs (Application Programming Interfaces), which are the digital ports making this communication possible.
.
The grass is greener sometimes
We see the success story of Uber. In just a few years this company has acquired a market capitalisation which is larger than that of BMW. This while Uber mainly combines multiple API services offered by other companies, i.e. Positioning is done by the operating system (iOS, Android), Route calculation and maps are provided by MapKit and Google Maps, Twilio sends real time text messages to the customers, Payment is handled by Braintree, The receipt is sent via Mandrill.
The services are hosted in the cloud on Amazon Web Services (AWSIt is financially tiring to constantly develop new features, or even related products, can be costly and time-consuming. With an open API, other developers make your product more useful to current users while attracting others with added value (maybe even from the competition). Getting a leg up while others help make your product more attractive may seem too good to be true, but it is possible by making your interface available.
.
Success through standardization
A few financial institutions have already taken their first steps in the evolution towards an open banking API ecosystem, with most prominent examples being BBVA, Crédit Agricole, Capital One, Citi, VISA, MasterCard, SWIFT and Fidor.
In case of banks this consists of providing APIs for services like payments, getting account information, placing a securities order…
In case of card companies like VISA and MasterCard this consists services like digital wallet, finding an ATM, doing fraud detection…
BBVA is often considered as the flagship of this evolution. Already several years ago, BBVA declared itself no longer as a bank, but as a financial services software provider.
Other successful initiatives are banks positioning themselves as providing the banking services (i.e. the licensed bank infrastructure) to Fintechs to build on top off (i.e. Banking as a Service). Examples here are CBW (Kansas), Solaris Bank, Wirecard Bank, Railsbank…
At the same time, several Fintechs are also creating their ecosystems. E.g. WealthFront (online trading) and Venmo (online remittances), Fidor Bank and Sum-Up (mobile point-of-sale), Metro Bank and Zopa (online lending), Moven (online bank) and CommonBond (online lending) or Number26 (mobile bank) and TransferWise (online remittances).
A major issue for Fintechs and companies from other sectors wanting to use the APIs of the financial service industry is the lack of standardisation in the APIs. Developers do not want to integrate a completely different API for each bank they want to connect with.
Unfortunately, like any standardisation process, creating this “lingua franca” is very challenging. Many initiatives try to define a standard and group banks together, which proclaim to comply with this standard, but an agreement on a global (or even national) standard is not expected for the very near future.
Open Bank Project , Open API initiative, IXARIS Open Payment Ecosystem, Open Financial Exchange (OFX), Financial Transaction Services (FinTS),Banking Industry Architecture Network (BIAN), Berlin Group, W3C Web Payments Interest Group
Again, the key here is a fast go-to-market strategy, allowing big banks to impose their standards to many early adopters creating a widely accepted Open Banking standard. A good test for such standardisation will be PSD2 (going live in 2018), where standardisation and acceptance could for example be obtained through aggregated PSD2 Payment Hubs used by multiple TPPs (third party payment providers) and Banks with well documented API calls.
.
Conclusion
