MAS Tech Risk Management (TRM) and Outsourcing: FAQs

MAS technology risk management is the framework of expectations that the Monetary Authority of Singapore sets for how financial institutions govern IT systems, cyber security and third party service providers. This FAQ answers the questions wealth managers, fund managers and fintechs most often raise when their technology or outsourcing footprint is reviewed by MAS, a board, or an investor.

Most licensed and registered financial institutions in Singapore, from banks to registered fund management companies (RFMCs) and licensed fund management companies (LFMCs), eventually run into the same problem: their technology stack and their outsourcing arrangements are described in three or four different internal documents, none of which quite matches what MAS actually expects. This article is written as a straight question and answer reference for the practical issues that come up in board packs, due diligence questionnaires and pre-licensing conversations. It is not a substitute for a proper gap assessment against your specific licence class, but it should let a director, compliance officer or CTO walk into a conversation about MAS technology risk management with the right vocabulary and the right expectations set.

What is MAS technology risk management, in plain terms?

MAS technology risk management refers to the supervisory expectations, set out primarily in the MAS Guidelines on Technology Risk Management (revised 18 January 2021), for how a financial institution identifies, assesses, treats and monitors risk arising from its use of technology. It covers governance (who on the board and senior management is accountable), system resilience, cyber security controls, software development practices, and the management of third party and outsourced technology services. It sits alongside a separate but closely related set of expectations, the MAS Guidelines on Outsourcing (issued 27 July 2016, last revised 5 October 2018), which deal specifically with how an institution assesses, contracts with, and monitors outsourced service providers, whether or not those services are technology-related.

The two frameworks overlap heavily in practice because most outsourcing arrangements today are, in substance, technology arrangements: cloud hosting, portfolio management systems, trade order management systems, KYC and screening tools, and data analytics platforms. A firm that treats them as two unrelated compliance exercises usually ends up with duplicated policies and gaps at the seams.

Who does this actually apply to?

The guidelines are expressed to apply broadly across MAS-regulated financial institutions, including banks, merchant banks, insurers, capital markets services licence holders, licensed and registered fund managers, payment institutions, and trust companies. Guidelines are not subsidiary legislation and do not themselves create criminal offences, but MAS treats adherence to them as a supervisory expectation, and shortfalls are routinely raised in inspections, licensing reviews and, for smaller managers, in institutional investor due diligence. A registered fund management company that has never formally documented a technology risk framework will usually be asked for one the first time an institutional allocator or a bank counterparty runs due diligence, even before MAS itself raises it.

Fintechs and payment institutions licensed under the Payment Services Act 2019 are squarely within scope too, and in practice tend to attract closer scrutiny of their technology risk posture than more established banks, simply because their entire business model sits on a smaller number of technology dependencies.

What does the scope of a technology risk management framework actually cover?

In practical terms, a framework built around the MAS Guidelines on Technology Risk Management should address: board and senior management oversight of technology risk; an IT risk management framework with defined risk appetite; management of information assets and data classification; system development life cycle controls, including security-by-design and testing; cyber security controls such as network segmentation, access control and vulnerability management; incident management and notification; business continuity and disaster recovery; and management of third party or outsourced technology arrangements. A separate but linked question is which of these arrangements should be classified as “outsourcing” for the purposes of the Guidelines on Outsourcing, since that classification determines the level of due diligence, contractual protections and ongoing monitoring MAS expects.

A recurring question at this stage is whether using a mainstream cloud provider (AWS, Azure, Google Cloud) counts as outsourcing. In MAS’s own framing, cloud usage is treated as a form of outsourcing and is subject to the same risk assessment discipline as a traditional outsourced data centre, even though the commercial relationship looks very different from a bespoke IT services contract.

How is materiality assessed for an outsourcing arrangement?

Before deciding how much due diligence and monitoring an arrangement needs, institutions are expected to assess whether it is a “material” outsourcing arrangement. Materiality is not a single fixed number; it is a judgement based on factors such as: the potential impact on the institution’s operations and reputation if the service provider fails; the cost of the arrangement relative to the institution’s total expenses; the sensitivity of the data being handled; the difficulty of finding an alternative provider; and whether the arrangement involves a function core to the institution’s business (portfolio management, trade execution, client onboarding) rather than a peripheral support function. A firm that outsources its payroll processing to a local vendor is in a very different risk category from one that outsources its core banking platform or its AML transaction monitoring engine.

This matters because material outsourcing arrangements typically attract board-level oversight, more detailed contractual protections (audit rights, sub-contracting controls, exit and business continuity provisions), and, in some cases, prior notification or consultation with MAS depending on the institution’s licence class.

What does this cost, and how long does an implementation project take?

There is no MAS-prescribed fee for complying with the Guidelines on Technology Risk Management or the Guidelines on Outsourcing; these are supervisory expectations, not licences with a fixed application fee. What institutions do incur are the practical costs of building and maintaining the framework. As a general guide for a small to mid-sized licensed fund manager or fintech, an initial gap assessment against the guidelines, covering governance documentation, a technology risk register, an outsourcing register and policy documentation, typically runs from around S$6,000 to S$18,000 depending on the number of systems and outsourcing arrangements in scope, and takes roughly 4 to 8 weeks from kick-off to a board-ready report. A fuller build-out, including a revised outsourcing policy, vendor risk assessment templates and an incident response plan, tends to add another 6 to 10 weeks. Ongoing annual review of the technology risk register and outsourcing register is usually budgeted separately as part of a compliance retainer rather than as a one-off project.

These figures are illustrative estimates for planning purposes only and will vary with the complexity of a firm’s systems and the number of vendors it needs to assess; they are not MAS-prescribed fees.

What are the key ongoing obligations once a framework is in place?

Once documented, the framework is not a “file and forget” exercise. Institutions are generally expected to: review and update the technology risk assessment and outsourcing register at least annually or whenever a material change occurs (new system, new vendor, material contract renewal); conduct due diligence on new service providers before contracting, and periodically thereafter; maintain the ability to audit or obtain audit reports (such as SOC 2 reports) from material service providers; test business continuity and disaster recovery arrangements; and report material cyber security incidents to MAS within the notification timeframes set out in the relevant notice for the institution’s licence class. Boards are expected to receive periodic reporting on technology risk, not simply delegate the topic entirely to the CTO or IT manager.

What are the most common gaps firms run into?

Three patterns turn up repeatedly. First, an outsourcing register that lists vendors but was never actually risk-rated, so nobody can say which arrangements are “material” and therefore need enhanced oversight. Second, cloud arrangements that were never formally assessed as outsourcing at all, because the onboarding was done quickly by an engineering team without compliance sign-off. Third, incident response plans that exist as a document but have never been tested, so the first real test of the plan is an actual incident. None of these are unusual, and none of them are difficult to fix once identified; they are simply the kind of gap that only surfaces when someone actually sits down and maps systems against the guidelines rather than assuming existing IT practice is sufficient. For a closer look at how these gaps tend to surface during an actual review, and the specific mistakes that lead to supervisory findings, see our companion piece on MAS technology risk management and outsourcing: common mistakes and rejection reasons, which takes a mistakes-first angle rather than the reference format used here.

How does this interact with fund manager licensing and mandates?

Fund managers preparing for an RFMC notification or an LFMC licence application are often surprised at how much weight is placed on technology and outsourcing governance relative to investment strategy documentation. Part of preparing a credible application is making sure the manager’s mandate and its operational infrastructure are coherent, which is a similar exercise to the one we describe when helping managers match a VCC mandate to the manager’s MAS scope: the technology and outsourcing framework has to fit the actual business the manager is licensed to run, not a generic template. A manager running a systematic strategy with a third party execution algorithm has a very different outsourcing risk profile from a long-only discretionary manager using an off-the-shelf portfolio system.

Banking relationships are a related pressure point. Institutions opening operating or client money accounts with Singapore banks are increasingly asked about their technology and vendor governance as part of account opening due diligence, alongside the usual documentation. Our guide on Singapore bank account opening with DBS, OCBC, UOB, Wise and Aspire covers the common mistakes that slow this process down, several of which trace back to inconsistent answers about IT and outsourcing arrangements across different forms.

Who signs off internally, and what should board reporting look like?

A question that comes up in almost every board meeting where this topic is raised: exactly who is meant to own it? MAS’s expectation is that the board and senior management retain ultimate accountability for technology risk, even where day-to-day management is delegated to a chief technology officer, a head of operations, or an external IT managed service provider. In practice, a workable governance structure usually has three layers: a designated senior individual (often the CTO, COO, or, in smaller managers, a designated compliance officer working with an outsourced IT provider) who owns the technology risk register day to day; a management-level committee or forum that reviews the register, incident logs and vendor risk assessments at least quarterly; and the board, which receives a summarised report, typically annually or semi-annually, covering the state of the technology risk framework, any material incidents, and any material changes to the outsourcing register. Smaller firms sometimes combine the second and third layers, but the paper trail showing that someone above the IT function actually reviewed and challenged the reporting is what examiners and institutional investors look for first.

A related and frequently misunderstood point is that board reporting does not need to be technical. A board pack that reproduces a vulnerability scan output verbatim is not useful; a board pack that says “12 vendors assessed, 2 rated material, 1 material incident this quarter resolved within SLA, no outstanding critical vulnerabilities beyond 30 days” gives the board something it can actually exercise judgement over.

FAQs

Does the MAS Guidelines on Technology Risk Management have the force of law?
No. Guidelines are not subsidiary legislation, so there is no statutory penalty for a breach of the guidelines as such. MAS nonetheless treats them as a supervisory benchmark, and persistent non-adherence can affect a firm’s licensing status, inspection findings and, for regulated activities requiring fitness and propriety assessments, the standing of individual officers.

Do registered fund management companies need a full technology risk framework, or is that only for banks?
RFMCs are within scope of the guidelines in the same way as licensed managers, though the framework should be proportionate to the size and complexity of the RFMC’s operations. A small RFMC running a handful of managed accounts on a standard portfolio management platform will have a much lighter framework than a bank, but it should still cover governance, an outsourcing register and basic cyber controls.

Is using a cloud-based CRM or portfolio system automatically a “material” outsourcing arrangement?
Not automatically. Materiality depends on the sensitivity of the data, the criticality of the function to the business, and the impact of an outage or breach. A CRM holding only marketing contact details is a lower-materiality arrangement than a portfolio management or trade execution system holding client transaction data.

How often should the outsourcing register be reviewed?
At minimum annually, and additionally whenever a new material vendor is onboarded, an existing material contract is materially amended, or a significant incident affecting a vendor occurs.

What happens if a cyber incident occurs at an outsourced service provider rather than at the institution itself?
The institution generally remains responsible for notifying MAS and managing the incident response, because accountability for the outsourced function is not transferred to the vendor. This is one of the reasons contractual incident notification clauses with vendors matter as much as the institution’s own internal incident response plan.

MAS Technology Risk Management (TRM) and Outsourcing: Frequently Asked Questions