By Phil Walsh

In this article, we explore a number of key considerations if implementing Endur’s/Findur’s accounting module (Accounting Manager/Desktop).

Mapping to G/L accounts

The main framework for mapping to the Chart of Accounts is to select which instrument-types, cash-flow types or other criteria (via a query) are potentially relevant for posting to a particular account. The framework will typically provide sufficient flexibility to support the client’s requirements for mapping vanilla products to the appropriate G/L account. However, key considerations in relation to mapping transactions to G/L accounts are:

(i) User-defined instrument types

In addition to the advantages that User Defined Instrument-types (UDIs) provide elsewhere in Endur/Findur, the key specific advantage from an accounting stand-point is where transactions that are based on the same underlying instrument type need to be mapped to different G/L accounts or, more generally, require different accounting treatment. Taking some examples to illustrate:

• FX instrument types are used to model both FX and Precious Metals transactions. Where the two need to be posted separately, UDIs can be used to provide the distinction at the accounting level, rather than adding complexity to the mapping queries to identify the distinction using other trade attributes.
• For distinguishing between OTC and OTC cleared products, given a single underlying instrument type is typically used to model both within Endur/Findur, the UDI can provide the basis for ensuring separate posting of such OTC and cleared business.
• Where an instrument type is used to represent a non-traded product which should not be accounted for within Endur/Findur, such as – perhaps – internal funding transactions or representations of physical assets, the UDI is one mechanism for offsetting the need for complex query logic to ensure there are no unrequired postings in such cases.

However, it is important to identify the need for UDIs prior to commencing trading on the Endur/Findur platform. If not, the effort to migrate existing transactions to a UDI will typically be sufficiently onerous that the case for migration will be a difficult one to make once live with a less ‘clean’ configuration. It is also worth noting, where utilising Openlink Standard Content as a basis for implementing Endur/Findur, aside from there being no explicit content for accounting, a Standard Content database will not necessarily provide the instrument-type distinction to support such a clear and clean configuration from the outset of an implementation.

(ii) Instrument-type grouping

For example, if we have a single G/L account for posting all OTC Options to, each individual option instrument needs to be individually selected when configuring the mapping and posting rules, as opposed to firstly being able to pre-define a group of instruments that should all be posted to the same account and in the same manner. Given that there is a large suite of OTC Option instruments within Endur/Findur spanning multiple different toolsets, care should be taken to ensure that all the appropriate instrument types are included within the accounting configuration.

In more recent versions of Endur/Findur, the concept of ‘Distributed Accounting’ has been introduced. This provides a mechanism for creating common configuration for accounts which will behave in the same way as far as posting rules are concerned, for example where products which are posted to different accounts, but use the same underlying P&L calculations for postings. As a result, this does reduce the need for some repetitive configuration, however it doesn’t fully address the issue of affording clients a seamless way of being able to singularly group instruments that should always be treated collectively.

(iii) Fees

Similar comments to those above with respect to instrument type grouping also apply to grouping and mapping fees. More specifically in relation to fees:

• For fees that are booked separately from outright transactions, UDIs can also be used as a clearer of way of distinction for accounting treatment, but with the same caveats referred to above with regards to instrument type grouping.
• For fees that are associated with outright transactions, and where the fee needs to be mapped to a G/L account that is separate from the posting of the primary value of the transaction, this can lead to more complex mapping (query) logic and care should be taken to ensure that each component of the transaction value is not posted multiple times.
• Specifically for prepayment fees, care should also be taken to ensure that the prepayment is not ‘double-booked’ between the realised and unrealised P&L accounts.

‘Custom’ accounting results

There is a vast number of standard calculations that can be used to generate posting values and, where there isn’t a suitable standard calculation available, custom calculations can be created using Endur/Findur’s APIs. However, it is important to note that there are no standard, ‘out-of-the-box’ calculations to support, for example, either balance sheet netting, US GAAP or IFRS, or LOCOM (Lower of Cost or Market) for inventory postings. As such, custom developed solutions are required. Such custom development should be carefully considered from both the perspective of handling the idiosyncrasies of the various toolsets/instrument-types and system performance – poorly designed and developed logic can drastically impact system performance.

Post month-end corrections

A key decision, when implementing Endur/Findur’s accounting framework, is whether to manage post month-end corrections within the system or externally, post the initial view of the month-end being generated within the system. Ideally the corrections would be calculated, stored and recorded within the system. However, typically this is managed off-system for a number of reasons.

To correct the official end-of-day P&L numbers at month-end either requires the affected transactions to be fully re-calculated or a top level adjustment applied. Attempting the former within Endur/Findur requires the use of a more recent capability of the system, generally referred to as Trade Snapshots, which is intended to provide the ability to re-run previous end-of-days incorporating corrected versions of transactions and market data. However, this capability is still relatively immature and has suffered from fundamental technical issues, such as running the processes on the grid, without which the time to process the corrections is likely to be at best too time consuming, at worst unable to fully process.

If a top-level adjustment is applied to the daily P&L results reported to front office externally to Endur/Findur, the Accounting module will not be aware of the adjustment. Even if the adjustment is made within Endur, perhaps through a Cash ‘transaction’, it will still be difficult to implement an account posting rule to determine which G/L accounts that adjustment should be applied to. There is a capability to manually apply adjustments to the G/L postings, however if dual-keying of adjustments is required users will typically consider directly entering the adjustment into the G/L much more practical than entering into Endur/Findur’s Accounting module and re-running the feed to the G/L.

Trade amendments

Endur/Findur’s accounting framework does not seamlessly handle transaction amendments. Primarily, there is no native capability to handle situations where transactions are amended between the end-of-day P&L calculations and the point that the accounting processes are run. Occurrences of this situation will generally be infrequent, but can cause more regular issues for organisations utilising the Endur/Findur application which are: trading outside of typical business hours, trading globally, trading non-standard products that require frequent transaction updates via trade amendments. There are a number of potential ways of offsetting or reducing the instances of such occurrences, however all would require significant effort to implement. Given the points made in relation to the previous sub-section, there is a strong argument for addressing this potential issue as part of the wider issue of managing post month-end adjustments.
 

Performance

There are various points to consider with respect to the performance of the Endur/Findur Accounting module.

The Accounting module will typically take longer to post values such as MTM/unrealised P&L, than it takes the EOD process to calculate and store these values. A key reason for this is that the account posting process will first attempt to determine which transactions in the database are required to be posted, rather than simply posting the transactions that are present in pre-computed end-of-day results. (Note that this is why the previous issue, in relation to trade amendments, occurs).

Ascertaining which transactions should be considered for posting is driven by a query. The query needs to ensure that it returns all transactions relevant for posting. However, the query needs to be designed such that it is not open-ended, i.e. it initially returns far too many transactions that are ultimately not relevant for the posting rule, in order not to detrimentally impact performance, but at the same time ensure that it is sufficiently comprehensive to not exclude relevant transactions for that posting rule.

For example, a query that is trying to post MTM/unrealised should attempt to ensure that transactions which are fully settled are not returned. If the query was defined to achieve this by only returning transactions with a settlement period in the future, this might exclude transactions which are still in an unrealised state, for example a swap with a settlement period of the current month, but hasn’t fully fixed by the month-end.

As mentioned earlier for requirements such as balance sheet netting and inventory postings, which can only be supported by custom posting calculations, if the custom calculations are not developed efficiently this can have a significant impact on the length of time that the posting process will take.

A final point to consider in relation to performance is user interrogation of the posted values. The user interface provided within Endur/Findur allows users to access all individual postings via a query. However, the performance suffers if the query returns above a certain number of records. It’s likely that the end user will be frustrated with this and will prefer the detailed posting data to be accessible from a reporting application that will allow them to interrogate large volumes of posting information.