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

Two flows.
One subject.

Seqlense Monitoring watches on-chain wallets and order-book flow in the same place, and ties both to the person behind them. An alert names a client, not a hash.

Hosted in Europe · MAR / MiFID II order-record retention · Full audit trail

Linked wallets
3 chains
Order-book clients
2 venues
Open alerts
1 critical
IDENTITY
Subject
Person · FR
Wash trading · cross-venue
Matched to one identity
On-chain + order book
Two engines
5 years
Order-record retention
CSV or API
Ingestion
Europe
Hosting

An alert that names somebody

Surveillance tools flag an address or a customer id. Neither is a person. Seqlense resolves both onto one identity, so a wallet flagged on Monday and a trading client flagged on Thursday stop looking like two unrelated events.

On-chain wallets

Addresses across the chains the scanner covers, with their enrichment, their scan history and their recurring schedules.

Linked to an identity
Order-book clients

The customer ids in your own order feed, kept verbatim. One person trading under a separate id per venue resolves to a single subject.

Matched to an identity

One page per subject

Their wallets, their client ids, every alert raised on any of them, and the notes your team left last time.

Cross-venue behaviour becomes visible

Splitting flow across two venues hides from any view keyed on the client id alone. It does not hide from the identity.

Two engines, one case file

They read different data and answer to different rules. Their findings land in the same alert list, against the same subjects.

On-chain market abuse
Wallet scan

Scan a wallet on demand or on a schedule. Counterparty risk, behavioural patterns and a verdict you can archive.

  • Scan from a wallet or a whole identity
  • Recurring scans per wallet
  • Thresholds set per organisation
  • Archived report behind every alert
Order-book abuse
Flow scan

Run across a whole organisation's order flow. Findings come back per client, per book and per pattern, not as one verdict.

  • Wash trading, smurfing, layering
  • Cross-venue, not one book at a time
  • Thresholds set per organisation
  • Says when a signal could not be assessed

A detector that lacks the data to judge reports it as not evaluable, and names the missing field.

Your export, as it is

No schema to conform to before you can try anything. Map your columns once, keep the profile, and reuse it for every file that venue sends.

1
Map your columns

The wizard reads your headers and proposes the match. Timezone and decimal separator are declared once for the file, not guessed per row.

2
Dry run first

A sample is validated and reported before anything is written. This is what stops eighty thousand rows landing with the wrong timezone.

3
Undo one import

A bad file is removed on its own, and the record that it happened is kept. No purging the workspace to fix one mistake.

The source row is kept

Every event stores the line it came from, verbatim. It is the only thing that settles a dispute over an alert months later.

Re-importing is safe

Event ids are derived from content, so replaying a file that timed out converges instead of double-counting.

Built around the second look

Raising an alert is the easy half. What decides whether a tool is used is what happens when someone opens it three weeks later.

Filters that match the question

By subject type, by tag, by date range, by source. A link you send a colleague opens on exactly what you were looking at.

Notes that outlive the alert

"Client verified, recurring false positive" belongs on the person, not on whichever alert happened to be open that day.

Mistakes are reversible

Deleted wallets and identities go to a trash. Duplicate identities merge. A bad import is undone without touching the rest.

Made to be defended

An alert you cannot explain to a regulator is not worth raising.

Order records kept five years

MAR and MiFID II expect it, and the order table is that record. It carries no expiry, deliberately.

Every action is logged

Who matched a client, who resolved an alert, who launched a scan, who removed an import, and when.

The bar that judged is recorded

Alerts carry the thresholds applied and the coverage of each pattern, so a verdict can be re-read, not re-argued.

Hosted in Europe

One tenancy key scopes every read and every write. Nothing crosses between organisations.

Frequently asked

Getting started

Do I need a developer to integrate?

Not to start. Order data goes in as a CSV through the mapping wizard, and a wallet is scanned by pasting its address. An API is there when you want to automate it.

What file formats do you take?

CSV exports, whatever the column names. You map them once per venue and the profile is reused. Both a final-state-per-order export and a full event log are accepted.

Can I try without an account?

Yes, on a wallet: the free risk check runs without signing up. Order-book monitoring needs a workspace.

Data and compliance

Where is my data held?

In Europe. Every query is scoped to your organisation, including the ones that resolve an identity.

How long do you keep order records?

Five years, with no automatic expiry, because that table is the order record MAR and MiFID II expect you to hold. Shortening it is your decision, not a storage default.

Do you decide who is a person?

No. Matching a client id to an identity is always an analyst's judgement or an import from your own KYC base. Nothing is inferred by heuristic.

See it on your own data

Start with a wallet in the free check, or bring one venue export and watch the first alerts land against named clients.

Speak with Sales

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