How onboarding, master data, and cross-functional approvals come together before an energy trading desk can execute a single deal — and what happens when one piece is missing.
At RWE Supply & Trading, no counterparty can trade energy or commodity products until they clear legal, credit, compliance, and operational checks — a process that runs through Jira for workflow and approvals, and Endur (RWE's ETRM platform) for master data and trading configuration. I owned this onboarding process end to end: validating incoming requests, chasing down approvals across Legal, Credit, and Compliance, maintaining counterparty records in Endur, and troubleshooting trade bookings that failed after "onboarding" looked complete.
Handling 15+ counterparty onboardings a month across four legal entities (Germany, UK, US, Singapore), the recurring pattern wasn't one big failure point — it was several small, specific gaps (a missing Business Unit, an agreement that didn't cover the traded instrument, a credit workflow that failed silently) that each blocked trading in a different way. The work was as much about diagnosing which gap it was as it was about processing the request itself.
RWE Supply & Trading trades with a wide range of external counterparties, and every one of them has to be fully configured — contractually and operationally — before a trader can book a deal with them. The onboarding workflow starts with a Jira request containing counterparty information, moves through Legal, Credit, and Compliance approval stages, and finishes with the approved data being maintained in Endur. Only once every mandatory prerequisite is in place does a counterparty become "Ready to Trade."
The objective isn't just paperwork — it directly protects the business: preventing failed trade bookings, keeping counterparty master data accurate, and reducing operational risk across four legal entities operating under different regulatory regimes.
A Jira request captures counterparty information, requested agreements, and portfolio selection. It progresses through Legal, Credit, and Compliance approval stages — each adding its own piece: agreement terms and collateral requirements from Legal, an approved credit limit from Credit, regulatory clearance from Compliance. Once every prerequisite is satisfied, the approved data is maintained in Endur: counterparty records, agreements, instrument permissions, portfolio configuration, and Business Units. Only then is the counterparty available for trading.
| Source | What it holds |
|---|---|
| Jira | Counterparty info, approval workflow, portfolio selection, requested agreements, operational status |
| Credit Team | Approved credit limits, credit approval status |
| Legal | ISDA / EFET agreements, agreement terms, collateral requirements |
| Endur | Counterparty master data, agreements, instrument permissions, portfolio config, Business Units, credit info |
Endur is the system of record — everything approved elsewhere ultimately has to be reflected there correctly, or trade validation fails downstream regardless of what Jira says.
Agreements and instruments don't automatically match. A valid ISDA or EFET agreement had to exist and explicitly cover the instrument being traded — an agreement permitting Power Futures wouldn't necessarily cover Coal Swaps. Because agreements were configured manually to reflect each counterparty's unique terms, this mismatch was a recurring, specific failure mode rather than a rare edge case.
Business Unit configuration was an easy-to-miss dependency. Each portfolio contains multiple Business Units — the internal entities authorized to trade — and if the required BUs weren't associated with the agreement or portfolio setup, trade validation failed even when everything else looked complete.
Automated credit workflows sometimes failed silently. When they did, there was no fallback except manual validation — meaning credit approval status in the system couldn't always be trusted without a manual check.
When a trader reported a failed booking, the fastest path to a fix was a fixed diagnostic order rather than checking everything at once:
This ordering matters: agreement and instrument mismatches were the most common root cause, so checking them first resolved most cases quickly, rather than starting with the rarer, harder-to-diagnose Endur configuration issues.
The business case here is risk avoidance and velocity rather than a single cost figure: every onboarding processed correctly is a counterparty that can trade without a failed booking, a compliance exposure, or a delay traced back to master data. At 15+ onboardings a month across four legal entities, even a small reduction in rework — one fewer misconfigured agreement, one fewer manual credit check — compounds quickly across a year of onboarding volume.
The onboarding process itself doesn't have a single dashboard — visibility into it comes from two places: Power BI and Jira dashboards flagging teams that hadn't nominated an approver within 24 hours (closing bottlenecks before they escalated), and the broader KPI dashboard suite covered in the KPI & Dashboard Design case study, which tracks nomination turnaround, workload distribution, and requests stuck in a given approval stage.