金融科技服务提供商合规性准备框架（英文版）.pdf

1 FINTECH SERVICE PROVIDERS (“FSP”) COMPLIANCE READINESS FRAMEWORK 15 May 2020 Version 1.0 2 TABLE OF CONTENTS OVERVIEW 3 I. ENTITY LEVEL CONTROLS 6 (a) Control Environment 6 (b) Risk Assessment 7 (c) Information and Communication 7 (d) Monitoring 8 (e) Practices related to Sub-Contracting 8 II. GENERAL INFORMATION TECHNOLOGY (“IT”) CONTROLS 9 (a) Logical Security 9 (b) Physical Security 12 (c) Change Management 15 (d) Incident Management 17 (e) Backup and Disaster Recovery 19 (f) Network and Security Management 21 (g) Security Incident Response 23 (h) System Vulnerability Assessments 24 (i) Technology Refresh Management 25 III. Appendix 26 3 OVERVIEW Eight in ten FinTechs in Singapore partner with a Financial Institution (FI) to enhance the FIs offerings or provide technology solutions to the FIs. As such there is a need for these FinTechs to adopt an efficient approach to demonstrate their compliance levels to the FIs while maintaining a baseline level of governance, rigor and consistency over their activities. To do so, the Singapore FinTech Association has undertaken a phased approach to enhancing the compliance maturity of these FinTechs by establishing the Fintech Service Provider (“FSP”) Compliance Readiness Framework. The primary objective of this framework is to promote a sustainable outsourcing relationship between the FSPs and FIs, by helping the FSPs understand the minimum compliance requirements that they need to put in place to operate within the FI industry. The self- assessment accompanying this framework will allow FSPs to be aware of the maturity of their control environment against the minimum compliance requirements. This framework also enhances the FIs comfort level in partnering with the FSPs. Based on MAS Outsourcing and TRM guidelines, FIs are expected to adopt their own approach/strategy to manage the risk of outsourcing to FSPs and understand any residual risk that management is accepting. With this framework, FIs would be able to use the results of the self-assessment performed by FSPs as part of their vendor due diligence and perform onboarding of these FSPs with the condition of the FSPs resolving any gaps identified within the self-assessment and eventually obtaining a third-party assurance report over their controls. The framework includes a set of minimum base requirements from OSPAR, the Monetary Authority of Singapore (“MAS”) Technology Risk Management (“TRM”) Consultation Paper and the MAS Cyber Hygiene Notice, that the FSPs are expected to comply with, as a starting point for servicing FIs. The framework has been streamlined to take into consideration the FSPs scale, operating model and their gradually evolving ability to eventually comply with the OSPAR, TRM requirements and the MAS Cyber Hygiene Notice. The detailed approach on how the framework was built from existing guidelines and frameworks is outlined in the section below. Approach to building the FSP Compliance Readiness Framework The starting point for the creation of the FSP Compliance Readiness Framework is the Guidelines on Control Objectives and Procedures for Outsourced Service Providers v 1.1 dated June 2017, issued by the Association of Banks in Singapore. 4 Using the ABS guidelines / OSPAR framework as a basis the following approach was taken to develop this FSP Compliance Readiness Framework: 1) Certain ABS OSPAR controls criteria were initially set aside based on the following principles a) Policy related controls criteria - Controls criteria that outline requirements to have a formal established policy (with periodic review) have been set aside for now, with the principle that as long as a process has been implemented to address the corresponding policy expectation, this process provides adequate comfort over the control environment. As an alternative an overall requirement to have formal documented policies has been included as a new criteria within the Entity Level Controls section of this version of the framework. b) Repetitive control criteria - Certain controls criteria are indicated as repetitive, for which another existing control criteria is identified (in a more relevant control domain) that addresses the underlying/associated risk. Essentially similar/duplicate controls criteria have been included only once within this version of the framework. c) Relevance of control criteria - Considering the desire to implement the requirements of the ABS guidelines / OSPAR framework using a progressive step-by-step approach and that the preliminary objective is the establishment of a baseline level of governance, rigor and consistency over the outsourced processes, certain controls criteria are set aside that are considered too ambitious for this initial version of the framework. For example, controls related to the business transaction processing (which will be specific to the nature of service provided by the FSP) have been set aside for future consideration. As an alternative, an overall requirement to have SLA tracking and periodic reporting to FIs has been included as a new criteria within the Entity Level Controls section of this version of the framework. 2) The controls criteria that have not been set aside, are classified as key or complementary. Key controls criteria are considered the more desirable option for compliance within the current version of this framework. Complementary controls criteria are included as an option alongside a key control criteria (which the former complements) such that the FSPs are able to rely on the complementary controls criteria, as an interim measure, while they devise action plans to implement the key controls criteria. 3) In addition to the base requirements adopted from the ABS guidelines / OSPAR framework, some additional requirements are included from the recent TRM Consultation Paper (issued 7 March 2019) and the Cyber Hygiene Notice (issued 6 August 2019) that were identified as relevant for FSPs. 4) The identified controls criteria from points (1), (2) and (3) have been revised/reworded to make them suitable and sustainable within an FSP environment. 5 5) As part of future stages/phases of the evolution of this framework, elements that have been set aside (for now) will be re- evaluated for inclusion with a view to eventual compliance to the ABS guidelines / OSPAR framework using a progressive step- by-step approach. 6) Whilst we have considered the MAS TRM Consultation Paper (issued on 7 March 2019) and Cyber Hygiene Notice (issued on 6 August 2019) in the development of the framework, given the phased approach, only controls that are the minimum base requirements for servicing FIs, from these documents have been included. Please refer to Appendix for the list of requirements from MAS TRM Consultation Paper guidelines that were not included within this framework. 6 I. ENTITY LEVEL CONTROLS Entity level controls are internal controls to ensure that the FSPs management directives pertaining to the entire entity are carried out. The controls include the following components: (a) Control Environment. (b) Risk Assessment. (c) Information and Communication. (d) Monitoring. (e) Practices related to Sub-Contracting. The following is a brief description of the components: (a) Control Environment The control environment sets the priority and culture for the FSP, influencing the control consciousness of its people. It is the foundation for all other components of internal control, providing discipline and structure. Aspects of the FSPs control environment may affect the services provided to the FIs. The control environment that an FSP should consider implementing includes the following components: i. Establishing workplace conduct standards and enforcement procedures ii. Conducting pre-employment checks on candidates iii. Defining organisational structures, reporting lines, authorities and responsibilities. Key responsibilities such as the expectations of the person responsible for information security should be defined iv. Personnel having the qualifications and resources to fulfil their responsibilities 7 (b) Risk Assessment The FSPs risk assessment process may affect the services provided to FIs. The following is a list of risk assessment factors that the FSP should consider as part of a regular risk assessment program: i. Rapid growth If the FSP gains a substantial number of new customers, the operating effectiveness of certain controls could be affected. ii. New technology If the FSP implements a new technology, its risks and impact to the FIs should be assessed. iii. New business models, products, or activities The diversion of resources to new activities from existing activities could affect the operating effectiveness of certain controls at the FSP. iv. Corporate restructurings A change in ownership or internal reorganisation could affect reporting responsibilities or the resources available for services to the FIs. (c) Information and Communication The FSP should implement formalised documentation of policies for all the underlying processes and controls related to various functions such as IT, Business Operations, Human Resource, etc. Adequate information and effective communication are essential to the proper functioning of internal control. i. The FSP should establish an internal communication channel to communicate to its staff, roles and responsibilities and significant matters related to the services provided to FIs. ii. The FSP should establish a communication channel with FIs for reporting exceptions, changes to operating environment and other significant matters (e.g. engaging a sub-contractor) and also allow for FIs to respond with any feedback/complaints on the services. FSPs should conduct initiatives to enhance awareness of information security and relevant regulatory requirements among their staff. For example, this could include sessions on phishing awareness, document encryption expectations, responsibilities relating to confidentiality/non-disclosure of client information, etc. 8 (d) Monitoring i. FSPs should monitor their processes relevant to services provided to FIs to identify issues and concerns. For example, this could include a self-evaluation of its processes to assess compliance maturity against the FSP Compliance Readiness Framework and subsequently proceed to employ independent auditors to evaluate effectiveness of controls. ii. FSPs should implement formalised documentation of policies for the underlying processes and controls related to various functions such as IT, Business Operations, Human Resources, etc. FSPs should implement periodic tracking and reporting on SLA compliance and service lapses relating to service provisioning to FIs. (e) Practices related to Sub-Contracting FSPs that engage sub-contractors as part of service provisioning to FIs should: i. be able to demonstrate due diligence and risk assessment of sub-contractors prior to onboarding ii. monitor the sub-contractors activities that affect service provisioning to FIs on an ongoing basis iii. ensure contractual terms in sub-contracting arrangements should align to the FSPs contract with the FIs 9 II. GENERAL INFORMATION TECHNOLOGY (“IT”) CONTROLS This section applies to the IT systems/applications that store, host or process FIs/FI clients data and as such are instrumental in delivering the services that the FSP provides to the FIs. General IT Controls are internal controls to mitigate IT, financial reporting and operational risks. (a) Logical Security These controls provide reasonable assurance that logical access to programmers, data and operating system software is restricted to authorised personnel on a need-to-have basis. 1. Logical access to programmes, data, and operating system software is restricted to authorised personnel on a need-to-have basis. i. IT systems are configured to require key security settings (e.g. password complexity, lockout settings, password history) over passwords used for access. ii. Access to IT systems software (including API services connecting to FIs) is only granted based on a documented and approved request, and on a need-to-use basis. As an alternative, the FSP may review access to IT systems software (including API services connecting to FIs), including sub-contractors access, on a periodic basis to verify that access has been granted on a need-to-use basis. iii. Access to IT systems software (including API services connecting to FIs) is revoked or disabled promptly when the access is no longer required. As an alternative, the FSP may review access to IT systems software (including API services connecting to FIs), including sub-contractors access, on a periodic basis to verify that access has been granted on a need-to-use basis. iv. Strong logical controls are used to identify, segregate and protect individual FIs information. Such controls should survive the tenure of the contract. For API services accessing FI data, these sessions should be logged to identify the third parties making the API connections and the data being accessed by the third party. 10 v. FIs data (including data that has been backed up exists within UAT) should be securely destroyed or removed as per agreed retention and destruction protocols as well as upon termination of contractual arrangements. vi. Industry-accepted cryptography standards (e.g. cryptographic algorithms and encryption key length) agreed with FIs, are deployed to protect FIs customer information and other sensitive data in accordance with the MAS Technology Risk Management (TRM) Guidelines section 12.1.3. These standards would apply for all FIs customer information and other sensitive data that is: (a) Stored in all type of authorised end-point devices, e.g. notebooks, personal computers, portable storage devices and mobile devices. (b) Transmitted between terminals and hosts, through networks (e.g. internet, cloud and APIs) and between sites, e.g. primary and recovery sites. (c) Stored in computer storage, including servers, databases, backup media and storage platforms, e.g. storage area network (“SAN”) (d) Electronically transmitted to external parties (where permissible). When transmitted electronically to external parties, e.g. via email, the decryption keys are communicated to the intended recipient via a separate channel, e.g. via telephone call. vii. Where the FSP owns cryptographic keys, the FSP should ensure cryptographic keys are securely generated and protected from unauthorised disclosure (including during transmission). Access to generate keys is restricted. viii. Where the FSP owns cryptographic keys, the FSP should store the cryptographic keys in systems that are hardened and tamper resistant (e.g. hardware security module). 11 ix. Users with elevated access privileges (including administrative account and accounts which can deploy changes into production) in respect of any operating system, database, application, security appliance or network device and accounts on any s