Do I need a developer to integrate Seqlense Monitoring?

Not to start. Order data goes in as a CSV through the mapping wizard, and a wallet is scanned by pasting its address. A REST API is available when you want to automate ingestion, scans and alert retrieval.

Can I try Seqlense Monitoring without an account?

Yes, on a wallet. The free wallet risk check runs without signing up and returns entity type, tags, categories, sanctions exposure and a risk score. Order-book monitoring requires a workspace.

Seqlense Monitoring | On-Chain & Order-Book Market Abuse Surveillance

The difference

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

0x9f2c…a41b

Flagged Monday. Counterparty risk on a wallet nobody can name.

Order book - venue A

POSTG0000114

Flagged Thursday. Wash trading on one book.

Order book - venue B

77821

Below every threshold, on its own.

Identity

One subject

Three records, one person. The alerts stack on the same file, and the volume nobody saw is the sum of the three.

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

Matched by a person, never guessed

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. Guessing who somebody is would produce a false positive indistinguishable from a true one - on the data used to accuse somebody of market manipulation.

The roster comes from your own flow

The client list is read from your order feed itself, busiest first, with a filter for the ones still waiting for a name. Match one at a time from the roster or from the identity's page, or map client ids to identities in bulk from your KYC base.

One page answers the question

Their wallets, their client ids, every on-chain and order-book alert raised on any of them, and the notes your team left last time. Duplicate identities merge and carry everything with them; a market-abuse scan launches across every wallet the subject holds at once.

The match lives beside the order record, never inside it. Correcting who somebody is never rewrites what they did - and removing a match leaves the order records untouched.

Detection

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. New to the distinction? The two flows, explained side by side.

Wallet scan

On-chain market abuse

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

Scan from a single wallet, or from every wallet an identity holds
Recurring scans on their own schedule, one per wallet
Thresholds set per organisation, not by us
Wallet enrichment kept beside the wallet: entity type, tags, what it has touched
An archived report behind every alert, always

Flow scan

Order-book abuse

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 and spoofing
Cross-venue by default - not one book at a time
Thresholds set per organisation, recorded in the alert
A pattern still running across daily scans stays one alert
Says when a signal could not be assessed, and why

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.

Pending

Run launched Over a window of your order flow.

Dispatched

Thresholds resolved For your organisation, not a global default.

Running

Every book read Cross-venue, in one pass.

Scoring

Findings scored Per client and per book.

Done

Alerts raised One per subject, against the identity.

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

Workflow

How Seqlense Monitoring Works

A structured, auditable workflow. Each step turns raw activity - on-chain or from your own order feed - into actionable, regulator-ready evidence attached to a named subject.

01 Scan Request

02 Data Ingestion

03 Normalization

04 Identity Resolution

05 Behavioral Analysis

06 Abuse Detection

07 Alert & Cases

08 Reporting

01

Scan Request

A wallet scan is launched from an address, from a whole identity, or on a recurring schedule. An order-book run is launched over a window of your order flow, across every venue at once. Both can originate from the web interface, an API call, or a transaction-based trigger such as a customer withdrawal or deposit.

02

Data Ingestion

On-chain data is collected from Seqlense's proprietary blockchain indexer - transactions, token transfers, smart contract interactions and counterparty activity across supported chains. Order data comes from your own venue exports, ingested as CSV through the mapping wizard or pushed server-to-server through the API. Event ids are derived from content, so replaying a file that timed out converges instead of double-counting.

03

Normalization & Contextualization

Raw data is normalized and enriched. Wallets are clustered, transaction sequences reconstructed, and market context such as liquidity, timing and known entities is applied. Order events are stored one row per event - never per order - with the source line from your file kept verbatim beside each one. Transactions are never analyzed in isolation.

04

Identity Resolution

Wallet addresses and order-book client ids are resolved onto the subjects that hold them, so activity split across chains, venues or sub-accounts is read as one person's behaviour. Matching is an analyst's judgement or an import from your KYC base - never a heuristic guess - and the match sits beside the order record rather than inside it.

05

Behavioral Analysis

Monitoring establishes behavioral baselines for wallets, clients and subjects, identifying deviations, coordination patterns and abnormal activity over time. Order-book abuse shows up in the shape of the flow - in what was cancelled, how fast, and by whom - not in any single order. This step focuses on behavior, not individual transactions.

06

Abuse Detection Engine

Behaviors are evaluated through deterministic rule sets aligned with MiCA, ESMA RTS and MAR, combined with statistical and behavioral models designed to reduce false positives while remaining fully explainable. Patterns are scored against thresholds your organisation set, and a detector that lacks the data to judge reports the signal as not evaluable rather than returning a negative built on absent data.

07

Alert & Case Management

When a risk threshold is met, alerts are generated with clear reasoning, timelines and supporting evidence - raised against the subject, not against an anonymous identifier. Analysts filter by subject type, tag, date range or source, and the link they send a colleague opens on exactly the same view. A pattern still running across daily scans does not re-raise; once resolved and recurring, it fires again.

08

Reporting & Regulatory Evidence

Findings consolidate into audit-ready outputs: evidence packs, the thresholds that judged each alert, the coverage of each pattern, and an immutable audit trail of who did what and when. Identities, wallets and alerts export to CSV or JSON. Order records are held for five years, as MAR and MiFID II expect.

Patterns

Types of Market Abuse Detected

Regulatory rule sets and behavioral analysis across both surfaces - what happens on-chain, and what happens in the book.

Insider Trading

Abnormal pre-event trading behavior potentially linked to the use of non-public or privileged information, correlated against wallet baselines and market timing.

On-chain Behavioral MiCA-aligned

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 book On-chain Cross-account

Pump & Dump

Rapid price inflation followed by coordinated sell-offs across multiple wallets or entities, read as one movement rather than a series of unrelated trades.

On-chain Pattern detection Behavioral

Smurfing

One order or one transfer 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.

Order book On-chain Threshold evasion

Layering & Spoofing

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

Order book Cancel ratio Sub-second

Behavioural Clustering

Clustering analysis surfacing coordinated wallet behavior, hidden relationships and emerging manipulation patterns. Every cluster is presented with the reasoning behind it, for an analyst to confirm or dismiss.

Behavioral Explainable Analyst-reviewed

Detection combines deterministic regulatory rules with behavioral analysis to keep verdicts explainable, auditable and defensible. Nothing about who a subject is is ever inferred by heuristic.

Getting your data in

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.

Local

Drop the CSV Headers read in the browser. Nothing leaves your machine yet.

Mapping

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

Dry run

Validate a sample Reported back before a single row is written. This is what stops eighty thousand rows landing with the wrong timezone.

Import

Rows streamed in One event per row, with the source line kept verbatim beside it.

Reusable

Profile saved The next file from that venue maps itself.

Guessing the decimal separator per value is how "1,234" becomes 1.234 in one row and 1234 in the next. It is declared once, for the file.

Undo one import

A file loaded with the wrong timezone or the wrong separator is removed on its own, and the record that the import happened is kept and marked. No purging the workspace to fix one mistake.

The source row is kept

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

Re-importing is safe

Event ids are derived from content, so replaying a file that timed out converges instead of double-counting. Re-posting a batch is not a mistake you have to clean up.

Both export shapes accepted

A final-state-per-order export and a full event log both work. You map them once per venue and the profile is reused from then on.

Investigation

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. Counts run over everything that matched, not just the rows that fit on screen - and 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. The next recurrence does not restart the enquiry.

Mistakes are reversible

Deleted wallets and identities go to a trash an admin can restore from, with everything they were linked to intact. Duplicate identities merge. A bad import is undone without touching the rest.

Compliance

Made to Be Defended

An alert you cannot explain to a regulator is not worth raising. Every step back to the original row is kept, and nothing in the path is rewritten.

Kept verbatim

The source row Your file's line, stored beside the event it produced.

Append-only

The order record No expiry. This table is the record MAR expects you to hold.

Recorded

The bar applied The thresholds that judged, and the coverage of each pattern.

Defensible

The alert Re-readable months later, with who did what and when.

The identity match sits beside the order record, never inside it. Correcting who somebody is never rewrites what they did.

Order records kept five years

Most tables expire in weeks. The order record does not, because MAR and MiFID II expect order data to be held for five years. Shortening it is a compliance decision, not a storage default.

Every action is logged

Who matched a client, who resolved an alert, who launched a scan, who removed an import, and when. Each line links back to the thing it touched.

The bar that judged is recorded

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

Hosted in Europe

One tenancy key scopes every read and every write, including the queries that resolve an identity. Nothing crosses between organisations.

Platform

Start by Hand, Automate Later

Fully managed SaaS, hosted in Europe. You should be able to try this with the export you already have, not after a migration project.

CSV import - no developer

Your venue export, mapped once in the browser through the wizard. It is the right way to see the product on your own data this afternoon, without involving engineering or waiting on a schema agreement.

API - server to server

Scoped API keys against the same endpoints the interface uses. Push order events, launch wallet or flow scans, read alerts back, and drive the whole workflow from your own systems.

Notifications - where you work

Webhook, Slack or Discord, filtered by severity, source and subject type, so a channel only hears what it should. Alerts reach the people who act on them without anyone watching a dashboard.

Web interface

Submit scans, match clients to identities and review alerts directly in the browser. Manual investigation, case management and reporting without any technical integration at all.

Keys you can scope and revoke Shown once, attributed in the audit trail

Unified processing CSV, API or web - same analysis pipeline

Destructive actions need an admin Trash, restore, bulk delete and merge are gated

No on-premise SaaS only - zero local installation

Your data leaves as easily as it came CSV or JSON export, and a purge that reports what it removed

One address, no account

The free wallet risk check runs the same read the product does, on one address, without signing up. Entity type, tags, categories, sanctions exposure and a risk score - across ten chains, rate-limited per IP. It is the shortest way to see what a verdict looks like before you decide anything.

Check a wallet - free Open Monitoring

Use Cases

Who is Seqlense Monitoring For?

Designed for organizations carrying market abuse surveillance obligations under MiCA, MAR and MiFID II - whether their exposure is on-chain, in the book, or both.

Crypto Exchanges & Trading Platforms

Order-book surveillance on your own flow and on-chain monitoring of inflows and outflows, resolved onto the same customers. Wash trading, layering, insider signals and pump & dump, with audit-ready evidence behind each alert.

Brokers & Multi-Venue Intermediaries

One client trading under a different id per venue resolves to one subject, so flow split across books stops hiding below every threshold. Five-year order-record retention held where MAR and MiFID II expect it.

Custodians & Wallet Providers

Recurring scans on customer wallets rather than a check somebody has to remember to run. Abnormal wallet behavior, fund fragmentation and counterparty exposure, with the archived report kept behind every alert.

Compliance & Risk Teams

Alerts that name a person, notes that stay on that person, filters that reproduce the view you sent a colleague, and a full log of who decided what. Mistakes are reversible; the record that they happened is not erased.

Regulatory Mapping

Market Abuse Coverage

Mapping market abuse surveillance expectations under MiCA, MAR and MiFID II to current Seqlense Monitoring capabilities - detection, identity, evidence and retention.

Requirement	Regulatory Expectation	Monitoring Coverage
Market Abuse Signal DetectionMiCA · MAR	Identify and monitor indicators of potential market abuse on an ongoing basis.	Continuous surveillance of on-chain activity and of your own order flow, through deterministic rule sets and behavioral analysis.
Insider Dealing IndicatorsMiCA · MAR	Identification of transactions potentially executed using inside or non-public information.	Detection of abnormal pre-event trading behavior, wallet deviations, and temporal correlation patterns.
Market Manipulation PracticesMiCA · MAR	Detection of manipulative behaviors affecting price formation or market integrity.	Wash trading, pump & dump patterns and coordinated wallet activity, scored against thresholds set per organisation.
Order-Book ManipulationMAR · MiFID II	Surveillance of order entry and cancellation behavior, not only executed trades.	Layering and spoofing measured from cancel timing and order origin, plus cross-venue wash trading and smurfing, read across every book in one pass.
Transaction StructuringMiCA	Identification of fragmented activity intended to bypass monitoring thresholds.	Wallet clustering, order-splitting analysis, and cross-wallet and cross-venue linkage through the resolved identity.
Attribution to a PersonMAR · MiFID II	Ability to attribute surveilled activity to the client or person responsible for it.	Wallets and order-book client ids resolved onto one subject by analyst judgement or KYC import - never by heuristic - with the match kept beside the order record.
Monitoring & AlertingMiCA · MAR	Ongoing surveillance mechanisms and timely alerts when risks are identified.	Automated alert generation, risk scoring and analyst review workflows, with webhook, Slack and Discord delivery filtered by severity and source.
Order-Record RetentionMiFID II · MAR	Order data retained and retrievable for five years.	An append-only order table with no expiry, holding one row per event and the verbatim source line from your file beside it.
Investigation & TraceabilityMiCA · MAR	Ability to justify decisions, reconstruct events, and maintain traceable investigation records.	Evidence timelines, the thresholds and pattern coverage that produced each verdict, investigation notes held on the subject, and a full audit trail of who did what and when.
Suspicious Transaction ReportingESMA RTS	Report suspicious transactions and orders with the supporting detail expected of a STOR.	Each alert consolidates the evidence a STOR requires - the source rows, the pattern that fired, the thresholds applied and the subject it is attributed to - exportable as CSV or JSON.

This coverage focuses on detection, attribution and investigation support. Filing obligations should be assessed against each organization's own internal compliance procedures.

Coverage

Supported Chains

The blockchain networks covered by Seqlense Monitoring for on-chain market abuse detection and surveillance.

18 networks monitored

Bitcoin Layer 1

Ethereum Layer 1

Solana Layer 1

BNB Chain Layer 1

Polygon Layer 2

Arbitrum Layer 2

OP

Optimism Layer 2

Avalanche Layer 1

B

Base Layer 2

B

Blast Layer 2

Dogecoin Layer 1

F

Flare Layer 1

L

Linea Layer 2

M

Manta Layer 2

Mantle Layer 2

S

Sonic Layer 1

TON Layer 1

Tron Layer 1

The free wallet risk check covers ten of these networks. More chains are being added regularly - need a specific one? Let us know.

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.

Open Monitoring Book a demo Reach our team →

Download the whitepaper

The full methodology: detection surfaces, identity resolution, evidence model and regulatory mapping.

API documentation

Endpoints for pushing order events, launching wallet and flow scans, and reading alerts back into your own systems.

FAQ

Frequently Asked Questions

Detection & getting started

What is the difference between on-chain and order-book monitoring?

One reads a public ledger that belongs to nobody, the other reads the trading system your own flow passes through. They catch different halves of the same behaviour, which is why both engines are here. The full explanation, side by side.

What kind of market abuse can Seqlense Monitoring detect?

On-chain: insider trading signals, pump-and-dump, wash trading, fund fragmentation and coordinated wallet behavior. In the order book: wash trading, smurfing, layering and spoofing, read across every venue at once rather than one book at a time.

Which blockchains does it monitor?

18 networks including Ethereum, Bitcoin, BNB Chain, Polygon, Arbitrum, Optimism, Avalanche, Solana and more. Full list below.

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. The 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 for every later file. 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.

Identity, data & compliance

Do I need to configure alerts manually?

No. Monitoring ships with rule sets aligned with MiCA, ESMA RTS and MAR. Thresholds are then set per organisation to match your own risk policy, and the thresholds that judged an alert are written into it.

Do you decide who is a person?

No. Matching a client id or a wallet to an identity is always an analyst's judgement or an import from your own KYC base. Nothing is inferred by heuristic - a guess there would produce a false positive indistinguishable from a true one.

Where is my data held?

In Europe. One tenancy key scopes every read and every write, including the queries that resolve an identity. Nothing crosses between organisations.

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.

How does Monitoring support STOR reporting?

Each alert consolidates what a Suspicious Transaction and Order Report needs: the verbatim source rows, the pattern that fired, the thresholds applied and the subject it is attributed to - aligned with the ESMA RTS on suspicious transaction and order reporting, and exportable as CSV or JSON.

Market Abuse SurveillanceTwo Flows. One Subject.