Sentinel
A real-time fraud-surveillance pipeline, built to the duty Singapore's Shared Responsibility Framework places on banks: catch an account being rapidly drained by a phishing scam, and act, within seconds.
- SGD 25.00acc-victim → p-grocer07-20 12:00
- SGD 18.50acc-victim → p-grocer07-21 09:30
- SGD 12.00acc-victim → p-hawker07-22 18:00
- SGD 30.00acc-victim → p-grocer07-23 20:00
- SGD 15.00acc-victim → p-hawker07-24 13:00
- SGD 1,800.00acc-victim → mule-8807-25 03:01
- SGD 2,600.00acc-victim → mule-8807-25 03:03
- SGD 3,200.00acc-victim → mule-8807-25 03:05
- SGD 120.00acc-normal → p-utility07-25 13:00
- SGD 60.00acc-normal → p-utility07-25 13:30
Press play. Surveillance scans each transfer in event order; a normal account passes clean, while the victim's account trips the rules the moment the scam drain begins, and every following transfer is held.
Why this exists
Singapore made banks legally liable, with no cap, when a customer is drained by a phishing scam and the bank did not do enough to stop it. One of the bank's required duties is round-the-clock, real-time watching for accounts being emptied fast. This is a working model of that watchman.
The technical depth
The Shared Responsibility Framework(SRF, in force 16 Dec 2024) sets a “waterfall”: when a customer loses money to a defined phishing scam, the financial institution bears the loss first if it breached its duties, then the telco, then the consumer. A breach means full payouts, with no liability cap. The operative duty for engineers is real-time fraud surveillance (from 16 Jun 2025): round-the-clock monitoring to detect and mitigate accounts having material sums rapidly wiped out, reinforced by the Protection from Scams Act 2025 (1 Jul 2025), which lets banks restrict or hold suspicious transfers.
Scope, precisely: this targets the phishing-drain pattern the SRF covers. It is not a general anti-money-laundering system (that is MAS Notice 626, a larger problem).
What “surveillance” concretely means
Four small, individually testable rules score every transfer against that account's own history. They are plain code on purpose: a compliance team has to read and defend each one, so the logic is transparent rather than a black box. Thresholds are tunable inputs, shown here as configured.
| Rule | Fires when | Regulatory concern |
|---|---|---|
| rapid_drain | ≥ 3 transfers or > $5,000 in 10 min | “material sums rapidly wiped out” |
| new_payee_high_value | first-ever payee and ≥ $1,000 | classic money-mule pattern |
| amount_spike | > 5× the account's recent typical | behavioural anomaly |
| odd_hour | transfer between 02:00–05:00 | weak signal, combined with others |
How it's built
The same pipeline shape as any streaming system: data comes in, gets validated, flows through a log, gets scored, and the decisions are stored so they can be proven later. The fraud detector is just one new stage; the architecture didn't change, only the domain did.
The technical depth
Sentinel reuses a generic ingest → stream → detect → persist pipeline. Transfers are validated at the edge, scored on an ordered event stream using event time (not wall-clock time), and every alert and hold is written to an auditable store. The endpoint is stateless and runs the rules on request: the same engine, ported to TypeScript, that has a Python reference implementation with a full test suite. The point it demonstrates: pipeline stages are an interface, and swapping the domain (clickstream to payments) reuses the whole structure.