Achieving a Reliable Front Office Reporting in ETRM systems: Typical Pitfalls

Are you the most trusting person on Earth? If that is the case, you obviously, haven`t dealt with front office reporting solutions, nor have you ever opened a bag of chips.

As the saying goes „Trust is the hardest thing to find and the easiest thing to lose”. When it comes to front office reporting and traders it is even more fragile than a gold fish`s memory. A couple of wrong position results may lead traders to feel like they are using a gambling tool instead of a reporting tool.

A front office reporting project can be complex since it relies heavily on components such as deal modeling, curve/volatility configuration, and simulations results. All of these need to be properly configured in the system in order for front office reports to be correct.

BIG mistake – Reporting is left to the end of the system implementation as it depends on so many system components.Delays however, may result in a rushed reporting roll-out and could lead to issues that subsequently only show up in Production. At this point, since traders rely on front office reporting for position management, this could be easily classified as a showstopper.

By their nature front office reporting projects are rarely straightforward, but typical pitfalls can be avoided if the following points are considered:

• Front office reporting is a team effort. It requires collaboration between:
  • End-users – need to define requirements in terms of the type of data they want to see, details of how the data should be organized, and performance expectations;
  • Business consultants – need to map end-user requirements to the system`s features and identify any gaps between requirements and system capabilities;
  • Technical consultants – need to take the performance expectations from the end-users and the front office configuration elements from the business consultant and map this to the system configuration.
• Front office reporting is often underestimated by thinking it is just as a simple matter of putting the appropriate columns and filters on a page. Instead, it is important to understand the actual data to be produced, and what it will be for each deal type in scope.
• The process of analyzing the data given by the reports and comparing against client needs is not started early enough in the project timeline. It is favorable if a design document for the reports is to be created early in the project, even if the pages themselves cannot be built yet.
• Estimation of how difficult something is to be completed during implementation is often done by analogy. This however sometime fails to appreciate the differences between underlying data, especially in regards to granularity.
• Overseeing a needed customization is costly in terms of additional time and effort necessary. Furthermore, due to the sequential work among multiple teams, it can often lead to project delivery delays.
• Focus on the server side first. Take into account reports` sizing and performance early in the project. Inappropriate technical sizing may lead to production issues. Front office reports may deliver correct numbers when a deal is booked in isolation but that doesn`t necessarily mean that they will work optimally when under peak load, if the hardware is inadequate. This sizing adequacy is driven by business requirements which often change over time.

Taking note of the above pitfalls could save you and your clients a lot of frustration. Failing to acknowledge them will lead to a reporting that users are reluctant to use as they do not trust the results.

Written by Maksim Yachev