Hong Kong Enters New Era Of Smart Banking With Launch Of Open API Framework

Late last week, the HKMA announced that it had concluded a consultation on its intended approach to open application programming interface (API) for the Hong Kong banking sector, and had published its final framework and implementation plan.

 

The open API is one of seven initiatives announced by the HKMA in September 2017 to bring Hong Kong into a “new era of smart banking”. Brief details of the consultation can be found in our briefing of February 2018.

 

The framework focuses at this stage on retail banking, but banks are welcome to extend the framework to other banking businesses as they consider appropriate.

 

The HKMA expects banks to deploy the framework in four phases:

 

Phase I (product and service information): within 6 months of the publication of the framework (ie, 18 July 2018) – by mid-January 2019;

 

Phase II (subscription and new applications for products/services): within 12 to 15 months of 18 July 2018 – by mid-July to mid-October 2019;

 

Phases III (account information) and IV (transactions): timeframe to be decided in the coming 12 months.

 

Earlier this week, the HKMA launched its own open API and made available 50 sets of financial data and important information most frequently accessed by the public. The HKMA intends to make the remaining data and information (around 80 sets) available in phases by mid-2019.

 

SCOPE AND OBJECTIVES

 

As mentioned above, the open API framework focuses initially on retail banking, as this sector covers the largest group of customers in Hong Kong. Banks are however welcome to extend the framework to other banking businesses as they consider appropriate.

 

The stated objectives of implementing the open API framework are to:

 

  • ensure the competitiveness and relevance of the banking sector and the delivery of banking services in line with international developments;
  • provide a secure, controlled and convenient operating environment to allow banks and their partners to work together to develop innovative and integrated banking services that improve the customer experience.

 

The framework is intended to be high-level (rather than prescriptive) to allow banks flexibility in implementing open APIs. The framework document sets out:

 

  • four categories of open APIs, their functions and a phased implementation timetable;
  • recommended architecture, security and data standards;
  • third party service provider governance process;
  • facilitation and ongoing development.

 

CATEGORIES OF OPEN APIS AND IMPLEMENTATION TIMETABLE

 

There will be four categories of open APIs, to be implemented in phases based on their implications, opportunities and risks, beginning with the least risky category. They are summarised below:

 

Phase and category of open API

Implementation timeline

(Based on the time period from the publication of the framework, ie, 18 July 2018)

Phase lProduct and service information 
(“Read-only” information offered by banks regarding details of their products and services)
Within 6 months, ie, by mid-January 2019
(Implementation road map to be provided to the HKMA within 2 months, ie, by mid-September 2018)
Phase llSubscription and new applications for products/services 
(Customer acquisition process such as online applications for credit cards, loans or other bank products)

Within 12 to 15 months, ie, by mid-July to mid-October 2019

(Implementation road map to be provided to the HKMA within 8 months, ie, by mid-March 2019)

Phase lllAccount information
(Retrieval and alteration (where applicable) of account information (such as balance and transaction history) of authenticated customers for stand-alone or aggregated views)
To be decided with the industry in the coming 12 months
Phase IVTransactions
(Banking transactions such as fund transfers, e-cheque issue and loan repayment for authenticated customers)
To be decided with the industry in the coming 12 months

Banks are expected to implement the framework within the specified timeframe above (the timeframe for phase II has been extended in light of feedback during the consultation). They may advance their programmes if they wish, either for completion of individual phases or for introducing open APIs for those categories which have not yet been set out in the timeline. However, they must ensure that a commensurate level of protection is provided to customers and that suitable governance arrangements are in place for third party service providers.

 

The sensitivity of the data increases for each category, hence more protection will be required for the latter phases than the earlier phases (see paragraph 12 of the framework).

 

The HKMA has set out high-level functions for each open API category in annex A of the framework. These are divided into core-banking functions (deposits, loans and other banking services) and other functions (investments and insurance). While the banks may choose which functions under investments and insurance to implement according to their business priorities, they are expected to implement open API for all of the core-banking functions.

 

In addition, banks are expected to provide the HKMA with implementation road maps, within the timeframe stated in the table above. They are required to explain how their road maps meet the general scope described in annex A (and in the case of gaps, the reasons). The HKMA intends to publish a summary of the road maps for reference by banks.

 

RECOMMENDED ARCHITECTURE, SECURITY AND DATA STANDARDS

 

The HKMA has set out its recommended architecture, security and data standards in annex B of the framework. They are not exhaustive and banks should always make reference to industry sound practices and relevant regulatory and internal requirements.
 
Banks may use their own data definitions, but they should publish a data dictionary using industry practices such as OpenAPI Specification (Swagger).

 

THIRD PARTY SERVICE PROVIDER (TSP) GOVERNANCE

 

Banks are expected to adopt a formal TSP governance process. Three approaches were suggested during the consultation and the "bilateral arrangement with a common baseline" approach was preferred, where a set of TSP governance common baseline is developed and agreed by the banks.

 

For phase I (product and service information), banks are only expected to have a simple TSP registration process with basic consumer protection measures in place. These are set out in paragraphs 33 to 35 of the framework.

 

As for phases II to IV, banks are expected to put in place a more comprehensive TSP governance process. The HKMA sets out guidance on the following (in paragraphs 36 to 49 of the framework):

 

  • onboarding checks on TSPs – developing a common baseline for onboarding checks, and a streamlined assessment model to assess the common baseline when the industry deems appropriate;
  • ongoing monitoring of TSP – putting in place a risk-based ongoing monitoring mechanism for banks to ensure that TSPs continue to meet the common baseline;
  • bilateral contractual relationships with TSPs;
  • publication of a list of partnering TSPs and their relevant products for consumer protection.

 

Banks and TSPs should also define and agree on a liability and settlement arrangement to protect customers in the event they incur loss, and communicate the same to customers.

 

FACILITATION AND ONGOING DEVELOPMENT

 

The HKMA has recommended various steps to facilitate an open API ecosystem, such as:

 

  • publication of all open APIs offered by banks in a central repository (the Data Studio of the Hong Kong Science and Technology Parks); 
  • publication of details on open API functions, architecture, security and data definitions on the banks’ websites or in the above central repository;
  • provision of examples and testing environment with data to assist TSPs in using the open APIs.

 

The HKMA intends to facilitate adoption activities by organising educational events, seminars, workshops and competitions.

 

Once open APIs have been implemented by banks, a body should be established to review the relevance of the architecture, security and data standards on an ongoing basis. The body may also take on other roles such as consumer education, maintaining dialogues with the TSP community, and (if harmonisation of open API functions is desired) working with the industry to achieve interoperability.

 

The Hong Kong Association of Banks has confirmed its support for the open API initiative and that a committee will be working with the HKMA to support the changing needs of the industry.

 

HKMA’S OWN OPEN API

 

Earlier this week, the HKMA launched its own open API on a dedicated webpage. An initial 50 sets of financial data and important information most frequently accessed by the public have been made available, such as market data and statistics, information on authorised or licensed entities, press releases and inSight articles. The remaining sets of data and information (around 80 sets) will be made available in phases by mid-2019.

 

The HKMA has provided examples illustrating how to write simple programmes to retrieve each set of data/information through the open API. The open API is free of charge and no application or registration is required. Information is automatically updated after a one-off programming exercise.

 

COMMENT

 

The global banking industry has undergone rapid change in the recent years with the rise of digital innovation and technology-driven initiatives, products and services, with open API (or open banking) being one of them.

 

The open API framework developed by the HKMA with input from the industry is a good start to improving the overall customer banking experience via data sharing. The HKMA recognises that the benefits of open API can only be reaped if it is widely, securely and cost-effectively implemented in the banking sector, and the framework is intended to achieve this within the set timeframes, commencing with retail banking. The framework will be reviewed from time to time and expanded in due course.

 

Banks, particularly those engaged in retail banking, should review the framework and make preparations to implement the required open APIs. In doing so, they should bear in mind customer protection, data privacy as well as cybersecurity.

 

 

For more see Conventus Law.