The Openlink transaction model is powerful and able to handle many common, and even a lot of obscure payment calculations, without customization. Sometimes, however, it becomes necessary to extend the capabilities of the payment calculation methods for an instrument, or a category of instrument. Findur has two ways to extend payment calculation methods: payment formulas and payment calculators.
We make the case here for why you should use payment calculators to handle customized calculations.
Payment Formulas
Since the 90s, Findur has supported custom payment calculation using the Payment Formula screen.
Using payment formulas, trade entry is difficult and risky. The trader must enter the payment formula on the instrument screen. Most often, a template will be created to save the formula for future re-use.
Payment Formulas have their own library of functions, and many users report difficulty using the features. The function library is difficult to understand for both business users and developers. The documentation is limited. There are very few sample formulas. Consultants that have used the feature frequently still report maintaining text files or spreadsheets outside the system that contain sample formulas to use the next time they need to create a new payment formula.
Unfortunately, since payment formulas are required only when the calculation method is complex, the formulas required are often very complex and therefore difficult to develop. The initial creation of the formula is often time–consuming. Sometimes it can take a skilled analyst more than a day to prepare, test and document the right formula.
There is no way to query all instruments that use a particular formula. (A workaround could be to query for all trades that use a particular template, but even that is not simple). If the formula is used for an OTC trade with a customer, there is no way to parse the formula and interpret the details for a customer-facing trade confirmation.
From the instrument screen, it is not obvious what the payment formula does without opening the formula and reading it. The only indication that there is a formula is a warning icon on the instrument screen. Due to the library’s complexity, it is easy to introduce a bug in the formula.
If some part of a formula, but not the entire formula, is used across several instruments, the formula code must be copied and pasted from one instrument to another, and updated to handle the particular difference. This leads to duplicate formula code scattered throughout the portfolio. Now if there is a bug discovered in a formula, the formula must be updated for every instrument, and the trades re-processed. Of course, this operation could and, if volume is high, should be automated via API.
Upgrades are more complex with payment formulas because each formula needs careful attention to ensure it continues to function as expected.
As if all of that is not difficult enough, we have seen examples of UI bugs that clear out the formula. The formula could also be cleared inadvertently by a user error executing during a lifecycle event such as a partial termination.
It is clear there are a lot of downsides to the Payment Formula screen, and that the user community needed a better way to handle complex payment calculations.
Payment Calculators
Openlink created the Payment Calculator extension. A calculator is written in Java or .NET by a developer, but don’t despair: we argue that it is more powerful, faster to build, and easier to use than payment formulas.
Trade entry is easier with a payment calculator because the trader selects the calculator from a pick list. There is no need to enter a long complex formula, or keep a list or spreadsheet of sample formulas. It is easy to automate trade entry in an interface via the API.
The calculator can be used at the leg-level to control all payments on the leg. Alternatively, the calculator can be used at the payment-level to control the calculation of one payment or a subset of payments. The trader can only select a calculator if it applies to the instrument type.
It is easy to query from the GUI for all trades that use a specific payment calculator on any instrument leg or individual payment.
Business analysts or traders might initially favor the payment formula method because they can create the formula in the instrument using the GUI without having to engage a developer. But it is important for the trader or business analyst to understand that the language (OpenComponents, or OC SDK) used by the payment calculator makes it easy to create and to deploy the extension.
The OC library is powerful and tightly-coupled to business objects, which makes it easier for business users to specify the business logic in language easily interpreted by a developer. The OC library is more intuitive than the payment formula function library.
Some developers report frustration with the limited documentation and few examples of OC code; if that is a frustration for you too, contact us. We have created complex payment calculators and can offer advice.
Since the extension must be written in Java or .NET, it is easier to prepare automated tests of payment calculators than payment formulas. See our paper about test automation for guidance, and feel free to ask for help.
Developers: How to Use Payment Calculators
Developers write a payment calculator using Openlink’s OpenComponents (OC) SDK in Java or .NET. After importing the plugin to the database, it is registered in the application as a Payment Calculator extension (Admin Manager | Extensions).
In the code, the calculator is registered for an instrument type or a category of instrument. Once defined in the code, the calculator will only be available for that set of instruments. This feature prevents a trader from selecting an inapplicable calculator. The OC interface passes the instrument’s details to the method.
The payment calculator extension is only available via a license key, or by engaging Openlink professional services, who can ‘sign’ the extension so it can be used without a license key.
As with all embedded OC extensions, the plugin is cached in the Openlink process (master, screng, olfpres, etc). While developing the solution, the Openlink process must be restarted to accept the new plugin code. If the calculator is running in the presentation layer, this can be a drag on development productivity. There are a few simple strategies available that will accelerate development of your payment calculator and avoid this downside.
Recommendation
When it becomes necessary to extend the capabilities of the payment calculation methods for an instrument, we recommend using a payment calculator. We have used the feature to create some complex calculators, including one for a total return swap that could not be supported by Findur out-of-the-box.
Contact us if you would like more information about how we could help simplify trade entry, improve payment transparency, reduce bugs and errors, increase test automation, and reduce fear during software upgrades.
