Workflow for regulated financial institutions · regulated LSI
A governed path from supervisory request to defensible answer
Supervisory requests often send finance, risk, and regulatory-reporting teams searching through legacy queries, spreadsheets, prior reports, and undocumented conventions under deadline pressure. This representative workflow shows how a bank can turn that work into governed self-service—where each answer remains connected to its source data, access decision, methodology, and audit record.
The problem: every request is archaeology
Supervisory requests can arrive with short deadlines and touch data across the core banking system, the risk warehouse, reporting files, and decades of conventions that were never written down.
The people who know where the logic lives become a human query interface: translating requests into SQL, reconciling definitions, and explaining the result after the fact. Even when the number is correct, the evidence behind it is often scattered across systems and difficult for a reviewer to reconstruct.
Typical supervisory-request turnaround
typical working daysIllustrative turnaround ranges. Actual results depend on source-system readiness, workflow complexity, and review requirements.
A general-purpose AI assistant does not solve this problem. Shared-cloud deployment may be unacceptable for bank data, and an answer the institution cannot defend line by line is worse than no answer.
The issue is not simply getting an answer. It is producing one the bank can explain, evidence, and stand behind.
Working the problem
Here is a supervisory request worked end to end as one governed session, drawn from real customer conversations. Every stage below is a real platform surface: the definitions it recalled, the queries it ran, the evidence it attached.
The question
The answer starts from what the bank has already validated—not from a blank query editor.
What the team already knewThe conventions that often live in a few experienced employees' heads become validated institutional memory:
- Reporting-date conventions
- Product-code mappings
- Restatement boundaries
- Approved methodology definitions
- Desk- and function-specific data-selection rules
Every query runs read-only against the risk warehouse, each with its audit reference—a reviewer can replay the trail.
Governed executionSELECT l.segment,
SUM(l.drawn_amount) / 1e9 AS exposure_bn,
SUM(l.drawn_amount) / t.loan_book_total AS share_of_book,
f.sub_limit_pct,
f.sub_limit_pct - SUM(l.drawn_amount) / t.loan_book_total AS headroom_pp
FROM loan_book l
JOIN limit_framework f USING (segment)
CROSS JOIN loan_book_totals t
WHERE l.cre_flag = TRUE AND l.as_of = '2026-09-30'
GROUP BY l.segment, f.sub_limit_pct, t.loan_book_total
ORDER BY share_of_book DESC;| Segment | Exposure | % of book | Sub-limit | Headroom (pp) |
|---|---|---|---|---|
| Office | €1.95bn | 5.5% | 6.0% | +0.5 |
| Retail | €0.90bn | 2.5% | 4.0% | +1.5 |
| Residential | €0.75bn | 2.1% | 4.0% | +1.9 |
| Logistics | €0.45bn | 1.3% | 3.0% | +1.7 |
| Hotels | €0.15bn | 0.4% | 1.5% | +1.1 |
Drawn exposure · month-end Sep 2026 · loan book €35.6bn
Concentration only means something against the board-approved limits—pulled from the same governed source and computed in the same record.
The analysisTotal CRE share of loan book
Six quarters vs 12.5% internal limit
Demo data.
CRE book by LTV band
Drawn exposure · month-end Sep 2026
When a supervisor asks how a figure was produced, the institution can export the complete chain:
- The question as asked
- The governed queries and tools that ran
- The source systems and result-set metadata used
- The reporting convention or methodology applied
- The file sections cited
- The access decision and validation history behind the result
The finding — evidence attachedOffice CRE is at 92% of its internal sub-limit
Office exposure of €1.95bn is 5.5% of the loan book against a 6.0% sub-limit, driven by drawdowns on two 2024-vintage facilities. Aggregate CRE remains within appetite at 11.8% vs the 12.5% limit, and 84% of the book sits at or below 70% LTV. Every figure carries its query, methodology, and audit reference.
{ "claim": "Office CRE utilisation: 92% of sub-limit", "derived_from": [ { "query": "evt-4c19d2", "source": "risk_warehouse.loan_book", "rows": 18204, "as_of": "2026-09-30" }, { "query": "evt-4c19d3", "source": "limit_framework", "version": "current" }, { "memory": "def-cre-taxonomy-v4", "status": "validated", "validated_by": "Group Risk Methodology" } ], "produced_in": "thread/supervisory-cre-request"}The export is not a retrospective reconstruction. It is generated from the governed workflow that produced the answer.
The response pack stages itself—exposures, trend, credit quality, and the methodology page, ready for review.
The deliverableThe deployment: private cloud, the bank's keys
DataQube runs inside the bank's own environment—private cloud, on-premise Kubernetes, or air-gapped infrastructure—with customer-controlled keys and no required external calls.
Read-only database access is enforced at the database layer, with row limits and timeouts. Single sign-on maps the bank's existing identity groups to roles. Need-to-know rules become enforceable policy rather than a spreadsheet maintained by hand.
Deployment, identity, and audit integration
Deploy into the bank's approved environment, integrate with its identity provider, and send structured audit events to the existing SIEM.
A live supervisory question, end to end
Connect approved risk and finance sources. Turn a real reporting question into a governed analytical thread with evidence attached.
Test the system the way audit will
Review access controls, logging, change tracking, and data minimization. Validate that denials, data reads, and configuration changes are visible and exportable.
More functions, the same guardrails
Add finance, treasury, controlling, and risk workspaces while applying information barriers and data-access rules consistently across the organization.
What audit can test
A bank does not become self-service by giving every team a chatbot. It becomes self-service when people can answer questions independently within controls that security, risk, and audit can trust.
A credible platform should make its controls observable—not merely describe them in a security questionnaire.
- Whether authorization denials are recorded, including the policy that produced them
- Whether a user can query outside the scope they were granted
- Whether read-only controls, row limits, and timeouts are enforced at the data layer
- Whether the audit record is append-only and exportable to the institution's SIEM
- Whether configuration changes and policy updates are visible and attributable
The goal is not a cleaner compliance narrative. It is evidence that controls operate in the real workflow.
What changes for the bank
A governed answer is a better answer
For regulated reporting, speed without evidence creates risk. Evidence without usable workflows creates delay.
DataQube gives banking teams a governed path from question to answer—inside the bank's own environment, with the controls and provenance needed for review.
Request a walkthrough of the banking workflow.
See your data answer questions - without leaving your infrastructure
Thirty minutes with an engineer: live product, deployment options, and your security team's questions answered by someone who wrote the code.