Treasury Data Platform

The problem

Treasury teams deal with a stream of numbers coming from everywhere: accounts, transactions, and cash positions spread across banks, entities, and formats. Keeping that picture straight by hand means spreadsheets stitched together at odd hours, and nobody trusts a spreadsheet that only one person knows how to update.

The product takes that data in through pipelines, cleans and structures it, and serves it back through a web dashboard, so the people responsible for the numbers can see where things stand. The product itself isn’t public, so this datasheet covers how it’s built instead of what it looks like.

I’ve owned most of the technical execution since the first commit, including the early calls on the data model, the service layout, and the deployment.

What I built

The backend is a set of Python services that handle ingestion, transformation, and storage. Data arrives in different shapes depending on the source, so MongoDB earned its place early: a flexible document model absorbs those differences without a migration for every new feed. The React frontend reads from the APIs and gives treasury teams a way to explore their own data without asking anyone to run a query for them.

How it works

Everything runs in Docker containers on Azure. Containerizing from the start kept deploys predictable and made moving between environments straightforward. When something breaks, the container setup makes it clear where the problem lives.

Shipping the product was only half the work. I also run it in production, which means handling deploys, watching monitoring dashboards, and fixing bugs as they come in from real users. Onboarding new customers became part of my job too. I walked them through setup, collected their feedback, and used it to prioritize work, since small annoyances for users turned out to matter more than impressive features nobody asked for.