Open APIs will sputter unless security and dependency are addressed
Many U.S. financial institutions are sharing customer data with third parties through rollout of open application programming interfaces (APIs) for payments and other services.
Last November, Citigroup unveiled a global API hub to enable third-party service providers to build innovative solutions around account management, peer-to-peer payments, institutional money transfer, and account authorization. And, in May, BBVA Compass provisioned eight proprietary APIs for external programmers to use its clients’ financial data, and develop new services around loan origination, payments management and identity authentication.
Bank of America recently announced plans for an API-driven information sharing agreement with two data aggregators, conditional upon its customers giving consent for the same. Wells Fargo and JPMorgan Chase, too, have struck partnerships with third-party service providers and data aggregators like Finicity, Xero and Intuit to allow the latter to import their customer data.
All these initiatives highlight the industry’s recognition of the fact that they have to rapidly disrupt themselves, or risk being disintermediated by the nimble, innovative fintechs of the world. After all, modern-day consumers–seeking instant gratification in an era of Uber and Airbnb–want affordable, frictionless and relevant solutions. They also want increased control over their banking data as they seek to use their preferred non-banking tools for tracking personal finance including spending, money transfer and taxes.
But the open API journey, even in its nascent stage, poses significant challenges for U.S. banks. First and foremost is the issue of identity theft. Many industry players remain concerned about the security aspect of screen scraping, the data-sharing method currently adopted by many third parties that requires consumers to share their actual bank account credentials.
Lenders need to design an architecture that can effectively manage dependencies across different APIs. They should also ensure a clean interface design that is easy to understand for third-party developers.
Developing APIs is only one part of the equation. Equally important is testing them for performance and security, more so considering that the various data masking and restrictions at play makes bringing live data into test environments difficult.
Once the APIs have been deployed in production, banks will have to ensure these software gateways can scale rapidly in tune with dynamic demand. This is critical, given banks will be dealing with numerous partners having their own set of reputational and regulatory risks. Hence, Open APIs will require comprehensive and proactive monitoring around availability, performance, security and other dimensions.
Going forward, banks should embrace a Microservices framework of loosely coupled services that can be built, tested and deployed on a standalone basis. Such a framework, driven by next-generation automation technologies, can help banks roll out compelling Open API capabilities in an agile manner.
In conjunction, banks should harness third-party tools provisioned by different IT vendors and cloud platforms to reduce the time to market for Open APIs, without compromising on the underlying security. Doing so will enable them to concentrate on the layers truly unique to their proprietary platforms and capabilities that they would like to showcase via Open APIs.
Finally, ensuring standardization and integrity of customer data, while complying with relevant regulations, will necessitate adoption of industry-wide standards on data interoperability.
Nevertheless, with their core services including payments and lending facing disruption from agile competitors, and customer loyalty declining, banks have to embrace Open API for disruptive innovation. Otherwise, software will eat up their world, to paraphrase those famous words of Marc Andreessen more than five years ago.