Managing Margin (Part 2) – Drowning in Data, Sinking in the Support Effort

In the first blog in our series on the many challenges associated with managing margin requirements, we noted that gathering, classifying, and handling all of the data required for the effort can slow the process to a crawl. Design flaws in the way data and margin rules are stored can make the downstream calculations frustratingly slow. These flaws also ensure that as more accounts are added, and as in-house rules are customized to meet the needs of a growing client base, the more the situation deteriorates.

Those responsible for maintaining a margin system often feel that they are drowning in these data management issues. They struggle to support an increasingly unwieldy structure that does not meet the needs of the business and frustrates those responsible for client relationships and risk management. There is a better way. In part two of this series we discuss ways to make margin calculations far more efficient by streamlining data records that currently take up far too much space and make margin calculations a painful process that is too slow to meet the firm’s need for answers in real-time.

The enemies of efficiency

There are two key areas of inefficiency that tend to choke margin calculations:

#1. Data bottlenecks
A key contributing factor to a margin system’s problems is that many firms store the data needed to calculate margin for different types of instruments in separate databases – data for interest rate swaps in one place, futures data in another, equity products in another, fixed income in another, and so on. In some respects, this makes sense– after all, the data elements needed to describe equities, bonds, swaps, futures and options are completely different. However, the margin calculation engine needs information from all of those databases and is usually prohibited from accessing them directly, due to security and privacy concerns. Therefore, the margin system relies on feeds from each of these databases, which tend to come in different formats that need to be ingested and reconciled quickly. While TS Imagine reconciles those feeds, cooperation and a commitment to prioritizing change requests are vital; otherwise, the process stops before it can get started.

Another critical task is identifying which positions are relevant to each set of margin rules. Bottlenecks arise when positions and quantities are available but the margin calculation engine has to obtain additional data because a key instrument feature is missing. Since a high percentage of the securities in a portfolio will not be impacted by a particular set of rules, “rejecting” positions quickly can save a tremendous amount of time. TS Imagine’s solution is to include the key features that determine rejection within the core description of a portfolio, instead of having to make a separate query to determine the correct set of rules for each position each time the calculation is generated. While retrieving too much data upfront and then storing it can also slow down the process, making the same query over and over just to retrieve a single key feature is extremely inefficient.

Investing time upfront to optimize the data handling process is critical. If one data feed is not available when expected, or the margin system needs additional data to handle a different risk calculation for a new client, it becomes just one of many requests to the database manager that goes into a queue, and the waiting begins.

#2. Duplication
The amount of duplication found in many margin systems, which is a main cause of sluggish response times, can be shocking. A system needs a “margin plan” for every client, where the plan specifies the rules to use in determining the amount of collateral available and the margin required for the positions the client holds. In most cases, roughly 90% of the rules are the same across accounts – it is the exceptions that differ. The mistake many systems make is in creating a record for every account that contains rules that are the same across all accounts, just to create a place to specify the exceptions that are unique to each one.

A much better approach:  store the common rules once, and reference them as needed. That way, when the rules change (infrequent, but it does happen) the update can be made in one place, rather than in tens or hundreds of thousands of records. Duplicating entire records that contain all of the rules each time a new client is added perpetuates an inefficient design and has serious consequences, as the system becomes slower and more unwieldy as new clients are added.

Design matters

As noted above, storing duplicate margin rules for each account is unnecessary and creates significant “diseconomies of scale” as the number of accounts grows. By using an architecture that focuses on exception handling, TS Imagine avoids this issue and manages portfolios far more efficiently than a system that repeatedly stores various set of margin rules.

The key observation is that the rules themselves (set by the clearing exchange, CCP or prime broker) rarely change; therefore, we can store each set of rules only once and “point” each element of a margin plan to the relevant sets of rules.

Of course, the parameters of the rules can differ on a per-client basis, and can change at any time. For example, under house margin rules some clients may be assigned a different haircut for the same instrument. The way to gain efficiency here is to focus on the exceptions. TS Imagine uses criteria, values and a hierarchy to determine whether to apply a default set of rules or to employ an override. The goal is to reduce the size of the “container” needed to store the per-client parameters, from a gigantic repository that accommodates hundreds of dimensions and millions of entries (the outcome if all rules are stored for every client) to one that is much smaller. We do so by giving priority to overrides (exceptions); in the absence of an override, we defer to less specific or default parameters. New entries are added only if existing criteria do not already allow for the type of override needed.

The criteria might be a certain type of instrument, and the value would be the haircut applicable to that client for that instrument. We use the (centrally stored) default rules unless an exception is specified. The concept is similar to how a driver (or GoogleMaps) selects the best route to get to a destination. The goal is to stay on the main highway as much as possible, and to use secondary roads only when needed to pursue a unique detour. Not only is this design extremely efficient for reasons described below, it also means that to implement the TS Imagine margin system, a client only has to provide overrides, instead of supplying rules for everything for every client.

Fast, flexible and accommodating

In addition to efficiencies that can be achieved in terms of data storage and updates, this approach makes it easy to search for clients for whom an exception has been applied with respect to a particular type of instrument. Criteria and values can be easily queried (for example, to find the lowest (or highest) value associated with a given criteria), values can be interpolated, and one can set priorities for Override inputs based on a combination of conditions – e.g., “Country of Risk = U.S.” and “Instrument = Equity index futures”. The design also accommodates complex rules involving a hierarchy of determinants by applying If/Then statements – e.g., “If Country of Risk = U.K., Canada or Australia, then…; else…”

We can also conduct searches by criteria or value to quickly find, insert and/or modify overrides across client accounts. This can be a tremendous time-saver and can prevent costly errors. For example, in 2011, when Greece appeared to be close to defaulting on its sovereign debt, a broker-dealer decided not to extend any margin based on clients’ exposures to Greece. Instead of having to search through 100,000+ records to find every exposure to Greece, TS Imagine’s architecture allowed us to insert a new house rule for that dealer – “Margin=100% if Country of Risk = ‘Greece’” – in a single place. All margin plans that pointed to that dealer’s house rules automatically picked up the new rule.

TS Imagine’s margin system can also optimize results based on different sets of rules by specifying an objective to minimize the margin requirement subject to various criteria (e.g., “all positions must be margined with nothing leftover”). Or, we can apply “waterfall” logic to choose which margin rule to apply first, then second, and so on.

Calculating margin inefficiently can make a firm feel like it is drowning in data and sinking in the effort required to support the inefficient structure. If the system architecture is poorly designed, the ability to deliver answers in real-time, which is increasingly critical for broker-dealers and their clients, can be virtually impossible. Perhaps your firm has experienced what others have described to us:  an unwieldy system that crashes or requires support that overwhelms your staff whenever market volatility spikes. In other words, just when you need it most, the system isn’t available. When creating any complex structure, whether a building or a software system, thoughtful architecture makes all the difference. That mindset can transform the task of calculating margin from a stressful challenge into a smoothly running function that supports a firm’s business objectives.

The TS Imagine platform’s margin system, designed around the concepts of Margin Plans, Margin Rules, and a scalable structure based on criteria, values and overrides, is flexible and adaptable, and can offer truly astonishing improvements that can deliver tangible benefits to those who rely on margin calculations to keep critical functions operating smoothly. For more information about how TS Imagine’s approach could help your business, please contact us.

Follow us on LinkedIn to be alerted about the next article in the series on workflow-oriented margin engines.