Xmon: Multi condition rules engine now available

Xmon tracks reference data requests and can validate them against a defined set of cost and/or volume-based rules. Xmon’s powerful rule engine applies controls at the user level, organisation level and levels in-between and allows proactive data access management to be implemented. Using Xmon’s Active control mode, data analytics are computed in real-time and evaluated against access and quota rules to determine whether or not a request should authorised.

We are happy to announce that the Xmon Rules Engine is now enhanced with a new redesigned User Interface, supporting multi-condition rules and unlocking even greater potential for cost control and data access permissioning.

There is a range of conditions you can set within a rule. Below is a non-exhaustive list and description of the most important conditions.

  • Cost: helping you set a cost limit per request, avoiding large cost spikes.
  • Volume: number of securities contained within a request.
  • Request Type: filter by requests sent in Ad-hoc pricing with quick data return, as opposed to Scheduled pricing.
  • Data System: this condition enables you to monitor requests per system and environment.
  • Specific days and times: Select the time and date range to monitor specific requests.

 

Let’s have a look at a practical example on how you can control cost using the new enhanced rule feature.

Clients using Bloomberg Scheduled requests as their main source of data download will be able to define a limit on count of securities, whenever they want to request new securities quickly and on the fly. Setting up a new multi-condition rule alerting you of a request made in this Pay As You Go mode with a large volume of securities, for when you need a new security request to return data within 15 minutes, will help you stay on top of the cost, while keeping large daily requests in Scheduled mode flowing uninterrupted. This feature is thus a form of a proactive control to avoid being charged twice for the same market data when requested in both pricing models.

Here’s an example rule definition that sets a hard limit for any request whose number of securities exceeds 50 in pay-as-you-go model.

We sent two requests with the above set up.

The first request (in green below) shows that the count of securities is below 50 and has been received without the rule being triggered.

The second request (in red) has been blocked as the count of securities surpasses 50 securities (it contains 100). Consequently, the Xmon will block the request and alert you of the breach via e-mail.

 

In case you do not wish to block requests, you have the ability to create soft limits and granular workflows for approval of the requests.

If you’re looking to optimise your market data spend even further, get in touch!