Scattered reporting turned into a 200-table warehouse.
Before a bank can ask a question of its data, somebody has to decide what the words mean. That is most of the work, and it is not a technical problem.
200 tables modelled From scratch BI system Custom control system
The situation
The reporting existed, but it was assembled — different teams pulling from different places, each with a defensible definition of the same number. There was no shared foundation, which meant every question of any importance turned into a negotiation about whose figure was correct.
What was needed was not another report. It was a structure that could carry all of them.
Modelling for a bank
The warehouse grew to roughly 200 tables, modelled with performance as a design constraint rather than an afterthought. In an environment of this size, a model that is merely correct will not survive contact with real volumes — the shape of the schema decides what is possible to ask.
Transactional and analytical concerns were separated deliberately. Reporting queries that scan history do not belong on structures designed to accept writes all day, and merging the two is the most common reason a warehouse becomes slow within a year of launch.
The control system
Alongside the warehouse, a custom control system was built to manage the loads: what ran, what it produced, what failed and what had to be reprocessed. Without that layer, a warehouse of this size becomes unauditable — you can see the numbers, but you cannot answer where a particular one came from.
That question, asked by an auditor rather than an analyst, is the one that matters most in a bank.
Tell us what you are trying to fix.
A tangled integration, a slow database, a system nobody understands any more. The first conversation is 30 minutes and costs nothing.