NOTHING RECONCILES
Core banking, cards, lending and the CRM each hold a version of the same customer. Nobody can say how many customers the bank actually has without a caveat.
USE CASE / BANKING & FINANCE
When the auditor asks where a number came from, you have a week to answer.
In a bank, a number is not just a number. It has to be traceable back to the transaction that produced it, through every rule that touched it on the way. Most banks can produce the number. Far fewer can produce the trail behind it without three people and a fortnight of work.
What usually goes wrong
MONTH-END IS MANUAL
The regulatory pack is assembled by hand, in spreadsheets, by the same two people every month. When one of them is on leave, the close slips.
NO LINEAGE
Somebody asks why a figure changed. Answering it means reading stored procedures written years ago by people who have left.
ACCESS IS ALL OR NOTHING
Analysts either see full customer data or they see nothing. So they get full access, because the work has to get done. That is the finding the auditor writes up.
AI HAS NOWHERE TO STAND
The bank wants an assistant that answers policy questions. But the documents are spread across four systems with no permission model, so the pilot cannot go live.
What we build
- A lakehouse with clearly separated raw, cleaned and reporting layers, so it is always obvious which layer a number came from.
- Column-level lineage, so any figure can be traced back to its source field automatically, not by reading code.
- Masking rules that hide account numbers, names and identifiers by role, applied at the platform level rather than per report.
- Reconciliation tests that run on every load and compare totals against the source system before anyone sees a dashboard.
- A change history that cannot be edited, so you can show exactly what the data looked like on any past date.
- One agreed definition for each regulatory measure, written down, versioned, and used by every report.
What AI looks like here
Policy and circular assistant
- What it does
- Lets a person ask a question in plain English across regulatory circulars, internal policies and past submissions, and get an answer with the exact paragraph it came from.
- How it works
- The documents are cleaned, split into sections and turned into embeddings, which are stored in a vector database. When someone asks a question, the closest sections are pulled back and passed to a language model, which writes the answer using only those sections. This pattern is called RAG, short for retrieval augmented generation.
- What it needs
- A cleaned document store, a vector database, a model hosted inside your own cloud account, and permission rules so a person only ever retrieves documents they are already allowed to read.
"Where did this number come from" explainer
- What it does
- An analyst clicks a figure in a report and gets a plain-English explanation of which source system it came from, which rules were applied, and when it last changed.
- How it works
- The lineage the platform already records is turned into a structured description, and a language model turns that description into readable English. The model does not calculate anything. It only explains what the lineage already says.
- What it needs
- Column-level lineage collected automatically at build time, a metadata store, and a model that never touches the underlying customer data — only the metadata about it.
Alert narrative first draft
- What it does
- When a monitoring rule flags a transaction pattern, the assistant writes the first draft of the case narrative, so the analyst edits instead of starting from a blank page.
- How it works
- Structured features about the alert are assembled from the platform. Those features, plus the relevant procedure text, are given to the model, which produces a draft narrative in the bank's standard format. A human reviews and signs off every single one.
- What it needs
- A feature pipeline, an approved narrative template, an audit log of every generated draft, and a hard rule that the model never makes or influences the decision itself.
The tools we use here
- Snowflake or Databricks
- dbt
- Apache Airflow
- AWS Glue
- Amazon S3
- Terraform
- GitHub Actions
- Snowflake Cortex or Amazon Bedrock
- Unity Catalog or Snowflake role-based access
- Dynamic data masking
- Power BI or Tableau
What changes for you
- The regulatory pack is produced by the platform, not by two people in spreadsheets.
- Any number can be traced to its source in minutes, by the analyst, without an engineer.
- Analysts get the data they need without seeing customer identifiers they do not need.
- When the auditor asks a question, the answer is a screen, not a project.
What we will not do
- We do not put customer identifiers into any language model, ever.
- We do not let a model make or influence a lending, credit or compliance decision.
- We do not build an assistant that answers without showing the source it used.
- We do not send your data to a model hosted outside your own cloud account.