This public consultation is intended to focus on a key part of maintaining market integrity: avoiding self-matching. We hope to engage all market participants to agree on a set of standard functionality, features and behavior regarding self-match prevention.
Date
30 Apr 2025
Looking from an exchange point of view, SMP can be operated in two different flavors using local versus market-wide SMP ID. Local SMP IDs apply in the context of a specific trading participant e.g. to avoid self-matching of proprietary orders. Local SMP IDs always require the same trading participant on both sides to trigger a SMP event, and there is no need to register such SMP IDs at the exchange. Market-wide SMP IDs are used by different brokers providing trading services for the same end client to prevent self-matching of orders entered on behalf of the end client. Consequently, Market-wide SMP IDs do require an exchange registration procedure but do not require the same trading participant on both sides to trigger a SMP event.
It seems that the aspect of local versus market-wide SMP IDs is not properly reflected in the consultation paper. For example, "Area for Exchange Standardization" - Point (1) is only referring to the concept of market-wide SMP IDs and is not mentioning the concept of local SMP IDs. Furthermore, the differentiation between local and market-wide SMP ID might impact "Area for Exchange Standardization" - Point (5) since a limitation of market-wide SMP IDs could make sense to avoid overburdening, to ensure an efficient usage and to reduce manual registration and maintenance efforts of market-wide SMP IDs. Finally, Market Participants should be aware of the differentiation between local and market-wide SMP IDs which, consequently, could be reflected in the "Consideration of Market Participants".
Some remarks about SMP and synthetic matching affecting "Areas for Exchange Standardization" - Point (8).
Point (8)b: Implied pricing might not be referring to any order type.
Point (8)c: When looking about any kind of implied pricing, it should be made transparent that implied pricing is exclusively based on passive orders resting in the orderbook. Implied pricing is combining different sides of different orderbooks and, consequently, there are no incoming and passive order facing each other for execution in the same orderbook.
A self-execution in the context of implied pricing takes place after a calendar spread involved in the implied pricing is decomposed into leg trades, and the leg trade side resulting from such a decomposition is balanced by the opposite trade side resulting from a different orderbook. This is completely outside the logic how SMP events are defined and, consequently, should be excluded from the point "Order Types and Behaviors Covered".