Skip to main content
Back Custom print Text Only Rich Text Print

  • Application Programming Interfaces (APIs)

    • Governance

      1. 3.1Institutions should establish a documented governance framework for effective decision-making and proper management and control of risks arising from the use of APIs. The governance framework should:
        1. a.Define the roles and responsibilities of the Institution, API Provider and API developer (where different), including the division of duties;
        2. b.Establish appropriate policies, procedures, standards and controls to govern the API Lifecycle within the Institution;
        3. c.Employ tools and technologies that enable communication, change management and performance monitoring across the API Lifecycle;
        4. d.Establish appropriate testing strategies prior to publication and on an ongoing basis for optimal performance of APIs, for example:
          1.  i.A load testing strategy which can be used to assess how the API performs against service-level agreements and to determine what response is normal for the API. Target API test case problems that would prevent longer load tests from running correctly should be developed;
          2.  ii.Stress testing of the APIs that can be undertaken by simulating a heavy load on the API or by conducting crash point testing to identify the maximum number of users the API can handle; and
          3. iii.A monitoring framework that can ensure critical interfaces and functions to be appropriately tested and verified for conformance to expected behavior;
        5. e.Establish a framework to assess, monitor, report and mitigate risks associated with the APIs including developing mechanisms to ensure regular testing and implementation of coding controls, production monitoring and support post deployment, process control mapping and development of a risk control matrix; and
        6. f.Be approved by the appropriate Governing Body.
      2. 3.2When Outsourcing to an Outsourcing Service Provider, Institutions should ensure that access to information is adequately controlled, monitored, reviewed and audited by the Institution’s internal control functions, and regulators, including the appropriate Supervisory Authority;
      3. 3.3Business continuity plans of an Institution should cover APIs and the security controls associated with APIs. Institutions should assess criticality of the different types of APIs used and ensure that the business continuity planning scenarios cover the various types of APIs being used. The business continuity strategy and arrangements should be updated when changes are made to the operating environment, and most importantly, be tested periodically.

    • Architecture

      1. 3.4Institutions should ensure that the systems and technology architecture for the APIs are designed such that the APIs can flexibly evolve. This could be done by making the architecture independent from the applications using the APIs (i.e. such that it is not over tailored to the most common use cases). The evolution of APIs should not hinder existing applications, which should be able to function without interruption.
      2. 3.5Institutions should establish controls so that the architecture supporting the API and the API itself is secure and protected against misuse or security attacks.

    • Design

      1. 3.6When determining the design of an API, Institutions may consider the following elements to deliver innovation and flexibility:
        1. a.Accessibility: Ensure all relevant parties can access the API;
        2. b.Interoperability: Enable exchange of Data across Institutions without any dependencies on underlying technologies;
        3. c.Reuse: Leverage existing standards and taxonomies to avoid duplication of effort;
        4. d.Independence: Avoid dependency on any vendors or technologies and retain various options for delivery models and implementation technologies;
        5. e.Extensibility: Establish flexibility to extend APIs to new stakeholders and business channels and offer new functionality in existing APIs;
        6. f.Stability: Ensure consistency in functionality and accessibility when modifying the API through appropriate governance;
        7. g.Privacy by design: All APIs should be designed in a way to only expose relevant Data elements to any party in order to fulfil the purpose of the API;
        8. h.Transparency: Promote transparency and clarity on the API, including environments supported, changes implemented, and standards followed; and
        9. i.Loosely coupled: Provide flexibility and minimise impact of changes to operations of other APIs or API applications.
      2. 3.7Institutions should have proper engagement with API Providers before API Providers can expose any Personal Data through the APIs. This engagement should cover the onboarding of and due diligence processes on the API Provider.
      3. 3.8Institutions should undertake the following steps when designing APIs:
        1. a.Decide on in-house vs outsourced API development;
        2. b.Prioritise and sequence APIs to publish;
        3. c.Consider guiding principles such as openness, usability and interoperability;
        4. d.Ensure that adequate security and Data protection mechanisms are in place to protect Personal Data; and
        5. e.Identify and define requirements and technical guidelines.
      4. 3.9During the development of APIs, Institutions and API Providers should ensure that they:
        1. a.Adopt the appropriate API design model based on the type of the API and the protocol used;
        2. b.Develop requirements and technical specification that define the output to be achieved by the APIs and how the APIs should perform their expected functionality from a technical perspective; and
        3. c.Document these requirements and technical specifications so that the behavior of the API is well understood and can be measured against expected behavior.
      5. 3.10Institutions should ensure that Personal Data being transmitted or stored is encrypted to enable privacy and integrity of Data. Institutions can consider utilizing secure public/private key based encryption methods and protocols, which should comply with internationally recognised and applicable security standards.
      6. 3.11Institutions should ensure that access management and authentication processes are used so that only authorised and authenticated individuals and organisations have controlled access to the appropriate API resources.
      7. 3.12Institutions should ensure that authentication mechanisms are implemented effectively and securely, preventing attackers from compromising authentication tokens, or exploiting implementation flaws to assume other user identities temporarily or permanently.
      8. 3.13Institutions should develop an appropriate infrastructure to manage and securely store access credentials.
      9. 3.14Institutions should use Multi-Factor Authentication when a Customer initially accesses an online service that uses APIs, to provide secure access to the account.
      10. 3.15Institutions should consider using Multi-Factor Authentication when a customer uses an API to access, process or transmit Personal Data. Multi-Factor Authentication may also be considered for the initiation or processing of transactions.
      11. 3.16Institutions should ensure that they create clear access control policies that separate administrators and regular users and that accurately reflect the hierarchies, groups, and roles within the organisation. Institutions should review their internal hierarchies, groups, and roles to ensure that there are no gaps in the roles that could lead to unauthorized access to the APIs.
      12. 3.17Institutions should ensure that APIs are designed to impose restrictions on the size or number of resources that can be requested by the user to prevent Denial of Service (DoS) attacks.
      13. 3.18An independent function or external expert with adequate skills and knowledge should conduct vulnerability assessments and penetration tests on the Institution’s and the API Provider’s systems and infrastructure to identify weaknesses or flaws in the security processes at least on an annual basis.

    • Standardisation

      1. 3.19Institutions should consider the adoption of standardised APIs that are issued either by Supervisory Authorities or the industry. Standardised APIs can, among other matters, include the following:
        1. a.API design standards: Adopting a uniform API design model and language across the relevant financial services industry based on a broad range of design considerations;
        2. b.Data standards: Adopting international Data standards that define the semantics and syntax of Data being transmitted using APIs, based on the type of Data being transacted and the use case, to promote interoperability; and
        3. c.Information security standards: Adopting international information security standards to ensure information is securely transmitted through APIs.

    • Management

      1. 3.20Institutions should consider establishing an API monitoring framework that addresses infrastructure, technology and security related incidents and events in a timely and effective manner. The monitoring framework should:
        1. a.Define what constitutes an incident/event, such as unusual activity or unauthorised changes;
        2. b.Monitor the use of APIs to rapidly and accurately detect incidents and events;
        3. c.Report incidents and events to decision makers in a timely manner commensurate with their severity; and
        4. d.Remediate the impact of the incidents and events in an effective manner.
      2. 3.21Larger Institutions with important API adoption should consider establishing a security operations centre dedicated to monitoring, assessing and defending IT systems and assets such as APIs, web sites, applications, Data servers, networks, hardware and software.
      3. 3.22Institutions should maintain an audit trail that records the appropriate metrics and security-related behavior of each API and records any breaches of security that occur. The audit trail should capture the metrics and behavior before and after such breaches to support future detection of breaches of security.
      4. 3.23Institutions should establish incident handling procedures to swiftly detect, review, report and rectify any incidents. Institutions should only provide the necessary details of any incident when reporting incidents to the public to avoid providing attack vectors for bad actors.