Overview Free wallet risk check Open Monitoring All products ↗ Pricing ↗ Supported chains ↗ Contact ↗ Request a demo ↗ Glossary ↗ Blog ↗ Newsletter ↗ Status ↗
Seqlense Monitoring

Order-book abuse

Wash trading, smurfing and layering live in the shape of the flow: in what was cancelled, how fast, and by whom. Monitoring reads your own order feed and comes back with a finding per client, per book, per pattern.

From your CSV to a named alert

Your export goes in as it is. Five stages later an alert names a client, a book and the pattern that fired, with the source row still attached.

1 - Map
Your columns
Headers matched once per venue. The profile is reused for every later file.
2 - Validate
Dry run
A sample is checked and reported before a single row is written.
3 - Store
Order events
One row per event, never per order, with the source line kept verbatim.
4 - Scan
Per client, per book
Findings come back as (client, book, pattern), not as one verdict per run.

Re-posting a batch is safe: event ids are derived from content, so a replay converges instead of double-counting.

Patterns that live in the book

Order-book abuse is not on-chain abuse with different words. It shows up in the shape of the flow: in what was cancelled, how fast, and by whom.

Wash trading

Buying and selling against yourself to manufacture volume. Amounts are compared exactly, because drift there is a false negative nobody would notice.

Order bookCross-account

Smurfing

One order split into many small ones to stay under every bar. Splitting across venues is only visible to a run that reads several books at once.

Cross-venueThreshold evasion

Layering and spoofing

Orders placed to move the price and pulled before they fill. Measured from cancel timing and origin, which is why those fields matter in your export.

Cancel ratioSub-second

Not evaluable, and said so

A detector whose feed lacks the field it needs reports the signal as not evaluable and names what is missing, instead of returning a negative built on absent data.

CoverageHonest verdicts

A scan covers an organisation, not a subject

An on-chain scan returns one verdict on one wallet. An order-book run reads a whole slice of flow and comes back with a finding per client, per book, per pattern.

Run launched over a windowpending
Thresholds resolved for your organisationdispatched
Every book read, cross-venuerunning
Findings scored per client and bookscoring
Alerts raised, one per subjectdone

Narrowing a run to a single book loses the cross-venue signal outright. Leaving venue and instrument empty is the normal case.

Your bar, not ours

Thresholds are set per organisation, and the bar that judged is written into the alert so a verdict can be re-read rather than re-argued.

Behaviour that continues stays one alert

A pattern still running across daily scans does not re-raise. Once it is resolved and recurs, it fires again.

A bad file is not a bad day

Undo one import

The wrong timezone or the wrong decimal separator is removed on its own. The record that the import happened is kept and marked.

The source row settles it

Every event keeps the line it came from. Months later that is the only thing that settles a dispute over an alert.

See it on your own book

One venue export is enough to get the first findings back.

Speak with Sales

Schedule a demo, access technical documentation, or receive a customized compliance assessment.