The EU Listing Act: Insider List and MAR Changes as an Engineering Task

The Listing Act is being read in most compliance functions as unambiguously good news: fewer disclosures, a higher directors’-dealings threshold, a lighter insider list. It is good news. But the relief only reaches you if the systems that collect and store this data are changed to reflect it, and that is an engineering task, not a legal one.

Regulation (EU) 2024/2809 — the Listing Act — was published in the Official Journal on 14 November 2024 and entered into force on 4 December 2024. It amends the Prospectus Regulation, MiFID II and the Market Abuse Regulation together. The MAR changes are the ones that touch operational systems every listed issuer runs: the insider list, the surveillance and disclosure workflow, and the register of managers’ transactions. None of those obligations lives in a policy document. They live in a database, a workflow tool and an access-control model. If the regime eases and those systems do not change, you keep collecting what you no longer have to, and you keep disclosing on a trigger the law has moved.

What actually changed in MAR

Three changes matter for the technology function. First, the notification threshold for persons discharging managerial responsibilities (PDMRs) under Article 19 rose from EUR 5,000 to EUR 20,000 per calendar year, with national competent authorities able to raise it to EUR 50,000 or lower it to EUR 10,000. Second, the delayed-disclosure regime in Article 17 was rewritten: in a protracted process, intermediate steps no longer trigger immediate disclosure, and the old “delay is not likely to mislead the public” condition is replaced by a requirement that the delayed information not contrast with the issuer’s latest public communication on the same matter. That change applies eighteen months after entry into force — around June 2026 — so it is a near-term deadline, not a done deal. Third, the insider list is being simplified: the alleviated format previously reserved for SME growth-market issuers is being extended to all issuers, with ESMA having finalised the draft implementing technical standards in October 2025, ahead of Commission adoption expected to take effect during 2026.

Verify the exact application date and any threshold your national authority sets before you configure anything. The substance is settled; the calendar in each member state is worth confirming against the transposing measures.

The insider list is a data model, not a spreadsheet

Most firms still treat the insider list as a maintained document. Under the alleviated format it is more honestly a small database with an access-control policy. The simplification is specific and it is about fields. Personal telephone numbers and full home addresses come out. Identification is satisfied by a national identification number, or, where that is unavailable, a date of birth — not the fuller set of personal data the old templates demanded. Where an external adviser has access, you record one nominated contact person for that provider, and the provider keeps its own internal record, rather than you enumerating every individual at the law firm or the bank.

If your insider list is a locked spreadsheet, you cannot cleanly stop collecting the fields the regime has dropped, and you cannot prove who saw what. Modelling it as a table with roles makes the eased regime enforceable rather than aspirational. A minimal schema for the event-based list, with permission-based access, looks like this.

-- Alleviated insider-list model (event-based section)
-- Reflects Listing Act easing: no personal phone/home address;
-- national ID number OR date of birth; nominated contact per provider.

CREATE TABLE inside_event (
    event_id       BIGSERIAL PRIMARY KEY,
    reference      TEXT NOT NULL,          -- deal/project code word
    description    TEXT NOT NULL,
    identified_at  TIMESTAMPTZ NOT NULL,   -- when inside information arose
    closed_at      TIMESTAMPTZ             -- NULL while still open
);

CREATE TABLE insider (
    insider_id     BIGSERIAL PRIMARY KEY,
    event_id       BIGINT NOT NULL REFERENCES inside_event(event_id),
    full_name      TEXT NOT NULL,
    -- Provide national_id_number; fall back to date_of_birth only
    -- where the national identifier is genuinely unavailable.
    national_id_number TEXT,
    date_of_birth  DATE,
    function_reason    TEXT NOT NULL,       -- why the person is an insider
    provider_id    BIGINT REFERENCES adviser(provider_id), -- NULL if internal
    access_from    TIMESTAMPTZ NOT NULL,
    access_to      TIMESTAMPTZ,
    CONSTRAINT id_present
        CHECK (national_id_number IS NOT NULL OR date_of_birth IS NOT NULL)
);

CREATE TABLE adviser (
    provider_id    BIGSERIAL PRIMARY KEY,
    provider_name  TEXT NOT NULL,           -- external firm
    contact_person TEXT NOT NULL            -- single nominated contact
);

-- Permission-based access: only the insider-list custodians read/write;
-- everyone else is denied, and every read is logged for the supervisor.
CREATE ROLE insider_list_custodian;
GRANT SELECT, INSERT, UPDATE ON insider, inside_event, adviser
    TO insider_list_custodian;
REVOKE ALL ON insider FROM PUBLIC;

The point is not the SQL. It is that “we removed the home-address field” and “only two named people can read the list” are now assertions you can demonstrate from the schema and the grants, which is exactly what a supervisor asks for. The same discipline that produces machine-readable prospectus filings for ESAP applies here: a regulatory simplification you cannot show in your data model is a simplification you have not actually taken.

Delayed disclosure moved the trigger, not just the wording

The rewrite of Article 17 is the change most likely to be mis-implemented, because it looks like softer language and is in fact a different trigger. Under the old regime a firm running a protracted process — a negotiation, an acquisition, a capital raise — had to assess each intermediate step as potentially disclosable and justify delaying it. Under the new regime, only the final circumstances or event require disclosure, and the delay is permissible so long as it does not contrast with the issuer’s latest public statement on the matter.

That is a decision-logic change in your disclosure workflow. If the tool still prompts a disclosure assessment at every intermediate milestone, it is enforcing the superseded rule and generating over-disclosure. If it never checks whether the delayed information contrasts with the last public announcement, it is missing the new condition. The classification logic that decides when the clock starts has to be rebuilt to the new test — the same engineering problem I have described for reporting-clock pipelines under other regimes, where the hard part is never the deadline but the trigger condition that starts it.

The over-collection trap

The failure mode with any easing regime is not under-compliance. It is inertia. Systems keep doing what they were configured to do, and a firm that has read the Listing Act, briefed the board and updated the policy still runs an insider list that captures home addresses and a surveillance workflow that flags intermediate steps — because nobody changed the configuration. That is worse than doing nothing, because you are now holding personal data you have no basis to hold and generating disclosure noise that obscures the events that matter. Under-configuration also cuts the other way: a firm that strips fields the regime still requires, or drops the new contrast test, has manufactured a control gap while believing it has taken relief.

Treating this as an engineering task is the discipline that avoids both. It is the same move as reading any obligation as concrete engineering deliverables rather than a memo: identify the fields, the triggers and the access rules the amended text actually requires, then change the data model, the workflow logic and the grants to match — and keep the before-and-after as evidence.

Who this is for

This is for the issuer’s CTO or head of engineering who owns the insider-list system and the surveillance tooling, the company secretary who maintains the list day to day, and the compliance owner who will be asked to show a supervisor that the easing was implemented rather than merely noted. The Listing Act hands you relief. Your systems decide whether you collect it or leave it on the table.