- Hot Topics
Several of the recent regulatory issues refer to rejecting or canceling orders. One example of this is the about-to-become-live Market Access Rule. I am uncertain as to whether the regulations, which sometimes seem to treat the words "rejected" and "canceled" synonymously, directly infer a FIX ExecReport(ExecType=Rejected) and ExecReport(ExecType=Canceled) respectively.
With the upcoming Market Access Rule, if a user exceeds his/her credit limit, the broker/dealer can "refuse to process" the order (I won't say rejected or canceled here). According to our compliance department, this order is OATS reportable.
From what I understand, many of our customers know that a FIX ExecReport(ExecType=Rejected) means "doesn't require OATS reporting", whereas a FIX ExecReport(ExecType=Canceled) means "does require OATS reporting.
So are we now entering a new age where a FIX ExecReport(ExecType=rejected) may conditionally require OATS reporting?
As a sideline to this, is there a field somewhere in the ExecReport that indicates if the order is OATS reportable or not?
> As a sideline to this, is there a field somewhere in the ExecReport that indicates if the order is OATS reportable or not?
I'm not sure. I do believe there is a field to indicate if something is tape reportable: ReportToExch(113). But that's for tape reporting, not OATS reporting.
I could see an argument for adding a new field, e.g. ReportToRegulator, which is used in parallel with ReportToExch. It may also be worth extending this, as well as ReportToExch, into Trade Capture Report.
FIX Trading Community
[ original email was from John Harris - firstname.lastname@example.org ]
Your post reminded me of these words from the Declaration of Independence:
"He has erected a multitude of New Offices, and sent hither swarms of Officers to harass our people and eat out their substance."
But those were written in the days before electronic trading, when men did not bow so readily those who would presume to direct their lives. So, because you are one of the good guys, let me try to answer your question, and reply to Ryan's post on this subject as well.
OATS is a FINRA system, the rules and regulations pertaining to which are here:
The Market Access Rule (Rule 15c3-5 under the Securities and Exchange Act of 1934) is explicated here:
(The rule itself is only a few pages long and presented at the end of the above document.)
Clearly, what the SEC intends under the Market Access Rule is for broker-dealers to REJECT orders that fail to pass the SEC's bureaucratic guidelines. The SEC does not want broker-dealers to accept and then cancel these orders. But the SEC does not bother to specify the actual implementation details and seems oblivious to the fact that some poor guy has to actually implement the required behaviors in software or hardware. And the SEC is equally oblivious of how market makers actually work and how this rule will either force market makers (especially in fixed-income markets) to either reduce liquidity provision or else to suffer mass, mandatory cancellations of passive liquidity as others aggress against this liquidity. But I digress, out of my abundant loathing of the bureaucrats at the SEC. Suffice it to say that the bureaucrats want orders rejected, not cancelled, when said orders fail to pass its ill-defined tests. So when that happens, ideally, protocol users will be reporting (or receiving, as the case may be) the numeric-equivalent value of "Rejected" in the ExecType <150> field.
OATS recording and reporting is a separate matter. I am not sure how or why customers ever took to the notion that rejected orders were OATS-exempt. I see no such exemption in the rules. According to my reading of the OATS rules, orders rejected for 15c3-5 reasons should be recorded and reported for OATS purposes. This is consistent with what your compliance department advises.
As to Ryan's suggestion of a "ReportToRegulator" field: this is unnecessary. I know of no cases in which regulatory reports are discretionary. Accordingly, the value of this field will would always be "Yes" or "True" and thus implicit. There is no point in burdening protocol users with this detail.
That said, I do think it would be valuable to extend the list of values for ExecType, so that when orders are rejected on 15c3-5 grounds, this fact can be made explicit and unambiguous to users.
Hope this helps.
> Several of the recent regulatory issues refer to rejecting or canceling orders. One example of this is the about-to-become-live Market Access Rule. I am uncertain as to whether the regulations, which sometimes seem to treat the words "rejected" and "canceled" synonymously, directly infer a FIX ExecReport(ExecType=Rejected) and ExecReport(ExecType=Canceled) respectively.