The scam claim queue the Shared Responsibility Framework creates

What the framework actually requires

The Guidelines on the Shared Responsibility Framework were issued on 24 October 2024 and took effect on 16 December 2024.

The framework assigns duties to financial institutions and to telcos, and requires a payout to the affected customer where those duties were not met. Responsibility falls in a waterfall: the financial institution first, the telco second.

The volume is real. Phishing scams recorded the second highest number of reported cases of any scam type in Singapore in 2025, at 6,264 cases, with about S$39.9 million lost, according to the Singapore Police Force. Most involved unauthorised card transactions after victims handed over card details and one-time codes.

It covers a defined category of phishing scams. It is not a general scam compensation scheme, and treating it as one is a common early mistake - it produces a lot of unnecessary work.

Four stages, one owner

The framework describes the handling of a claim in four stages: claim, investigation, outcome and recourse.

The financial institution is the primary point of contact with the customer, and coordinates with the telco where a telco is involved. Both run their own investigations at the same time.

So the bank owns the relationship for the whole duration, including the stretch where it is waiting on somebody else. Anyone who has run a service desk knows what that means in practice.

A phishing claim is also intelligence. The 2026 FATF and APG mutual evaluation names fraud and scams among Singapore's prominent money laundering threats, so the evidence gathered for a claim is often the first view of a wider network.

Where the 21 and 45 days actually go

The deadline sounds generous until you break a single claim into the work it contains.

1. Take the claim and classify it, including whether the framework applies at all.
2. Pull the transaction trail and the account history.
3. Retrieve the customer's due diligence records and prior contact history.
4. Establish which duties applied, and evidence whether each was met.
5. Coordinate with the telco and track what you are waiting on.
6. Reach an outcome, write it up, and send it to the customer.
7. Keep the whole file reviewable for whoever asks later.

Now multiply that by claim volume during a scam wave, when arrivals cluster and headcount does not.

The deadline is a reporting problem first

Twenty-one business days is roughly a calendar month. Most teams find out they are going to miss it somewhere around day fifteen, which is late for a structural reason.

If a claim's state is spread across a case manager, an inbox and somebody's spreadsheet, nobody can see the queue as a queue.

The useful view is not a closure percentage. It is how many claims are open, how many days each has left, which ones are blocked, and on what.

A blocked claim waiting on a telco response and a blocked claim waiting on an internal document look identical in a backlog count. They need different people to fix them.

Written outcomes are evidence, not correspondence

The framework requires a written outcome to the customer. It is worth being deliberate about what that letter contains.

A year later, in a dispute or a review, the letter and the file behind it are the record of how the bank reached its conclusion. If the reasoning lived in an analyst's head and the letter states only the result, there is nothing to stand on.

So the useful test for a claim file is simple. Can somebody who was not there reconstruct the decision from what is written down? If not, the claim is closed but it is not finished.

What the preparation layer changes

Source: Guidelines on the Shared Responsibility Framework, issued 24 October 2024, effective 16 December 2024.

Results reported across one active deployment show what happens when evidence assembly stops being manual: case response time moved from about three days to under an hour, and analyst hours per case fell roughly 75%.

Those figures come from a different market and a different case type. The mechanism is the same one, and it is the mechanism that transfers rather than the number.

What we would build first

If a Singapore bank asked where to start, it would not be the payout decision. That stays with your people, under your policy.

It would be everything before it: intake and classification, evidence assembly from the systems the claim touches, deadline tracking that shows the days remaining rather than the days elapsed, and a file that holds together when someone reopens it.

Get that right and the deadline stops being the thing you manage. It becomes a number you happen to meet.

The volume problem nobody plans for

Claims do not arrive evenly, and the framework's clock does not care.

A scam wave produces a cluster of claims within days of each other, all starting their 21 or 45 business day windows at roughly the same time. Headcount does not cluster, so a month later a large number of deadlines land in the same week.

That is a forecasting problem before it is a staffing one. A queue view showing days remaining rather than days elapsed makes it visible weeks ahead, which is the only point at which anything can be done about it.

The alternative is discovering it on day fifteen of the earliest claim, when every option left is expensive.

Where claims stall, in order

Four stalls account for most missed deadlines, and only one of them involves the customer.

1. Waiting on internal evidence that exists but has not been retrieved yet.
2. Waiting on the telco, which the bank cannot accelerate and must track explicitly.
3. Waiting on a duties assessment that needs someone senior who is working other claims.
4. Waiting on the write-up, where the decision is made and the file is not finished.

The fourth is the most avoidable and the most common. A decision that is not written down is not a completed claim, and the framework requires a written outcome.