The 3 Critical Consideration
Open banking is a mindset, not a destination
All business endeavors must have an eventual payout. Banks will typically make APIs available to partners and developers to create solutions for end-user consumption. Best-in-class monetization practices indicate a hybrid model, in which APIs and services are individually tagged to the highest ROI method:
- End-users can pay transaction fees to use the solution.
- Partners and/or developers can pay for service/data usage.
- A revenue-sharing agreement, such as pay-per-click advertising.
DBS Bank, in Singapore, for example, built the first online, bank-driven consumer marketplace to move upstream into the consumers’ car buying/selling journey with partners sgCarMart and Carro. This API-driven model allows DBS to remove the intermediary car dealers (indirect originations). Consumers can take up a car loan directly from the bank, thereby enjoying cost savings in the form of lower interest rates. This concept disrupts the traditional model, where banks rely on intermediaries to connect and acquire car loan customers.
To contend with competitors, regulatory mandates and demanding customer requirements, banks must embrace open APIs
that enable them to plug-and-play in the fintech ecosystem and reinforce their value proposition amid escalating share-of-wallet challenges. APIs have been around for years and continuously heralded as the next big thing in banking. Well, now that the fintech ecosystem has exploded and the capabilities and options for APIs have vastly improved, the next is the now and legacy banks need to get onboard or get left behind.
Key to the current wave of API adoption among banks was the emergence of Open API Specification (OAS), which set standard contract terms for resources and the corresponding response-request cycles, which has allowed banks to bring new integrations and features to market faster and easier. Plus, it’s less miserable for developers, which means more are willing to do the heavy lifting of integrations.
With a growing API ecosystem, banks can tap into external innovation through data and logic exposed through open APIs to develop new service solutions and improve the customer experience, customer loyalty and wallet share.
Open banking model expedites a bank’s ability to respond to market conditions and allows for the rapid industrialization and implementation of newly developed service solutions. It also introduces banks to potential future acquisition targets and gives them the ability to measure synergies up close and personal. This begins with:
- Tactical API gateway built on existing technology stack.
- Utilization of multiple API management vendor capabilities.
- Low investment and short time frame.
As adoption evolves, an API management platform and a basic API portal are established. Business-prioritized
systems and use cases are then exposed, which mandate moderate integration of core systems and more investment.
Controlling the data handshake is essential
Open banking also exposes banks to risk, including loss of control over customer engagements, consumer base fragmentation and the erosion of bank-led product innovation. Banks need to manage such outcomes to achieve their business objectives. Chief among these concerns is the protection and separation of consumer data. Banks should include a legitimate purposes test in their partnership agreements so that they know how third parties intend to use their customer data and that such uses are limited to what consumers would reasonably expect given the type of product or service being offered.
Later, customers need to be informed of these legitimate purposes through clear, concise information screens—or consent agreements—rather than an opaque, potentially all-encompassing, terms and conditions agreement. Tiered access to consumer data is absolutely essential to ensuring that only the right people access the right data points, for the right individuals, at the right moment. Without this, the potential for error and evil is exponential.
Central to the API experience and ensuring the protection of customers and data is creating and an experience of trust. From our experience, there are three ways to build trust in the API environment:
- Active consent: Clear, concise definitions and permissions to end-users, that is, customers, about what kinds of data they will be allowing access to, in what ways or formats, and for what use.
- Layers of authentication: On the developer side, clear steps and permissions for different users and levels of access and information.
- Refined time constraints: Removing open-ended access and “remember user” shortcuts to reduce the possibility of easy access through endpoint theft or access.
For an example of consent practice, look no further than UK challenger bank Starling Bank and its partnership with Yolt, a financial management app. When a Starling Bank customer links their account to Yolt via the company’s app, Starling then clearly explains to the customer what data and level of account access they will be sharing with Yolt, and the customer must authorize an agreement. The customer can then revoke access at any time through the Starling app.
Starling could take it to the next step by making consent could be time-bound, with consent reminders every 6–12 months, to ensure they understand what data and account access they are sharing. Customers should be able to revoke consent at any time. Google displays all the consent agreements in a customer’s account dashboard with the ability to revoke access to any application. As mentioned, having a defined time period of access with reminders and requests for renewed consent is another option.
Show the way and light the path with effective documentation
A well-documented API improves the developer experience, accelerates the integration process, and bolsters both the bank and the service's reputation. The process cannot be reduced to basic HTML pages of descriptions and outcomes. It is vital to provide a visual and interactive experience that allows developers to directly try out the various functions to assess their appropriateness for their needs.
API Blueprint, based on Markdown, is a simple language for marking up documents in plain text which can then be converted to HTML and other formats. It is both easy enough to understand on sight but also expands to meet the broader need. Additional possibilities include RAML (RESTful API Modelling Language), IO Docs and Slate. The latter tool, open source and Markdown-based, offers user-friendly results often concentrated to a single page of content.
Some examples of effective documentation include: