Student proposal: can stolen money be traced across banks in seconds without sharing customer data? Please break this

#fintech #security #architecture #discuss

I'm a 300-level Computer Science student at NOUN in Lagos. I have no professional experience in fraud or banking, so this post is me asking for correction from people who do.

The problem as I understand it

When online fraud happens, the money often moves through several mule accounts and gets cashed out within minutes. Victims usually report hours later. Each bank or wallet only sees its own part of the trail, and privacy and banking secrecy rules (rightly) stop them from freely sharing customer data. So by the time anyone connects the dots, the money is gone.

The idea

Transactions are naturally a graph: accounts are nodes, transfers are edges with a timestamp and amount. My question was why money isn't traced like one across institutions. After reading around, I now understand the main reasons: each institution only holds its own edges, ledgers need strict consistency, and sharing data raises legal and competitive problems.

So my proposal is a federated, privacy-preserving transaction graph:

Each institution keeps its raw ledger and runs a local node.
There is no central database of everyone's transactions.
When fraud is flagged, a machine-readable alert follows the money from node to node. Bank A tells Bank B, "funds from case X arrived in one of your accounts." Bank B checks its own ledger, places a temporary hold, and forwards the alert to wherever the money went next.
The graph is never assembled in one place. It exists as a chain of handoffs.

The machine-only boundary

Only fixed-schema messages cross between institutions, with no free text and no names:

{
  "case_token": "c_8f21...",
  "account_token": "HMAC(consortium_key, account_no)",
  "amount_bucket": "100k-500k",
  "ts": 1767225600,
  "action": "HOLD_REQUEST",
  "sender_sig": "..."
}

Messages would be signed, sent over mutual TLS, rate-limited, and fully audit-logged. The receiving node can recognize its own accounts from the token but learns nothing about unrelated customers. Anything beyond match, hold and forward would require a legal process with a human involved.

Prior work

I know this isn't new. As I understand them, the BIS's Project Aurora, Singapore's COSMIC platform, FinCEN's 314(b) sharing and some federated learning pilots explore related ground. What I couldn't find is an open standard for the cross-institution alert protocol itself, which may mean the gap is real or that I'm missing something. Please tell me which.

Where I think it breaks (please attack these)

Re-identification: if tokens are stable and edges carry timestamps and amounts, could patterns link pseudonyms back to people? Would token rotation, per-case tokens and amount bucketing be enough?
Wrongful holds: automated holds will freeze innocent people. Who is liable, and how should expiry and appeals work?
Legal basis: is the NDPA or banking secrecy law a hard blocker in Nigeria, or can a consortium model work?
Adoption: would a bank or fintech realistically adopt an open spec? Or is a shared blacklist enough and this is overengineered?
Coverage gaps: wallets, crypto exchanges and cash-out agents that don't join would leave dark spots in the trail.
Taint rules: when mixed funds move, FIFO, proportional and "poison" tracing give different answers. Which would a court accept?

What I'd build first

A message spec
A two-node simulator showing a hold propagating across two simulated institutions
A threat model document covering re-identification and false positives

Everything would be open source (Apache 2.0). Keys, detection thresholds and any live network would stay with whoever operates a deployment.

What I'm asking for

Engineers: poke holes in the protocol, token design and failure modes.
People in fintech, banking, compliance or law enforcement: tell me what fraud recovery really looks like today and where this wouldn't fit.
Anyone: point me to existing projects or papers I've missed.

Nothing here is validated. It's a design I want torn apart before I write code, so blunt, specific criticism is the most useful kind. Thanks for reading.

No repo yet. I'd rather get your criticism first, then open one with the spec and a two-node simulator, and I'll link it in the comments once it exists.

DEV Community