Many originators of market data traditionally licensed their content based on the number of users in consumer’s firm. As technology evolved from green screen terminals to multi-user systems, the same piece of content could be used for the benefit of the same individual by multiple systems, displays, or distribution methods. While a number of providers chose to price their services by user of each of the methods of consumption, certain providers allow their customers to “net” usage across some or all of their products.
Three models of netting are worth noting and are exemplified by publically published documents from certain parties. None of the examples below are specific to any single bilateral relationship, though it is important to note that some bilateral agreements may exist. They are presented in no certain order, and specific policies and providers are picked purely as illustrations.
NYSE’s Multiple Installation for Single Users (MISU) policy, which can be found at https://www.nyse.com/publicdocs/nyse/data/MISU_Policy_with_FAQ.pdf. In this type of policy, the recipient of content is responsible for identifying situations where the product is being consumed in a way that is compliant with the MISU policy. The recipient would remit fees to the provider for all instances of access, but would receive credits for those the provider agrees fall under the MISU’s scope.
From the perspective of modeling, where do netting rules fit? While they are calculated as part of Payment Duty, netting policies are often specific to a subset of products that may be covered by a single agreement. As such, do we need a property for Products that indicates that netting rules may apply to them, or can we define netting exclusively in the Duties section, making back references to the specific products they apply to?
An important practical consideration is to decide if a Product needs to know if it is net-table.
Consider a payment structure that is very uncommon today in Market Data, but is heavily used in other areas – micro transactions. In this model, each access either generates a small cost to the user, which is subtracted from their running balance, or is granted for free due to netting rules. Once the balance falls below a pre-defined threshold, a new payment is made and applied to the account’s balance. In our example, the access method for the Product may need to check with an Inventory Management system to see if the access should be granted because it would produce no extra fee, or a charge should be applied against the client’s balance. If Netting is defined as a Duty only, would an Access Management System even know to check netting rules before charging the client? In this example, it would be very useful for the Product to indicate that it is net-table, lest the Access System checks all duties for all products at all times, or charges the client at all times, then the client would be responsible for applying for credits (see MISU model above).
While this specific payment structure is somewhat theoretical, there is anecdotal evidence of it showing up in our industry already.
Many originators of market data traditionally licensed their content based on the number of users in consumer’s firm. As technology evolved from green screen terminals to multi-user systems, the same piece of content could be used for the benefit of the same individual by multiple systems, displays, or distribution methods. While a number of providers chose to price their services by user of each of the methods of consumption, certain providers allow their customers to “net” usage across some or all of their products.
Three models of netting are worth noting and are exemplified by publically published documents from certain parties. None of the examples below are specific to any single bilateral relationship, though it is important to note that some bilateral agreements may exist. They are presented in no certain order, and specific policies and providers are picked purely as illustrations.
From the perspective of modeling, where do netting rules fit? While they are calculated as part of Payment Duty, netting policies are often specific to a subset of products that may be covered by a single agreement. As such, do we need a property for Products that indicates that netting rules may apply to them, or can we define netting exclusively in the Duties section, making back references to the specific products they apply to?
An important practical consideration is to decide if a Product needs to know if it is net-table.
Consider a payment structure that is very uncommon today in Market Data, but is heavily used in other areas – micro transactions. In this model, each access either generates a small cost to the user, which is subtracted from their running balance, or is granted for free due to netting rules. Once the balance falls below a pre-defined threshold, a new payment is made and applied to the account’s balance. In our example, the access method for the Product may need to check with an Inventory Management system to see if the access should be granted because it would produce no extra fee, or a charge should be applied against the client’s balance. If Netting is defined as a Duty only, would an Access Management System even know to check netting rules before charging the client? In this example, it would be very useful for the Product to indicate that it is net-table, lest the Access System checks all duties for all products at all times, or charges the client at all times, then the client would be responsible for applying for credits (see MISU model above).
While this specific payment structure is somewhat theoretical, there is anecdotal evidence of it showing up in our industry already.