Banking and financial services

The data exists. The answer does not.

A mid-sized bank runs dozens of operational systems and thousands of tables. When a manager asks why arrears have grown in one region, the answer does not come out of that data. It comes out of a queue.

The route is the same everywhere. The question is raised. A request is logged with IT or the management-information unit. It waits two or three days for review and prioritisation. A report arrives on day five, or day seven. That is the optimistic case, and it assumes the report answers the question that was actually asked.

Three things hold it in place. A predefined dashboard answers only the questions somebody already thought of. The branch manager, the credit officer and the marketing lead cannot ask directly; access is mediated. And by the time the report lands the decision window has closed, which turns data into an archive document rather than a management instrument.

The problem is not missing data. It is the turnaround rate of question and answer.

What the queue costs

Four costs, none of which appears on a line item:

• Funding opportunities that are not identified while they are still open.
• Credit risk recognised late. Arrears are observed once they already exist.
• Valuable customers whose departure becomes visible after the balances have moved.
• Analyst capacity spent regenerating the same reports instead of analysing anything.

The largest cost is subtler than any of them. Every answer produces roughly three further questions, and each of those re-enters the queue at the top. So the enquiry stops early. What has profitability done in these branches? gets asked. Was it the income side or the cost of funds? sometimes gets asked. Do the affected branches share a characteristic? — the question where the answer actually lives — is usually never asked, because at a week per step nobody gets that far.

How the work changes

The hard part of analysis is not running the query. It is framing the question.

"Why has profitability fallen in this region's branches?"

That question has no single answer, because it contains three unstated choices: which period, operating profit or net, and compared against last year or against the approved budget. So the system does what a good analyst does — it asks, agrees a scope, and confirms it before starting. Then it proposes the axes worth examining: income mix, cost of funds, portfolio quality. Nothing runs until the scope is confirmed.

For questions whose answer is not a number, a research run dispatches an orchestrator and a fleet of workers — between three and twenty per run — that pursue different angles concurrently against the relevant sources and return one documented report with the figures behind it.

Two properties matter more than either of those in a bank. A user with the right permission sees the exact query that ran, so a finding can be checked rather than believed. And when the data is not sufficient, the system says so instead of producing a plausible number. A wrong answer is more damaging than no answer, and a data-plane circuit breaker enforces it: eight consecutive failures return an honest error rather than a confabulated one. Charted numbers come from executing code against the result set, never from a model writing arithmetic into a sentence.

What it connects to

Nothing is migrated and nothing is copied elsewhere. The data stays where it is and is only read. One adapter layer covers thirty database engines behind a single interface — Oracle, SQL Server, Db2, PostgreSQL, MySQL, ClickHouse, Snowflake, MongoDB, Elasticsearch and the rest — which is what makes a single answer out of several systems possible at all.

The connection is opened as a read-only database user, created and controlled by the bank’s own security team, and every query executes inside a read-only, time-bounded transaction with a row cap. The most important step of a deployment is not the install. It is schema documentation: a drafting assistant proposes a description for every table and column, and the bank’s experts edit and approve them. That is where “effective balance” gets bound to the column the bank means by it, and it is the step that decides whether the answers agree with the bank’s official reports.

Where this is the wrong fit

• If the questions are fixed, build a report. Forty people asking the same question every morning need a dashboard, and a dashboard is cheaper and more predictable.
• If the warehouse is undocumented, budget the documentation first. This is the most common reason these deployments disappoint. No language model repairs a schema nobody can explain.
• If the bank has not agreed what the metric means, the disagreement is about the definition and no tool settles it. It surfaces in week one, which is at least useful.
• If you need writes — approvals, corrections, workflow — this is the wrong layer. Read-only is a design decision, not a limitation we intend to remove.
• If there is no warehouse or replica at all, that project comes first. Pointing analytic queries at a live core system is not something we will help you do.
• It is deployed in production for two organisations today. Deeply engineered and early, and we would rather you knew that before the first meeting.