3.6When determining the design of an API, Institutions may consider the following elements to deliver innovation and flexibility:
a.Accessibility: Ensure all relevant parties can access the API;
b.Interoperability: Enable exchange of Data across Institutions without any dependencies on underlying technologies;
c.Reuse: Leverage existing standards and taxonomies to avoid duplication of effort;
d.Independence: Avoid dependency on any vendors or technologies and retain various options for delivery models and implementation technologies;
e.Extensibility: Establish flexibility to extend APIs to new stakeholders and business channels and offer new functionality in existing APIs;
f.Stability: Ensure consistency in functionality and accessibility when modifying the API through appropriate governance;
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;
h.Transparency: Promote transparency and clarity on the API, including environments supported, changes implemented, and standards followed; and
i.Loosely coupled: Provide flexibility and minimise impact of changes to operations of other APIs or API applications.
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.8Institutions should undertake the following steps when designing APIs:
a.Decide on in-house vs outsourced API development;
b.Prioritise and sequence APIs to publish;
c.Consider guiding principles such as openness, usability and interoperability;
d.Ensure that adequate security and Data protection mechanisms are in place to protect Personal Data; and
e.Identify and define requirements and technical guidelines.
3.9During the development of APIs, Institutions and API Providers should ensure that they:
a.Adopt the appropriate API design model based on the type of the API and the protocol used;
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
c.Document these requirements and technical specifications so that the behavior of the API is well understood and can be measured against expected behavior.
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.
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.
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.
3.13Institutions should develop an appropriate infrastructure to manage and securely store access credentials.
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.
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.
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.
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.
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.