No results found

Your search did not match any results.

We suggest you try the following to help find what you’re looking for:

  • Check the spelling of your keyword search.
  • Use synonyms for the keyword you typed, for example, try “application” instead of “software.”
  • Try one of the popular searches shown below.
  • Start a new search.
Trending Questions
 

Building Better Banks: 3 Critical Considerations to Opening the Bank

Building Better Banks: 3 Critical Considerations to Opening the Bank

With the rapid emergence of feature parity among bank technology vendors, it is easy for banks to take on a copycat approach to digital innovation. What is seen as a differentiator in the conference room is often a “so what?” for customers on the street. Features are not core competencies and chasing the latest digital add-on only commoditizes banking.

Avoiding the pitfalls of “we have it, too” digitalization requires embracing the possibilities of open source. When we say open source—long dismissed as buggy code and half-baked design—we mean open banking.

There is no shortage of case studies showing the potential and power of open banking, but even after years of normalization, fear of the new has stalled wide adoption in most regions.

Banks can only grow so far within a walled garden and opening up their core and customer data to innovation requires careful planning and forethought. Oracle outlines a framework for success when banks embrace open banking.

The 3 Critical Considerations

1

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.

2

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.

3

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:

Build Better—With Oracle Digital Banking

You can copy, you can add, you can say “we have it, too”—but true differentiation in digital banking requires bigger thinking, better planning and the best technology partners. And, as you most likely know, with fewer partners comes less complexity and mismanagement.

With Oracle Digital Banking, banks can go beyond simple data-driven transactions to interact, engage and share a moment with their customers. Become a moment-driven bank with a singular platform and provider that liberates your business from inefficient, sluggish, and fragmented silos and a “walled garden” mentality.

Oracle’s integrated data access brings richer insights and the ability to anticipate and contextually align services and offers to your customer’s life stage, needs and specific circumstances.

The truth is: The leading banks of tomorrow will either be or become technology companies. Embracing open banking is no longer a faraway possibility.

Related Products and Solutions

  • Digital Banking

    Omni channel customer experience solution powered by a next-generation API framework.

  • Retail Banking

    Deliver customized product recommendations and services in the digital environment.