MVP Data Management Screens Integration into an Energy Trading Platform

Trade Entry and Data Management Screens for Energy Trading Platforms

Industry
Energy
Technologies Used
.NET, SQL Server, NHibernate, ReactJS

Summary

We build trade entry and data management screens inside energy trading platforms. Energy suppliers and brokers hedge the commodity they have committed to deliver, so they need to record every trade accurately, see the resulting position, and adjust it as the book changes. That work happens on a gas trade entry page, hedge entry tables, a dialog for creating a new trade, toggles that switch how volumes are expressed, and a trade table showing past and current activity in one place.

The Challenge

These screens are not a reporting layer bolted on top; they are the point of capture, so an error made here propagates into position, exposure and settlement. Volume units are a persistent source of defect, because therms, dekatherms and MMBtu are convertible but not interchangeable in display. Price structures are the other trap: a fixed price, an index-linked price and a basis differential are different structures, not one nullable column. Volumes are profiled rather than scalar, so position reporting has to aggregate over a shape rather than a number. Concurrent editing of the same trade is normal on a busy desk. Gas day conventions do not match calendar days. And small inconsistencies between a screen total and a report total destroy user confidence quickly.

The Solution

Extension, not replacement

In an established .NET platform the sensible approach is extension rather than replacement. SQL Server holds the trade store, NHibernate maps the object model, and React provides the interactive front end while the surrounding application keeps its existing shell.

Domain model

  • A trade header carrying counterparty, trader, book, trade date and status.
  • Trade legs describing delivery point, tenor, volume profile, price type and price, with each price type modelled as its own structure.
  • Hedges that reference the physical obligation they offset.
  • Append-oriented storage with amendment records rather than in-place edits, because a trading book must be reconstructible as of any prior moment.

Data, units and reference integrity

A toggle that switches presentation never rewrites the stored value. A monthly trade is a daily quantity across a delivery window, and position reporting aggregates over that shape. Counterparties, traders, delivery points and pipelines come from controlled lists and feed dynamic dropdowns whose contents depend on prior selections, which both speeds entry and removes a whole class of manual error. Bulk import from spreadsheets is a hard requirement in this domain, so the importer needs strict validation, a preview stage showing exactly what will be created, and all-or-nothing commit semantics.

Correctness and audit

Every amendment records a user, a timestamp and a before and after image. Optimistic locking with a version column handles concurrent edits, and the conflict is surfaced to the user rather than resolved silently. Position calculation lives in one place used by both screen and export, never duplicated, and rounding rules are defined once and applied consistently. Deleted trades are reversed, not removed.

How we build it

We follow the conventions of the existing platform rather than introducing a parallel architecture, so the work remains maintainable by the team that owns it. NHibernate sessions are scoped per request with explicit transaction boundaries, batch sizes are tuned for the import path, and eager or lazy loading is chosen deliberately to avoid the query-per-row pattern that appears the moment a trade table renders legs. React grids handle large trade sets through virtualisation and server-side paging. Validation lives in the domain layer as well as the form, since bulk import bypasses the interface entirely, and screens are verified across Chrome, Firefox and Edge because desks standardise on different browsers.

What This Delivers

Traders capture gas trades and hedges on screens that match how the desk actually works, with controlled reference data doing the remembering. Position and exposure reflect what was entered, in the units the reader expects, because presentation and storage are separate concerns. Spreadsheet books can be loaded with a preview before anything commits. Every amendment is attributable and reversible, and the book can be reconstructed as of any prior moment. A clean, well-normalised trade store is also what makes later analytics and machine learning work feasible; a schema that encodes business rules in free text does not.

Technologies and Tools

.NET with NHibernate over SQL Server, React front-end grids with virtualisation and server-side paging, optimistic locking with version columns, spreadsheet bulk import with preview and all-or-nothing commit, and cross-browser verification on Chrome, Firefox and Edge.