October 9, 2026
October 9, 2026
Most monitoring guides for financial services describe dashboards and alert types. Regulators describe something narrower: how many hours a critical system may be down in a year, and how fast you must tell them when it breaks. Those numbers decide what your monitoring has to detect, and how quickly. This guide starts from the published thresholds in Singapore, Malaysia and the European Union.
In short: banking IT monitoring is measured against regulatory clocks, not dashboards. Singapore allows a critical system no more than 4 hours of unscheduled downtime in any 12 months and requires notification within 1 hour of discovery. Malaysia adds a 120 minute cap per single incident. Your detection window is whatever is left over.
The three clocks your monitoring runs against
Read the Singapore row as a single sentence and the design constraint becomes obvious. A bank gets four hours of unscheduled downtime for a critical system across an entire year, and it has one hour from discovery to tell the regulator. Detection is not a convenience feature in that arrangement. It is the first hour of a compliance deadline.
Scope is not a matter of preference. MAS Notice FSM-N05 defines a critical system as one whose failure will cause significant disruption to the bank's operations or materially impact service to customers, and gives two examples: a system that processes time critical transactions, or one that provides essential services to customers. Clause 4 then requires the bank to put in place a framework and process to identify those systems.
That definition does real work. It pulls in the payment rails, the core ledger and the customer channels, and it also pulls in the unglamorous dependencies those rely on, such as authentication services and the integration layer. A monitoring scope drawn around servers rather than around customer-facing outcomes will pass an inventory check and still miss the thing that takes the channel down.
The Malaysian text is narrower in wording and similar in effect. RMiT S 10.32 applies to critical systems where there is a reasonable expectation of immediate delivery of service to customers or dealings with counterparties, and requires those systems to be designed for high availability.
If your monitoring scope and your documented critical system register disagree, fix that before buying anything. The gap between the two lists is where incidents go unseen.
Four hours across twelve months is the figure most cited from the Singapore notice. It is worth converting into an operating budget, because the conversion changes decisions.
Four hours a year is roughly 99.95 percent availability. Expressed as incidents, if your mean time to restore a critical system is two hours, the annual allowance is two incidents. If restoration typically takes forty minutes, you have six. Malaysia constrains the same budget from the other end: under S 10.32 no single incident may exceed 120 minutes, so one long outage cannot be absorbed by an otherwise clean year.
Now subtract the part you control least. Every minute between the failure starting and someone noticing is spent from the same budget, and it is the cheapest minute to recover. Cutting mean time to detect from fifteen minutes to two does not require new architecture. It requires monitoring that alerts on customer-visible symptoms rather than on infrastructure health, and a human who is awake.
This is the calculation to put in front of a board, because it reframes monitoring spend as the purchase of restoration headroom rather than as tooling.
The Singapore notification clock starts at discovery, not at failure. Clause 7 requires the bank to notify MAS as soon as possible and not later than 1 hour upon discovering a relevant incident, where a relevant incident is a system malfunction or IT security incident with severe and widespread impact on operations or material impact on customer service.
Two consequences follow, and they pull in opposite directions.
Late detection does not extend the reporting deadline, but it does consume the restoration budget. Meanwhile the one hour clock is short enough that the classification decision has to be made under pressure. Deciding at 03:00 whether a degradation is a relevant incident is not a judgement to improvise, so the triage criteria belong in a runbook agreed with compliance in advance, not in the responder's head.
The practical control is a pre-agreed severity matrix that maps observed symptoms to a reporting decision, reviewed by the people who will have to defend it. Monitoring feeds that matrix. Without it, teams either over-report and exhaust the regulator's patience, or hesitate and miss the hour.
Malaysia's revised RMiT, issued and effective on 28 November 2025, is unusually specific about monitoring as a capability rather than as an outcome. Three clauses are worth quoting in substance.
S 10.30 requires real-time monitoring mechanisms that track capacity utilisation and performance of key processes and services, capable of providing actionable alerts that enable timely detection and resolution of service interruptions. It adds a maintenance duty: the monitoring scope, metrics and thresholds must be updated periodically so they remain effective.
S 10.39 requires real-time network bandwidth monitoring and resilience metrics that flag over-utilisation and disruption from congestion or network faults, including traffic analysis to detect trends and anomalies.
S 10.35 is the one most likely to catch firms out. It addresses interruption of digital services including periods of performance degradation and intermittent failures, and requires prompt and effective response to minimise customer impact, with services stabilised within the S 10.32 timeframe. It also requires formalised arrangements with third party service providers to ensure coordination and timely recovery.
The word doing the work is intermittent. A system that is up but failing one transaction in twenty will satisfy an availability check and fail customers. Threshold-based monitoring configured around binary up and down states does not see this. Detecting it needs success-rate and latency monitoring at the transaction level, which is a different instrumentation decision and usually a different conversation with the vendor.
The periodic review duty in S 10.30 is also easy to overlook. Thresholds set at go-live and never revisited drift out of usefulness as volumes change, and a regulator can ask when they were last reviewed.
Monitoring in a regulated bank has a second job that tooling discussions often skip. It generates the evidence for the report that follows the incident.
Singapore requires a root cause and impact analysis report within 14 days of discovering a relevant incident, or such longer period as MAS may allow. Clause 8 sets out what it must contain: an executive summary, an analysis of the root cause, a description of the impact on the bank's regulatory compliance, its operations and its service to customers, and a description of the remedial measures taken.
You cannot reconstruct that from an alert history alone. Writing it needs correlated telemetry retained long enough to reconstruct a timeline, records of customer-facing impact rather than only server state, and a defensible account of when discovery actually occurred. Retention policy is therefore a compliance decision, not a storage-cost decision.
There is also a live operational change. MAS published a circular on financial institution incident reporting on 16 December 2025, informing institutions of an updated reporting template. From 1 February 2026, reportable incidents should be submitted using that updated template on the MAS-FI Transactions Platform, known as MAS-Tx. If your incident process still ends with an older template or channel, that workflow needs revisiting rather than the monitoring itself.
The European reporting shape differs enough to matter for any bank in scope of both. DORA runs a three-stage sequence: an initial notification within 4 hours of classifying an incident as major and no later than 24 hours from detection, an intermediate report at 72 hours, and a final report at one month. A firm reporting into both Singapore and the EU is running two different clocks from the same telemetry, which is an argument for one evidence pipeline rather than two.
A one hour notification clock is a staffing statement. It only holds if a competent person sees the alert and can classify it at any hour, including during a public holiday.
Three arrangements are common. An internal team on an on-call rotation keeps the most context and is the hardest to sustain, since overnight pages fall on the same engineers who ship during the day. A fully outsourced watch covers the clock at a lower cost but needs disciplined runbooks, because an external responder without them will escalate everything or nothing. A hybrid keeps detection and first response external and continuous, while escalation for classification decisions goes to named internal people, which suits most mid-sized banks.
Whichever model you choose, RMiT S 10.35 expects formalised arrangements with third party service providers for coordination and timely recovery. An informal understanding with a vendor does not meet that, and it will not survive an examination.
Time zone overlap decides how much of the work happens in daylight. Vietnam sits one hour behind Singapore, so a Vietnam-based team shares a full working day with a Singapore bank, and escalations reach a fully staffed team rather than a skeleton shift. Against a European operations centre the overlap with Singapore is a narrow band at the edge of both days, which is workable for follow-the-sun handover and poor for real-time collaboration on a live incident.
This article deals with the monitoring side of that arrangement. The governance obligations that apply when you outsource any of it, including due diligence, audit access and exit planning, sit alongside the wider technical support scope and follow a separate set of rules.
If you are specifying monitoring for a regulated institution, these are the items that map to obligations rather than to features. General background on monitoring scope and practice is covered in our guide to IT monitoring and our note on proactive monitoring and support.
Score each as evidenced or absent. Items that are configured but never tested belong in the absent column until a drill proves otherwise.
Is 99.9 percent availability enough for a bank in Singapore?
Not on its own. 99.9 percent allows roughly 8.8 hours of downtime a year, which is more than double the 4 hour ceiling in clause 5 of FSM-N05 for a critical system. The figure to design against is closer to 99.95 percent, and the ceiling applies per critical system rather than as a portfolio average.
Does the one hour notification apply to every incident?
No. It applies to a relevant incident, which FSM-N05 defines as a system malfunction or IT security incident with severe and widespread impact on the bank's operations or material impact on service to customers. Most tickets are not relevant incidents. The risk is not over-reporting, it is having no agreed way to tell the difference at speed.
Do these rules apply to a bank branch as well as a locally incorporated bank?
FSM-N05 is addressed to banks in Singapore, and MAS lists its application as covering full banks both locally incorporated and branch, and wholesale banks on the same basis. Confirm your own institution's category against the notice rather than assuming.
What changed for Malaysian institutions in the 2025 RMiT revision?
BNM issued the revised policy document with effect from 28 November 2025. Among the stated aims are stronger resilience to service disruptions including a customer-centric approach to intermittent issues, stronger fraud detection and proactive monitoring, and expanded applicability to certain non-bank merchant acquirers and intermediary remittance institutions above a 5 percent market share threshold.
Can monitoring be outsourced while the bank stays compliant?
Yes, and it commonly is. The obligations remain with the institution, and RMiT S 10.35 specifically expects formalised arrangements with third party providers for coordination and recovery. Outsourcing the watch does not move the accountability.
Conclusion
The most useful first exercise costs nothing. Take your critical system register, put last year's unscheduled downtime against each entry, and mark how much of each outage elapsed before anyone knew. That third column is the part monitoring can actually change, and in most institutions it is larger than the team expects.
Serdao has run technical support and monitoring for eighteen years from a French head office with delivery in Ho Chi Minh City, which puts European regulatory practice and Singapore working hours inside the same team. We are members of CCI France Vietnam and la French Tech. Our monitoring and proactive support page sets out how the service is scoped, and you can contact our team to walk through your critical system register.