rules<\/em>\u00a0are here.<\/p>\n\n\n\nNo issuer owes all of it.<\/strong> Each section opens with the fact that triggers it.<\/p>\n\n\n\n1. When it attaches \u2014 earlier than most teams assume<\/strong><\/h2>\n\n\n\nApplies to every reader. A pure issuer that never seeks admission to trading is outside this Regulation entirely, and can stop here.<\/em><\/p>\n\n\n\nArticle 2(1)<\/strong> attaches MAR to financial instruments admitted to trading on a regulated market or a multilateral trading facility, or for which a request for admission has been made<\/strong>. A DLT-based venue authorized under the pilot regime is an MTF for this purpose. The trigger is the request, not the first trade. So the insider list and the closed-period machinery below have to be live before the admission application is filed<\/strong>, not built during onboarding.<\/p>\n\n\n\nThe scope test is instrument-based, not entity-based. A non-EU issuer whose token is admitted to an EU venue is inside; the fact that the issuer holds no EU authorization is irrelevant. Article 2(4) reaches conduct outside the Union in relation to in-scope instruments.<\/p>\n\n\n\n
Three duty sets, triggered independently<\/strong><\/h3>\n\n\n\nThe issuer's own set \u2014 Article 17 disclosure, Article 18 insider lists, Article 19 managers' transactions, Article 11 market soundings, the Article 5 safe harbour, and the Article 8\u201315 prohibitions \u2014 attaches on admission and never goes away. The venue operator's Article 16(1) duty to prevent and detect abuse is the venue's, not the issuer's. The third set, Article 16(2), is discussed in section 10, because whether it reaches a plain issuer is a question rather than a settled fact.<\/p>\n\n\n\n
2. The rule that keeps most of MAR off-chain<\/strong><\/h2>\n\n\n\nApplies to every module in this article. It is why the on-chain surface is two contracts and not seven.<\/em><\/p>\n\n\n\nAn on-chain record earns its place only when an on-chain function gates on it. Most of MAR fails that test on purpose: crossing a notification threshold makes a transaction\u00a0notifiable, never unlawful<\/strong>; being on an insider list restricts no trade. Disclosing inside information is a duty owed to the market, not a condition a transfer can check. A contract computing any of those could only emit an alert an indexer would raise anyway, while pricing worse, unable to compute business days, and unable to correct an immutable total after a bad feed.<\/p>\n\n\n\nWhat gates is the closed period<\/strong><\/h3>\n\n\n\nA manager who tries to move the issuer's instrument inside a closed period is doing something the Regulation prohibits, and a transfer hook can refuse it. That is the whole of MAR's on-chain surface:\u00a0PdmrClosedPeriodFreeze<\/code>\u00a0and the register it reads. Everything else below is a document, a calendar, an indexer, or a person.<\/p>\n\n\n\n3. Closed periods \u2014 Article 19(11)<\/strong><\/h2>\n\n\n\nApplies from admission. Bites hardest on an issuer whose directors, and their families, hold the token.<\/em><\/p>\n\n\n\nArticle 19(11)<\/strong>\u00a0prohibits a person discharging managerial responsibilities from conducting any transactions in the issuer's shares, debt instruments. Or linked instruments during a closed period of\u00a030 calendar days<\/strong>\u00a0before the announcement of an interim or year-end financial report the issuer is obliged to publish. Calendar days \u2014 not trading days, not a month.<\/p>\n\n\n\nOn-chain.<\/strong> We build<\/strong> PdmrClosedPeriodFreeze<\/code> as a date-range block on every flagged wallet, reached through a thin adapter on the rule engine like every other gate. Three properties matter more than they look:<\/p>\n\n\n\nIt checks both sides of the transfer.<\/strong> The Article prohibits \"any transactions\" \u2014 acquisitions as much as disposals. A gate that inspects only the sender lets a director buy<\/em> through the window on the strength of the results they are about to announce, which is the abuse arriving from the other direction.<\/p>\n\n\n\nThe window ends at the actual announcement, not the scheduled date<\/strong><\/h3>\n\n\n\nThe naive form is\u00a0block.timestamp <= reportDate<\/code>, and it fails on the ordinary case of results slipping by a week. The scheduled date passes, the freeze lifts itself, and every flagged wallet is free to trade during precisely the days when the unpublished numbers are most certainly inside information. So the issuer schedules the period through\u00a0schedulePeriod()<\/code>\u00a0and closes it through\u00a0recordAnnouncement()<\/code>; an unannounced period stays frozen past its scheduled date indefinitely. Late results extend the freeze. They do not end it.<\/p>\n\n\n\nA live window cannot be cancelled, and the slip case has its own call<\/strong><\/h3>\n\n\n\nCancellation exists \u2014 an interim report genuinely dropped from the calendar \u2014 but only\u00a0before<\/em>\u00a0the window opens. Once flagged wallets are frozen, a cancellation that unfreezes them has no honest reading, and if it is the only call available it is also the one an issuer with slipping results is forced to make. The audit trail then cannot distinguish a rescheduled report from an evasion. So a live window is rescheduled instead,\u00a0later only, against a mandatory evidence reference<\/strong>, keeping its opening date so frozen directors stay frozen and moving only the far end. A window that has not yet opened is recomputed from the new date. Pulling a report forward is refused outright: the way to end a window early is to publish the report.<\/p>\n\n\n\nIt is prospective only.<\/strong> Scheduling a period whose window has already opened cannot reverse transfers that settled inside it. Publishing the financial calendar at least 30 days ahead is therefore a control, not an administrative preference, and any window opened late leaves a gap that has to be reviewed off-chain against the Article 8 prohibitions.<\/p>\n\n\n\nThe freeze needs an override path, or it is non-compliant by over-blocking<\/strong><\/h3>\n\n\n\nArticle 19(12)<\/strong>\u00a0permits the issuer to allow a manager to trade inside a closed period on two grounds only: exceptional circumstances such as severe financial difficulty compelling an immediate sale, or the characteristics of the trading \u2014 employee share or saving schemes, and transactions where the beneficial interest in the security does not change. The criteria are in Commission Delegated Regulation (EU) 2016\/522. A hard date-range block with no exception path reverts transfers the Regulation expressly permits, and the fix cannot be a redeploy mid-period.\u00a0grantPermission()<\/code>\u00a0is governance-gated, per wallet, per window, names the ground as an enumerated value rather than free text, and carries a hash of the issuer's written reasoning. The log\u00a0is<\/em>\u00a0the evidence that the permission was granted deliberately.<\/p>\n\n\n\n4. The declared register \u2014 Article 19(5)<\/strong><\/h2>\n\n\n\nApplies from admission. This is the input the freeze reads, and it is the easiest gate in the architecture to under-scope.<\/em><\/p>\n\n\n\nArticle 19 reaches\u00a0persons closely associated<\/strong>\u00a0with a manager, defined in\u00a0Article 3(1)(26)<\/strong>. A spouse or equivalent partner, dependent children, other relatives sharing the household for at least a year, and any legal person, trust or partnership managed by or set up for the benefit of the manager. Their trades carry the same notification duty and the same closed-period prohibition.<\/p>\n\n\n\nWhy it is hard:<\/strong>\u00a0a closely associated person is typically not otherwise known to you. Their wallet is not discoverable from your own onboarding data, and they may hold no relationship with the platform at all.\u00a0The flag set cannot be derived. It must be declared.<\/strong>\u00a0Article 19(5) is what makes the register exist. The issuer notifies its managers of their obligations in writing, the managers notify their own closely associated persons, and the issuer keeps the list.\u00a0A freeze scoped to managers' wallets alone lets a director's spouse trade straight through a closed period<\/strong>. A live breach the contract would report as a clean transfer.<\/p>\n\n\n\nOn-chain<\/strong><\/h3>\n\n\n\nPdmrRegister<\/code>\u00a0is the wallet-address mirror of that legal artefact. Nothing else in the stack knows who a manager is. Four rules the naive version misses:<\/p>\n\n\n\n\nA declaration is effective on entry, not on self-confirmation.<\/strong>\u00a0declareWallet()<\/code>\u00a0is the registrar's act, and the freeze applies from it. The wallet holder may then call\u00a0confirmWallet()<\/code>\u00a0to prove key control \u2014 evidence the issuer wants, not a precondition. Gating the flag on confirmation would hand every closely associated person a trivial opt-out: never confirm, never get frozen.<\/li>\n\n\n\nThe person key is the identity registry's\u00a0personId<\/code>\u00a0where one exists.<\/strong>\u00a0Two person namespaces running in parallel let the same human be one person to the freeze and a different person to everything else. A manager who is also an investor then gets two identities, and the threshold aggregation in section 5 is assembled across the wrong wallets. An unregistered wallet is still declarable. The people this register exists for often have no onboarding record and is marked as not yet anchored rather than rejected.<\/li>\n\n\n\nThe register decays silently.<\/strong>\u00a0People marry, separate, and set up trusts without telling the issuer. Nothing in the Regulation fixes a re-attestation cadence; we run one anyway, and\u00a0flagStaleDeclaration()<\/code>\u00a0surfaces a person whose declaration has aged out.<\/li>\n\n\n\nRecords are revoked, then purged after a retention period \u2014 never deleted live.<\/strong>\u00a0The register is the evidence that a freeze was or was not owed on a given date. \u26a0\ufe0f\u00a0Check what that retention period actually is before writing it down as a legal requirement: Article 19 imposes none.<\/strong>\u00a0The five-year duties in this Regulation are the market-soundings records under Article 11(8), the website retention of disclosed inside information under Article 17(1), and the insider list under Article 18(5) \u2014 the managers'-transactions Article carries no record-keeping provision at all. So a purge window here is\u00a0operator policy by analogy to Article 18(5)<\/strong>, not a statutory minimum. And what actually binds is the standing Article 19(5) duty to maintain the list. The distinction matters the moment an erasure request arrives: refusing it is defensible on a documented policy, and indefensible on a citation that does not exist.<\/li>\n<\/ul>\n\n\n\nWhat is on-chain is a salted hash and a wallet \u2014 and the events carry less than the storage does<\/strong><\/h3>\n\n\n\nNames, relationships and the nature of the association never reach the chain in any form: an address is pseudonymous, a stored family relationship is not. The event layer is stricter again. A declaration emits the\u00a0wallet and an opaque declaration hash, and nothing else<\/strong>. Not the person key, not which manager a closely associated person is associated with, not the role. <\/p>\n\n\n\nPut the person key in a log and it states permanently that a set of addresses is one human. Put the association in a log and it names, for the life of the chain. Someone's spouse or child who under this Regulation would never be named at all unless they traded above the threshold. Storage can be deleted; a log cannot.\u00a0The who and the what are storage reads, and the indexer joins them off-chain from data the operator already holds.<\/strong><\/p>\n\n\n\n5. Managers' transactions \u2014 the notification engine is off-chain, and that is a decision<\/strong><\/h2>\n\n\n\nApplies from admission. This is where a contract looks like the obvious tool and is the wrong one.<\/em><\/p>\n\n\n\nArticle 19(1)<\/strong>\u00a0requires a manager or closely associated person to notify the issuer\u00a0and<\/strong>\u00a0the competent authority of every transaction on their own account in the issuer's instruments, promptly and no later than\u00a0three business days<\/strong>\u00a0after the transaction. The duty applies once transactions in a calendar year reach the\u00a0Article 19(8)<\/strong>\u00a0threshold of\u00a0\u20ac20,000<\/strong>, counted\u00a0by adding without netting<\/em>.\u00a0Article 19(9)<\/strong>\u00a0then lets a\u00a0competent authority<\/strong>\u00a0move that threshold\u00a0in either direction<\/strong>\u00a0up to\u00a0\u20ac50,000<\/strong>\u00a0or down to\u00a0\u20ac10,000<\/strong> informing the European Securities and Markets Authority of the decision and its reasons.<\/p>\n\n\n\nThat second sentence is the one to build against, and it is easy to read as a single upward option. It is not.\u00a0The threshold is three-valued, the authority sets it rather than the Member State, and the direction that matters commercially is the one people forge<\/strong>t. An engine hard-coded to twenty or fifty thousand silently under-reports for every manager in a jurisdiction whose authority chose ten. Over-notifying costs a filing nobody reads; under-notifying is the breach.<\/p>\n\n\n\nThe issuer then has its own deadline, under\u00a0Article 19(3)<\/strong>: make the notified transaction public within\u00a0two business days of receiving the notification<\/strong>. Note where that clock starts\u00a0on receipt, not on the transaction<\/strong> which is why the issuer's alert has to fire on the on-chain transfer rather than on the manager's paperwork arriving.<\/p>\n\n\n\nThe aggregation reads like contract work and is not<\/strong><\/h3>\n\n\n\nCrossing the threshold makes a transaction notifiable, never unlawful, so nothing gates. And a contract would do the job worse in three specific ways. <\/p>\n\n\n\n
\nIt needs a price feed to\u00a0estimate<\/em>\u00a0a euro consideration the settlement leg already knows exactly. <\/li>\n\n\n\nThe deadlines run in business days, which a contract cannot compute per Member State. and <\/li>\n\n\n\n An on-chain running total is immutable, so one bad price corrupts the person-year with no correction path.\u00a0The indexer recomputes.<\/strong><\/li>\n<\/ul>\n\n\n\nSix rules move off-chain with it, and each is a way the engine gets built wrong<\/h3>\n\n\n\nRule<\/th> Why the obvious implementation is wrong<\/th><\/tr><\/thead> Aggregate per person<\/strong>, through the register's wallet-to-person join<\/td>A per-wallet counter undercounts anyone holding two addresses, which for a manager is the normal case<\/td><\/tr> Never net<\/strong> buys against sells<\/td>A netting counter lets a manager trade all year and never cross<\/td><\/tr> Calendar<\/strong> year<\/td>Not rolling 365 days, not the issuer's financial year<\/td><\/tr> The threshold is \u20ac20,000, \u20ac50,000 or \u20ac10,000 \u2014 those three and nothing else<\/strong><\/td>A per-jurisdiction parameter, not a free number: an engine that accepts an arbitrary threshold accepts one nobody crosses. Three values, not two<\/strong> \u2014 the authority's option runs downward as well, and a \u20ac20,000 floor under-reports wherever it was taken<\/td><\/tr>An unpriceable transaction fails closed on the reporting determination<\/strong> \u2014 mark the person-year indeterminate and notify anyway \u2014 but never blocks the transfer<\/strong><\/td>Under-notifying is a breach; over-notifying costs a filing<\/td><\/tr> Fire the issuer's alert on the on-chain transfer<\/strong>, not on the manager's notification arriving<\/td>A director who files late otherwise consumes the issuer's own publication window before the issuer knows a trade happened<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n6. Inside information, and what a public ledger does to it<\/strong><\/h2>\n\n\n\nApplies from admission. This section governs every contract upgrade, parameter change and migration for the life of the instrument.<\/em><\/p>\n\n\n\nArticle 7(2)\u2013(3)<\/strong>\u00a0treats a protracted process a negotiation, a restructuring, a planned change as inside information, and each intermediate step may itself be inside information. Since the Listing Act amendments to Article 17 took effect, the duty to disclose as soon as possible attaches only to the\u00a0final event<\/strong>\u00a0of such a process. The intermediate steps carry a\u00a0standalone confidentiality duty<\/strong>\u00a0until then.\u00a0Article 17(4)<\/strong>\u00a0permits delayed disclosure on three cumulative conditions with notification to the authority.\u00a0Article 17(7)\u2013(8)<\/strong>\u00a0requires immediate disclosure once confidentiality is lost, and full public disclosure after any selective one.<\/p>\n\n\n\nNow consider what a smart-contract upgrade looks like on a public chain. A timelocked upgrade is scheduled by a transaction that publishes the target and the calldata in the clear.\u00a0That is an intermediate step, published to everyone, before the final event.<\/strong>\u00a0The breach is confidentiality, not lateness and that changes the cure. You cannot fix a public intermediate step by disclosing earlier, because the disclosure duty has not yet attached. And you cannot delay under Article 17(4) what the chain has already published.<\/p>\n\n\n\nWe build nothing that reverts here<\/strong><\/h3>\n\n\n\nThe standard timelock takes calldata in the clear and offers no concealed variant. What survives is a classification and a scheduling rule. Each upgrade type is classified as intermediate or final\u00a0before<\/strong>\u00a0scheduling. Where the step is intermediate and confidentiality is still owed,\u00a0the clock is not started<\/strong>, the operation is scheduled late. Where the step is in fact final, the announcement is released before or with the transaction. The indexer carries a leak alert, because an on-chain leak is machine-detectable the moment the transaction is mined.<\/p>\n\n\n\nNor do we commit documents early, and the same reasoning is why<\/strong><\/h3>\n\n\n\nThe tempting mechanism is a salted commitment. Anchor a hash-of-a-hash to a document nobody may yet see, open it when the final event is disclosed. But a commitment hides\u00a0what<\/em>\u00a0was anchored, not\u00a0that<\/em>\u00a0something was and for a document confidential precisely because it is undisclosed inside information, publishing that something was committed is publishing that the inside information exists.\u00a0The control breaches the duty it exists to protect.<\/strong>\u00a0There is no commit-reveal in the document registry.<\/p>\n\n\n\nWhat does the work is anchoring later, which is the document-side form of scheduling later<\/strong><\/h3>\n\n\n\nA document not anchored until the final event is disclosed has no confidentiality exposure to engineer around. A commitment only ever buys a provable pre-announcement timestamp, and nothing in this regime asks for one on-chain. A delayed disclosure under Article 17(4) is evidenced by the notification to the competent authority, and the Article 18 insider list keeps its own dated record off-chain where it must live in any case, because it is personal data.\u00a0The rule, in both lanes: if confidentiality is owed, do not put the artefact on the chain yet. Do not put a clever shadow of it there either.<\/strong><\/p>\n\n\n\nDisclosed inside information stays on the issuer's website for at least five years<\/strong> under Article 17. The document registry's hash gives an integrity proof across that period; the hosting is the issuer's.<\/p>\n\n\n\n7. Insider lists \u2014 off-chain, and no anchoring contract<\/strong><\/h2>\n\n\n\nApplies from admission. Stated because the tempting build is wrong for two independent reasons.<\/em><\/p>\n\n\n\nArticle 18<\/strong> requires the issuer to keep an insider list with per-event sections and an optional permanent section, to obtain written acknowledgment from each listed person, and to retain the list for at least five years after it is drawn up or updated. Article 18(6) gives issuers on an SME growth market a reduced format.<\/p>\n\n\n\nThe list is off-chain. The tempting addition is a contract anchoring a hash of each version for the retention period, and it fails the section 2 test: nothing on-chain gates on insider status, and the Regulation never asks a contract to read it. Two further reasons against it. A qualified electronic timestamp carries a legal presumption of accuracy and integrity that a chain hash does not, so it is the stronger artefact in front of a regulator. And anchoring an\u00a0event-based<\/em>\u00a0section publishes a timestamped signal that a new piece of inside information came into existence on that date around an unannounced transaction, the anchor pattern is itself the leak.<\/p>\n\n\n\nOne tokenization-specific entry.<\/strong>\u00a0Multisig key holders and anyone with upgrade authority hold standing access to undisclosed material changes. They belong in the\u00a0permanent<\/strong>\u00a0section, not a per-event one and unlike everything else on the list, that population is derivable from privileged-key state.<\/p>\n\n\n\n8. Market soundings \u2014 before any token exists<\/strong><\/h2>\n\n\n\nApplies to any issuer that pre-markets an issuance to anchor investors. It bites before admission, during the period most teams think MAR has not started.<\/em><\/p>\n\n\n\n\nArticle 11(3)<\/strong>\u00a0and\u00a0Article 11(5)<\/strong>\u00a0govern the disclosing side of a market sounding. <\/li>\n\n\n\nObtain the recipient's consent to receive inside information (11(5)(a)), <\/li>\n\n\n\n then inform them in scripted terms that they may not use it to deal (11(5)(b)), <\/li>\n\n\n\n may not cancel or amend an existing order in the instrument (11(5)(c)), and <\/li>\n<\/ul>\n\n\n\nare bound by confidentiality (11(5)(d)) and keep a written record of what was given, to whom, and when.\u00a0<\/p>\n\n\n\n
Article 11(6)<\/strong>\u00a0requires that record to be provided to the authority on request, and the recipient to be told when the information ceases to be inside information. That close-out is the step teams forget, and it is the one that releases the recipient from the dealing ban.<\/p>\n\n\n\nNothing here touches a contract. It is a scripted, recorded procedure, and it is an issuer-lane duty that is easy to miss because it runs during pre-marketing.<\/p>\n\n\n\n
9. The buy-back safe harbour \u2014 Article 5<\/strong><\/h2>\n\n\n\nApplies only to an issuer repurchasing its own shares<\/strong>. This is the section the design is most often wrong about, in a direction that is expensive.<\/em><\/p>\n\n\n\nArticle 5(1)<\/strong> disapplies the Article 14 and 15 prohibitions to trading in own shares<\/strong> in a buy-back programme that meets its conditions. Three limits follow before any mechanism is discussed.<\/p>\n\n\n\nIt covers shares.<\/strong> A tokenized bond, a fund unit, or a revenue-participation token repurchased by its issuer is not inside this safe harbour. That does not make the repurchase abuse; it means the repurchase stands on the general prohibitions with no presumption in its favor, and the closed-period rule in section 3 still reaches it. A design that applies \"the Article 5 harbour\" generically to every buy-back is applying an exemption that does not exist for most tokenized instruments.<\/p>\n\n\n\nIt covers three purposes.<\/strong> Article 5(2): reducing the issuer's capital; meeting obligations arising from debt instruments exchangeable into equity; meeting obligations from employee share or option schemes. \"General corporate purposes\" and price support are outside it.<\/p>\n\n\n\nIt is all-or-nothing.<\/strong> Miss one condition and the exemption is not reduced; it is unavailable for that trading, which is then judged on ordinary manipulation grounds. That is why every condition below is a revert in the buy-back module and none is a warning event.<\/p>\n\n\n\nThe conditions<\/h3>\n\n\n\n Article 5(1)(a)<\/strong>\u00a0\u2014 full details of the programme disclosed before the start, meaning start date, end date, maximum consideration, maximum number of shares and maximum price.\u00a0Article 5(3), as amended by the Listing Act<\/strong>\u00a0\u2014 trades reported as belonging to the programme to a\u00a0single<\/strong>\u00a0competent authority, the one for the most relevant market in terms of liquidity under MiFIR Article 26(1), which forwards on request; an internal pipeline still filing with every venue's authority is running the pre-December-2024 pattern. <\/p>\n\n\n\nCommission Delegated Regulation (EU) 2016\/1052 \u2014 price no higher than the higher of the last independent trade and the highest current independent bid; daily volume no more than 25% of average daily volume over the preceding 20 trading days; no selling of own shares during the programme; no trading during a closed period; each transaction made public within\u00a0seven daily market sessions<\/strong>\u00a0of execution.<\/p>\n\n\n\nOn-chain<\/strong><\/h3>\n\n\n\nThe module that carries those as parameters<\/p>\n\n\n\n
\n disclosure anchored before start, <\/li>\n\n\n\n ceilings consumed per purchase, <\/li>\n\n\n\n an oracle-fed price and volume reference that fails closed when stale, <\/li>\n\n\n\n the closed-period gate reused so one calendar governs directors and <\/li>\n\n\n\n treasury alike \u2014 is\u00a0BuybackAgent<\/code>, covered in the distributions article. <\/li>\n<\/ul>\n\n\n\nTwo limits on it are worth carrying here.\u00a0<\/strong><\/p>\n\n\n\n\nThe instrument class is checked first and the module refuses to open a programme on anything but a share<\/strong>. So the \"shares only\" limb above is a revert rather than a note. <\/li>\n\n\n\nAnd\u00a0the no-selling condition is not a contract control<\/strong>. The treasury's units move through the instrument's ordinary transfer rules, where the treasury is a holder like any other. So that condition lives in the programme's operating rules with a named owner. <\/li>\n<\/ul>\n\n\n\nWhat it deliberately is not<\/h3>\n\n\n\n A stabilization contract, which is a different Article 5 harbour with a designated manager and its own conditions and a continuous redemption facility, which is a different regulatory posture altogether and cannot be swapped for a programme after deployment.<\/p>\n\n\n\n
10. Surveillance of your own trading \u2014 a capability, and a question<\/strong><\/h2>\n\n\n\nApplies if the issuer ever trades its own instrument \u2014 a buy-back, a redemption, a treasury operation. A pure issuer that never touches its own book can skip thAs section.<\/em><\/p>\n\n\n\nArticle 16(2)<\/strong> requires any person professionally arranging or executing transactions to have arrangements to detect and report suspicious orders and transactions to the competent authority without delay. It binds investment firms and dealers plainly. A passive issuer admitted to a third party's venue owes nothing under it on other participants'<\/em> trading.<\/p>\n\n\n\nWhether it reaches an issuer's\u00a0own<\/strong>\u00a0trading a buy-back programme run through its own contract is a question with two readings, and this article does not choose. One reading treats an issuer executing its own repurchases as arranging or executing transactions in respect of that flow, and attaches the duty scoped to its own order flow. The other treats \"professionally arranging or executing\" as an intermediary's status that a plain issuer does not acquire by running a programme. Get the answer from counsel before the first buy-back opens.<\/p>\n\n\n\nThe capability is worth building on either reading<\/strong><\/h3>\n\n\n\nBecause the safe harbour in section 9 already requires the issuer to know what its own orders and executions were, and because the offence surveillance has to detect is not visible in settled transfers.\u00a0Article 8(1)<\/strong>, final subparagraph, makes cancelling or amending an order placed before coming into possession of inside information itself insider dealing. A pipeline that indexes only executed transfers cannot see it at all \u2014 the order that mattered was withdrawn, and a withdrawn order leaves no transfer.<\/p>\n\n\n\nSo the surveillance feed is an\u00a0order-lifecycle<\/strong>\u00a0surface \u2014 created, modified, cancelled, alongside executions \u2014 and the indexer replays the order book rather than the register.\u00a0MarketEventSchema<\/code>\u00a0specifies that surface: one schema serving both market-abuse surveillance and, for whoever owes it, transparency reporting, because the two read the same set.\u00a0What does not exist is an issuer-lane emitter for it.<\/strong>\u00a0The buy-back module publishes executions and nothing before them, so an issuer that treats those events as its surveillance feed has a pipeline that cannot see the offence it was built for. <\/p>\n\n\n\n