Societe Generale Commodities Electronic Execution Disclosure

SG, acting as a market maker, on a principal basis, provides liquidity to its counterparts by streaming indicative prices via automated channels, including but not limited to SG-proprietary and third-party electronic platforms and direct Application Programming Interfaces (collectively, “Platforms”). When a trade request at a quoted price is submitted in response to SG’s indicative pricing, SG is not obligated to accept the trade request and may accept or reject the trade request at its sole discretion as pre-trade risk management controls are applied automatically. These pre-trade checks, which may delay acceptance or rejection of a request to trade, are composed sequentially of a Trade Validity Check and a Price Validity Check:

• In the Trade Validity Check, we consider whether the Trade Request has all the appropriate transactional details from an operational perspective (user authorisations, limits on counterparty exposure, and other controls) to confirm that the Trade Request is actionable and that any resulting transaction will be within SG’s credit tolerance for the relevant client.
• In the Price Validity Check, and only following a successful Trade Validity Check, we identify whether a customer’s Trade Request Price, as compared against the refreshed SG client-specific price at which we are willing to trade is within a counterparty-specific price tolerance (“Price Tolerance”) to determine whether we accept or reject the trade, and also whether the difference is within a counterparty-specific price deviation tolerance (“Price Deviation”) past which all trades are rejected. These controls may be applied immediately upon receipt of a submitted Trade Request, or after a short delay (“Holding Period”). The Price Tolerance check is sometimes described as “Last Look”.

The Price Validity Check is intended to protect SG, as a liquidity provider in the electronic commodities markets, against latency inherent in electronic communications or erroneous price formation generated by external systems. It also allows SG to manage its execution risk without downgrading the quality of spreads and liquidity it indicates to counterparties. In the absence of these checks, SG would potentially protect itself by providing less depth of liquidity and wider spreads to counterparties using the Platforms.

By default, SG’s Last Look is “asymmetric”, providing customers with higher fill ratios and deeper, more consistent liquidity. If the Price Validity Check shows that the refreshed price has moved relative to the Trade Request Price by more than the relevant Price Tolerance for that customer but under the Price Deviation, SG will reject the Trade Request only if the price has moved during the period of delay against SG (rather than when price movements have gone in its favour).

The Holding Period refers to the period of time we put the customer’s trade request in a queue once it has been received by SG systems, and before we refresh the customer’s specific price. This period of time may vary between 0 and 200 milliseconds. There may be additional delays due to latencies on customer and external systems, networks, or on our internal systems.

SG does not engage in any hedging activity specific to a particular Trade Request during the pre-trade checks.

All the pre-trade checks may vary by client, based on each client’s connection type, trading platform, trading pattern, and other factors. Thus, pre-trade checks for a single client using multiple connections and trading platforms may differ across connections and platforms. Further, such settings are subject to change by SG without notice.