How should a bank app show pending items and cut-off times on a legacy core?

Illustrative situation: at 7:40 pm on a Friday a customer sends rent to her landlord from her bank’s new app. The confirmation says “Transfer sent.” The home screen shows AED 4,200 and the account screen shows AED 3,950, with no explanation for the gap. On Saturday morning the landlord has received nothing. On Monday the app moves the payment from “Sent” to “Processing” and, hours later, to “Completed.” Nobody lied. The first screen assumed a bank that moves money instantly, and the core moves it in batches. The scene is invented, but each part of it has a documented counterpart, and this guide takes them in turn.

Humbleteam, a product design agency, publishes this guide. It draws on public rules and help pages from the UAE and the UK that you can read yourself, and it is general information, not legal advice. Your bank’s compliance team decides which rules apply to your product. It pairs with our 8-week pilot plan and legacy constraint map, which helps you find out what the core can and cannot return. This guide covers what the customer’s screen should say once you know.

Why does a legacy core leave gaps between what happened and what the screen says?

Many cores run on a daily rhythm. In a batch-based core, the bank may record a temporary “memo” entry during the day and replace it with the real posting during end-of-day processing, which is how memo posting is generally described. Oracle’s documentation for its FLEXCUBE core shows one concrete version: the system accepts channel transactions around the clock, but during the end-of-day batch it holds them (“tanked”) and processes them after the batch completes. When a branch is marked unavailable for the day, accepted transactions take effect only from the next business day. That is one vendor’s documented behavior, not a description of every core.

The customer meets this as two numbers. TD’s help page defines a posted balance as the amount after transactions have fully processed, and an available balance as what you can spend after pending items and holds, and adds that posting order and cut-off times also affect both figures. Nationwide says a pending card payment normally goes through within 7 days, though some take up to 180 days. HSBC UK notes that uncleared cheques and Direct Debits do not show in the available balance yet, and that pending debit card items show in its app but not in online banking.

The design consequence: every value on a screen has a source system and an update rhythm. Write both down before drawing anything. Without that list, two screens built on two rhythms will disagree, and the customer will assume the app is wrong.

How should a screen show two balances honestly?

A published Financial Ombudsman Service decision shows the failure. A customer’s international transfer was declined. Her current balance looked high enough, but pending card payments had cut her available balance, and the transfer plus a fee left her GBP 3.90 short. The ombudsman did not uphold her complaint, which turned on timing and on which balance she had looked at. A screen can prevent that confusion.

These suggestions are ours:

• Lead with the figure that answers “what can I spend now,” in plain words such as “Available to spend.” NN/g’s second heuristic asks for words users know instead of internal jargon, so keep “ledger” and “posted” out of the main label.
• Name the second figure for what it is, such as “Balance after today’s processing,” and let a tap list the pending items between the two. HSBC’s page shows that not every difference can be itemized, so say so when the list may be incomplete.
• Use one definition on every screen. The transfer form should check the available balance, fee included, before the customer submits, not after.
• Stamp the figure. The UK Open Banking balances resource carries a date and time with each balance, and it allows several balance types per account. If your core exposes only one, do not invent a second.

Which transaction states does the customer need?

“Pending” is not one state. The Open Banking transactions resource treats a pending transaction as mutable: its date, description or amount may change, or it may be backed out completely. A booked one is final, and its booking date is when it was booked, not when the customer acted. Its payment status model follows ISO 20022 and lists 13 status codes with an update time, so your channel layer may already receive more than success and failure. Ask for the full list.

The CBUAE Consumer Protection Standards require account statements to show the amount, type and status of each transaction (clause 2.1.1.43), so status wording is a compliance matter from the start. The GOV.UK Design System’s Tag component offers two rules worth copying: name statuses with adjectives, not verbs, so they do not look clickable, and start with the smallest set that works.

For the “On hold” row, UK payment services rules give a model. Where a provider delays an order over suspected fraud, regulation 86 requires it to tell the payer about the delay, the reasons and what the payer must do, by the end of the next business day. A label that carries those three parts is better than “Under review.”

How should cut-off times and “arrives by” estimates work?

A cut-off is a promise about the bank’s clock, not the phone’s. Emirates Islamic’s online banking terms state that the time on a transaction advice is the time of the bank’s main computer, and that a request made before the cut-off in the bank’s record is completed that day, while later ones take next business day value. Public documents show how much the clocks differ, even within one bank.

Three rules for the screen follow from that.

• One product often spans several rails with different clocks. The app should pick the rail by rule and tell the customer which clock applies before they commit: “Send before 6:30 pm today for same-day processing.”
• A missed cut-off can change the price. Emirates Islamic’s money transfer page says a request after the cut-off uses the next working day’s exchange rate. The CBUAE standards require fees to be disclosed before the customer confirms a transfer (5.1.5.2). Put cut-off consequences on the same screen as the fee.
• Holidays can be known late. The UAE government says Islamic holidays are determined by moon sighting, and Standard Chartered notes that holidays in the currency’s own jurisdiction can matter. Calculate “next business day” on the server from the bank’s calendar, and word the estimate as conditional.

For remittances, the same CBUAE standards (2.1.5.5) say that, where possible, the customer should get an estimated transfer time with a warning that the time can be delayed. Write estimates as “expected by,” not “in,” state the condition, and never promise what the receiving bank will do. Standard Chartered says openly that it does not guarantee when the beneficiary’s bank will credit.

How should the app handle stale data, limited APIs and optimistic updates?

NN/g’s first heuristic is that the system should keep users informed about what is going on. With a batch core, that means showing the age of the data. Our suggestions:

• Put “as of” next to any figure fed by a cache or a batch. Use the core’s own timestamp, not the time the app fetched it.
• Cache what is allowed to be stale. A booked balance can wait for the next batch. The available balance used to approve a transfer should be read from the core when the customer submits.
• When the core is unreachable, show the last known figure with its time, not a blank or a zero.
• Treat long outages as a notification event. The CBUAE standards (5.1.1.36) require, for unforeseen interruptions expected to last over four hours, a website notice and an SMS or email where possible.

Optimistic UI is a poor fit for money movement. React’s documentation describes optimistic state as temporary: if the action fails, the screen reverts to what it showed before. That is acceptable for renaming a payee or switching a notification. For a transfer, a “Sent” screen that later reverts is the situation in the opening scene. Show “Received” until the core acknowledges the instruction, and keep optimistic changes to settings that cost nothing to undo.

What should an action that cannot finish in real time look like?

Use three beats: accept, confirm, notify. The GOV.UK confirmation page pattern says a confirmation must include a reference number where there is one, details of what happens next and when, and contact details. The CBUAE standards (2.1.1.44) require banks to inform customers of all account transactions as they occur by SMS, with details available in mobile or internet banking, so the notification and the in-app state must agree.

Some waits are built in. Standard Chartered applies a four-hour cooling-off period before a new beneficiary can be used. Show that as a state with an end time, such as “Available at 3:40 pm,” not as a failed save.

How should errors and reversals read?

NN/g’s error-message guidelines ask for precise, human-readable language and constructive advice. For money, add one more requirement: say where the money is. A good message has four parts: what happened, where the money is now, what happens next and when, and what the customer can do.

Reversals have their own clocks. For funds returned by a correspondent bank, CBUAE standard 5.1.5.6 requires the bank to advise the customer within two complete business days and to credit the funds as soon as they arrive, with an exception for financial crime investigations. If such a rule covers your product, the “Returned” state and its notification need an owner who watches that clock.

How do you agree the wording with compliance?

Regulators treat timing statements as information duties. The CBUAE standards (2.2.1.2) say information must be timely and up to date, at each stage. The FCA’s Consumer Duty rules require communications to be likely to be understood and not misleading, and to arrive in good time (PRIN 2A.5). Your reviewers will ask what a sentence promises and whether the bank can keep the promise.

Three habits make that conversation shorter. First, write each timing phrase at one of three levels: a fact (“Received at 7:40 pm”), a conditional expectation (“We send it Monday at 4:00 pm”), or a commitment, used only where the bank is bound. Second, link each phrase to the system rule behind it, such as a cut-off value or a calendar. Third, keep a wording register with an owner and an approver for every phrase, and re-review when the batch time, rail or holiday calendar changes.

The timing map worksheet

Fill one row per customer action that touches the core: transfers, bill payments, deposits, card freezes, address changes. Do it with the core owner in the room.

Illustrative worked example: a Friday evening transfer at Bank A

Bank A is invented. Its rules are also invented: domestic transfers above its instant limit leave in one batch at 4:00 pm on working days, its calendar skips Saturday and Sunday, the core posts the debit to the ledger at 11:30 pm on the day of the request, and it cannot see when the receiving bank credits the money. Actual weekends differ by country and, as the Standard Chartered table shows, by currency, so use your own calendar.

The row for the first moment, filled in, reads: action “Send money to a saved payee”; core “request queued, memo debit applied, batch at 4:00 pm on working days”; screen now “Received” with the cut-off line; screen later “Sent” at release, no “Completed”; promise “We send it Monday at 4:00 pm,” a conditional expectation; owner a content designer, approver the compliance lead, with payment operations confirming the batch time and calendar; trigger any change to batch time or calendar.

Two choices carry the design. The ledger movement at 11:30 pm does not change the label, because the money has not left the bank. And since the core sends no completion signal, the app never says “Completed,” so every promise stays inside what the core can see.

Where do these defaults stop working?

The sources are regulator texts, vendor documentation and bank help pages. They show how documented rules and well-known banks behave, not how your customers behave, and a bank’s own pages can be indicative or out of date, as Standard Chartered’s note says. Cut-offs, rails and holiday calendars change, so recheck any figure here against your bank’s current terms. The guide does not cover card disputes, Shariah review of product terms, or the engineering of real-time cores, and the wording examples need your compliance team’s approval.

What can you produce now?

Four things before anyone draws a screen: a timing map for your five most frequent core-touching actions, a state list with the label and notification for each state, a wording register with owners and review triggers, and a Friday-evening test, run in a test environment with the core’s clock set after the cut-off.

If you are choosing a design team, give each candidate one of your real actions and ask for a filled timing map. Our comparison of design agencies used to bank compliance and legacy systems lists studios with published bank cases to start from.