18 Years Inside Citi — What Living in a Tier 1 Bank Teaches You
Warren, New Jersey. Jersey City. New York. Tampa. Dallas. London. Eight years as an onsite program director and technical partner inside Citi's global technology organisation. This post reached 37,000 impressions on LinkedIn — which tells me this observation touches something real.
There is a belief that circulates widely among engineers who have not worked inside a Tier 1 bank: that large financial institutions move slowly because of bureaucracy, legacy systems, and organisational inertia.
After 18 years in banking technology — eight of them onsite inside Citi's global organisation across the United States and the United Kingdom — I want to offer a more precise explanation.
Large banks do not move slowly because of bureaucracy. They move carefully because the cost of a systemic failure is not a business setback. It is a regulatory event, a market confidence event, and potentially a systemic risk event.
That single distinction changes everything about how you engineer, how you deliver, and what you value in a technical colleague.
The asymmetry of consequence
In consumer technology, failure is recoverable. A bad deploy gets rolled back. A bug gets patched. Users are inconvenienced. The engineering culture that emerges from that reality optimises for speed — move fast, observe, correct.
In Tier 1 banking, that calculus does not hold.
A settlement failure at scale does not inconvenience users. It triggers Nostro breaks across correspondent accounts, creates regulatory reporting obligations, and — at sufficient scale — can generate counterparty credit risk that crosses desks at the central bank level. A data breach is not a PR event. It is an enforcement event with capital implications.
The engineering discipline that follows from that asymmetry is unlike anything I have encountered in consumer technology. It is not slower engineering. It is engineering with a different risk model — one that weights the tail risk of catastrophic failure far more heavily than the average case.
Once you internalise that difference, the controls that feel constraining to engineers from non-regulated backgrounds start to look like something else entirely. They look like wisdom accumulated from prior failures — institutionalised so the same failure cannot happen twice.
What the best Tier 1 banking engineers actually have
I have worked alongside technically exceptional engineers across my career. The ones who thrived inside Citi were not always the most technically advanced in the room.
They were the ones who could answer a second question after every architectural decision: what happens downstream if this fails?
Not just the immediate failure mode — the cascade. What does a failed MT202 do to the Nostro position? What does a missed cut-off window do to the settlement queue? What does a schema change in a core reference data table do to every downstream system that reads from it?
That second-order thinking is not something you develop from certifications or architecture frameworks. It comes from domain depth — from understanding the business well enough to trace the consequence of a technical decision through the operating model.
The engineers who had it were irreplaceable. The ones who didn't — regardless of their technical skill — required constant supervision at the boundary between the technical and the operational.
Regulatory pressure as engineering discipline
The audit trail requirements that feel constraining to engineers joining from consumer technology backgrounds are worth examining more carefully.
At Citi, every significant system change required documented evidence of design review, test coverage, rollback capability, and impact assessment. Change Advisory Board sign-off was not bureaucratic theatre. It was a forcing function that required you to have thought through the failure modes before you deployed — not after.
I watched that discipline contain failures that would have been catastrophic in less controlled environments. Not because the engineers were better. Because the process assumed fallibility and designed for it.
The same principle applies to Basel capital requirements, to MiFID reporting obligations, to SWIFT message format standards. They feel like constraints. They are actually a shared memory of what went wrong before the rules existed.
Engineers who understand that — who can read a regulatory requirement and trace it back to the failure it was designed to prevent — build better systems. Not because they are more compliant. Because they understand the problem more deeply.
Global delivery is an engineering problem
One of the clearest lessons from those eight years onsite was this: coordination and communication at global bank scale are engineering problems, not HR problems.
Running delivery across time zones, regulators, legal entities, and cultures — from Warren, New Jersey to London to Mumbai — requires the same rigour you would apply to a distributed systems architecture. You need clear interfaces. You need failure modes defined at each boundary. You need explicit assumptions surfaced and tested.
Teams that treated global delivery as a people management challenge struggled. Teams that treated it as a distributed systems problem — and engineered the coordination layer accordingly — delivered consistently.
Handoff protocols between time zones are an API contract. Escalation paths are circuit breakers. Status reporting cadences are heartbeat intervals. Once you see global delivery through that lens, the solutions become more tractable.
Domain depth compounds — technology changes
I have held Azure Architect and GCP Architect certifications. I have worked across mainframe systems, distributed Java platforms, cloud-native data pipelines, and now AI-assisted automation tooling.
The technology stack I worked on in 2006 is largely obsolete. The domain knowledge I built in those same years — FX settlement mechanics, correspondent banking relationships, SWIFT message flows, regulatory capital frameworks — is as relevant today as it was then. More relevant, because fewer people carry it as the generation that built those systems moves on.
Technology changes. Domain depth compounds.
The engineers who understood that early — who invested in domain knowledge as deliberately as they invested in technical skills — are the ones who built careers with compounding returns. Not because they stopped learning technology, but because they combined technology capability with something that is genuinely scarce: the ability to connect technical decisions to business and regulatory consequence.
That combination is what Tier 1 banking teaches you, if you pay attention.
It is the most durable competitive advantage I have built in 24 years.
Frequently asked questions
Why do large banks move slowly?
They do not move slowly — they move carefully. The cost of a systemic failure in a Tier 1 bank is a regulatory event, a market confidence event, and potentially a systemic risk event. The engineering discipline that follows from that reality is fundamentally different from consumer technology, where failure is recoverable and speed is the primary optimisation.
What makes a great engineer in a Tier 1 bank?
The ability to answer a second question after every architectural decision: what happens downstream if this fails? That second-order thinking requires domain depth — understanding the business well enough to trace the consequence of a technical decision through the operating model. It cannot be taught by certification. It accumulates through deliberate immersion in the domain.
Is banking domain knowledge still valuable in the age of fintech and AI?
More valuable than ever. The engineers building fintech infrastructure and AI applications in financial services need to understand the regulatory and operational context their systems operate in. Domain depth combined with modern technical capability is genuinely scarce — and that scarcity only increases as the generation that built the original systems moves on.
What is the difference between banking and consumer technology engineering?
The asymmetry of consequence. In consumer technology, failure is recoverable. In Tier 1 banking, failure can trigger regulatory action, market confidence loss, and cascading counterparty risk. That single difference shapes every engineering decision — from architecture choices to change management processes to audit trail requirements.
Found this useful? I write weekly on banking technology, fintech automation, and the lessons 24 years at Citi and Standard Chartered taught me. Subscribe to the newsletter — no spam, unsubscribe anytime.
Working on a banking technology challenge or looking for a fractional CTO? Explore my services or get in touch.
Raj Thilak is Head of Technology for Data & Analytics with 18 years at Citi and Standard Chartered across Warren NJ, Jersey City, New York, Tampa, Dallas, and London. He specialises in banking technology delivery, FX settlement, SWIFT messaging, and fintech automation. Based in Pune, India. rajthilak.dev
Found this useful? Subscribe for weekly insights.
Join the conversation
Loading comments...