1. Hong Kong, Open API, and Open Banking: the stakes.

The stakes behind the launch of an Open source API Framework in Hong Kong are high. Beyond the technical term, Open APIs are about encouraging and further facilitating the offer of financial services to the public by making a variety of banking data accessible to financial services providers and innovators. App makers and financial facilitators, in sum.

Open API as a source of financial diversification for Hong Kong.

Long things short, Open API system and open banking will permit procedural simplifications by cross-referencing databases.

While banks normally hold extremely confidential the information provided by their users, creating data bridges between banks and Third party Service Providers (TSPs) according to a set of known and standardized rules will create a new range of possibilities. Data would be accessible more easily. And the ability of consumers to access new services and applications would increase.

For instance, wealth management apps could be connected to our personal finances. Alternatively, personal finance management apps would gain easier access to our various bank accounts. In both cases, of course, the new services would be made available without creating a burden on the end-user, because the APIs would do the work.

Publically available data (bank branch information, financial products details) would be easily accessible through standardized databases. Private data (personal transaction, banking history, etc.) would still be stored by the financial institutions, of course, but they would also be made available to a list of certified Third-party Service Providers (TSPs) authorized to plug into the banks’ databases to extract selected information. The third-party would therefore have the possibility to offer a set of services to the client depending on the set of available information. In turn, the end-user would gain access to a new range of services (in the form of apps) which so far had remained locked-out.

Open APIs are already there.

Examples of such services can already be found on the market. Logging-into our favorite websites using our Gmail or Facebook accounts is very common. Numerous hotel and flight booking apps and websites already access the databases of flight companies and hotels to offer the best deals to their clients.

In the case of open banking, the difference would be that the data relied upon originates from banks. Instead of comparing hotels, consumers would compare permanently updated banking products. Or they would manage multiple bank accounts from a single app.

In Hong Kong, for instance, Citibank has announced in 2017 that six API partnerships had been signed to “enhance consumers’ banking and transactional experience with ease and freedom’ by making available “easy and speedy banking services in response to consumers’ increasingly digital lifestyle”. The applications are diverse, but they will allow City clients to pay with their credit card reward points on online shopping platforms, or to reduce the time required to make a Financial Needs Analysis when the clients apply for financial products with the AIA insurance company. Collaboration is also announced in relation to the widely used Octopus card, including instant top-ups. In sum, the range of possibilities is wide.

Hong Kong urgently needing an Open API and open banking framework?

Generally speaking, however, Hong Kong is not very advanced when it comes to API and open banking developments.

The previously mentioned examples are used here and then for illustrative purposes but otherwise, commentators generally describe Hong Kong as the lagging-behind city. When assessing industry readiness, in fact, the HKMA notes a significant disparity between banks. Some have already launched open infrastructures – mainly for internal use – whilst others have no plans at the moment.

As a result, potential developments happening in relation to the HKMA’s Open API Framework could have a positive impact on Hong Kong’s increasingly digital economy. By creating converging standards, more cross-bank and cross-app services could be developed. App developers would have an incentive to propose innovative solutions. And consumers would benefit from additional services provided that the service providers conform to the standards. The question is… how?

The HKMA’s open Banking and Open API Framework.

The open banking and Open API Framework is the HKMA’s solution to the problem.

After setting up a virtual banking regulation over the summer, the Hong Kong regulator now turns to create a specific framework for facilitating API developments.

The move is obviously part of the various efforts conducted by the HKMA to turn Hong Kong into a regional Fintech Hub. The idea of developing open banking and Open API systems was indeed discussed last summer as part of the FSDC Report on the Future of Fintech in Hong Kong and it is clearly a strategic element in Hong Kong’s financial leadership competition with Singapore.

As far as the HKMA is concerned, the role of the Open API framework is threefold:

1. to “ensure the competitiveness and relevance of the banking sector”;
2. to “provide a secure, controlled and convenient operating environment to allow banks and their partners, to work together and develop innovative/integrated banking services that improve customer experience”; and
3. to “keep up with worldwide development on delivery of banking services”.

To achieve the attended results, the HKMA has therefore defined an Open API Framework built on five pillars:

1. Functions and deployment timeframe;
2. Technical standards on architecture, security and data;
3. TSP governance model;
4. Facilitation measures;
5. Ongoing development (or how Hong Kong is doing compared to the competitors).

Open API Framework: The key takes.

The Open API Framework is explained very comprehensively in the full analysis of the API Framework which can be downloaded with the following link. Otherwise, the key takes can be summarised as follows.

Convergence on API functions but no standardization.

The consultation process pointed to a consensus on the idea that a form of standardization is necessary ‘for better interoperability”. In its January document, in fact, the HKMA noted that twenty-one out of twenty-three banks supported the idea of creating standardised – as in “exactly the same” – API protocols among banks “so that third party service providers (TSP) only need to develop their software once” and allow connecting “all banks without the need for further customisation”.

Nonetheless, the Open API Framework will focus on convergence rather than standardization. First, standardization methods putting constraints on the banks would go against the efforts already put into place by several of them. Second, opinions emanating from the technology participants suggested that to “quickly offer” Open APIs made more sense than waiting for new Open APIs to be made on the basis of not-yet-designed standards. Third, the participants also agreed that standardization would likely occur as an answer to market needs over time.

Open API Framework: Categories defined.

The HKMA has also developed “a set of high-level Open API functions” to answer the participants’ conclusion that it would be necessary to “categorise” and “prioritise” the types of APIs to be implemented in the future. The proposition is in line with the ‘no standardization’ decision and flexibility appears to be the main objective. However, the participating banks remain free to adopt those recommendations (and to implement theirs) as they deem fit.

Hence, four categories of frequently-used Open APIs have been identified, each requiring its own level of security systems:

Phase 1: Product and service information – also described as “Read-only” data provided by banks to detail their products and services;

Phase 2: Subscription and new applications for product/service – data which facilitate the customer acquisition process by allowing online submissions/application of credit cards, loans or other bank products;

Phase 3: Account information data – private data required for the retrieval and alteration of account information of authenticated customers (balance, transaction history, limits, payment schedules, etc.);

Phase 4: Transactions data – Banking transactions and payment or scheduled payments/transfer initiated by authenticated customers

Open API Framework: prioritization.

The four categories were defined taking into account several factors, including the usage frequency of the data and their importance, to encourage the implementation of the more obvious Open APIs first. Eventually, focusing on the most common Open APIs also means that the operators will have more time to put research and development efforts into place, thus increasing security for the release of more sensible APIs.

As a result, the HKMA has set up a timeline for the implementation of the Framework, as well as a roadmap for the use of technical standards on architecture, security, and data – explained in detail in the full analysis available in .pdf here:

Open API Framework: Third party Service Providers (TSP) certification

The third – and major – aspect of Hong Kong’s Open API Framework relates to the certification of Open API Third-party Service (TSP) providers. The objective is obvious here, i.e. ensure that the providers who are given access to bank data are subjected to a form of TSP certification in terms of due diligence, monitoring, and contractual engagement.

A new ‘TSP governance’ burden.

The format of the certification scheme has been the object of discussions. Under the January document, the HKMA noted that the participants asked for a central entity acting as a TSP certification body. In its final Open API Framework document, however, it wrote that “in order to strike a balance between innovation and customer protection, it is preferred that TSPs offer solutions under a partnership arrangement with banks”.

Hence, instead of a central certification body the HKMA is creating a burden of “TSP governance [covering] activities such as due diligence, onboarding, control, monitoring, roles and responsibilities, consumer protection, data protection, security, infrastructure resilience, and incident handling”, that banks will have to deal with.

The move is justified by its ability to provide “maximum flexibility” and the banks are given wiggle room to establish and agree on “common baselines” regarding assessment benchmarks and onboarding checks. They are also left responsible for selecting the TSPs depending on their own standards and risk evaluation requirements, even though the possibility to conduct common proceedings is also made available. In other words, Open API Governance is likely to fall on the banks themselves.

For more information on what the regulator “expects” from banks, see the full analysis of the OpenAPI Framework.

The Hong Kong Open API Framework following an international trend.

It is interesting to note that the HKMA’s Open API Framework compares Hong Kong to the other Open API initiatives internationally. As mentioned previously, some of the needed standards insist on the necessity to operate in line with these initiatives to encourage a broader compatibility and use of Open APIs. Other than that, the regulator also uses a comparison with other jurisdictions to promote its own Framework.

UK, EU, Japan, and Australia.

In the UK, the HKMA notes that an Open Banking initiative has been put into place by the Competition and Markets Authority since 2016, with framework extensions since late 2017 to enable banking connection with credit cards, e-wallets, and prepaid cards. There, however, an ‘implementation entity’ has been created to ‘whitelist’ TSPs before they are given access to the banks’ data.

In Europe, the PSD2 framework is described as “the legal foundation for the further development of a better integrated internal market for electronic payments within the EU” and, whilst it does not mention Open API, “seeks to require banks to grant third party providers access to a customer’s online account/payment services in a regulated and secure way”.

As far as Australia is concerned, the HKMA notes that the Australian Reserve Bank only recently released its final Open Banking review report (February 2018), “making 50 recommendations on the regulatory framework, the type of banking data in scope, privacy and security safeguards for banking customers, the data transfer mechanism and implementation issues”.

Following an amendment to the Japanese Banking Act in May 2017, the HKMA noted in January that Japanese banks would be “required to announce support on Open APIs by March 2018 and have it deployed by middle of 2020”. It noted, also, that “banks and TSP would need to refine or agree on the actual function and control measure during implementation”. In Japan, however, the scope of application of the Open API Framework is expected to be much narrower than in Hong Kong as it would only cover deposit-related activities in account balance inquiries, account activity inquiries, and interbank transfers.

Singapore far ahead.

In contrast, the HKMA notes that Singapore appears to be far ahead of the Open API competition. A ‘Finance-as-a-Service: API Playbook’ was released in November 2016 by the Monetary Authority of Singapore (MAS) and the Association of Banks. It identified and categorized more than 400 APIs covering various financial actors including insurance, asset managers and even governmental agencies. It is emphasized, however, that the Playbook does not cover topics such as TSP certification and ecosystem development or maintenance. An API exchange (APEX) has also been developed last year.

Since the introduction of the PlayBook in 2016, Singapore has embraced and developed API based solutions. In late 2017, the Government Technology of Singapore built an API exchange (APEX) to serve as a centralised data sharing platform. Government agencies across Singapore can utilise APEX to share data securely in real-time through the use of APIs.

How HK positions itself, with what impacts.

Hence, while Hong Kong is compared to an innovation turtle by some Fintech commentators, the HKMA positions itself as one of the few and promising frameworks supporting the development of Open APIs.

A liberal financial place welcoming Open APIs and Open Banking.

On the one hand, the regulator promotes Hong Kong as a looking-forward financial place. Simply put, the regulator insists that Hong Kong’s Open API Framework is more comprehensive than that of Singapore and it dissociates itself from “the mandatory approach” adopted in the EU, the UK, and Australia.

Instead, it promotes Hong Kong as a liberal financial place in which “flexibility in implementing Open API” is aimed at supporting the banks’ business strategies, where the priorities “have been selected on the basis of their potential benefits to banks and customers”, and where “existing international or industry practices have been leveraged”.

The Open API Framework creating a heavy regulatory burden?

On the other hand, flexibility for market efficiency purposes comes at a price called ‘TSP governance’ for the banks.

Empowerment with numerous expectations.

The HKMA talks about empowering the banks to ensure the “speedy” implementation of the framework, but reading the documents leads to conclusions that most commentators have missed. As emphasized several times in this Insight, however, the HKMA also “expects” banks to put a variety of systems into place.

While the preliminary document from January suggests that the participating banks asked for a TSP Certification central body, the regulator has opted TSP certification by the banks themselves. The banks must appoint “their own accessors to carry out the common baseline assessment for them”. They must ensure that their systems do not create “barriers to entry”, which means that they also ought to implement the fair competition dimension of the Framework.

Regulation through private contracts?

The Open API framework also creates a burden on the banks to ensure that the TSPs’ use of the data is in line with consumer protection law… which somehow implies that contracts between the banks and the TSPs could substitute to a non-existent regulatory framework on the matter.

Indeed, the banks “should negotiate bilaterally with TSPs on commercial contracts in addition to the TSP onboarding assessment and ongoing monitoring”, and “there should be a risk-based ongoing monitoring mechanism for banks to ensure that TSPs continue to meet the relevant parts of the common baseline”. Finally, the Open API Framework is clear in stating that the banks are responsible for monitoring the internet against scams.

Hence, whilst the preliminary document insisted that it would be necessary to develop a set of governance measures such as due diligence, onboarding, control, monitoring, roles and responsibilities, consumer protection, data protection, security, resilience incident handling… burden in on the banks to make it happen.

The Open API Framework creating a financial burden too?

The Open API Framework also suggests that the banks could have to support a significant financial burden, if only because the provenance of funds from one app to another will complexify financial transactions. As a result, and in line with the Code of Banking Practice, customers should not be responsible and refunds should be made whenever necessary. In other words? The risk could remain on the banks, and might very well depend on the commercial agreements they will be able to craft with the third party operators. Of course, such agreements can be negotiated.

Market access risks for TSPs?

Another risk could be mentioned, i.e. that of an unleveled playing field from the perspective or competition.

The Open API Framework seeks to facilitate the development of Hong Kong’s Fintech and financial services industry, but some of the participants have “expressed concerns about the potentially large investment in building an API infrastructure as to whether there would be clear business and/or use cases to justify the investment.

There is a strong case for an increase in business opportunities with, in particular, the possibility to create bridges between retail banking and private banking as increasingly developed by Saxo bank for instance (Citywire). In fact, banks such as DBS or Citi have already opened dedicated API platforms and sandbox to this extent (see here for more examples). At the same time, all banks are not equipped with such technologies. Hence, the Open API Framework could widen the gap between tech-rich banks and the others.

As noted by the Hong Kong Fintech Association, however, “a key aspect of co-opetition is to establish ‘the line’ above which parties fiercely compete and below which they cooperate and collaborate’. Hence, some TSPs have already expressed concerns. In such circumstances, the risk would be to witness a sort of abuse of dominant position. Hence, whilst the Framework opens the market to TSPs at first sight, some regulatory risk remains.

Bottom Line

To conclude, the Open API Framework elaborated by the HKMA presents significant opportunities for the banking and financial sector in Hong Kong. The regulator insists that flexibility and rapid delivery are the key, and Hong Kong’s Framework is overall presented as more business-friendly than that of the competing jurisdiction.

However, the framework appears to impose a very significant burden on the banks, which will eventually have to implement it themselves. This, in turn, is likely to create costs, potential tensions in terms of competition, and a significant regulatory risk for the implementing players.

>> Related Insight: Virtual banks in Hong Kong: HKMA Guideline seeks Smart Virtual Banking.

>> Related reading: Fintech Talks, our Asia-Pacific Fintech Insights.