SUBCONTRACT DELIVERY FOR ENERGY TRADING PLATFORMS
We build and extend ETRM modules for the software companies, consultancies and system vendors delivering them across Europe.
→ position keeping · curves · exchange gateways
→ scheduling · settlement · EMIR / REMIT
| CONTRACT | VENUE | POS MW | MARK | Δ | MTM EUR |
|---|---|---|---|---|---|
| DE Base Cal-27 | EEX | +45 | 89.02 | +0.62 | 20,088 |
| DE Peak Q1-27 | EEX | -30 | 112.27 | −0.48 | 10,368 |
| NL Base M+1 | EPEX | +22 | 79.41 | +0.31 | 4,910 |
| TTF Gas Cal-27 | ICE ENDEX | +60 | 32.02 | +0.17 | 7,344 |
| NO2 Base M+2 | NORD POOL | -18 | 45.94 | −0.26 | 3,370 |
| FR Base W+1 | EPEX | +12 | 95.10 | +0.55 | 4,752 |
| CEGH Gas Q4-26 | CEGH | +25 | 34.83 | +0.23 | 4,140 |
| NET | 5 venues | +116 | 54,972 |
Illustrative data. The mechanism is the point: every price tick reprojects positions and MtM from the event log. No overnight batch, no stale marks.
IN THE DOMAIN
15 yrs
Energy trading and risk only. No pivots.
MODULES DELIVERED
40+
In vendor platforms and in-house systems.
ENGINEERS
15
No junior bench.
VENUES CONNECTED
5
Nord Pool · EPEX SPOT · EEX · TTF · CEGH
TYPICAL CLIENT
Your team
Software houses, consultancies, system vendors.
THE VIEWS WE BUILD
Three screens every trading desk argues over before nine in the morning. We build the services behind them, and we can read them, which is a shorter conversation than it sounds.
Solid: as-of today 06:00. Dashed: same curve one month ago. Versioned snapshots, so the move is explainable.
Every bar has to be defensible in the morning meeting. The residual is the one a trader asks about first.
Limit breaches belong in the capture path, not in a report that arrives the next morning.
01 / DOMAIN
Nine layers that all have to agree with each other by 06:00. The map tracks the layer you are reading.
SYSTEM MAP · 9 LAYERS
FRONTTrade capture and lifecycle●FRONTExchange and broker gateways·MIDDLEPosition keeping·MIDDLECurves and market data·MIDDLEValuation, MtM and PnL attribution·MIDDLERisk metrics and limits·BACKScheduling and nomination·BACKSettlement and invoicing·COMPLYEMIR and REMIT reporting·price.tick → mtm.revalued → position.projected
keyed by trade_id · compacted · replayable
Bilateral deals, exchange fills, broker confirmations and bulk uploads have to land in one lifecycle with one identity, and amendments must not disturb a close that has already been signed off.
FAILS AS → amendment reruns the whole night; two systems disagree on the same trade id
WE BUILD → capture layer, amendment path, lifecycle state machine, idempotent ingestion
Nord Pool, EPEX SPOT, EEX and the gas hubs, plus broker feeds: order entry, trade capture reports, session windows, throttling, and the resend path after an outage.
FAILS AS → a dropped session at 09:00 and no way to prove which orders were live
WE BUILD → gateway services, session handling, replay, venue reconciliation
Physical and financial positions by book, delivery period and location, projected from the event log rather than assembled by an overnight job.
FAILS AS → positions are only correct once a day, and never for yesterday at 14:00
WE BUILD → event-sourced projections, bitemporal stores, as-of queries
Forward curve construction, shaping, interpolation and versioning, with vendor feeds reconciled against exchange settlement prices instead of trusted.
FAILS AS → traders open on marks nobody can trace to a source snapshot
WE BUILD → curve service, shaping rules, snapshot versioning, reconciliation jobs
Revaluation runs and PnL split by price, volume, curve move, new deals and FX. Numbers a trader can argue with in the morning meeting.
FAILS AS → an unexplained residual line that grows every quarter
WE BUILD → revaluation engine, attribution logic, explainable breakdowns
VaR, exposure and limit monitoring with a defensible record of every override and who approved it.
FAILS AS → limit breaches discovered in a report, not at the point of trade
WE BUILD → limit checks in the capture path, exposure aggregation, audit trail
TSO nominations, schedule versions, cut-off times, imbalance follow-up, and reconciliation of what was traded against what actually flowed.
FAILS AS → a missed cut-off becomes an imbalance cost nobody budgeted
WE BUILD → nomination services, version handling, imbalance reconciliation
Invoice generation, netting agreements, statement matching, credit notes and the disputes that follow.
FAILS AS → settlement runs in a spreadsheet next to the system, not inside it
WE BUILD → settlement engine, matching rules, invoice generation, dispute states
Extraction, enrichment, validation, submission, rejection loops and back-reporting, built so a schema change on two months' notice is configuration, not a project.
FAILS AS → rejections tracked in a workbook; every schema change costs a quarter
WE BUILD → reporting pipeline, rule sets as data, requeue and evidence trail
02 / INTEGRATION
An ETRM landscape is never one system. There is a vendor platform, two exchanges, a market-data provider, the ERP that issues invoices, a TSO that speaks EDIFACT, a regulator that speaks ACER XML, and a fifteen-year-old in-house tool nobody is allowed to switch off.
We connect them because we already know the interfaces, the formats and the way each one misbehaves, including the ones with no documentation and one contact person on holiday.
FORMATS AND PROTOCOLS WE ALREADY KNOW
Plus the undocumented ones: staging tables, SFTP drops and a stored procedure someone wrote in 2013.
| FROM | VIA | TO | WHAT ACTUALLY BREAKS |
|---|---|---|---|
| Vendor ETRM platform | vendor API · staging tables · SDK hooks | In-house risk and reporting warehouse | Curve versions coerced silently on the way out, so risk and front office quote different marks. |
| Exchanges: EEX, EPEX SPOT, Nord Pool | REST · FIX-style sessions · TCR files | Trade capture and position keeping | A session reset inside the clearing window, with no record of which orders were live. |
| Market-data providers | streaming feeds · file drops | Curve and market-data service | Two snapshots claiming the same timestamp, and no source stamped on the mark. |
| TSO and schedule exchange | EDIFACT MSCONS · ESS / ERRP · ENTSO-E XML | Scheduling and nomination module | Schedule version numbering that disagrees with the cut-off the TSO applied. |
| ERP and billing (SAP IS-U class) | IDoc · REST · flat files | Settlement and invoicing | Netting rules that differ per counterparty but are implemented once, centrally. |
| Regulatory ARM / RRM | ACER XML schemas · submission APIs | EMIR and REMIT reporting pipeline | A schema change with two months' notice landing in hard-coded validation rules. |
| Legacy in-house tools | CDC log streams · Kafka · scheduled extracts | New services during modernisation | No natural key shared across systems, so the same trade exists three times. |
RULE 01
Every interface gets a written contract with schemas and versioning before either side builds against it, including the interfaces we inherit.
RULE 02
Every inbound message can arrive twice and every day can be replayed. That is what makes an outage a delay instead of a data-quality project.
RULE 03
Counts and values checked against the counterparty's own file: exchange settlement, vendor snapshot, ERP ledger. A report goes out when they disagree.
RULE 04
A mapping layer that holds external references alongside a canonical id, so the same deal is recognisable in six systems.
03 / SERVICES
SVC-01
The missing component, built to fit the platform you already run: position keeping, curve service, settlement, limits. It lives inside its data model, its release train and its performance budget.
.NET · Java · SQL Server
SVC-02
Customisation of commercial ETRM systems of the Endur / Allegro / TRM class: adapters, custom valuation logic and reporting layers that respect the vendor's upgrade path.
C# · Java · vendor SDKs
SVC-03
Venue and vendor connectivity with session handling, replay after outage, and reconciliation against settlement files rather than optimism.
REST · gRPC · Kafka
SVC-04
EMIR and REMIT pipelines end to end: extraction, enrichment, validation, submission, rejection handling and the evidence trail an auditor asks for two years later.
Python · .NET · PostgreSQL
SVC-05
Strangler-pattern extraction from long-lived systems; event sourcing where history matters, bitemporal models where 'as of when?' is the real question.
CQRS · Kafka · Azure / AWS
SVC-06
Three to eight senior engineers who already speak the domain, embedded in your delivery organisation for the length of the programme.
your repo · your process
04 / ENGAGEMENT
You hold the contract, the client relationship and the roadmap. We supply the energy-domain engineering that would otherwise cost your team two years and one failed release.
Your repo, your CI, your board, your definition of done. No client-facing overhead, no parallel project, no logo on the deck unless you want one.
| MODEL | Dedicated team | Scoped module delivery |
|---|---|---|
| SHAPE | 3–8 engineers, named, stable over quarters | 2–4 engineers, one bounded deliverable |
| HORIZON | 6 months and up, rolling | 6–16 weeks, defined end |
| COMMERCIAL | Monthly rate per engineer | Fixed scope, acceptance criteria agreed up front |
| WHO OWNS SCOPE | You. We work your backlog | Shared. Specified together, then ours to deliver |
| TYPICAL TRIGGER | A platform programme short on domain capacity | One module blocking a release date |
| ENDS WITH | Ramp-down and knowledge transfer on notice | Handover: tests, runbook, walkthrough |
Direct work for utilities and trading houses runs on the same two models, with one contract fewer and the same engineers.
05 / TECHNOLOGY
Not a logo grid. What we write, where it sits in a trading system, and how long it has been in production for us.
.NET / C#
Trading engines, calculation services, vendor platform extensions
Java / Spring Boot
Integration services, exchange gateways, reporting pipelines
Python
Curve construction, quantitative tooling, reconciliation
SQL Server · PostgreSQL
Bitemporal trade and position stores, settlement data
Apache Kafka
Event backbones for price ticks and lifecycle events, with replay
REST · gRPC
Service contracts between trading, risk and back office
Azure · AWS
Deployment alongside on-prem trading floors
06 / PREVISE CORAL
PREVISE PARTNER
Coral is the core of an ETRM system: trade capture, positions, valuation, settlement. Around that core sit apps, and an app does one of two things. It adds a function the core does not have, or it reads data out of the core and passes it on to something else. Integration work is nearly always the second kind. We build both.
Solid is built by us, dashed is a platform module we extend. Formats are the ones the routes actually carry. On the schedule route we hand over an export; the nomination itself is filed by the downstream system.
| MODULE | CORAL GIVES YOU | WHAT WE ADD | VIA | DEPTH |
|---|---|---|---|---|
| Trade capture | Deal entry and lifecycle | Desk-specific capture screens, bulk amendment paths | Coral SDK | extended |
| Exchange gateways | Generic connectivity | Venue sessions, replay after outage, reconciliation | REST · FIX-style | ● built |
| Position keeping | Positions by book and period | Nothing. The platform covers it. | n/a | platform |
| Curves and market data | Curve storage and shaping | Vendor ingestion, snapshot versioning, reconciliation | Volue · vendor feeds | extended |
| Valuation and PnL | Revaluation and attribution | Nothing. The platform covers it. | n/a | platform |
| Schedule export | Schedule records | Collects and aggregates schedule data, validates it, exports it to the nomination system | Deltaxe · GMLS · DispoEnergy | ● built |
| Settlement and invoicing | Invoice generation | Netting rules per counterparty, dispute states | flat files · API | extended |
| EMIR and REMIT reporting | Data extraction | Validation, submission, rejection loops, evidence trail | ACER XML | ● built |
Where the depth column reads platform, we leave it alone. Claiming every module would be easier and less useful to you.
01
Applications that run inside Coral and follow how your desk actually works, rather than how a generic workflow assumes it does.
02
Exchanges and market-data vendors in, the nomination system out. The same seams as everywhere else, with one side of them already familiar.
03
Reusable Coral extensions built to commercial standard, so they survive a platform upgrade instead of living in one client's branch.
07 / HOW WE WORK
STEP 01
The first week is schema, event log and the last three incident reports. We write code in week two, not day two.
STEP 02
Small pull requests into your branch strategy. Domain tests named after real market cases, not mocks of themselves.
STEP 03
Your repository, your licence, from the first commit. No wrapper library only we can maintain, no runtime we host.
STEP 04
Decision records, a runbook for anything that runs before market open, and a walkthrough until your team can change it without us.
08 / CONTACT
A reply within two working days from an engineer who has built that part before. If it is outside what we do, we say so in the first message.
NDA on request before the first technical call. We are used to reading someone else’s schema first.