Conversational AI for regulated institutions
One agent. Two channels. One configuration.
The same knowledge base answers chat and voice. The channel is a field on the session rather than a second system, which is why the history and the session ID survive a switch. What backs each answer, and how it is logged, is set out under Evidence.
30 minutes, with the engineer rather than a salesperson.
One configuration
Prompt · knowledge base · guardrails · evaluation
- Chat
- Voice
- A citation required on every answer
- One session ID across the channel switch
- Chat first, voice later
Entry points
The same page for everyone. The links below are entry points, not separate versions — what your colleague reads, you read too.
- Internal audit and compliance Outsourcing, register, exit
- Data protection Data handling, deletion schedule, data-subject rights
- Information security Audit trail, incidents, kill switch
- Contact centre and digital channels Channels, architecture, engagement
- Procurement Contract, exit, next steps
- In-house assessment The pack, made to circulate
The situation
Your support line closes at 17:30. The questions arrive at 22:00.
And they do not arrive only as calls. The same question about a blocked card reaches you by phone, through the contact form and in chat — depending on where the customer happens to be.
Support line staffed
Enquiries arrive
- 00:00
- 06:00
- 12:00
- 18:00
- 24:00
17:30 continuously, as calls and as messages
Schematic representation of the time window. Not measured data — we do not know your volumes before a pilot has run.
-
After hours
Questions do not stop when the line closes. They queue until the next morning and then arrive all at once, at the same staffing level.
-
Two channels, one issue
Calls and messages concern the same topics. Separate systems answer them differently — not by design, but because they are maintained separately.
-
Two sets of answers
What the phone team says and what the chatbot writes drift further apart with every product change. It will surface in an audit.
Channels
The channel is a property of the session, not a second product.
Two surfaces, one configuration. Others are integrations into the same configuration — not a new product, but not something that runs today either.
-
Channel 01
Web chat
A script tag on your site. No redesign, no login, no access to customer data. The lowest-risk way in — and the channel Stage 1 begins with.
-
Channel 02
In-browser voice
The same agent through the microphone, with no download and no app. For people who would rather speak than type, and for accessibility.
How do I block my card?
As text
You can block your card at any hour through the blocking number or in e-banking under "Cards". The block takes effect immediately and cannot be reversed.
Source terms-2026.pdf §4.2
As speech
You can block your card at any hour through the blocking number or in e-banking under "Cards". The block takes effect immediately and cannot be reversed.
Source terms-2026.pdf §4.2
A constructed example from a fictional institution. The wording comes from the same knowledge base and carries the same citation; only the delivery differs.
Why both answer the same
- The channel is a field on the session, not a service of its own
- One system prompt, one knowledge base, one guardrail layer
- One release process, one rollback path
- One transcript format, one session ID
- One disclosure as an AI system
- One test set, which both run against
Integration paths
Not channels that run today. Scope and feasibility belong in the Stage 2 scoping — nothing is committed before that.
-
Path 01
Telephony over SIP
Connected to your existing switch. Depends on the speech platform in use: which handover and transfer paths it supports is examined during scoping, before anything is committed.
-
Path 02
Embedded in your app
Chat as a view inside an existing application. There is no SDK of my own; the embed follows the web surface.
Architecture
One core, two front ends
The front ends differ in exactly one respect: voice additionally passes through transcription and speech synthesis. Everything that determines the answer sits beneath them.
Front ends
-
Chat
Text in, text out. Widget or an existing surface.
-
Voice
STT / TTSTranscription before the core, speech synthesis after. In the browser today.
The only difference between the two front ends.
Request Answer + citation
The trust boundary
Shared core
-
Knowledge base
Your documents, versioned and indexed. No answer without a citation from this corpus.
-
Guardrails
Blocked topics, advice prohibitions, mandatory disclosures. Applied before and after generation.
-
Tools
Defined calls into your systems — appointment, status, handover. Every call is logged. From Stage 3 onwards.
-
Evaluation
A test set built from real enquiries. Runs on every change before it goes live.
The dashed line is the boundary written into the contract. In the chat pilot it holds your public documents, the prompts and the logs. Deployment in a dedicated VPC or in your own data centre is supported by the platform in use; it has not been implemented yet and belongs in scoping.
What crosses the boundary
With hosted inference, prompt content leaves the zone — under a processing agreement, in a contractually fixed region, with no training on your data. That undertaking comes from the contract with the model provider and is passed through into your own processing agreement. It is inherited, not self-performed.
Regulation and sovereignty
What you receive, and what stays with you
These points decide whether a project reaches procurement at all. That is why they are here rather than in the small print.
What you receive
-
FINMA Circ. 2018/3
Outsourcing agreement
A draft contract with audit and access rights for you, your internal audit and FINMA. Disclosure of sub-outsourcing. The entries for your inventory of outsourced functions, in your format.
-
DORA Art. 28
Register fields and exit
The fields for your register of information in the prescribed reporting format — the register itself is maintained and filed by you. Plus a draft exit strategy with timelines and support for your resilience testing.
-
GDPR / revFADP
Processing agreement
Processing agreement, deletion schedule with retention periods per data class, procedures for data-subject rights including access to stored transcripts. The undertaking that your data is not used to train models comes from the contract with the model provider and is passed through.
-
EU AI Act Art. 50
Transparency notice
Disclosure that an AI system is answering applies to text and voice alike. In the voice channel it happens in the first response. You sign off the wording.
-
Audit trail
Log format
One transcript format for both channels, with a retention period and a deletion schedule. A sample is included in the assessment pack.
-
Evaluation
Methodology
Test set construction, criteria and measurement, in writing and signed off before the pilot. Supervisors expect testing evidence, not completed questionnaires.
What stays with you
These duties cannot be outsourced. Anyone offering to take them off your hands has not read the circular.
- The materiality assessment of the outsourcing
- The data protection impact assessment
- Maintaining and filing the register of information
- Sign-off on answer texts and on the transparency notice
- The decision on the deployment model
- Liability towards your customers
What Stage 1 deliberately does not touch
The scope of the first stage is a design decision, not a limitation. It keeps the assessment small while trust is still unproven.
-
No customer data
The pilot works on public documents. Personal data never reaches the agent.
-
No authentication
No login, no identification, no session tied to a customer.
-
No access to core systems
No tool calls into CRM or core banking. That integration is the subject of Stage 3.
-
No personal data in transcripts
The agent does not ask for personal data, and the surface tells people not to enter any. You set the deletion schedule for free-text input before the start.
Sub-outsourcing
- Speech platform
- Model provider
- Hosting
- Termination
Operation relies on third-party inputs. The categories are public here; the full chain with names, domicile and processing purpose is provided on request before contract, and bindingly in the outsourcing agreement. The chain is not yet stable — a list of names on this page would be wrong within a month.
| Chat pilot | Dedicated VPC | On-premise | |
|---|---|---|---|
| Implemented by me | yes | no | no |
| Supported by the platform | yes | yes | limited availability (early access) |
| Suitable for customer data | no | yes | yes |
- yes
- limited availability (early access)
- no
The first row is the distinction that matters. VPC and on-premise are properties of the platform in use, not installations I operate — and on-premise is only in early access there. Which deployment applies is your decision before procurement; it is written into the contract.
The legal entity is your outsourcing provider, not your supervisor. This page does not replace a legal assessment and claims no certification. What is supplied is the documentation that makes your assessment possible.
Evidence
Proof rather than claims
An agent running inside a bank has to be able to show why it said something — in both channels, to an auditor, months later.
Contractual commitment
-
Audit trail across both channels
One transcript format for chat and voice, carrying the same session ID across the modality switch. A call and the chat before it are one case, not two.
-
Source attribution
Every answer names document and section. Where the agent finds no citation, it says so and offers handover — including in voice, where a footnote does not work. It is evidenced in operation against your documents.
-
Evaluation criteria
A test set drawn from your real enquiries and signed off jointly. Every prompt or knowledge change runs against it before going live. If a criterion fails, the change does not ship.
-
Versioned prompts
System prompt, guardrails and knowledge state are versioned and independently reversible. A rollback is visible in the log. The target time is in the service level, not on this page.
The agent on this site
The agent is not publicly available on this page. It runs in client demonstrations, and I show it during the technical review — against your documents rather than an invented sample corpus. A public demo shows that something works. The call shows whether it works on your corpus.
| Time | Session | Channel | Knowledge | Prompt | Source |
|---|---|---|---|---|---|
| 21:47:03 | sess_8f21c4 | Chat | kb-v14 | prompt-v7 | terms-2026.pdf §4.2 |
| 21:47:41 | sess_8f21c4 | Chat → Voice | kb-v14 | prompt-v7 | — |
| 21:48:12 | sess_8f21c4 | Voice | kb-v14 | prompt-v7 | fees-2026.pdf §1.1 |
| 21:49:30 | sess_8f21c4 | Voice | kb-v14 | prompt-v7 | Handover to agent |
A constructed sample, not an extract from an operating system. It shows the format: the same session ID across the switch from chat to voice. That single column is the proof that "one agent, two channels" is architecture and not a slogan.
Containment rate
The share of conversations that close without handover. I define the measurement with you before the pilot and report it from day one. A number in this position would be invented before your pilot has run — the space for it is reserved.
-
Question
from chat or voice
-
Pre-check
blocked topics, advice prohibitions
-
Generation
from the knowledge base only
-
Post-check
citation found? disclosure applied?
Answer with citation
No citation → handover
Checks sit before and after generation. A model that checks itself is not a control.
Engagement
Three stages. You can stop after any of them.
Chat carries the least risk and comes first. Voice follows only once the first stage has been evaluated. Authenticated use cases come last, or not at all.
-
Stage 1
4 – 6 weeks
Chat pilot on public content
Web chat over a bounded topic area drawn from your public documents. No authentication, no customer data, no access to core systems. It ends with an evaluation against the jointly defined test set.
You provide
- Public documents (terms, fees, FAQ)
- One subject-matter contact
- 20 – 40 typical questions for the test set
- A place for the script tag
Exit available Exit without any integration into your systems.
Evaluation, then sign-off
-
Stage 2
3 – 4 weeks
Voice on the same configuration
The same agent gains a voice front end — first in the browser, then, if the scoping review supports it, on a test number on your switch. Knowledge base and guardrails are untouched; what changes is only what spoken language demands: length, confirmations, handling interruptions.
You provide
- A SIP test number or trunk
- Sign-off on the synthesised voice from communications
- Escalation targets for handover
Exit available Exit without unwinding the chat channel.
Evaluation, then sign-off
-
Stage 3
subject to assessment
Authenticated use cases
Only here does the agent touch customer data: balances, card blocking, appointments. It requires a signed-off authorisation model, a data protection impact assessment, and the materiality assessment for the outsourcing.
You provide
- Integration with CRM or core banking
- Authorisation and authentication model
- Completed data protection impact assessment
Exit available This stage is optional and never necessary for many institutions.
The practice
Who builds this, and what happens if that person is unavailable
With a small supplier, key-person risk is the loudest objection in the room. Silence makes it louder, so the answer is here.
Responsible
[First name Last name]
Owner, [legal entity]
Background
[Professional background in three or four sentences: education, previous employers with dates, relevant projects. Only statements a reference check would confirm.]
Verifiable at
[LinkedIn profile] · [commercial register extract] · [references on request]
Who is in the room
I do the work. Where specialist knowledge is required I bring in named subcontractors; they appear by name in the outsourcing agreement before they start. There is no team that is not named here.
If I am unavailable
-
What sits with you
Knowledge base, prompts, guardrail rules, evaluation data and operating documentation sit in your repository, not mine. You do not need me to reach them.
-
What is documented
Operating manual, release process and recovery are written so a third party can take them over. That is part of acceptance, not a later promise.
-
What the contract settles
The contract names [cover arrangement] and [handover period]. If the cover arrangement fails, the exit documentation applies — the same one that applies on ordinary termination.
-
What you keep
Everything you brought in, and everything produced in operation. In open formats, exportable at any time.
Bracketed placeholders: name, background, verification links, insurer and cover amount are inserted before publication. Nothing here is invented.
Professional indemnity
Professional indemnity cover is held with [insurer] for [cover amount]. The policy is included in the assessment pack.
Stage of the practice
This practice is new. There are no client references, no certification and no production installation to date. What does exist is on this page and can be checked.
Making sense of the category
How to evaluate this category — including if you decide against me
You are comparing against large platform vendors and against buying a licence directly and implementing in-house. Either can be right. This section helps with the evaluation, not with choosing me.
Questions to ask any vendor
- Does every answer name its source — and what happens when none is found?
- Where does the audit trail sit, in what format, and for how long?
- Who holds the outsourcing agreement: the vendor itself or a reseller?
- What sub-outsourcing exists, and is it disclosed before contract?
- What does exit cost, and in what format do you get your data back?
- Who is in the project, by name, and what happens if that person leaves?
- Is there independent testing evidence — or only completed questionnaires?
| Large platform vendor | Specialist practice | |
|---|---|---|
| Contracting party | Corporate group, often via an integrator | Direct, one legal entity |
| Certifications | ISO 27001, SOC 2 and others held | None |
| Key-person risk | Spread across a team | Concentrated; settled contractually |
| Depth of customisation | Within product boundaries | The configuration belongs to you |
| Response to change requests | Release cycle | No release cycle; timelines in the service level |
| Availability | Support organisation, several time zones | Agreed service hours, no 24/7 |
| Exit | Depends on licence and data format | Open formats, settled contractually |
When a large vendor is the right answer
- Your board wants a brand name in the procurement file.
- Hundreds of seats across several countries, with support in every time zone.
- An existing framework agreement already covers the vendor — procurement is avoided.
- Your procurement requires certifications a small practice cannot produce.
- You need genuine 24/7 availability with a documented escalation chain.
When this practice is the right answer
- A bounded use case that should be decided in weeks.
- You want to own the configuration rather than rent it.
- The person who builds it should be the person in the technical review.
- Audit trail and exit capability weigh more than feature count.
If you finish this section concluding that a large vendor fits better, the evaluation worked. I will tell you the same thing on the call.
Assessment pack
The document set for your evaluation
Supervisors now expect independent testing evidence, not completed questionnaires. The pack is built so your assessment can actually be carried out with it — and so you can circulate it internally.
What it contains
- Pre-completed responses to the standard third-party risk questionnaire
- Structured against the FS-ISAC generative AI vendor assessment
- Register fields for DORA Art. 28 in the prescribed reporting format
- Draft exit strategy with timelines
- Evaluation methodology: test set construction, criteria, hallucination measurement
- Sub-outsourcing by category; full chain with names on request
- Deletion schedule and retention periods per data class
- Sample of the audit trail format
What it does not contain
- No certificates — none are held
- No independent security test report; planned for [period]
- No client references
- No production measurements; the containment rate comes out of your pilot
Access
Lightly gated: name, institution and email. No phone field, no qualifying questions, no sales sequence afterwards. The reason is stated openly: I want to know which institution is assessing, so I can answer follow-up questions. Circulating it internally is explicitly encouraged — the pack is made to be passed around.
Objections
What usually gets asked at this point
What does this cost?
There is no price list. Effort follows scope, and scopes differ too much for a number on a website to be honest. The figure for your institution comes out of scoping and is set out in the proposal. The first call and the assessment pack cost nothing.
Who is behind this, and what happens if that person is unavailable?
One person, named, with a background that can be checked, plus named subcontractors where specialist knowledge is required. Knowledge base, prompts, evaluation data and operating documentation sit in your repository, not mine — you do not need me to reach them. Cover arrangement and handover period are settled in the contract. The Practice section also states what this practice does not have today.
Why not simply use a large vendor?
Sometimes that is the right answer: for a brand name in the procurement file, for hundreds of seats across several countries, for an existing framework agreement, for genuine 24/7 availability, or where your procurement requires certifications I do not hold. The section on making sense of the category lists the cases individually, along with the questions to test both routes. If I am not a fit, I will say so on the call.
Where does our data sit?
In the chat pilot the agent processes public documents only; customer data never reaches it. Transcripts and logs sit in [standard environment, region]. Deployment in a dedicated VPC or in your own data centre is supported by the platform in use, but I have not implemented it — that belongs in scoping and in the contract, not on this page. With hosted inference, prompt content leaves the zone under a processing agreement in a contractually fixed region.
What if the agent makes something up?
The agent answers only from the approved knowledge base and cites a source for every statement. Where it finds no citation, it says so and hands over. Guardrails additionally apply before and after generation to blocked topics — investment advice, tax guidance, commitments on terms. Error cannot be ruled out; what it is made is detectable and traceable.
What happens at 03:00 when the agent answers wrongly?
Three things apply independently of one another. First the post-check: without a citation the agent does not answer, it hands over. Second monitoring: [thresholds] on handover rate, answer length and guardrail hits raise an alert to [alerting path]. Third you: every surface carries a reporting route, and your operations team can switch the agent off without reaching me. Confirmed incidents are reported to you within [period] with time, affected sessions and cause.
Who can switch the agent off, and how quickly?
You can. The kill switch sits in your hands, not mine: [named roles] in your institution switch the agent off via [route], without reaching me. The channel then falls back to your existing behaviour — contact form, queue, or opening-hours message. Switching off does not have to be justified.
What service hours and response times apply?
One person does not have 24/7 availability, and I do not claim any. What is agreed is [service hours] with [response time] for highest-severity incidents and [response time] below that. Outside those hours what protects you is the kill switch, not my availability — which is why it sits with you. If your institution requires genuine 24/7 cover, that is a reason to choose a larger vendor.
Are we told before anything ships?
Yes, beforehand. Every change to prompt, guardrails or knowledge state runs against the test set and goes live only after your sign-off. You receive notice [lead time] before release, with the change, the test result and the rollback path. Model changes made by the provider are announced as soon as I know of them — the fact that I do not control them is part of the disclosure.
Who is liable for a wrong answer?
Towards your customers, you are — outsourcing does not change that, and any vendor implying otherwise should worry you. What the contract settles is duties of care, service levels and liability between us, backed by professional indemnity cover. Scoping the first stage to public content without authentication keeps the exposure deliberately small while trust is still unproven.
How do we get out again?
The exit strategy is part of the contract, not a later negotiation. Knowledge base, prompts, transcripts and evaluation data are exportable in open formats at any time. There is no proprietary lock on your content: what you brought in, you take back out in the same form. Export on exit is not charged for.
Can this connect to our CRM and telephony?
Both are integration paths for Stage 2 and later, not channels that run today. Telephony over SIP depends on the speech platform in use; which handover paths it supports is examined during scoping, before anything is committed. CRM and core banking through defined tool calls with logged input and output, no open database access. In Stage 1, none of it is connected.
Why do chat and voice share one configuration?
Because two configurations inevitably drift. Separate systems mean two release processes, two audit trails and two sets of answers that diverge further with every product change. Here the channel is a property of the session, not a product of its own: same prompt, same knowledge base, same guardrails, one log.
Can we stay on chat alone?
Yes. That is a complete state, not half a project. Chat absorbs most of the out-of-hours volume on its own. Voice is available when you want it — it is not a condition.
How do customers know they are talking to an AI?
In chat through a permanently visible marker, not a notice shown once on opening. In voice through a statement in the first response. In both cases the route to a human stays available and is offered actively on request. You sign off the wording.
After the call
What happens next, and how long each step takes
So you know what you are getting into before you book. No follow-up chasing, no sequence.
-
Day 0
The call
Thirty minutes, technical. Your architecture, your data requirements, how a first stage would be scoped. If it is not a fit, I say so on the call.
From you Nothing to prepare.
-
Within 2 working days
Summary and documents
A written summary, the assessment pack, and a first read on scope. No presentation.
From you Nothing.
-
Within 10 working days
The proposal
Once the topic area is bounded: the scope of Stage 1, the size of the test set, dates, exit terms and the commercial terms.
From you The bounded topic area and the documents it covers.
-
At your pace
Internal assessment
Your internal audit, data protection and procurement review it. Follow-up questions are answered in writing. I do not chase.
From you One contact who consolidates questions.
-
After sign-off
Stage 1 begins
The pilot starts with acceptance of the test set, not with the first prompt. What gets measured is fixed before anything is built.
From you The subject-matter contact and the documents.
The decision point
The decision point sits at the end of Stage 1, not at the start. The basis is the evaluation against the jointly defined test set — and it can equally mean that this does not continue.
Thirty minutes, one engineer, your questions
No pitch deck and no sales presentation. I go through your architecture, your data requirements and how a first stage would be scoped. If it is not a fit, I will say so on the call.
If you would rather write, email directly. anubhav@putthrough.com