How should a bank app handle maintenance windows and outages on a legacy core?

Illustrative situation: a customer in Abu Dhabi pays for fuel at 3:05 am on a Saturday and her card is declined. She opens the bank app. It says “Something went wrong. Please try again later.” Two days earlier the app showed a banner reading “Scheduled maintenance. Some services may be unavailable.” It gave no time and no list, and she swiped it away. Nobody told her that cards were among the services affected. The scene is invented. Each gap has a plausible cause: one notice was written for every channel, the card switch leans on the core, and the error screen was built for bugs, not for a planned shutdown.

Humbleteam, a digital product design agency, publishes this guide. It covers what a bank app should say and do around planned core maintenance and unplanned outages when the app sits on a legacy core: notice, what keeps working, queueing or refusing payments, cards versus app transfers, outage and recovery messages, UAE weekend and Ramadan timing and support scripts. Rules and public pages are described as of November 4, 2026 and can change. This is general information, not legal advice. Your compliance team decides what applies and approves the wording.

What do the rules say about planned maintenance and outages?

In the UAE, the Central Bank’s Consumer Protection Standards (listed as in force, N 1158/2021) have a short Service Interruptions section. Clause 5.1.1.35 says banks must advise consumers in advance of any planned interruption to digital services of more than four hours, such as online banking, the ATM system or the card payment system. It says planned updates and maintenance count, and that they must be planned to limit disruption. Clause 5.1.1.36 covers unforeseen events expected to last more than four hours: a website notice, an SMS or email where possible, alternative services where possible, and an incident report to the Central Bank. We found no minimum notice period, no list of what must keep working and no rule for shorter windows.

In the UK, the FCA’s operational resilience rules apply to banks. They require a communication strategy to reduce harm from disruptions (SYSC 15A.8.1R) and “clear, timely and relevant” communications during one (15A.8.3R). The guidance expects firms to plan in advance how to give warnings quickly (15A.8.2G). We read those provisions in the March 2021 policy statement. New incident reporting rules start on March 18, 2027. The FCA says their definition does not cover a routine system update carried out to plan, but a controlled interruption that goes wrong and meets the thresholds must be reported. Its August 2026 data release on incidents reported by retail banks lists change management among the top three drivers in every year from 2018 to 2026. So a planned window carries risk of its own.

The CMA’s Retail Banking Order, which briefs sometimes cite for service reporting, has no outage or availability clause in the 2017 text we searched. Its service quality indicators are customer survey scores.

What do real bank notices say?

Each page below is one bank’s practice, not a market standard.

RAKBANK’s customer notice board carried three recent notices. One covered Sunday, October 18, from 2 am to 6 am, posted four days ahead. It lists digital banking, card transactions including digital wallets, ATMs and all transfers, including instant ones. Another covered a Saturday window from 4 am to 5 am, posted a day ahead. It adds that card point-of-sale payments will be disrupted and asks customers to make arrangements before 4 am. A third paused only digital transfers for an hour from midnight. The two longer notices give a phone number for fraud and card blocking. Mashreq’s notice for a Friday window, 3:00 to 4:30 am UAE time, lists card transactions, the app, ATMs, deposit machines and customer care.

Santander UK’s service status page splits mobile, online and phone banking, cash machines, branches and card payments, and says maintenance often happens in the early hours of Sunday. FAB’s service status page goes further and marks individual functions as available or temporarily unavailable. When we read it, its stamp said March 16, 2026. Monzo’s status page lists components such as the app, card payments, and inbound and outbound transfers, with a maintenance state and subscriptions through Slack, webhook and feed.

How should the app warn customers in advance?

Use layers, since no single channel reaches everybody. Our suggestion: an in-app banner from several days out, a push and an email or SMS the day before, a last push before the window, and an entry on a public status page. RAKBANK’s notices ran one to four days ahead. The rule sets no number, so your risk team picks one.

Write the notice to answer four questions: when, what stops, what still works and what to do first. Give the day, start, end and time zone, and list stopped functions by name. The GOV.UK pattern for service unavailable pages asks for the day, date and time the service returns, and warns against vague words like “maintenance.” The bank notices above use the word in a heading, then name the services.

Warn inside the flow too. NN/g’s error prevention heuristic says to check for problem conditions and offer a confirmation before the user commits. Applied here: when a window starts within 24 hours, the transfer screen says “Transfers pause Sunday from 2:00 am to 5:00 am UAE time. Send before 1:45 am, or schedule it for after 5:00 am.” Scheduled payments that fall inside a window get the same warning when the customer sets them up.

What should keep working, and what should the app show read-only?

Plan by function, not by channel. FAB’s page shows the right grain: balances and history, own-account transfers and utility bills are separate lines with their own status.

Cards deserve their own row. Customers treat a card as the backup when the app fails. In the RAKBANK and Mashreq notices, it was not one. Monzo says its Stand-in system keeps card payments, transfers and balances working in an outage, and that the app shows a limited experience. That is a separate backup bank, so a bank without one should not copy the promise. If your card switch depends on the core, say so in the notice.

For a read-only mode, show the last known balance and recent transactions with an “as of” time taken from the core, not from the app’s fetch time. Gray out actions that need a write and give the return time. Keep a route for stopping a lost card, by phone if the app cannot. Whether the app can freeze a card depends on where card management sits, so ask.

Should the app queue payments or refuse them?

Both are honest if the screen says which one it is. RAKBANK’s maintenance notices describe refusing transfers. Its holiday notice describes queueing: transfers above 50,000 and foreign currency transfers are processed the next working day.

Our rule: queue only what the bank will honor at a stated time, and call it “Received,” never “Sent.” Our guide to pending items and cut-off times covers that wording. Refuse everything else before the customer commits. The worst state is an unknown outcome: it invites a second tap and a double payment. Give every instruction a reference so a retry cannot duplicate it. Keep the customer’s input: the GOV.UK pattern says to state what happened to their answers, and NN/g’s error-message guidelines say to preserve what users entered. “Nothing was sent. We kept your details” is a complete sentence.

How should an unplanned outage read, and what comes after?

GOV.UK’s problem page pattern is for short faults and says to switch to a service unavailable page when a problem cannot be fixed quickly. Translate that into two stages. First, a plain in-app message within minutes: what is affected, what is not, and do not repeat payments. When the outage looks long, add a status page entry, a push or SMS with the scope, a next-update time and a phone route. For anything expected to pass four hours in the UAE, 5.1.1.36 adds the website notice and the report to the Central Bank. Assign someone to clear the status page, since a stale one costs trust.

Recovery is its own screen. ADCB’s July 2026 press release after a disruption says no balance was inaccurate, names the channels that stayed up, and points customers to internet banking while the app returns. We do not know what its app said. Our suggestion for the in-app version: a list of every instruction made during the outage with its result, a current balance with its time, and a line on what the bank will do about fees. Monzo’s page tells customers to keep receipts and raise a complaint for a direct loss.

Support teams need the same facts. Two script lines (ours): “Our systems are in a planned window until 5:00 am UAE time. Cards, ATMs and transfers are paused.” and “We know about the problem. I cannot give an end time. The next update is at 2:30 pm.” One rule: never promise a return time that the status page does not show.

What changes for weekends, Ramadan and time zones in the UAE?

The RAKBANK windows above fall on Saturdays and Sundays between midnight and 6 am, and the complaint desk hours in the same notices run Monday to Thursday and Friday morning. A weekend window therefore meets a closed desk, so the notice should carry an emergency phone line. Mashreq states “UAE time.” We suggest showing the window in UAE time and in the device’s local time, for customers who travel.

Ramadan begins at the sighting of the new moon, announced by the UAE’s moon-sighting committee, so the dates are not fixed in advance. The UAE government’s Ramadan page says working hours are reduced by two hours a day under the labor law. Branch, call center and operations hours shift, so confirm each window with operations and the contact center first.

A window worksheet

Illustrative worked example: Saltmere Bank

Everything here is invented. Saltmere Bank is a fictional bank on an older core that posts in a nightly batch. Joss Harren is its digital product lead and Dilnoza Marek leads core operations.

Saltmere runs a monthly Sunday window from 2:00 to 5:00 am UAE time. Harren and Marek decide five things. First, a banner five days out, a push and email two days out, a push at 9 pm the night before, and a status page entry. Second, the notice lists what is paused (transfers, bill payments, new payees, limits) and what is not (card purchases and ATM withdrawals within daily limits, balances as of 1:55 am), plus the card-block phone line. Third, in the app, payment buttons are disabled with “Back at 5:00 am.” Fourth, a transfer started at 1:58 am either clears the core before 2:00 or shows “Not sent. Nothing left your account.” Fifth, scheduled payments inside the window run at 5:10 am and say so when set up.

On a Tuesday at 11:20 am the core stops without warning. The app banner appears at 11:26 am, the push at 11:40 am with the scope, and the next update at 2:30 pm. At 2:25 pm the core returns. The recovery screen lists three transfers started during the outage as not sent and shows a balance as of 2:25 pm.

Where do these defaults stop working?

The sources are regulator texts, one data release and public bank pages. None measures whether a notice reduces calls or failed payments. ADCB’s maintenance notice pages returned an access block, so we did not use them. Rules change, and we did not check later amendments to the UK provisions or Saudi, Bahraini or other regional rules. Real-time cores, disaster recovery and corporate banking channels are outside this guide.

What can you produce now?

Five things before design starts: a function list with core dependencies, a notice template with its four answers, a read-only screen spec with the “as of” rule, a queue-or-refuse decision per payment type, and a support script reviewed by compliance. If you are choosing a design team, our comparison of design agencies used to bank compliance and legacy systems is a starting point.