So You Want to Build Tech for Investment Banks
I spent about seven years working in the intersection of technology and institutional finance, mostly building execution systems and risk infrastructure for mid-sized buy-side shops. The short version of what people get wrong is that investment banking technology isn't about flashy dashboards or trading algorithms. It's about plumbing. It's about making sure that when a senior VP at Goldman wants to move four billion dollars across three jurisdictions before lunch, the system doesn't silently drop a trade because of a timezone mismatch or a rounding error. The work is almost entirely unglamorous and it's also the only reason these banks haven't collapsed under their own operational complexity. Let me explain how the actual technology layer works, then walk you through what building it involves.
The Reality of Technology And Investment Banking
When people outside the industry imagine bank tech, they picture Bloomberg terminals and high-frequency trading. That's not even close to the bulk of the work. The actual systems are built around order management systems (OMS), execution management systems (EMS), and various reconciliation engines that run 24/7 during trading hours. These platforms have to handle pre-trade compliance checks, post-trade settlement, counterparty risk calculations, and regulatory reporting — often simultaneously, often with conflicting data sources. The biggest mistake junior engineers make is treating investment banking software like any other enterprise application. It's not. A latency issue in an e-commerce platform means your customers wait longer. A latency issue in an investment bank's order routing system means someone loses millions and there's a compliance incident to report to three different regulators. The tolerance for failure is fundamentally different. I learned this the hard way in my third year. We were migrating a client's equity trading workflow from a legacy OMS to a newer platform. Everything looked fine in testing. Then we hit a live production scenario where the new system's handling of partial fills — specifically how it reconciled fill reports across three different data vendors — created a discrepancy in the trade confirmation queue. Not a crash. Just a silent accumulation of orphaned records that grew by about forty thousand entries per day. Our pre-trade compliance checks started flagging positions that didn't exist, and the risk team was blocking legitimate trades because the system thought the book was over-exposed. It took us eleven days to trace the root cause. The workaround was a custom reconciliation layer that normalized fill data before it entered the position management engine. Took about six weeks to build properly.
What the Technology Stack Actually Looks Like
Most major banks run on a hybrid architecture. You'll find Java and C++ in the trading engines because they need deterministic performance. Python and R for quantitative analysis and risk modeling. .NET or Java-based frameworks for the front-office workflow tools that portfolio managers interact with daily. The database layer is usually a mix of relational databases (Oracle, SQL Server) for transactional data and time-series databases for market data storage. Cloud adoption in this space is surprisingly slow. Not because the technology isn't ready, but because of regulatory constraints and the sheer inertia of legacy systems that work. Most banks are running on a phased migration strategy — new systems on cloud, old systems on-prem, with integration layers connecting them. It's ugly and it's expensive and it's how it's going to stay for another decade minimum. Message brokers like Kafka and RabbitMQ are absolutely critical. Trades flow through these systems in real-time, and if you lose a single message in the queue, it creates reconciliation debt that takes hours or days to unwind. I've seen entire operations teams spend a holiday weekend tracking down a single missing message in a Kafka topic that caused a PnL discrepancy of about two million dollars.
Get the Full Details
The Skills Gap in This Field
There's a persistent talent problem that everyone in the industry knows about but never talks about openly. The engineers who understand both the technology and the finance are extremely rare. You can find excellent backend engineers who've never looked at a financial statement. You can find analysts who understand options pricing but can't write a basic API call. The people who can do both are either already placed at top firms or are independent contractors charging rates that make CFOs wince. The workaround most firms use is building cross-functional teams where technologists and finance professionals work side by side for extended periods. This is expensive in terms of headcount and office space, but it's the only approach that produces systems that actually work in production. Documentation helps, but documentation written by people who don't understand the system's failure modes is worse than no documentation because it creates false confidence.
Common Pitfalls When Building Financial Systems
The first thing to get wrong is data granularity. Investment banking data has multiple levels of detail — trade level, position level, account level, portfolio level, and firm level. Each level serves a different purpose. Trade data feeds execution. Position data feeds risk. Account data feeds compliance. Portfolio data feeds reporting. Firm data feeds everything. The mistake is assuming that one data model can serve all five purposes. It can't. You need a data architecture that maintains separate schemas for each level while keeping them synchronized. The synchronization itself becomes a second system that requires its own engineering investment. The second common failure point is error handling. In normal enterprise software, an error is a bug. In investment banking software, an error is a business event. A trade rejection from an exchange isn't a failure — it's expected behavior. The system needs to distinguish between transient errors that should be retried and permanent errors that require manual intervention. Getting this distinction wrong means either drowning operations teams in false alerts or missing real problems until they become regulatory incidents. The third thing that catches people off guard is the regulatory reporting layer. MiFID II, EMIR, Dodd-Frank, FINRA rules — these aren't nice-to-have features. They're the reason the system exists. Every trade needs to be reported to the correct regulator in the correct format within the required timeframe. The reporting requirements change frequently. What was compliant last quarter might not be compliant this quarter. Your system needs a configuration layer for reporting rules that doesn't require a code deployment every time regulation changes.
Building a Simple Order Management System
If you want to understand this space practically, try building a basic OMS. Not for production use. For learning. Here's what I'd recommend as a starting architecture. Use Python with a PostgreSQL backend. Python because the financial libraries are mature — pandas for data manipulation, NumPy for calculations, and several good packages for handling financial time series. PostgreSQL because it handles transactions correctly and has solid JSON support for storing semi-structured market data. The core entities you need are: orders, positions, instruments, and accounts. That's it. Four tables. Everything else is a relationship between these four. An order belongs to an account. A position tracks holdings in an instrument for an account. An instrument has metadata like ticker symbol, asset class, exchange, and currency.
The order lifecycle is what matters. Order created order routed order partially filled order fully filled order cancelled. Each state transition needs to be logged. Not for auditing purposes alone — for debugging. When something goes wrong at 2 PM on a Tuesday, you need to know exactly what happened at 10:47 AM when the order was first submitted. Here's a simplified example of how an order object should look in your system: The order_id is your primary identifier. client_order_ref lets the trader reference the order in their own notes. symbol, side, quantity, and price_type define what's being traded. status tracks the current state. filled_quantity and average_fill_price track execution progress. account_id links the order to the portfolio. exchange and liquidity_pool are needed for routing logic. timestamps on creation, last update, and any fill events give you the audit trail.
Don't overcomplicate this. Most beginners add portfolio theory, optimization engines, and machine learning models before they've built a system that can correctly track a single trade from creation to settlement. That's like trying to learn calculus before you understand addition.
Where This Field Is Headed
There are a few trends worth watching. Blockchain and distributed ledger technology for settlement is getting real attention, though progress is measured in years not months. RegTech tools that automate compliance reporting are becoming table stakes rather than differentiators. And the push for real-time risk aggregation across all asset classes is driving significant infrastructure investment. Open banking APIs are another area creating genuine demand for engineering talent. Banks need to expose their data and services to third-party providers while maintaining security and regulatory compliance. This isn't consumer banking APIs — this is institutional-grade data access with authentication, authorization, rate limiting, and audit logging at levels that most web developers have never encountered. The compensation reflects the difficulty of the work. Senior engineers in this space at major firms typically earn well above market rates for general software engineering. Not because the coding is harder — though it is in some dimensions — but because the consequence of failure is so much higher and the talent pool is so much smaller.
A Practical Note on Getting Started
If you're reading this and you want to break into this field, don't start by trying to build a trading platform. Start by understanding what a trade actually is. Learn how buy and sell orders work. Learn what happens after the trade executes — settlement, clearing, custody. Learn why there are two different dates associated with every trade (trade date and settlement date) and what happens when they don't match. Then learn the basic regulatory framework. MiFID II if you're in Europe. Reg SHO and Regulation SCI if you're in the US. You don't need to memorize the rules. You need to understand why they exist and how they constrain system design. Finally, build something small and watch it fail. Add a partial fill. Add a cancelled order. Add two accounts that share a position. Add a market data feed that goes offline unexpectedly. The failures will teach you more than any successful implementation ever could.
