Restriction, disclosure, disabling: the police orders a Singapore bank has to work

Two different things, often confused

Restriction Orders and the orders against scam-enabling accounts are worth separating at the start, because they protect different people and the operational handling differs.

A Restriction Order under the Protection from Scams Act 2025, in force since 1 July 2025, protects someone who is about to send money to a scammer. The account holder is the potential victim.

The orders in the Scams (Countermeasures) and Other Matters Bill, passed on 9 September 2026, point the other way. They target accounts being used to enable scams, including accounts operated by money mules.

Same bank, same operations team, opposite customer. Getting that distinction wrong in a customer conversation is an unpleasant way to find out your processes were merged.

What each order asks the bank to do

Read down that right-hand column as an operations head rather than a lawyer. Every row is a queue.

Orders arrive before a loss. The Shared Responsibility Framework governs what happens after a phishing loss, and the same operations team usually carries both.

The first of these is already in use. By 1 February 2026 the Singapore Police Force had issued 12 Restriction Orders to banks under the Protection from Scams Act. A separate Facility Restriction Framework for scam mules, operational since 1 October 2025, had placed 550 money mules, 801 SIM card mules and 51 corporate entities under restrictions by 9 February 2026.

The carve-outs are where the work hides

A Restriction Order does not simply freeze everything. The person still needs to eat, pay bills and cover rent, so requests for legitimate expenses have to be assessed and released, and released quickly.

That is not a one-time action. It is an open case that generates repeated requests, each needing a decision, a record and a customer conversation, for as long as the order runs.

Account Disabling Orders come with their own clock. An account can be disabled for up to 30 days, extendable once by up to another 30. Somebody has to track those dates, because an order that quietly outlives its authority is a problem of a different kind.

Appeals raise the evidentiary bar

Both regimes give the affected person a route to appeal to the Commissioner of Police, whose decision is final.

For the bank this changes what the file has to contain. It is no longer enough to have acted on the order. You need to be able to show what you received, when you received it, what you did, when you did it, and what you told the customer.

This is the same lesson that shows up everywhere in financial crime operations. The action is quick. The evidence around the action is the job.

The downstream queue nobody plans for

Acting on an order creates the conversation that follows it, and that conversation is staffed entirely by the bank.

Results reported across one active deployment put a number on how large this can get. Cases generated by account restrictions accounted for 22.4% of an entire post-complaint queue, spread across 37 distinct scenarios.

A restriction can be full or partial, the customer may be reachable or not, documents may be supplied, partially supplied or fail validation. Each combination is a different piece of work with a different correct answer.

Implementation detail is still settling

The Bill passed on 9 September 2026 after a first reading on 4 August 2026. Operational specifics are still being worked through.

That is a reason to design the handling now rather than wait. Teams that build the queue, the tracking and the record while the volumes are small are in a much better position than teams that improvise once the orders arrive daily.

Waiting for perfect clarity before building any process is how a backlog gets its head start.

What we would prepare, and what we would not

The decision to restrict, disclose or disable is the police's. The bank's job is execution, and execution is where the hours go.

CaseLEA handles the part around the decision: reading the order and classifying it, pulling the account and transaction evidence it refers to, preparing the response in the required format, tracking expiry and extension dates, and keeping a record that survives an appeal.

What it does not do is act on your customer's account by itself. A person confirms anything with consequence - that is your policy, your approval threshold, and your name on the outcome.

The tracking problem, stated plainly

Expiry management sounds like an administrative detail until you consider what an expired order means.

An Account Disabling Order runs up to 30 days and can be extended once by up to another 30. A restriction left in place past its authority is a bank acting on a customer's account without a basis, which is a materially different problem from acting slowly.

Manual tracking of that in a spreadsheet works at low volume and fails predictably as volume grows, usually during the period when volumes grow fastest.

So the tracking has to be part of the case rather than alongside it, with the expiry date, the extension status and the responsible owner attached to the order itself.

What to build before the volumes arrive

Four things, in order of how painful they are to retrofit.

• Classification on intake. Which order type, which customer position, which clock starts.
• Expiry and extension tracking. Dates on the case, visible as days remaining.
• The living-expenses workflow. Repeated requests, each with a decision and a record.
• The appeal file. What was received, when, what was done, and what the customer was told.

The fourth is the one teams add last and need first. An appeal to the Commissioner of Police is final, so the file supporting it is the bank's only opportunity to be accurate.