Lessons from building a trading platform for an energy company: security, real-time, and backoffice

I took part, as a Forward Deployed Engineer and together with a team, in building an investment and trading platform for an energy-sector company, including its operations backoffice. Working on a system where every operation has regulatory, financial, and audit implications forced me to think differently than I would on an order-management app. In this article I share the architecture and process learnings I took away. It includes no code or internal client information, but it does cover the principles and decisions that may help other teams in a similar situation.

What an investment platform demands: security, auditability, and real time

When a project involves trading and investments, three requirements show up from day one and are not negotiable.

Security. I do not only mean authentication and authorization, although that is the foundation. It is about designing on the assumption that every component can be an exposure vector: who can see which position, who can execute which operation, and how access is segregated between operational and supervisory roles. On a platform that handles real capital, the principle of least privilege is not an optional best practice: it is a design requirement from the first architecture meeting.

Auditability. Everything that happens on a trading platform must be reconstructable afterwards: who did what, when, with which market data available at that moment, and what decision the system or the user made. This changes how flows are designed: every operation needs a complete, immutable, queryable trail, not as a later addition but as part of the data model from the start. Designing auditability "later" tends to end up more expensive and more fragile than building it in from the beginning.

Real time. Markets do not wait. An investment platform needs to reflect prices, positions, and operation states with a latency users do not perceive as latency. This affects architecture decisions: what is synchronized live, what can be processed asynchronously, and where eventual consistency is acceptable and where there is no room for it. The tension between "everything real time" and "everything consistent" is one of the most recurring design discussions in these systems, and it has no single answer: it depends on which part of the flow you are looking at.

These three requirements do not live in separate compartments. A security decision affects auditability, and a real-time decision affects security. Designing for all three at once, from the start, is what separates a robust financial platform from a prototype that works in the demo but does not survive production.

The operations backoffice and reconciliation

If the trading frontend is the visible part of the iceberg, the operations backoffice is what supports that visibility. A central part of the work on this project was precisely that backoffice: the set of tools and processes that allow executed operations to be recorded, validated, and reconciled against the corresponding sources of truth.

Reconciliation is, in my experience, one of the most underrated problems in fintech. It is not showy and it does not appear in demos, but it is where the errors that matter get caught: an operation that does not match, a state left inconsistent between systems, a difference that needs explaining. Designing this layer well means thinking about:

• End-to-end traceability, so an operation can be followed from origin to settlement with no gray areas.
• Periodic reconciliation processes as well as on-demand ones, because problems are not always caught in the automatic cycle.
• Clear, actionable alerts when something does not reconcile, sent to whoever can actually resolve it, not to a log nobody reads.

The backoffice is not a secondary module: it is often what determines whether the platform is reliable in the long run. A flawless trading frontend with a weak backoffice is a promise that sooner or later breaks.

Working with client teams and vendors

Technical architecture is only half of the work. The other half, just as decisive, is how work is coordinated between the development team, the client's internal teams, and the external vendors in the ecosystem (market data, custody, infrastructure, among others).

Some process learnings I took away:

Understand the domain before proposing solutions. In a financial project for an energy company there are business rules, regulatory constraints, and internal processes that are not in any technical document. The first productive stage is not writing code: it is listening to the teams who know those rules and translating them into clear requirements.

Align integration expectations with each vendor separately. Each vendor has its own SLAs, data formats, and availability windows. Part of a Forward Deployed Engineer's job is to map those particularities early, so they do not become surprises once the system is in production.

Frequent, verifiable communication. In projects with multiple stakeholders, ambiguity is the silent enemy. Documenting decisions, confirming understanding in writing, and validating assumptions with the people who hold the business context prevents rework later.

Design for change. Regulatory and business requirements in a financial environment evolve. The architecture has to absorb those changes without every adjustment meaning rewriting half the system.

Working at the intersection of the technical and the organizational is probably the part of the Forward Deployed Engineer role I value most: it is not only about solving engineering problems, but about solving them within a real human and business context.

What I took away

• In fintech, technical architecture and the way you work with people are inseparable.
• Security, auditability, and real time are designed together from the start, because each decision affects the other two.
• The backoffice and reconciliation deserve the same attention as the visible frontend.
• Listening to the team that knows the domain comes before writing code.
• Documenting decisions and confirming assumptions in writing prevents a lot of rework.

If you are working on something similar or your team faces similar challenges, I would like to exchange experiences: you can write to me on LinkedIn. And if you want to know more about my work as a Forward Deployed Engineer, I describe it in my portfolio: https://estebanburgos.com.ar/portfolio.