[This message was posted by Hanno Klein of Deutsche Börse Systems <hanno.kl...@deutsche-boerse.com> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/8874f655 - PLEASE DO NOT REPLY BY MAIL.]
The warning can be issued in multiple ways and should be subject to bilateral agreement. It could be out-of-band, it could be a generic message such as UserNotification, it could be a more specific message informing about a utilization rate relative to the pre-defined limit. Warnings only make sense if you have time to react and avoid to exceed further limits that might lead to a slowdown, rejection or disconnect. Plain vanilla risk limits are like a switch. This requires to be quite conservative, regardless of the market situation on that day. It is better to have multiple risk levels of which only the last one results in the inability to trade. Disconnect are not desirable in the context of risk limits as you want the member to be able to see and reduce his risk. You just don't want him to be able to increase it. The ThrottleType of RiskLimit says what is being used as a basis for the detection of a condition requiring throttling. It is not an inbound rate and not the number of outstanding requests being measured. The ThrottleAction (not the ThrottleType) defines the throttle to be imposed, e.g. queue inbound. You are right that the Throttle component is something needed in the PartyRiskLimit messages to describe throttles per risk limit type. But that is outside of this proposal. > > I would like to propose two minor additions in terms of valid values > > that should provide useful: > > > > 1) Additional ThrottleAction "4=Warning" to allow notification of the > > user before actual throttling takes place > > How would the warning take place? Out of band? An existing FIX message? > > > 2) Additional ThrottleType "2=Risk Limit" to allow throttling when > > exceeding risk limits > > I'm not sure I understand how this would work. I had thought risk limits > were like a switch; if you exceed them, you can't trade anymore. > > Party Risk Limits Report, as defined in EP105, just states a limit, as > well as optional textual warning level names and the percent of the > limit at which they are issued. > > In the case of integrating risk limits and throttling, I'm guessing > you'd have a lower risk limit, at which point a customer is throttled, > and a higher risk limit, at which point the customer can no longer > trade. Or possibly there may be multiple levels of increasing risk > limits, at which point the customer could be more aggressively > throttled. > > I also don't see how ThrottleType = Risk Limit would work. It sounds > like you're saying, "If a risk limit is exceeded, then impose this > throttle." But the throttle to be imposed would itself need to indicate > if it limited the inbound rate or the outstanding requests, which is > what ThrottleType does. I'd like to consider extending Party Risk Limits > Report to indicate that if a given risk limit is exceeded, then a given > throttle will be turned on. [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
