What kind of business benefits could be achieved if all of the existing API technologies were harnessed to their fullest potential? Also, in that case, what type of architecture would this entail? Figure 1 is a compilation of the best API practices through 2017. One can identify different kinds of API:
- System Integration API: in addition to driving the enterprise application integration at banks among system designers and developers, this also offers a platform for the Open API Developer Portal;
- Connectivity API: control of exclusive connections for bank customers naturally eliminates various constraints regarding conventional external connection services, (such as data, process, service time, etc.);
- Banking Platform API: providing open connectivity platforms for electronic settlement agency services and digital neobanks, depending on bank initiatives, should be viewed as a potential area of financial services offerings to external businesses and a B2B system platform infrastructure;
- Innovation API: the outlook for open innovation platforms emerges from these APIs, primarily centering on banks and a financial services ecosystem and new value chain that combine the flow of goods, business, and money. Presumably, this will form the foundation for creating new partners.
Open API Method and Its Advantage
A user acquires data from the information system of a financial institution by sending a command to an API created and opened by a financial institution using the Third Party Provider’s (TPP) dedicated app or executes a process based on instructions sent to the system, such as payment instructions.
API system-related characteristics or traits
Development burden for financial institutions: under the API method, financial institutions need to modify their information systems so that they can be accessed externally via the API. In the global market, there are many tools available to assist with building out APIs for legacy systems.
Development burden for TPPs: with the API method, it is sometimes necessary to develop information systems and dedicated applications so that TPPs can cope with different APIs at each financial institution. However, once that is done, as long as the API is not changed, the burden for updating the program is limited. In general, the frequency of change for API is regarded as being lower than the change frequency of the URLs. As a result, the API method can have a lighter long-term burden for participants than the web-scraping method.
Obtainable data: with the API method, systematically, there is no need to limit the data to be provided within a website. Because of this, the user can acquire the data, even the data that is not provided on the website, via the TPPs dedicated application. In such a case or arrangement, obtainable data that the user has agreed to allow to be provided is provided by the financial institution via the API. (On financial regulation, there are limits to what data a bank makes available via an API. For example, in the UK, banks only have to make 6 APIs available to be in compliance.)
Data communications burden: under the API method, since it is possible to obtain only the data necessary to provide a service from financial institutions, the burden of data communication between TPPs and financial institutions is reduced.
Business Advantage of API Method
Account information: with the API approach, without the need to use account information such as ID and password, a predetermined and limited scope of account data can be accessed using the token issued to TPPs by the bank.
Management responsibility: with the API approach (figure 2), banks issue trustworthy and authorized TPPs tokens that grant them access to a predetermined scope of account information.
Maintenance costs: with the API approach, access is granted on the basis of token authentication, resulting in minimum modifications being needed to program on the TPP side when there are changes to specifications of bank users.
Access restrictions: user or bank authorization can be used to limit access. Accessible data is not limited to the scope of data provided such as through Internet banking.
Open API Opportunities and Threats
In the global market, open APIs and open-API banking have already reached the implementation stage. Looking to shed more light on where the market stands today, we conducted the SWOT analysis (Strengths, Weaknesses, Opportunities, and Threats – figure 3) while considering the initiatives of early movers in the market and recognizing that Japan’s market is nascent.
Open API Opportunities
A Customer-Centric (Customer-Data-Centric) Approach
The new system clearly delineates between the TPPs, which are entrusted with depositor account information and transmitting instructions for fund transfers, and banks, which hold customer information and depositor account information and are responsible for managing this information.
Regulations have been placed on using the so-called scraping method to acquire and use depositor customer information and account information to access accounts. TPPs will only be able to access customer information and account information through a process of token authentication.
Under this approach, TPPs approved by customers and assessed and authorized by banks will be issued a token from the bank for access to a predetermined and limited scope of customer information and account information. This once again establishes banks as the sole entity responsible for managing relationships with customers and gives them priority in doing so.
Japan’s financial services have entered a new phase with the customer – and customer data – firmly at its center. This development is an opportunity for banks to act to build new customer relationships.
External Collaboration: B2B and the Platform Business
At the same time, depending on the framework, APIs can also serve as B2B products; expectations are that API platforms will evolve from merely being a means to offering new services to fusing finance and IT to become innovation platforms.
It is imperative that regulations for the new system pave the way to implement information systems that enable banks the external access necessary for conducting API authentication access via tokens while adopting an approach that establishes an optimized ecosystem for financial services and payment services.
This will serve as the launching pad to major business opportunities that will translate into open API business models (figure 4). Through external connections and collaboration, open APIs portend B2B revenue opportunities and offer an avenue to creating platform businesses.
Financial institutions have the choice of complying by meeting the bare minimum of regulatory API authentication (i.e., minimizing developer involvement, and limiting the API to function with a scope of customer experience unchanged from conventional practices) and consequently limiting potential revenue opportunities; they also have the choice of embracing the challenge of establishing an advanced API platform (maximizing the involvement of developers with the aim of creating an API that generates new value with functions that offer a better customer experience) in line with the wishes of external developers, including TPPs.
A variety of models are available, and which approach is preferable depends on the situation. Models range from pay-as-you-go, subscriptions, and freemium approaches to charging for premium services, value-added proportional distribution, and white-label models for efficiency and shortening time to market. Which to choose depends the existing dynamics of relationships pertaining to cocreation and competition, the provided service content, the value chain, and more.
Open API Threats
Security Measures and User Protection
From a systems perspective, open APIs mean that a new communications path is being established to link the information systems of financial institutions with the outside world. This brings new risks including data leaks, data fraud, and illicit transactions. There is also the possibility that data relating to user account information and settlement instructions will be exposed to the risks of leaks, tampering, and fraud via handling by TPPs.
First and foremost, when financial institutions open up their APIs to TPPs, the fundamental system risk relates to the reliability of information regarding user (bank customer) identity verification and the account as well as account-related instructions. Today, financial institutions face an intractable problem when it comes to their information systems: how to ensure that they can correctly determine that authentication and account instructions are genuine.
Fundamentally, the security risk is that a TPP makes an error, and the bank is held responsible, either by regulators or customers.
In the case of Japan, the Japanese Bankers Association’s Review Committee Report on APIs details the fundamental principles of user protection and security measures. Regarding security measures, the report calls for continuous improvement, review, and advancements in the following areas:
- API connection suitability and eligibility of third parties;
- Measures to prevent unauthorized external access;
- Measures to prevent unauthorized internal access;
- Measures to handle incidents of unauthorized access.
Strategic Alignment of Risk Awareness, Tolerance, and Positioning
New business environments always come with potential upsides and downsides. The flip side of a business opportunity is that it can be accompanied by unexpected pitfalls. In planning the “migration” plan to the “new world” of open APIs, Celent believes that it is key to find a risk tolerance level suitable for your company, optimize positioning in the value chain, and strategically align your company’s core competencies and existing assets.
In particular, consistency and alignment between core banking systems and authentication platforms, including core internal and external system APIs, might best be metaphorically regarded as an engine powering your company on the long road from open APIs to open API banking (figure 5).
New Competition from Nimble Third Parties Who Access Customer Data
It might seem as though vertical division of labor and horizontal disintegration have already proliferated enough. But new financial service providers that are not the traditional financial institution are deftly using new technologies to engage customers, and to secure a new customer base with products and services across financial infrastructure segments, and, in the process of doing so, forming a new community around these activities.
In the competitive environment of the new financial services industry, opportunities for traditional financial product service operators will erode as TPPs (distributors and new service providers) deprive them of opportunities to engage in dialogue with customers.
That involves more than the temporary deterioration of the revenue environment for traditional financial institutions. It also includes the risk of losing future business opportunities due to changing customer needs and the loss of core customers.
Open API is Just the Beginning
Presumably, open APIs will accelerate the modularization and decoupling of products and sales in the banking industry (figure 6). This may enable banks to focus on and pursue greater specialization in their original and core operational areas (deposits, lending, financing, currency exchange) with peripheral services being unbundled and possibly assumed by entities such as financial services providers. In this way, through open APIs, such services may be established as independent new service businesses.
There is a high possibility that banks can generate independent revenue-earning opportunities with their current bundling of services, which typically include account opening, inquiries, transfer services, payments/fund transfers, PFM/household finances management/financial management, investment management/robot advisors/wealth management, consumer loans, business loans, insurance sales/securities sales, and BPO (business processing outsourcing).
By providing open APIs to TPPs, it may be possible for banks to generate B2B commission fees and to parlay this into a revenue source. Will TPPs go beyond the framework of bank agencies and form new value chains with users, other business types, and other industries? Can banks continue to be the center of new value chains and new communities? Looked at from one perspective, open APIs are merely an opportunity for restructuring the financial value chain and reorganizing the industry.
