My current project has me back in finance data — piecing together how sources map to a target model, and working out which problems are worth automating and how. It’s pulled me straight back to where a lot of this started: an internship at HSBC that, at the time, I mostly filed under “learning experience.” Looking back, it planted more than I realised. It taught me reporting frameworks, corporate lingo (with formal Hindi), and what taking ownership and accountability actually feels like. If I had to describe the work in two words, it would be:
- Automation
- Reconciliation
Both words still describe my job. That’s the part that surprised me.
My work involved automating the regulatory reporting end-user calculations. Like most things reporting, you have new data coming in annually, with interspersed manual adjustments happening monthly. Every month you need reports showing how changes in foreign exchange rates have moved our numbers across monthly, quarterly, and annual periods. It’s the same class of problem I now sit with daily — a data model, a set of sources, and the unglamorous question of whether the numbers can be trusted end to end.
A quick offshoot if you’re interested: the main calculation for the reports was RWA (Risk Weighted Assets). The learning resources used the formal definition for understanding, but the way you calculate it in practice is to take a weighted average of your assets. The weights are the risk percentages, either provided by a regulatory authority or calculated internally. I still like using that example — it’s a clean reminder that a scary-sounding regulatory metric is usually a weighted average with good documentation around it.
There was an existing Excel-based tool to handle the annual data ingestion from internal sources. However, the reports and the calculations to get to the final report were formula-linked with manual interventions wherever required. My initial assignment was to create a tool to automate the reporting. I studied the manual workflow and implemented another Excel-based tool with fancy VBA code duct-taped to data manipulations offloaded to Power Query and DAX. It worked — it even fetched the FX rates from an internal website through custom web-scraping code I wrote in VBA. Nevertheless, it was hiding a lot of unnecessary complexity under the UI. That was my first real lesson in something I now weigh on every project: there’s a difference between a tool that removes complexity and one that just hides it. Mine hid it. Hidden complexity always comes due later — usually for whoever maintains the thing after you’re gone.
By the time I presented the demo to the stakeholders, the requirement had changed. The ask now was to have a single tool incorporating both the data ingestion and the reporting. And it needed to be implemented in this fancy tool called Alteryx, which I had never heard of before. Never one to bow down to a challenge, I started working on it. It was a no-code tool, with a graph representation for the workflow — tools as nodes interconnected with directed edges (check out n8n; it has similar workflows, and you don’t have to shove a fortune to test it out). It isn’t that hard to figure out if you have a good understanding of databases (SQL), especially with their rich examples for each of the tools.
With the help of a colleague’s manual workflow as the reference for data ingestion, I implemented a workflow — still complex, due to the myriad data transformations the various internal data sources required and their data mappings. Getting those mappings right meant pivoting the raw sources and reconciling them against what the reports expected, over and over, until the coverage held. Nevertheless, it was much easier to understand than the Excel workflow. I know, because I painstakingly wrote the documentation and organised the workflow in the UI. It’s not developer-friendly if your problem is inherently complex, but once implemented it’s quite comfortable for the end users.
Throughout the project I kept dreaming about how a YAML-based workflow like we have with Docker Compose would address many of my pain points. Back then it felt like a daydream; now it’s just a view I hold. When a problem is genuinely complex, config-as-code — versioned, diffable, reviewable — beats dragging boxes on a canvas, and it’s only become truer as LLM-assisted tooling makes writing and reviewing that config cheaper than it’s ever been. No-code buys you an easy demo and a comfortable end user; it charges you back in everything that comes after.
The full-circle moment came recently, and it’s why I finally wrote this down. Helping an ETL team piece together the gaps in a source-to-target mapping (STTM), I was trying to work out what the data model did and didn’t cover. My ETL lead’s suggestion: pivot the raw data and read the pivots — that’s how you see the coverage and the holes. It’s the exact same thing I did at HSBC. Pivoting and cross-tabbing raw data to understand what’s really in it, and reconciling it against what the model expects, was the quiet backbone of that internship — the “Reconciliation” half of my two words. Watching a senior engineer independently reach for the technique I first learned as an intern was oddly reassuring: the fundamentals travel. The tools change — Excel, Alteryx, whatever comes next — but the instinct to reconcile against the raw data doesn’t.
That’s the thread. Today I’m the person in the room who can talk about the strategy and then go build the thing underneath it — and that didn’t come from a title. It came from duct-taping FX scrapers into VBA and documenting Alteryx graphs nobody asked me to document. The internship didn’t just give me a line on a résumé; it gave me the two words I still work by, and the habits underneath them. Automation, to make the tedious thing repeatable. Reconciliation, to make sure the repeatable thing is right.