Six years inside a Tier-1 European bank: lessons in Wealth and Core Banking

I joined ABN AMRO in 2020 as a cloud data engineer. Six years later I’m embedded across the Wealth Management and International Core Banking grid, leading payments domain delivery and regulatory engineering. Here’s what I’d tell someone walking in tomorrow.

Table of contents

The first eighteen months are mostly orientation

The instinct is to ship something fast — show value, justify the hire. Don’t optimise for that. The first eighteen months in a large bank are about understanding the terrain: which teams own which systems, where the political seams are, why the obvious-looking refactor is actually a six-quarter program touching seventeen stakeholders, and which “broken” things are broken on purpose because of a regulatory or accounting constraint nobody told you about.

The engineers who shipped fast in their first quarter were, six months later, the ones unwinding the things they shipped. The engineers who spent the first quarter listening were the ones writing the architecture proposals by year two.

Domain literacy is the multiplier

The biggest career inflection wasn’t a new tool. It was when I stopped describing my work as “data engineering” and started describing it as “payments engineering” or “wealth platform engineering.” The technical work didn’t change. The conversations did.

In Wealth Management and Core Banking, the people you most need to influence are not engineers. They are product owners, regulatory leads, accounting controllers, and risk officers. They will work with engineers who understand their domain. They will route around engineers who don’t. Investing the time to learn how a SEPA transfer actually clears, what makes a CESOP record in-scope, why the bank books a particular FX leg the way it does — that’s what unlocks the room.

Regulatory delivery is its own discipline

Most engineering culture optimises for speed of change. Regulatory delivery optimises for deterministic outcomes inside a fixed window. ECB submissions don’t move because a deployment slipped. CESOP cycles don’t pause for a refactor. The window is the window.

That changes how you build. You over-engineer for traceability. You instrument every cycle for the metrics auditors will ask for, before they ask. You build the “what was the state of this record on day X” query into the platform as a first-class capability, not a heroic ad-hoc lookup. You make rollback paths real, tested, and routine. None of this is glamorous. All of it is the difference between a clean cycle and a regulatory exception letter.

Cloud migration is a governance project wearing engineering clothes

For three years I acted as single point of contact (SPOC) for a multi-country re-platforming program migrating on-premise banking workloads onto Azure. The thing nobody mentions in the kickoff: the cloud migration is mostly about governance.

The technical lift — Azure Data Factory pipelines, Synapse models, CI/CD — is well-understood. What slows things down is data quality (the on-prem data was wrong in stable, known ways; the cloud doesn’t tolerate that ambiguity), master data management (which system is the system of record, really?), data architecture (the on-prem model encoded twenty years of decisions, half forgotten), and data security (who can see what, in what jurisdiction, under what legal basis).

If you’re SPOC on a similar migration, front-load the governance conversations. They’re going to happen. Whether they happen at design time or at user-acceptance time determines whether the program ships on schedule.

Self-service BI is a contract, not a feature

A pattern I see go wrong: the data team builds a Power BI report for a stakeholder. The stakeholder asks for a tweak. The team makes it. Two months later the team is maintaining forty subtly different Power BI reports for the same business question, none of which agree.

The fix is treating the data layer as the product, and BI as a thin presentation on top. Self-service means: here is the governed dataset, with documented definitions, with an owner and an SLA. Build whatever visualisation you want. The data team owns the meaning. The business owns the visualisation. That separation removes 90% of the maintenance burden — and, more importantly, removes the “five reports, five answers” problem.

Engineering leadership inside a bank is mostly translation

The senior engineers I’ve watched succeed inside ABN AMRO aren’t the strongest individual contributors. They’re the strongest translators — between business and engineering, between regulatory and operational, between the platform team and the consuming chapters. They turn ambiguous stakeholder asks into engineering work plans, and turn engineering constraints into language the business can actually use to make tradeoffs.

If you’re a senior engineer in a bank, your output is increasingly written documents, architecture diagrams, and 1:1 conversations — not pull requests. That feels uncomfortable if you joined engineering to write code. It is, however, what the role is.

Tooling churn matters less than you think

In six years on the data platform I’ve seen: SQL Server → Synapse → Databricks. Power BI Desktop → Power BI Service → Power BI fabric items. ADF v1 → ADF v2 → Databricks Workflows. erwin classic → erwin Web.

In every case, the people who chased the tooling change as a career strategy were no further ahead two years later than the people who stayed close to the domain. The tools are commoditising; the domain expertise is not. The best technical investment is the one that compounds — and the things that compound in banking are domain knowledge, stakeholder relationships, and a reputation for reliable delivery. Not the latest Databricks runtime.

What the second six years will be about

Increasingly, three things: bringing AI capability into the platform layer (not as a demo, as a production capability with the same governance posture as everything else); making the Wealth and Core Banking client view consumable across the bank rather than rebuilt per consumer; and continuing to push regulatory delivery off legacy and onto governed, auditable platforms.

If any of those sound interesting, I’m currently exploring senior engineering and consulting roles across EMEA and the GCC — say hi via LinkedIn or email.