A wallet address is not a person. Neither is a customer id. Monitoring resolves both onto one identity, so an alert names somebody you can act on and behaviour split across venues stops looking like unrelated events.
On-chain tools flag addresses. Order-book tools flag customer ids. Both are correct, and neither knows the other exists, so one person appears twice as two people who never met.
Splitting flow across venues hides from any view keyed on the client id alone. It does not hide from the identity.
Nothing is inferred by heuristic. A match is an analyst's judgement, or an import from your own KYC base, and each is recorded as what it is.
The client roster is read from your order flow itself, busiest first, with a filter for the ones still waiting for a name.
One click from the roster, or from the identity's own page. A client already held by somebody else names the holder before it moves.
A roster import maps client ids to identities in bulk, and stays distinguishable from a manual match forever after.
"Is there anything wrong with this person" used to mean checking two screens and hoping you remembered the third.
On-chain and order-book alerts in one list, counted over everything that matched and not just the rows that fit on screen.
A conclusion about a person belongs on the person, not on whichever alert happened to be open that day.
A bulk import creates "Jean Dupont", a roster creates the same person. Folding one into the other moves everything and keeps the trail.
Launch a market-abuse scan across all of a subject's wallets at once, and hear about the ones that were refused.
Matching a client id to a name by heuristic would produce a false positive indistinguishable from a true one, on the data used to accuse somebody of market manipulation. A roster import is different: it comes from your KYC base, which is a source and not a guess.
It is yours, kept verbatim from your feed, and meaningful only inside your workspace. Two organisations using the same string never meet.
That is the normal case, and the point. One person trading under a separate id per venue or per sub-account resolves to one subject.
No. The order table is append-only and holds no identity. The match lives beside it and is resolved when a page is read, so correcting one never rewrites history.
Any time, and deleting an identity takes its matches with it. The order records are untouched either way.
Bring one venue export and see how much of the book you can already attribute.
Schedule a demo, access technical documentation, or receive a customized compliance assessment.