Nov 04, 2026
No image
Trade Entry and Data Management Screens for Energy Trading Platforms
Completed

Trade Entry and Data Management Screens for Energy Trading Platforms

$100,000+
more 1 year
United States
6-9
Service categories
Service Lines
Software Development
QA and Testing
Web Development
Domain focus
Energy & Utilities
Technology
Programming language
C#
JavaScript
SQL
Frameworks
.NET
React.js
Subcategories
Software Development
Enterprise Software
QA and Testing
Integration

Challenge

Trade entry screens in an energy trading platform are the point of capture, not a reporting layer bolted on top, so an error made there propagates into position, exposure and settlement. Volume units are a persistent source of defect: therms, dekatherms and MMBtu are convertible but not interchangeable in display. Price structures are the second trap, because a fixed price, an index-linked price and a basis differential are different structures rather than one nullable column. Volumes are profiled rather than scalar, so position reporting has to aggregate over a shape. 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.

Solution

We extended the established .NET platform rather than replacing it. SQL Server holds the trade store, NHibernate maps the object model with sessions scoped per request and explicit transaction boundaries, and React supplies the interactive grids inside the existing application shell.

The domain model is 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, and hedges that reference the physical obligation they offset. Storage is append-oriented with amendment records instead of in-place edits, so the book can be reconstructed as of any prior moment.

A toggle that switches presentation never rewrites the stored value. Counterparties, traders, delivery points and pipelines come from controlled lists feeding dynamic dropdowns whose contents depend on prior selections. Bulk spreadsheet import has strict validation in the domain layer, a preview stage showing exactly what will be created, and all-or-nothing commit semantics. Optimistic locking with a version column surfaces concurrent edit conflicts to the user rather than resolving them silently, and position calculation lives in one place used by both screen and export with rounding rules defined once. React grids use virtualisation and server-side paging, and screens are verified across Chrome, Firefox and Edge.

Results

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 stay separate concerns. Spreadsheet books can be loaded with a preview before anything commits, which removes a whole class of manual entry error.

Every amendment is attributable and reversible, deleted trades are reversed rather than removed, and the book can be reconstructed as of any prior moment for audit or dispute. Screen totals and export totals agree because the position calculation is shared. The resulting clean, well-normalised trade store is also what makes later analytics and machine learning work feasible, which a schema encoding business rules in free text would not.