From first meeting to first alert.

Security vendors love to describe their platforms and hate to describe their onboarding — because onboarding is where the promises meet your compliance team. We'd rather have that conversation in public. This note walks through a typical engagement, in order, with the parts that usually stay in the fine print stated plainly: where the data lives, who can see it, what happens when you leave.

Week 0 — scoping, with no data in the room

The first conversation establishes three things: the adversary you face (fraud rings, mule networks, coordinated agents), the data you already hold (transactions, accounts, events), and the regime that data lives under. Nothing is uploaded, sampled, or “previewed” at this stage. The output is a written scope: the lawful basis for processing, the deployment target, and what a successful pilot means in numbers your team already tracks — alert precision, review load, time-to-first-evidence.

One decision matters more than the rest: where the engine runs. The answer is always some version of inside your perimeter — your virtual machines, your private cloud, or, for sovereignty-critical environments, a fully air-gapped installation (that deployment is called ARNOR; nothing in it phones home, by construction). We do not operate a multi-tenant cloud that your records flow into, because the simplest way to guarantee data never leaves your jurisdiction is to never move it.

Week 1 — deployment your security team can actually audit

The detection core is deliberately small and dependency-free — no framework sprawl, no transitive supply chain your security review has to chase. That is an unfashionable engineering choice and a very deliberate security one: what you audit is what runs. Access to the operator console sits behind your network controls plus its own authentication — salted, iterated password hashing and signed, stateless session tokens — and every ingest and detection endpoint requires it.

Just as important is what doesn't happen in week one: our engineers do not get standing access to your environment. Support runs on the diagnostics you choose to export — health states, throughput counters, never records.

Weeks 1–2 — connecting data without surprises

Pilots start with a batch export — typically 90 days of transactions and the account book, as CSV or JSON. The import path is built for the person doing the importing: every file is schema-checked and previewed — required fields, date and amount validation, row-level issues listed — and the confirm button stays disabled until the errors are zero. No half-loaded datasets, no silent coercions. From there, teams graduate to the streaming API: batches posted to an authenticated endpoint, the graph updating live in the console as they land.

Two properties of the pipeline do quiet but heavy lifting for data protection. First, the engine's features are behavioural — degrees, timing, amounts, counterparty structure — so it runs perfectly well on pseudonymised identifiers; display names are a convenience for analysts, not an input the models need. Second, every accepted batch is written to an append-only ingest log before anything else touches it, so the system's state is always reconstructible from first principles — restart it and it replays to exactly where it was.

Weeks 2–3 — calibration, or: your baseline, not ours

We've published why this step is non-negotiable: priors that look obvious do not transfer between domains (our agentic-detection note documents one inverting outright). So the models calibrate on your data: the legitimate baseline is fit from your history, deterministic rules are tuned to your typologies, and if you hold labelled cases, the supervised layer trains on them — inside your perimeter, like everything else.

Calibration ends with the most operational conversation of the engagement: choosing the operating point. The engine produces a precision/recall table at concrete review budgets — what you catch if your team works the top 0.1%, 0.5%, 1% of ranked accounts each day — and you pick the trade-off your staffing supports. The alert volume is a decision you make, not a firehose you receive.

Week 3 onward — the working loop

Day to day, your analysts work the console: a live entity graph, a geospatial view, and a ranked alert queue where every alert carries its evidence — the drivers that raised it, which detection layers agree, and a recommended action sequence (contain, recover, investigate, report). Each decision can be exported as a case dossier: a machine-readable evidence chain in the W3C provenance format, sealed with an integrity hash, fit for a regulator, a court, or your own audit archive.

And the loop closes: when an analyst confirms or clears an alert, that label is stored durably and the model retrains on it — visibly, with a training counter in the interface, so the team can watch the system converge on their judgement rather than take it on faith. Weekly during a pilot, we review the numbers that matter — precision at your chosen budget, review load, coverage — and recalibrate together.

None of this is exotic. That is, in a sense, the point: handling regulated financial data safely is mostly a matter of refusing the architectures that make it unsafe, and then doing a small number of things — validation, provenance, explainability, human control — with discipline. Simple to run, hard to compromise, honest about what it knows. That is the product.