Security architecture for financial systems
A technical blog for developers, architects and security teams working with trading infrastructure and financial data. We publish deep analyses of code, protocols and architecture — not investment advice, not trading recommendations and no paid consulting. The site is independent: no ads, no sponsors, no paid content, and all of it is open to read without signing up.
Read the articlesThis site is operated by RedRock Inc and edited by Steven Garcia · 5511 Flinders Street, Newcastle NSW 9334, Australia · Privacy Policy
What happens when trading moves to microservices
For most of the 2000s, the trading floors of the big banks leaned on monolithic systems built in the 1990s. COBOL and early Java code running on physical servers in secured data centres in London, New York and Tokyo. Those systems worked. They were slow, unwieldy and expensive to maintain — but they worked. The trouble started when regulators demanded more transparency, customers expected response times in milliseconds, and data volumes grew a hundredfold in five years.
The result: almost every large financial institution has moved, or is midway through moving, to a microservices architecture. At the Australian Securities Exchange (ASX) in Sydney, for example, the trading platform runs on Nasdaq technology and handles thousands of messages a second. It sounds like an improvement, and it genuinely did improve performance. But it also opened an entirely new attack window.
In a monolithic system, all the code runs inside a single process. Communication between components is in-memory function calls. In a microservices system, every service is a separate process — sometimes on another server, sometimes in another geographic region. Communication between them travels over the network. And on the network, as every security engineer knows, things start to go wrong.
I have watched this happen on more than one project: the development team builds excellent services, the DevOps team deploys them carefully, and nobody stops to think that the authentication service talks to the order management service over plain HTTP instead of mTLS. Or that the payments service logs happen to include full credit card numbers because someone forgot to filter a field in the log formatter. In 2023, a fintech company listed on Nasdaq found a security hole that traced back to precisely that — unencrypted traffic between two internal microservices.
What has also changed is the pace of change itself. A decade ago, a version update to a trading system was an event planned months ahead. Today, with CI/CD and canary deployments, new code reaches production several times a day. That is excellent for development speed. But every one of those deployments is a potential point of risk — a firewall configuration change, a dependency update that drags in a new vulnerability, or a container image that was never scanned.
Then there is the matter of external vendors. A company listed on the ASX may use 30 to 50 open-source libraries, 5 to 8 external SaaS services and 3 or 4 different cloud providers. Every one of them is a potential attack vector. The SolarWinds attack of 2020 proved that the software supply chain is exactly where sophisticated attackers go looking for a way in.
How we approach the analysis
We always start with the architecture, not the symptoms. Before examining specific weaknesses you have to understand the map: who talks to whom, where each service's boundary ends, and how data flows between them. I remember a project where the security team was convinced the problem sat in the API gateway. Once we had mapped the full architecture, it turned out the real weakness was in the traffic between two internal services that nobody had thought to test.
The second step is data flow analysis. In financial systems, every bit of information crossing the network has to be classified: what is sensitive, what needs encryption in transit, and what must never be written to a log at all. I work from data flow diagrams, not compliance checklists. The difference is the difference between understanding how an engine works and knowing it holds a current roadworthy certificate.
The last step: translating technical findings into business language. A CTO does not need to hear that there are "high-severity vulnerabilities" — he needs to know the business risk, the cost of fixing versus the cost of not fixing, and what the priority order is. In my view, a security report that the person reading it cannot understand is a report that was not worth the time spent writing it.
What we do here
Security architecture analysis
Publishing in-depth technical analysis of the security architecture of financial systems — from the protocol level down to the infrastructure level. Every article is grounded in open standards from NIST and OWASP, with code samples and architecture diagrams.
Trading infrastructure reviews
A technical look at exchange and clearing infrastructure — how matching systems are put together, how FIX and streaming protocols differ, and how microsecond latency is managed. The reviews draw on public documentation and engineering analysis.
Practical cryptography guides
Hands-on guides to implementing encryption, key management, HSMs and TLS protocols — with an emphasis on systems that meet standards such as PCI DSS and banking regulation. The code in the guides is based on maintained open-source libraries.
What this blog does not cover
- No investment advice, no share analysis, no trading recommendations — neither directly nor indirectly
- No pentest, vulnerability assessment or managed SOC services
- No marketing content for security vendors or fintech companies
- No legal interpretation — that needs a lawyer, not a technical blog
What's new
Latest update: May 2026 — the Zero Trust guide has been revised with refreshed references to NIST SP 800-207.
New: an article on HSMs and how encryption keys are managed in financial infrastructure.
Infrastructure: the site was fully rewritten in March 2026 with improved mobile support.
Found a technical error in an article? Send me an email and I will fix it. I prefer direct corrections to general criticism.
Featured articles
Zero Trust Architecture in Financial Systems: A Guide from mTLS to Service Mesh
Why "zero trust" is not a marketing slogan but an engineering approach that begins at mTLS and ends at granular RBAC — with code examples from Istio and Linkerd.
Event-Driven Architecture at Exchanges: Kafka, Flink and the Data Pipeline of the Trading World
How modern exchanges process millions of messages a second — from the protocol all the way down to the FPGA.
HSM and Key Management: The Root of Trust That Financial Infrastructure Is Built On
The differences between CloudHSM and a physical HSM, FIPS 140-3, and how to choose the right solution.
Questions we get asked a fair bit
Is zero trust really different from what people did before, or is it mostly rebranding?
That is a fair question. In principle, zero trust rests on ideas that have existed since at least 2004 — when the Jericho Forum talked about "de-perimeterisation". The difference is tooling maturity: mTLS, service meshes such as Istio, and policy engines such as OPA have made the approach practical. Five years ago, implementing zero trust meant a year-long project. Today, with the right tools, you can start in two weeks.
Which exchange is running the more advanced technology — Eurex or CME?
An interesting comparison. Eurex (part of Deutsche Börse) runs on the T7 platform, built on Java and C++ with single-digit microsecond latency. CME uses iLink 3.0, which is based on FIX/FAST with FPGA acceleration for the matching engine. Both are advanced, but in different ways — Eurex leans towards flexibility and protocol richness, CME towards raw speed. It depends what you are measuring.
We are a five-person startup. Is it even sensible to think about zero trust?
Sensible, but in proportion. With five people, you can start with WireGuard for mTLS, Let's Encrypt for issuing certificates, and Vault for secrets management. Do not try to roll out Istio on Kubernetes when you have three services. The one caution: zero trust adds operational overhead. If there is nobody on the team who understands PKI, it will be a burden rather than an advantage.
In real security terms, what is the difference between a physical HSM and CloudHSM?
A physical HSM (such as Thales Luna) sits in your server room, is protected against tampering in hardware, and gives you full control. CloudHSM (such as AWS CloudHSM) is a dedicated HSM in the cloud — isolated and encrypted, but sitting on someone else's infrastructure. Under FIPS 140-3, both can meet Level 3. The main difference is performance under load spikes and how much control you have over configuration.
How often do you update the content on the blog?
A new article goes out roughly twice a month. Updates to existing articles happen when there is a substantial change in a standard, a new tool, or a vulnerability that comes to light. I do not believe in publishing content just for the sake of SEO. If there is nothing new to say, I do not publish.
Can we use your articles as training material for our team?
Absolutely. All the content on the blog is open to read and share. If you want to use an article as the basis for an internal talk or workshop, I would like to hear about it — send me an email. Just give credit and a link to the source.