- FinTech
- Systems
- Writing
When people talk about finance engineering from the outside, they usually talk about scale, latency, or the amount of money moving through the system. Those things matter, but they are not the part that stayed with me.
What stayed with me was the standard.
At BlackRock, I learned that once software touches accounting state, reporting, reconciliation, or downstream financial decisions, "mostly right" stops being a meaningful target. A system can be fast, modern, and architecturally clean and still be operationally dangerous if the data is stale, if exceptions are hard to interpret, or if two systems disagree and nobody can explain why quickly.
That realization changed how I thought about engineering. Before that, I probably valued cleverness more than I should have. After working in finance, I started valuing discipline much more highly. Not bureaucracy for its own sake, and not process theater, but the kind of discipline that shows up in the structure of the system itself. Where is the source of truth? What validates a number before it becomes visible to someone else? How do we recover from partial failure? If something goes wrong under pressure, how quickly can a human trace what happened?
Those questions sound almost conservative on paper, but they lead to better systems.
One of the biggest mindset shifts for me was realizing that financial systems are really trust systems. People do not experience them as a collection of pipelines, APIs, transformations, and storage layers. They experience them through confidence. Can I trust this number? Can I publish this output? Can I act on this report without second-guessing it? Can I tell whether this mismatch is expected, dangerous, or simply delayed?
That changes how you look at architecture. In a lot of domains, speed creates the impression of progress. In finance, speed without validation just moves ambiguity faster. Streaming helps, modular services help, better storage patterns help, but none of those things solve the real problem on their own. The real problem is confidence under pressure.
That is where reconciliation becomes such an important teacher. Reconciliation forces a system to admit that the world is messy and that multiple representations of reality can drift apart for legitimate reasons. Timing differences, sequence mismatches, partial updates, stale upstream data, interpretation gaps, all of these show up eventually. Once you live inside that world long enough, you stop designing software around the fantasy that one pipeline will always be clean and complete. You start designing around visibility, recovery, and explanation.
That lesson has stayed with me far beyond finance. I still think a lot about how systems fail, but more importantly I think about how they explain failure. A good system does not just detect that something is wrong. It preserves enough context that a person can understand what went wrong without doing digital archaeology across five dashboards and three teams. That sounds like an operational detail, but it is actually a product decision. If the system makes ambiguity legible, people trust it more. If it hides ambiguity until the last mile, people start building manual workarounds around it.
BlackRock also sharpened my view of modularity. I do not mean modularity as an abstract architecture virtue. I mean modularity as a survival tool. If ingestion, normalization, validation, publishing, and reconciliation are shaped clearly enough, teams can isolate problems faster and reason about behavior more confidently. If everything is compressed into one opaque stage, every incident becomes slower and more expensive to understand. The question that really matters in those moments is rarely "Was the architecture elegant?" It is usually "Where did the problem enter the pipeline?"
That experience also made me more careful about the word velocity. High velocity in finance is not only about throughput. It is about keeping data fresh while preserving correctness, absorbing change without introducing silent drift, and making exceptions visible before they become downstream damage. That kind of velocity is harder than it sounds because it depends on more than runtime performance. It depends on contracts, checks, observability, and shared discipline across the system.
What I carried forward from that period was not a preference for one stack or one architectural style. It was a stronger instinct for what trustworthy systems feel like. They tend to have explicit contracts, visible state transitions, reconciliation-aware workflows, and enough instrumentation to tell you whether the business reality and the system reality are still aligned. They do not rely on optimism. They make doubt inspectable.
That is why the BlackRock chapter still feels foundational to me. It taught me that good engineering is not only about making things smarter or faster. In the systems that matter most, it is also about making them dependable, traceable, and explainable when the day goes bad.
That standard has followed me into everything else I have built since, whether the surface area is payments, trust tooling, analytics, or AI-assisted workflows. The domain changes. The engineering standard does not.
Build systems that people can still trust on a bad day.