Getting Generative AI Approved to Write to a System of Record
An ongoing customer due diligence system running in production inside a bank, with a language model inside the flow and an approval path that lets confirmed values reach the master customer record.
- Generative AI
- Regulated Environments
- Systems Integration
- Conversational AI
- 6 months
- Requirements to productionElapsed time for the whole engagement. Very little of it was the model: the critical path was integration with on premise core systems, master data, a credit bureau over a legacy protocol, government population services, telecom data and a customer relationship platform.
Overview
Prototypes stall for a reason that has nothing to do with the model. Risk will not accept a determination it cannot trace. Compliance will not accept a component that can invent a value in a governed field. Finance will not accept per record inference costs across a whole book. Security will not accept a channel that discloses customer data on infrastructure the bank does not own. Each objection is correct, and a demonstration answers none of them.
This system got past all four and ran in production, writing into the master customer record. Records falling due for re-verification are detected in core systems on premise and streamed into a cloud estate. A cascade of matching techniques settles what it can before anything is asked of anyone. What survives becomes a short, consented conversation with the customer on the messaging app they already use. Confirmed values reach an operations portal where routine updates clear automatically and anything needing judgment is queued for the bank's own compliance staff. A language model sits inside that flow and is the least used component in it.
The Context
The client is not named. The engagement was delivered for a retail and commercial bank in a regulated market, against an obligation to keep customer records current: address, contact numbers, occupation, industry and source of funds.
The only person who can confirm any of it is the customer. Asking them is expensive, so it happened through whichever member of staff was already talking to them, which made it uneven and interrupted something else. That shape is not specific to banking. Insurers hold policyholder details, telecom operators hold subscriber registration, healthcare providers hold patient demographics and coverage. Anywhere there is a record you are obliged to refresh and a frontline absorbing the cost of refreshing it, the same pattern applies with the field names changed.
The Challenge
Almost every organization attempting this hits the same wall. A language model produces a value. That value has to update a governed field. Nobody will authorize it. The project then either dies, or survives as a recommendation engine that a person retypes into the real system, which removes most of the benefit.
- Risk would not accept a determination that could not be traced to how it was reached
- Compliance would not accept a component able to invent a value in a governed field
- Finance would not accept per record inference costs across the whole book
- Security would not accept customer data disclosed on infrastructure the bank does not own
A control that depends on the model behaving well is not a control. Every answer below is structural.
What Was at Stake
Leaving it unresolved has a specific cost, and it is not the prototype. It is that the obligation stays where it was: absorbed by frontline staff, one customer at a time, in the middle of a conversation about something else. Records go stale between checks, and the work scales with the size of the book rather than with the number of records that actually changed.
The failure mode on the other side is worse. A matching system that quietly resolves a real change as a match produces a clean audit trail across a missed risk indicator. A customer previously recorded as a doctor who now describes themselves as a cardiologist has changed nothing; one term sits inside the other. A customer whose source of funds was salaried income and is now rental income has changed exactly the thing ongoing due diligence exists to detect. The two look identical to a string comparison and require opposite outcomes. Any vendor quoting a single matching accuracy figure without addressing which direction its errors run has not thought about this problem.
Our Role
Kainskep delivered the system. The bank provisioned infrastructure and ran acceptance testing.
- Data engineering and the matching engine
- Conversational AI and the intent handling around it
- API development and integration across on premise and external systems
- Cloud architecture and DevOps for a serverless Microsoft Azure estate
- Management reporting, scoped as a deliverable rather than added afterwards
The messaging platform was not our choice. The bank already ran one for its existing bots and required this system to use it on estate consistency grounds rather than technical ones. That decision arrived mid engagement and was absorbed without renegotiation. In a large organization this is normal, and a delivery partner who treats your standards as an obstacle rather than a condition is the wrong partner.
What Moved It Past the Gate
Four decisions, taken together, are what a risk function actually signed for. None of them is exotic. All of them are structural, which is the point.
The model is the last resort, not the front door
The matching engine runs as a cascade ordered by cost. Direct match resolves exact agreement, and most fields on most records stop there. Fuzzy match handles spelling variation, abbreviation and the ordinary noise of data captured by different people at different times. Proximity match resolves addresses geospatially, deciding whether two differently written addresses point at the same physical place rather than comparing them as strings. Only what survives all three reaches a model.
The model cannot invent a value
Outputs are mapped onto the bank's existing code lists. The model does not mint categories. Where nothing maps it does not guess and does not approximate: the customer is shown the valid options and asked to choose. Where a mapping was fixed and agreed in advance it runs as a deterministic derivation rule rather than as model reasoning. The model can decide that two things mean the same. It cannot decide what things exist.
The system decides what needs a human, humans decide the outcome
Confirmed and derived values flow into an operations portal. Updates meeting defined criteria clear automatically. Anything flagged as requiring judgment is queued and approved by the bank's own compliance staff before it takes effect. Volume is kept away from people and judgment is routed to them, which is what makes automated write back acceptable to a risk function.
The behavior is visible to the people accountable for it
Management reporting was treated as part of the deliverable rather than as something bolted on when questions started. The people who own the obligation can see how the system is behaving in production without asking an engineer.
Each matching layer writes its verdict to its own result stream, so a questioned case can be traced to the layer that settled it and the basis it used. That is a different conversation with an auditor than pointing at a model and describing its training.
How the System Works
The path a record takes, from falling due to reaching master data.
Detection and ingestion
Records falling due for re-verification are detected in core banking systems on premise and published to a streaming platform, then bridged over private connectivity into the cloud estate. The bridge performs transport only and carries no business logic, so its behavior is testable and observable at both ends.
- On premise core
- Private connectivity
- Queued on arrival
The matching cascade
Four layers in fixed order, cheapest first: direct, fuzzy, geospatial proximity, then model based reasoning over the genuinely ambiguous residue. Each layer emits its own determination record rather than collapsing into a single outcome, so the overwhelming majority of determinations never involve a model at all.
- Direct
- Fuzzy
- Proximity
- Model
Eligibility, evaluated before contact
Before any message is generated, government population data is checked for deceased status and telecom data is checked for how long the number has been associated with its current SIM. Under three months, no message is sent. Failure of either check ends the flow rather than adding a warning to it.
- Deceased check
- SIM age check
A consented conversation that narrows
The opening message identifies the institution, names the obligation, links terms and asks whether the customer wants to proceed. Identity is challenged before anything is displayed. As fields are confirmed the system drops them and asks again only about what remains, until nothing is left. Structured reply buttons handle the common path and free text is understood for everything else, with both converging on the same state.
- Consent first
- Step-up challenge
- Progressive disclosure
Screening on the way in, code lists on the way out
Inbound content is screened and classified against curated intent libraries before any business processing. Outputs are bound to governed code lists. The model reasons freely in the narrow space between those two constraints, which is where the judgment that justified using it actually lives.
- Intent classification
- Attachments refused
- Emojis interpreted
Write back through approval
Confirmed and derived values land in an operations portal. Routine updates clear automatically against defined criteria. Anything flagged for judgment waits for a compliance approver before it reaches the master customer record. A derived value is disclosed to the customer rather than applied silently, then routed and approved on the same path.
Turning generation settings down does not buy safety, it buys stupidity, and the two get confused constantly. Predictability here comes from the structure at both ends, not from constraining the model until it can no longer reason. That changed the conversation with the bank from how creative the model is allowed to be into what it is structurally capable of producing, which is a far easier conversation to close.
What We Delivered
Requirements to production in six months, of which very little was the model. The schedule was the integration surface.
The matching engine
Four layers with per-layer result streams, so every determination records which layer settled it and on what basis.
The conversational layer
Consent, step-up authentication, intent classification, the narrowing loop, and conversation state resolved across a burst of messages rather than message by message. People send three messages before you answer the first, and the second changes what the correct answer to the first would have been.
The operations portal
Auto-approval against defined criteria, a manual queue for judgment cases, and the write path into master data.
The integration surface
Core banking event capture, master data management, a credit bureau over a legacy SOAP interface, government population services, telecom subscriber data, the customer relationship platform and the messaging vendor.
- On premise
- External processors
- Messaging vendor
Consolidated logging and alerting
One conversation touches on premise sources, a messaging vendor, four matching layers, external services and a serverless estate. It can be reconstructed end to end from one place, which is unglamorous and is what makes the system operable at three in the morning.
Management reporting
Production behavior visible to the people who own the obligation, without an engineer in the loop.
Trigger events originate in core systems on premise, and getting them out reliably over private connectivity is foundational work that nobody sees and everything depends on. Understanding an institution's internal systems does not compress by adding people to it, which is the most common estimating error we see in this class of project.
Outcomes
The business case for this program projected a specific efficiency improvement. It was modeled during requirements gathering, before a line of code existed, and it was never measured afterwards. It is not reprinted here as an outcome, because it was not one. We would rather hand you a page with no headline percentage than one with a number that falls apart the first time you ask how it was calculated.
- Ran in production against real customer records
- Wrote into master data through an approval path the compliance function accepted
- Guardrails held against live customer input, including input nobody designed for
- Failure modes were found in a controlled population and closed there
The first production cohort was drawn from the bank's own staff who hold accounts there: low risk, reachable, and far more likely to report a defect than escalate one. For a system that displays personal financial information on a public messaging channel, choosing the initial blast radius is a design decision in its own right. Four behaviors appeared there that no design had anticipated, which is exactly what that cohort existed to find.
What This Page Does Not Cover
Published in anonymized form at the client's instruction. Client identity, proprietary system names, vendor names and commercially sensitive figures are withheld.
- The institution, its market position, and the size of its customer book
- The messaging platform, the credit bureau, and the other named vendors in the flow
- Model selection, prompt design, and the contents of the intent libraries
- Volumes, throughput, and per record cost at full scale
- The efficiency figure the business case projected, because it was modeled rather than measured
Related Capabilities
The disciplines this engagement drew on, and where each is described in full.
AI Engineering
The production engineering around a model that has to run unattended inside a governed workflow, including what it is structurally prevented from doing.
AI engineering for production systemsData Engineering & Machine Learning
The matching engine and the pipelines feeding it, from on premise event capture through to a determination record per layer.
Data engineering and machine learningCloud Infrastructure
The serverless estate, private connectivity to core systems, and the consolidated logging that makes one conversation reconstructable end to end.
Cloud infrastructure engineeringApplication Development
The operations portal, the approval queue, and the APIs joining a serverless estate to systems that predate it by decades.
Software engineering for complex applications