Generating Futures Variation Margin in Findur

by Lucido Group

Openlink’s standard script, STD_Margin_Call_Process is partially complete. While the Openlink corporate message may be that the standard scripts are accelerators, rather than complete solutions, the generation of variation margin on futures and options on futures can and should be standardized.

There are many deficiencies, both technical and business-related. We have significantly improved the solution. Read about those improvements here.

Generating Variation Margin in Findur

Variation margin can be generated via the standard plugin intraday or at the end of the day. After the plugin has been run, the variation margin will be generated in the form of cash transactions between the broker and the internal business unit. P&L will be updated on the derivative positions. For reporting purposes, records will be generated in the margin_call_data table, including the link between the futures tax lot and the cash transaction.

If there is a problem with the generation of variation margin, or it is necessary to amend a transaction, and to regenerate the variation margin, a process to undo the variation margin must be run. We will write a separate paper on that because the standard solution isn’t great at that either. Contact us if you have any questions about amending variation margin.

Does Not Automatically Use Closing Prices Prices

The plugin does not automatically load closing prices. Conceptually, this is because it has support for intraday variation margin, but we find the solution brittle and operationally risky without a feature to automatically load closing prices for the process date.

We added a line of code to automatically load closing prices.

No Trap for Missing Prices

There is no feature in the plugin to alert users to a missing price. We added features to handle a missing market price.

More specifically, we added a feature to look for a missing market price, and if any is detected, skip that instrument’s variation margin. We send an email alert, and we generate variation margin on all other instruments that can be priced, so that broker statements may be reconciled for all other instruments. We don’t want to hold up unaffected brokers, or the rest of the portfolio over perhaps only one missing price. And the missing price might not have changed from the prior day, which would allow the reconciliation to be correct anyway.

It’s just sensible to alert users to the operational risk of the missing price, but not assume the missing price is a showstopper.

No Support for Zero Prices

Options on futures are frequently worthless. Worthless options have a price of zero, yet the market pricing framework in Findur fails to distinguish between a missing price and a zero price.

We added a feature to calculate variation margin on the position when its price is zero.

Uses a Theoretical Price When There Is No Market Price

There is a feature that allows the solution to generate variation margin on futures and options that have a missing market price. This is a dangerous feature that can lead to outrageous results. The ‘standard’ Openlink solution will calculate a price on the instrument using the instrument’s projection index. It is a strange feature that leads to problems as soon as there is a missing price. The solution believes that a price is missing if there is a zero price. Options are quite often correctly priced at zero. Openlink’s market price framework have no native support to distinguish between a null price and a zero price.

We removed the feature so we never use a calculated theoretical price to generate variation margin; we only use market prices.

No Handling of Settlement Instructions

Findur users frequently maintain relationships with several brokers and yet the standard solution has no support for handling settlement instructions. The standard Openlink solution will generate the cash transaction to pay or receive variation margin, and will use the native default settlement instructions features, which could attach instructions for a correspondent bank, rather than the broker account.

We added a feature to pick up the settlement instruction used on the futures trades, and use the same account for the settlement of variation margin on the trade.

No Support for CME Treasury Note Futures

The CME Treasury complex has a way to calculate variation margin that differs from other instruments. There is rounding at one part of the step-by-step calculation of variation margin that affects the margin result when the price closes at a half tick. The standard solution usually calculates the correct amount, but back office users shouldn’t need to hand hold the plugin for days when it’s wrong. This isn’t difficult to get right.

We extended the instrument data model, and added a feature to support the alternative calculation method.

No Exception Handling or Notifications

The standard Openlink solution, like so many has rudimentary failure notifications. When there are failures, users should not need to comb through error consoles and log files to identify the root cause of the problem. Users should expect to receive notifications that provide immediate detail about the origin of the problem.

We added features to report exceptions via email, including the details of why the solution failed, such as missing prices.

No Support for Generating VM using TPM Workflow Manager

TPM supports the configuration of executing a plugin, but not an Openlink Task.

The standard variation margin plugin must be configured as part of a Task with a param plugin. The param plugin is responsible for selection of the trades to be margined, even though a user would not typically select the trades in the window. There is no good reason for the design to have include bifurcation of the automation into a param script and a main script.

Since TPM has no support for running a task, so a change to the margin call process plugin is required to query for the trades and run the variation margin in the main plugin.

We made a simple change to allow the solution to be utilized as part of a TPM workflow.

Basic Problems

All of the standard Openlink plugins suffer from rudimentary problems such as bad indentation, awful naming of variables, long blocks of code, code that does stuff that is never used, unused variables, and more.

Whenever we touch a standard Openlink solution, we follow the boy scouts rule to leave the campground cleaner than you found it.

A Better Way

If you have noticed these, and other problems, in Openlink’s standard plugins, let us know. We can help you address these issues easily and quickly.