SUBCONTRACT DELIVERY FOR ENERGY TRADING PLATFORMS · SINCE 2011
Fifteen engineers in Kraków who read a position report before they read a requirements document. 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
Median 11 years each. 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 — with a report 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 — 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 — one contract fewer, 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 / SELECTED WORK
All work under NDA. The discretion we keep about your competitors’ systems is the discretion you would want about yours.
4h → 20min
END-OF-DAY CLOSE
NORDIC POWER SUPPLIER · NORD POOL, EEX
Positions came from an overnight batch. A back-dated amendment meant a full rerun, and nobody could answer what the book looked like at 14:00 the day before.
Event-sourced positions with valid time and record time held separately, projected on demand. Close dropped from four hours to twenty minutes and as-of questions became a query instead of a restore.
.NET · KAFKA · SQL SERVER · 9 MONTHS · 4 ENGINEERS
PROJECTION
trade.amended v3 valid_from 2026-03-01 recorded_at 2026-03-14 → position.projected as_of any timestamp
END-OF-DAY CLOSE, WEEKS 1–10
06:00
CURVES READY, WAS 11:00
CENTRAL-EUROPEAN GAS TRADER · TTF, CEGH
The nightly curve load failed about twice a month. Traders opened the day on stale marks with no way to tell which vendor snapshot produced them.
A streaming service ingests 1.2 million curve points a day, versions every snapshot and shapes monthly quotes to daily granularity. Every mark now carries its source and timestamp.
JAVA · SPRING BOOT · KAFKA · POSTGRESQL · 7 MONTHS · 3 ENGINEERS
FEED
price.tick TTF M+1 1 200 000 pts/day p99 ingest 40 ms curve.published 05:58 versioned · auditable
CURVE PUBLISH TIME, 10 SESSIONS
6.4% → 0.2%
REPORT REJECTION RATE
EUROPEAN UTILITY GROUP · REMIT, EMIR
Two reporting streams held together by manual corrections. Each schema change cost a quarter of the team's capacity, and rejections were tracked in a shared workbook.
One validation and submission pipeline for both regimes, with rule sets held as data rather than code. Eleven counterparties were onboarded the following year with no further engineering.
PYTHON · .NET · AZURE · 11 MONTHS · 3 ENGINEERS
PIPELINE
extract → enrich → validate (rules v42) → submit ARM / RRM → reconcile ack auto-requeue on reject
REJECTION RATE, 12 MONTHS
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.