Appendix B · Monitoring Security and data handling ← Back to the findings

Where monitoring runs, and what stays local.

A matte aluminium padlock; its shackle, closed, is the same deep lapis blue as the tool's accents.

Transaction monitoring handles the most sensitive table a bank holds. This tool's public data is written and generated, so no module needs the network, and none may reach it. The two files you measure with, your alerts and your transactions, never leave your machine.

The network allowlist is empty, and a test reads each file

Routing, a sister tool, fetches model weights once and Screening fetches public sanctions lists. Monitoring downloads no file. Its public test set, a frozen file whose content hash (a fingerprint of its exact contents) is checked, is built from written cases and seeded variants, so the allowlist of modules that may touch the network is empty. A source comment beside that list records the same. A structural test reads each source file for network calls (fetch, node:http, WebSockets and the like) and fails the suite if any module gains one. The detector first proves it can see a planted call. So its zero means it looked and found none.

Verify the network test

Run the suite. The test fails if any file gains a network call.

run it yourself

npm testfails if any module touches the network, and asserts the allowlist is empty

Where it livessrc/frontiere.test.ts:30 · src/frontiere.test.ts:51

No real transaction and no real person appear anywhere public

Each account, amount and date in the public test set was written for the typology it illustrates or generated from those cases under a seed. Nothing in it is anonymised customer data, because customer data is absent altogether. The cases file records this in its own header, and each case carries the one-sentence reason it was written.

Verify the provenance

The cases file gives its provenance, where each case came from.

run it yourself

python3 -c "import json; d=json.load(open('src/cas-etiquetes.json')); print(d['provenance'], len(d['cas']), 'cases, each with a written reason')"

prints: authored 84 cases, each with a written reason

Where it livessrc/cas-etiquetes.json:2 · src/synthetic.ts:71

Your two files stay yours, and the outputs carry no value

The measurement runs at your desk. It reads, in memory, your dispositioned alerts (those your analysts already decided) and your transactions, and writes its outputs next to your files and nowhere else. The outputs hold counts, rates, confidence intervals (the range the true rate likely sits in) and verdicts by your alert id. A verdict is the tool's answer on one alert. None of your account ids, amounts, transaction dates or countries leave the machine. Your alert ids do survive as verdict keys, so choose opaque ones.

It makes no callback, sends no telemetry and needs no account. The whole measurement is a local process reading two CSV files (plain text tables) on your machine.

Verify on your own decoy

Measure a file holding an invented amount and account id, then search the outputs for them.

run it yourself

grep -r "the amount you invented" your-alerts-measured.md your-alerts-measured.jsonfinds no match, because the outputs carry verdicts and none of your values

Where it livessrc/your-alerts.ts:9 · src/your-alerts.ts:25

The test set is hashed, the suite runs offline, and re-measuring needs a visible flag

The public test set is sealed by a content hash, so a figure edited by hand fails loudly. Re-measuring over an existing test set requires an explicit flag on the command line, where an auditor can see it. The whole suite runs with the network cut, and for this tool that is the only way it runs.

Verify the content hash, offline

Cut the network, run everything, then recompute the content hash.

run it yourself

CRUSETRA_OFFLINE=1 npm testthe whole suite, network cutnpm run sceller -- releve-public.json --checkprints "already sealed, and the seal matches"

Where it livessrc/sceller.ts:60 · src/measure.ts:5