Second line of defence, first conversation.
Model risk, change control, customer data safeguards, records retention. A financial services review asks these in a specific order and expects specific evidence. The architecture answers all four, and this page is the translation — control by control, in the vocabulary your validators already use.
What this page is not
It is not a claim of sector experience, and it does not name a bank we have worked with. The case studies carry no logos for the same reason. This is the same exercise as the control mapping, narrowed to one industry's vocabulary: here are the questions your review will ask, here is the control that answers each, and here is what remains your obligation rather than ours. Ask about deployment history directly and you will get a direct answer.
The translation
Four questions, and the control each one is really asking for.
MODEL RISK GOVERNANCE
“Show me effective challenge. Not the output — the derivation.”
Supervisory guidance on model risk expects a validator to be able to challenge a model rather than accept it, and a generative system defeats that the moment its output is a fluent paragraph with no traceable derivation. Deterministic citation provenance resolves every claim to the exact tool call and result set that produced it, and the end-to-end distributed trace propagates across the control and execution planes so the record survives the boundary. A validator reviews the actual derivation.
CHANGE CONTROL & SEGREGATION OF DUTIES
“Who approved this, and could they have approved their own work?”
IT general controls want a proposer and an approver who are structurally different parties. An agent that can write to a system of record collapses that distinction, so the agent never holds write authority at all. Every write stops at a gate, shows its blast radius before anyone approves, and executes under a human approval pinned to a version token — so an approval granted against one state cannot be replayed against another.
CUSTOMER DATA SAFEGUARDS
“Where does non-public customer information go?”
Under an on-premises or BYOC deployment, nowhere — the execution plane runs inside your own infrastructure and the control plane holds no customer data at rest. Independently of topology, sensitive spans are detected and tokenized before any inference call, by a deterministic scanner rather than a model judgement, and the mapping that would reverse them stays inside your perimeter. Egress is denied by default and inference routes through a gateway you have already approved.
RECORDS & THIRD-PARTY RESILIENCE
“Reconstruct this decision in two years, without us.”
An audit trail that only a vendor can interpret is a concentration risk, and third-party operational resilience regimes are increasingly explicit about that. The trace is emitted into your own observability stack in open formats, the deployment runs on infrastructure you control, and full source transfer plus infrastructure as code is included in every engagement. If we disappeared, the system would keep running and the record would stay readable.
Where it lands
The work that is already governed, done faster.
Regulatory and management reporting
A governed source and a plain-English request become a dashboard with a real semantic model — one your BI team owns, edits, and can defend line by line.
Verification on regulated systems
Requirements, source code, and merged changes become traceable verification tests, with the requirement-to-test mapping an auditor asks for produced as a by-product.
Data readiness before any of it
Where two desks define the same measure differently, that is recorded as a fact about the business rather than resolved silently in favour of whichever definition the model saw first.
Send the model risk questionnaire too.
Not only the security assessment. If your second line has a standard set of questions for a model that produces text, we would rather answer them in writing before a demo than discover them in month three.