Every client has a need to know the position of each trade in the portfolio. This would be taken for granted by the user community as a straight-forward feature available in Findur. It turns out, it isn’t that simple.
In this paper, we describe how we have helped clients report on this key requirement.
Why Position is Important
Trade position is important in many contexts including regulatory compliance, reporting, extracts, system integration, risk, accounting, performance, and more.
It is critical that any solution to this key requirement is used throughout the system for consistency of view. While it might seem obvious, too often we see point solutions in corners of the application that have been re-implemented (you can read about our opinions regarding code duplication here).
The right approach is to configure/build a solution once, and use it pervasively. Put all your eggs in one basket and then watch that basket.
Why Date Context is Important
The first thing to think about is that a trade’s position should be considered in the context of a date.
A trade is generally not an exposure before its trade date, something that must be taken into account when running as of reporting for a prior date. Likewise, a trade has no position after its maturity date, expiration date, termination date, and in some cases, its settlement date. The date handling is definitely asset class-dependent.
So reporting on a trade’s position independent of a date context is fraught. For this reason, we generally favor a solution that has a date parameter. In Findur, date context is most easily implemented as a user-defined simulation result.
Where to Source the Data: Database, Sim Results or Transaction Fields
The data on a trade’s position is available in the database, in simulation results, and in transaction fields. There are reasons to like, and dislike, each of these approaches.
Where to Source the Data: Transaction Fields
In general, our favorite solutions are easily tested in automated unit test suites. It is easy to build automated tests for a solution that uses transaction fields. In a unit test we can load the transaction, and pick any transaction (or leg) fields we need, including key lifecycle dates such as start date, maturity date, expiration, and so on. The transaction need not exist in the database because a unit test can create a transaction in memory. This is not the case, however, for unit tests that include lifecycle events such as the termination of a bilateral OTC derivative.
Some users will argue that the problem with using transaction fields is that it requires the engagement of a developer. We think that users should expect more from their development team than confusion and obstruction, so this is not much of a disadvantage.
There are easily-overlooked benefits to using code to build solutions: code repository audit trail, solution governance (Report Builder definitions can be updated, and broken, by any privileged analyst with an opinion), and ease of deployment. Test automation always requires a developer, and we find stakeholders quickly realize the benefits of a comprehensive coverage of automated unit tests. If your dev team isn’t delivering automated test suites, read about why they should, and contact us to discuss how we can introduce you to software development best practices from the 1980s.
Where to Source the Data: Database
The database is most likely to be used by most clients in most contexts. We think this is a mistake most of the time.
Since v10.2, the most common solution in Findur used for reporting, and even interface needs, is Report Builder. It is an excellent solution, and easy to learn. It is also easy to use, as long as you know the system’s data model. Since Report Builder is easy to use, many business analysts default to it as a solution to many requirements, sometimes regardless of complexity.
We see some users that suffer from the problem, a little knowledge is a dangerous thing, build complex expressions in Report Builder that are difficult to understand. For trade position we have seen nested IF statements based on start dates, maturity dates, and toolset running beyond a dozen statements. These statements are difficult to test, maintain, and enhance.
The worst problem about building a solution in Report Builder for trade position is that it exists in isolation in that Report Builder definition. There is no way to use the same solution in an accounting result, or a pre-trade compliance check, or many other parts of the system where a trade’s position might be important.
In general, a solution that uses the database can be more difficult to test than a solution built using an in-memory transaction because the transaction record must exist in the database. We could include trade booking in the unit test suite setup (@BeforeClass in JUnit), but the trade processing might fail due to insufficient security privileges, a pre-trade compliance failure, or any other reason. Including trade booking in the test suite increases the cost of building and maintaining the unit test suite.
We could use a historical trade. One advantage to using a historical trade is that it is most likely to exist in development, test and production environments. However there are some downsides: there is a chance that the data will change with time, such as the trade will be closed out or mature. It is also possible that we are missing some use cases in the set of historical trades, such as instrument types, short-sales, called issues, maturities, and many more.
Where to Source the Data: Simulation Results
Associating the trade position to an existing simulation result, such as Current Notional, is likely to offer the nearest thing to an out-of-the-box solution to resolve our trade position requirements.
We will discuss later why this assumption is wrong for several categories of instruments, and for several key lifecycle dates.
The other problem with using a simulation result to obtain the trade position is that it sets up a data dependency that makes it more difficult to build automated test suites. The automated test suite will need to first run a simulation. Of course that is possible, but it will increase the complexity of the test setup, and will slow down the test execution.
Where to Source the Data: Conclusion
There are several factors described above regarding the relative advantages of going to the database, the in-memory transaction, or a dependent simulation result. Weigh the advantages and disadvantages of each against the complexity of the set of use cases. If a dependent simulation result resolves nearly 100% of the requirement, that would most lead us to favor that data source.
Instrument Considerations
In this section we address specific issues that arise for Findur users regarding the accurate specification for a trade’s position.
Fungible Instruments
Fungible instruments, known in Findur as Shareable, have their transactions stored in Findur with a scaled position. For some classes of instruments, such as bonds and money market instruments, the default trade position is denominated in millions of par value. It is important to account for the notional on the holding instrument definition. Most instruments use 1,000,000, but some must be configured differently, such as Aussie inflation-linked bonds. Don’t forget to account for the instrument notional, a requirement whether sourcing the data from the database or a transaction field.
Some bonds amortize, so the Current Notional simulation result will drop with time. You may want to report the amortized notional, although a traditional consideration of the position would be the original notional. Similarly, inflation-linked bonds have a notional amount that adjusts to rates of inflation. Findur does not handle the inflated notional consistently between the IDX-BOND and IBOND instrument types, so define the expected result and design around the inconsistency. (IBOND current notional is uninflated; IDX-BOND current notional is inflated).
Exposure is generally considered with respect to the trade date, rather than the settlement date.
Bonds and discount notes mature, so account for maturity. Some instruments, such as US T-Notes will have month-end or mid-month maturity dates, even when that day is not a good business day for settlement. For example, if March 31 is the maturity date of a T-Note, and that day is a holiday, the principal and interest will roll forward to settle on the next good business day. What do you expect to report for the position on March 31? What is the consequence of reporting the position open until its final settlement on the next good business date? There is a credit exposure to the issuer until the payments settle, although there is no longer any market risk.
Findur’s position closeout functionality is an awkward solution that can introduce complexity to many corners of the system. One place where the solution is made more complex is for reporting trade position. Pay attention to the exposure and reporting requirements around partial and full closeouts.
If you want to report the remaining position after a closeout, use the confusingly-named field: ab_tran.mvalue in the database, TRANF_FIELD.TRANF_MVALUE in OpenJVS, andEnumTransactionFieldId.ForwardMargin in OpenComponents.
FX Trades
FX trades may need special logic depending on the buy/sell flag, settlement date, and the type of deal (Spot, Forward, FX Swap).
FX Swaps can be a bit confusing because the details of both the near and far leg are presented to the user in the GUI, but treated differently in the database.
Generally, the position is zero before trade date and on/after settlement date. There are always two currencies involved, and the position might need to be sourced from confusingly named fields such as fx_c_amount or fx_d_amount in the fx_aux table, or TRANF_FIELD.TRANF_FX_D_AMT and TRANF_FIELD.TRANF_FX_C_AMT in OpenJVS, or EnumTransactionFieldId.FxDealtAmount and EnumTransactionFieldId.FxCounterAmount in OpenComponents.
Repo Trades
Repo trades conceal more complexity in reality and in the Findur data model than appears at first glance. We published a paper about some of the complexities of repos.
The definition of the position of a repo is dependent on site requirements: we have seen its initial cash, but also the collateral par amount. It is important to account for the possibility of having more than one piece of collateral on the repo, something that Findur supports. Substitutions, margin calls, amortizing collateral, sometimes even coupon payments, can affect the repo’s position. Obviously, for each of these repo lifecycle events, there is a date context to be taken into account.
If you are using an in-memory transaction, there is inadequate support in OpenComponents for repo transactions so you will need to drop into OpenJVS.
We think you will agree with us that there is more complexity than appears at first glance. We have worked a lot with repos, so spare yourself the project cycles and reach out for advice.
OTC Instruments
It is difficult to offer succinct complete coverage of such a diverse set of products as OTC instruments. Included here is a list of some of the considerations we have encountered in the past.
It is important to define the requirements, and the solution around the boundaries of lifecycle events. This includes a new trade, maturity, amortization, increase/decrease, exercise, expiration, credit event, knock-in/knock-out, novation and termination.
Most OTC instruments are multi-leg, but do not assume that the position is always represented on the first leg. For some instrument types, Findur may store the required position on a subsequent leg. For example, you should use the second leg’s notional on index CDS in order to account for credit events. Also, you might expect to use the floating leg’s notional on zero coupon swaps.
Some OTC instruments have a notional that changes, for example an amortizing notional. In this case, a leg-level field such as the notional will return the original notional, not the current notional. The current notional simulation result reliably returns the notional of the current calculation period.
Partial and full terminations, described as ‘buyouts’ in Findur, have a complex data model in the application. There are several ways to process a termination, depending on how the proceeds should settle. The method used affects how the instrument’s profile is adjusted, including the timing of the change in the notional. Unfortunately, there is no out-of-the-box support for entry of the trade date of the termination; all handling on the instrument is recorded using the settlement date. If the position must be reported relative to the termination’s trade date, for example, the exposure drops to zero on the trade date of the termination, not the settlement date, then it is necessary to extend the transaction event data model. Contact us to help with the setup if this is necessary for you. There are several parts of the system that will need to be changed, and we have handled all of it from pre-trade through to P&L, accounting and post-trade reporting.
Design Conclusions
It is difficult to specify a design without understanding the full set of requirements. In general, the best solutions in Findur have the fewest customizations, particularly the fewest complex customizations.
If the native Findur current notional simulation result resolves most of the requirements, then it may be best to create a user defined simulation result with current notional as a dependency, and customize only the products that need it. This is the most common design.
If the current notional result is far from a complete specification of the requirements, and the most complex handling is completely divorced, then consider a more thorough design that involves the most comprehensive automated test coverage possible.
We all want to avoid customizations, but when the application’s features are too far from the requirements, customization cannot be avoided. Robust test automation, and design simplicity go a long way towards delivering a solution that can be easily extended for future needs, with a low risk of regression.
For many Findur users, they find themselves asking why the application does not support their needs without customization. We can help close these gaps, so let us know how we can help.
