MAS and AI in financial institutions
MAS Notice FSM-N05, paragraphs 4 to 6 — Notice on Technology Risk Management
MAS Notice FSM-N05 imposes legally binding requirements on banks in Singapore, and paragraphs 4 to 6 are three of them: a framework to identify critical systems, unscheduled downtime of no more than four hours in any twelve-month period, and a four-hour recovery time objective validated annually. Nothing in the Notice carves out AI.
§ 1 — Who it binds
Which firms, and which systems
Financial institution
Banks in Singapore, by paragraph 1 of Notice FSM-N05, with “bank in Singapore” taking its meaning from section 2(1) of the Banking Act 1970. Insurers owe the equivalent obligations under Notice FSM-N03, and the requirement exists across the FSM-N series by licence class. Inside a bound firm the only gate is criticality: the Notice carves out no technology, no vendor arrangement and no AI, and a system is critical by the consequence of its failure rather than by what it is.
§ 2 — In practice
Criticality is decided by consequence, not by technology
There is no single MAS Notice on Technology Risk Management, and citing one as though there were is a live error in secondary commentary. The sectoral Notices — 644 for banks, 127 for insurers, 506, PSN05 for payments, and 655 on cyber hygiene — were cancelled on 10 May 2024, and each cancellation record points forward to a replacement issued under the Financial Services and Markets Act 2022. Those replacements remain segmented by licence class: FSM-N05 is the Notice to banks in Singapore, FSM-N03 the insurers’ equivalent, FSM-N06 cyber hygiene for banks. A firm has to cite the Notice for its own class. A policy still naming 644 is describing an instrument that stopped existing two years ago, and the substitution is not cosmetic, because the operative paragraph numbers changed with it.
The gateway is definitional and blind to technology. A system is any hardware, software, network or other information technology component that forms part of an IT infrastructure. A critical system is one whose failure will cause significant disruption to the bank’s operations or materially impact its service to customers — such as one processing time-critical transactions, or providing essential services to customers. A model-serving endpoint, an inference API and a vendor’s hosted model all satisfy the first definition, and the second is decided by consequence of failure rather than by what the component is built from. So the assessable question is not whether an AI system appears on the register. It is whether the critical systems already on it have AI inside their failure boundary: a fraud model whose failure stops card authorisations is inside one, and a drafting assistant is not. Firms classify at the application layer and rarely ask what the application depends on.
Paragraphs 5 and 6 both assume a system that is either up or down. An AI system seldom fails that way — it stays available, answers at ordinary latency, and is wrong. Neither the four-hour unscheduled downtime ceiling nor the four-hour recovery time objective has a natural reading for a model serving confidently degraded output, and the Notice supplies no point at which wrong becomes unavailable. That threshold belongs to the firm, set in advance and in writing, because the alternative is settling it during an incident with a regulatory clock already running. The property being protected is described in general terms as resilience under adverse conditions on Article 15, which states no figure where these paragraphs state two.
Paragraph 6 asks for two things to be documented at least once every twelve months, and firms usually hold one: how recovery testing is performed, and when the recovery time objective was validated during that testing. On an AI-dependent service the harder question is what was recovered. A container that starts and answers is not evidence the model came back — the version, the weights, the configuration and any retrieval state have to be the ones that were lost, and a test that never compares the restored system’s outputs against the originals has exercised the platform. Where those comparisons are retained they double as the trace an engagement can work from later; Article 12 addresses the same evidential problem from the logging side.
The allowance in paragraph 5 is a rolling counter rather than a calendar budget: the maximum applies to each critical system across any period of twelve months. That makes partial degradation an accounting question as well as a detection one. An hour in which a model answered a share of its requests incorrectly either did or did not consume the allowance, and whichever way the bank answers, it needs to have answered before the year in which the answer matters. Firms that never wrote the rule down discover at the ceiling that they have been counting the generous way, and by then the counting method is itself the finding.
§ 3 — When it applies
The day the Notice took effect
10 May 2024
Paragraph 10 of the Notice states that it takes effect on 10 May 2024. This is a commencement date for a legally binding requirement, not a publication date for voluntary material. Notice 644, the predecessor for banks, was cancelled the same day.
§ 4 — What discharges it
What the classification must produce
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
The critical-systems register with AI dependencies resolved
For each critical system, whether a model, an inference endpoint or a vendor API sits inside its failure boundary, and who decided that it does. A register naming applications only has answered a narrower question than paragraph 4 asks.
02
The identification framework and its decision rule
The written rule by which a system is classified, together with at least one AI-dependent system it excluded and the reasoning. Exclusions are where a framework is tested; inclusions are where it is comfortable.
03
The annual recovery validation record for an AI-dependent system
Both limbs the Notice asks for: how recovery testing is performed, and when the objective was validated during that testing. A method with no validation event, or an event with no method, satisfies half the paragraph.
04
Twelve months of unscheduled-downtime accounting
The trailing figure per critical system against the allowance, showing explicitly how any interval of partial model degradation was or was not counted. The treatment adopted matters more than the total reported.
05
A recovery test in which the model was the thing recovered
Weights or endpoint restored, version confirmed, and evidence that the restored system produced the same outputs as its predecessor on a held-back input set. Restoring infrastructure demonstrates that infrastructure was restored.
06
The written position on silent degradation
The point at which wrong answers count as unavailability, who set it, when it was last reviewed, and the monitoring that would surface it. Undocumented, it is settled under pressure by whoever happens to be on the call.
§ 5 — Worked example
Worked example — six hours of fallback
A bank’s card fraud-scoring model sits behind the authorisation flow. The authorisation platform is on the critical systems register; the model runs as a separate hosted inference service supplied by a vendor and is recorded in the model inventory and nowhere else. In March the vendor’s endpoint returned elevated latency for six hours and the platform fell back to a static rules set, which approved transactions the model would have declined. The platform itself never went down.
Was a critical system unavailable, and if so for how long?
The bank has to answer and its own records do not. The failure boundary of the critical system reaches the inference service, because the authorisation flow behaved materially differently once that service degraded — so the identification framework required by paragraph 4 ought to have resolved the dependency and named it, whoever owns the vendor relationship. On the allowance, six hours of fallback is either nothing, because authorisations continued, or six hours, because customers received a different service from the one the system exists to provide. Both readings are arguable; only one of them can be the bank’s, and the reason to write the rule in advance is that the argument then happens in a policy review rather than in a supervisory meeting. What is not arguable is that the annual validation never exercised this failure mode. It tested the platform, and the platform is not what failed.
§ 6 — What a weak answer looks like
A model inventory answering a register question
The model inventory offered in answer to a critical-systems question. The bank produces a well-kept list of every model in production, with owners and risk ratings, and observes that none of them is classified critical. Both statements are true, and neither addresses paragraph 4, which asks what the bank’s critical systems are and what sits inside them. The classification travels the other way — from the consequence of a failure to the components inside its boundary. A model that is nobody’s critical system can still be the thing whose failure takes one down.
§ 7 — Exposure
What follows from a binding Notice
A legally binding requirement under a Notice. No monetary figure is stated on this page.
The Notice records that it is issued pursuant to section 29(1) of the Financial Services and Markets Act 2022. MAS states that Notices primarily impose legally binding requirements on a specified class of financial institutions or persons, and that Directions have legal effect, meaning MAS could specify whether a contravention of a direction is a criminal offence. The quantum is deliberately absent: the statutory provision text could not be read from a primary source, and an unverified figure will not be published here.
§ 8 — Elsewhere
Availability duties elsewhere
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
Article 15 addresses accuracy, robustness and resilience across a high-risk system’s lifecycle, including behaviour under adverse conditions. These paragraphs address availability of a bank’s critical systems and fix two numeric thresholds for it.
Article 12 requires automatic recording of events over a high-risk system’s lifetime. Those records are frequently what an annual recovery validation has to draw on to establish what was actually restored.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 9 — provenance
The provision itself
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
- MAS Notice FSM-N05, Notice on Technology Risk Management, issued to banks in Singapore under section 29(1) of the Financial Services and Markets Act 2022. Paragraphs 4, 5 and 6, with the definitions of “system” and “critical system”.
- Paragraph 10: “This Notice shall take effect on 10 May 2024.”
- Cancellation record for Notice 644, cancelled 10 May 2024, pointing to Notice FSM-N05 on Technology Risk Management.
- MAS’ statement of instrument classes: Notices primarily impose legally binding requirements; Directions have legal effect and MAS could specify whether a contravention is a criminal offence.
§ 10 — Also read
Also read
Article 15 — accuracy, robustness and cybersecurity
Certification
Assessed on the same standard of evidence
Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.