/811-regulations-eu-market-abuse-regulation

name: 811-regulations-eu-market-abuse-regulation
description: Use when reviewing, designing, or modifying Java enterprise systems that may support EU Market Abuse Regulation concerns, market surveillance, suspicious order and transaction reports, insider dealing controls, unlawful disclosure controls, market manipulation detection, inside information disclosure workflows, insider-list evidence, PDMR transaction notifications, alert explainability, model or rule provenance, reviewer decisions, or compliance escalation. This should trigger for requests such as Review a Java trading surveillance system for MAR controls; Design suspicious order and transaction monitoring evidence; Add alert explainability and reviewer-decision audit trails; Assess AI-assisted market-abuse detection before production release. Part of Plinth Toolkit
license: Apache-2.0
metadata:
  author: Juan Antonio Breña Moral
  version: 0.18.0

EU Market Abuse Regulation for Java Enterprise Market Surveillance Controls

Use this Skill to review Java enterprise applications, trading systems, order-management services, transaction-monitoring pipelines, market-data platforms, surveillance services, disclosure workflows, insider-list tooling, alert triage applications, investigation records, CI/CD workflows, or operational tooling that may support Market Abuse Regulation (MAR) concerns.

Apply this Skill to determine what engineering controls, reviewable evidence, and escalation paths are needed before a system is released, connected to production trading data, used for suspicious order or transaction monitoring, used to manage inside information, or used to support market-surveillance decisions.

This Skill is not legal advice. It helps Java engineers, architects, tech leads, platform teams, market-surveillance teams, compliance engineering teams, and reviewers identify when MAR concerns may apply and how to translate market-integrity expectations into enterprise architecture controls such as suspicious order and transaction monitoring, insider dealing controls, market manipulation signals, inside-information disclosure evidence, insider-list workflows, alert explainability, model and rule provenance, reviewer decision trails, false-positive handling, investigation records, observability, change control, documentation, and compliance evidence handoff.

The purpose of this Skill is to increase awareness of potential gaps in the system and create engineering evidence for qualified review. The response produced by this Skill does not represent legal advice, a legal opinion, a determination of insider dealing, market manipulation, unlawful disclosure, reportability, jurisdiction, or a final regulatory determination.

The main question is:

> When does a Java enterprise financial system require MAR-aware market-surveillance controls, and what should developers build differently?

External reference: [Market Abuse Regulation (EU) No 596/2014](https://eur-lex.europa.eu/eli/reg/2014/596/oj/eng).

Market Abuse Regulation chapters summary reference: [MAR chapters summary](references/811-regulations-eu-market-abuse-regulation-chapters-summary.md).

Java engineering examples reference: [MAR engineering examples](references/811-regulations-eu-market-abuse-regulation-engineering-examples.md).

Questionnaire asset: [MAR engineering review questionnaire](assets/questions/811-market-abuse-regulation-engineering-review-questionnaire.md).

Report template asset: [MAR engineering review report template](assets/reports/811-market-abuse-regulation-engineering-review-report-template.md).

Scope

This Skill applies to:

• Java systems supporting investment firms, trading venues, issuers, market-data platforms, surveillance platforms, order-routing services, transaction reporting, alert triage, investigation case management, disclosure workflows, insider-list workflows, and compliance reporting
• Spring Boot, Quarkus, Micronaut, and framework-agnostic Java services with trading orders, transactions, market data, instrument reference data, inside information, disclosure events, insider lists, alert scoring, reviewer decisions, or regulator-facing evidence
• APIs, message consumers, batch jobs, repositories, schemas, Kafka topics, event streams, data lakes, rule engines, ML models, dashboards, review queues, investigation workflows, reports, and release gates that can affect market-surveillance evidence
• Systems requiring evidence for suspicious order and transaction monitoring, market manipulation signal detection, insider dealing controls, unlawful disclosure controls, inside-information disclosure timing, delayed disclosure records, insider-list retention, PDMR transaction notification support, model or rule provenance, explainability, false-positive handling, and owner handoff
• Changes involving database migrations, Kafka message contracts, rule thresholds, feature flags, model retraining, alert suppression, reviewer decision states, market-data lineage, privileged access, operational dashboards, and production release gates

Market Abuse Regulation Engineering Review

Treat insider dealing, unlawful disclosure, market manipulation, reportability of suspicious orders or transactions, disclosure-delay legality, financial-instrument scope, market-sounding interpretation, accepted market practices, sanctions, jurisdiction, and regulatory interpretation as governance decisions for legal, compliance, market-surveillance, risk, product, operations, and accountable business owners.

Engineering teams should still create evidence that makes those decisions reviewable:

• Which trading venue, instrument, issuer, order, transaction, quote, benchmark, commodity, emission allowance, market-data source, disclosure workflow, insider list, alert model, rule set, reviewer queue, or investigation record may be in scope
• Which clients, traders, issuers, PDMRs, insiders, surveillance analysts, compliance reviewers, operations teams, data owners, and