Open API in Hong Kong

The Hong Kong Monetary Authority released the Consultation Paper on Open API Framework for the Hong Kong Banking Sector on 11 January 2018 (the ‘Open API Paper’). The public consultation period finishes on 15 March 2018.


In September 2017, HKMA chief executive Mr Norman Chan announced a number of smart banking initiatives. The Open API Paper has been released pursuant to that announcement – but there is a massive backdrop of momentum internationally for this area.   


What does Open API involve, and what does the Open API Paper point to for the future of fintech in Hong Kong?


  1. What is Open Banking?

What is Open Banking?

“Open API” references Hong Kong’s version of Open Banking.

Broadly speaking, “Open Banking” efforts encourage or mandate financial institutions (usually retail banks at first) to release their data in a secure, standardised manner – so that it can be shared more easily with third party service providers (‘TSPs’) that have been authorised to access the data by the relevant financial institution and/or end user. These TSPs are frequently start-ups or other non-traditional providers of financial services – who are aiming to provide specialised banking services to end users, with the goals of lower costs of banking services (eg lower overdraft fees, less switching costs) and greater competitiveness in the industry.

The shared data may be:

  • simple and/or publicly available – e.g. bank branch locations, details of bank products; or
  • complex and/or private – e.g. end user’s account transactions and history with the bank.

This sharing is typically done via application programming interfaces (‘API’) – i.e. software protocols that allow data to transfer between different systems in a standardised manner.


  1. Increasing international momentum for Open Banking

Open Banking is gaining popularity across different places in the world. In particular:

Regulatory / national efforts

  • European Union - has updated its Payment Services Directive (“PSD2”) for Open Banking-related rules.
  • UK - the Competition and Markets Authority (‘CMA’) has mandated Open Banking for the UK’s nine biggest retail banks – this has come into force on 13 January 2018.
  • Singapore – the Monetary Authority of Singapore and the Association of Banks in Singapore published the “Finance-as-a-Service: API Playbook” in November 2016 – identifying APIs that are available to banks, insurers, asset management companies and government agencies.
  • Australia – the Reserve Bank released its final Open Banking review report in 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.


More generally - while jurisdictions differ in their objectives, many regulators are looking to drive “fintech” and be more competitive against  “competing” jurisdictions. Lowering entry barriers and allowing non-traditional players to be involved is a key part of this drive. 


Banks pushing ahead with releasing data via APIs

Certain banks have released some previously proprietary data via secure APIs – recognising an opportunity to “get ahead of the curve” and work with new market entrants. For example:


  • Citibank launched its Open API portal in Hong Kong in March 2017 – making available 30 APIs across seven categories.
  • DBS launched its Open API portal in November 2017 – making available 155 APIs for Singapore across 20 categories.


End users’ increasing expectations

End users have increasing expectations of their relationship with banks:


  • Fintech efforts – particularly with payment technologies and data usage across different platforms – have taken off in China and across Asia, leading to increased expectations regarding user experience.
  • End users increasingly recognise that their data with banks have real value, and should belong to them (and be portable to anywhere they wish). Increasing recognition of data privacy has played a key role in this development.


Tech companies investing in fintech

Technology companies have shown keen interest in disrupting financial services – and seeing fintech, and particularly payment services, as being key driver in driving greater engagement and monetisation amongst its end users – leading to an expansion of its platform across different sectors. Tencent in China (with WeChat Pay) is a prime example of a company who is using payment services to drive adoption of and engagement with their wider platform and services.  Open Banking will help drive disruptive services by tech companies in the long run.




  1. The Open API Paper

It is against such background that the HKMA launched its proposed Open API framework (‘Open API’) via the consultation paper, welcoming responses from both the banking and technology industries.

The Paper’s highlights and issues include the following:

  • Current readiness of banks in relation to Open API. Between July and October 2017, the HKMA consulted 20 domestic banks and three international banks regarding Open API.

The HKMA found, following such consultation, that:

The technology and business readiness of banks for deploying API in Hong Kong was found to vary widely from “already launched Open API” to “without any concrete plan”. Among the banks met, only one launched Open API for external parties to use, three deployed API for internal use, nine planned road map for implementation or were working on API developments, and ten were without a concrete plan.”

  • The HKMA’s objectives for Open API. HKMA lists three goals:
  • ensure the competitiveness of the banking sector;
  • encourage more parties to provide innovative/integrated services that improve customer experience; and
  • keep up with worldwide development on delivery of banking services.
  • Target scope. Open API will only apply to retail banks in Hong Kong.
  • Proposed timetable. The HKMA has proposed an aggressive timetable for implementing Open API.



Information category

Expected timeline from the release of Open API


Product and service information – i.e. access to frequently-used bank product information, on a "read only" basis – e.g. allowing TSPs to compare products between different banks.

Six months


New applications for product/service – allowing TSPs to conduct customer acquisition activities, e.g. allowing online submission/application of credit cards, loans or certain insurance products.

12 months


Account information – allowing TSPs to retrieve and (if applicable) amend account information (balance, transaction history, limits, payment schedules, etc.) of authenticated end users for stand-alone or aggregated views.

To be reviewed Q4 2018


Transactions – allowing TSPs to conduct payment (or scheduled payment/transfer) transactions by end users.

To be reviewed Q4 2018


  • Recommended API functions.  The Paper recommends high-level API functions – “in order to allow flexibility for banks to develop services that best fit their offering, business priority and existing business/technology plan”. While banks will be “expected” to offer functions consistent with phases 1 and 2’s proposed functions, they will not be mandated to offer any specific functions.  
  • Technical standards and data. Similarly, the Paper recommends certain architecture, security and data standards, with reference to international standards and market practice. The HKMA recognises that data standards will likely to be more difficult to mandate compared to the first two areas. The HKMA does not propose using a central body to build the APIs to be used.
  • How will TSPs be certified and regulated? The Paper envisages that banks will lead Open API efforts, and any engagement with TSPs will be within the banks’ individual risk management framework and business objectives. The HKMA does not propose that it will take up a central role – e.g. by certifying third parties or setting standard rules of engagement.

The Paper acknowledges that banks recognise having a central entity certifying TSPs’ access may be beneficial, and suggests that banks may fund a central certification entity as Open API matures.

The above is in contrast to the approach from the UK’s CMA , who has taken a leading role in mandating regulatory and technical standards for banks and TSPs to operate.


  1. Legal-related issues to be resolved

The Paper does not specifically address various issues that may be of interest to lawyers and other industry players. In both Australia and the UK’s equivalent consultation processes, there were diverse views from the market, depending on the party’s position in the ecosystem.

  • Responsibility for data usage and transfer, and liability for data breaches between data transferor and data recipients. For example – if TSPs are required to have insurance in order to access Open API, will that affect smaller startups – or will there be a central authority (and central insurance scheme)? If there is a data breach, what is the extent of the data transferor’s responsibility for such breach?   
  • Customer’s consent. In Open Banking, customer’s consent is an essential requirement for permitting TSPs to access end users' data – there will be no data transfer without such authorisation.

How will customer consent be granted and revoked, and whether banks or third parties will control the consent and on-boarding process? On which platform will the process originate and end? Who is responsible for drafting the consents? How long will consents last for and how broad the scope can they be, will they be service-specific? Who will control the consistency of consents between data transferor and data recipients? How will consents be linked to liability, given consumers may at early stages of Open API be more likely to blame banks? Questions like these are to be considered.

There has already been public concerns in the UK regarding a lack of education to end users in relation to how consents are obtained and how Open Banking will benefit the public.

  • Personal data and privacy. How will data under Open API framework interrelate with existing data privacy laws? Is such data proprietary or personal data?  
  • How data will be accessed. Can banks charge for data access, and will there be transparency regarding who pays and how those fees are calculated? What will be the licensing terms? This is particularly pertinent if (as the HKMA suggests) banks are directly engaging with TSPs, on non-standard terms.
  • Resolution of customer complaints. At present, the HKMA has not proposed a central body for resolving complaints. Will banks be responsible for handling complaints on a per-bank basis?
  • Right to “read-only” vs “writing” data. When will TSPs be granted access to each? It is likely the latter will require specific authorisation and terms, given increased data security risk.
  • Control of data. How will users be able to, in real time, control what data comes and goes, grant and revoke consents; and how this relates to data categorisation design?
  • User education. How will users be encouraged to trust and use an Open API framework, in order to encourage further competition and new market entrants?


  1.  Summary

The Open API consultation paper represents a massive positive step for Hong Kong fintech – Hong Kong is one of the first jurisdictions to engage the industry players in a consultation. It demonstrates the HKMA as a progressive regulator that is interested in collecting feedback from both the banking and technology industry.

The HKMA seems to be aiming for a rapid implementation of phases 1 and 2 – which contain information that involve lower risks for banks to distribute, and therefore less need for developing new regulations/supervisory mechanisms.

There is less detail around phases 3 and 4 – i.e. the transfer of complex or private data. While the HKMA is requiring banks to adopt the finalised Open API, it also states that “a broad framework with high-level objectives is therefore proposed so that banks can exercise flexibility on the implementation details and decide on the schedule in light of the proposed time frame”. 

Open API will likely to both create ample opportunities for  and disrupt the banking industry. From end users' point of view, Open API can encourage development of new services such as:  

  • artificial intelligence-enhanced financial advisors,
  • online only financial services,
  • easier/more transparent switching between banking providers,
  • one-click/direct message payments in shopping services, social media platforms or messaging services,
  • personalised price comparison services – making personal recommendations to customers in terms of alternative current accounts or overdrafts based on a customer's actual spending behaviour, and
  • money manager services, where a customer can view their transaction history from multiple current accounts (held with different banks) in a single app.

Throughout the paper, the HKMA emphasises that Open API will be an industry-led effort – notably, the role of TSPs, allocation of risks and liability, and the role of banks as “gatekeepers” (with the HKMA not suggesting itself as a central authority for this) are to be determined. Given the issues to be resolved and the natural tension between incumbents and new players – it remains to be seen how Open API will develop in Hong Kong (and HKMA’s role in this). No doubt this consultation process will iron out some of the issues at play.

Major digital transformations such as Open API are not easy, with major technical, commercial and legal challenges to be navigated. 

Nevertheless, Open API has the potential to revolutionise retail banking and be a key piece to Hong Kong’s push for international fintech leadership.


Counsel, Ashurst