Operations · Policy Q&A
WorkflowBanking operationsAnswering policy questions in bank operations: which setup fits which question
Operations staff ask the same policy questions every day, and a wrong answer becomes a breach. This guide compares four ways to answer them, and shows when a cited, logged Q&A workflow is the right choice.
Valnora & Elric team6 min read
Compared in this guide
- AIntranet search
- BRelay with the policy base
- CDeployed Q&A workflow
- DPolicy team mailbox
Banking operations runs on written procedures: what counts as proof of address, when a payment needs a second signature, which accounts can be opened without a branch visit. Staff ask about them all day. Most questions are routine, and the answers are written down somewhere. The risk sits in the answers that are slightly wrong: an outdated version, a misread exception, a confident guess.
Supervisors expect institutions to have clear internal policies and to make sure staff can apply them; governance guidelines such as the EBA’s say so in general terms. How staff actually get answers is left to you. This guide compares four ways to do it and explains when each one fits.
The options at a glance
Four ways to answer policy questions
| Criterion | Intranet search | Relay with the policy base | Deployed Q&A workflow | Policy team mailbox |
|---|---|---|---|---|
| Where the answer comes from | The asker reads the documents and interprets them | A Relay searches the Knowledge Base and answers in its chat | Fixed steps: search, cited draft, checks, then reply | A policy specialist |
| Citations | Links to documents, not to the passage that answers | Can cite passages if its instructions require it | Every answer names document and section, enforced by the steps | Depends on the specialist |
| Consistency | Low. Two people read the same page differently | Good for one-to-one questions, varies with phrasing | High. Same steps, same checks, same format every time | High within one person, varies across the team |
| Unsupported or sensitive questions | Asker may guess | Escalation text in its instructions tells it who to point to | Routed to the policy owner at a Human block before any reply | Handled directly |
| Record of what was asked | Search logs at best | Chat history and Relay activity | One row per question plus a block-by-block run trace | Mailbox history |
| Effort to set up | None beyond keeping the intranet current | Low. Instructions, Knowledge Base, autonomy level | Moderate. Build, test against past questions, deploy | None, but scales with headcount |
| Best for | Browsing and reading in depth | Individual specialists who want a research assistant | High-volume, repeated questions from front-line teams | Novel questions and interpretation calls |
None of these replaces the others. Most banks will keep the intranet for reading, the policy team for judgement calls, and add one of the two Agent Serve options for the questions in between. The choice is about which questions go where.
When intranet search is enough
Search works when the asker has time to read and the policy is short and unambiguous. It fails on the questions that matter most: exceptions, cross-references between procedures, and documents with several versions in circulation. It also leaves no record of what the person concluded.
If your procedures are well written and questions are rare, start here and do nothing else.
When a Relay fits better
A Relay is an AI coworker with its own instructions and access. Connected to a policy Knowledge Base, it searches the documents and answers in its chat, and its escalation text tells it who to point people to when it cannot answer.
This suits specialists, such as a KYC lead or a payments operations manager, who want a research assistant they can question back and forth. Set it to Observe: it reads and drafts, and cannot save files, send email or book meetings. The trade-off is consistency. A conversation can drift, and the format of answers depends on how each question is phrased.
When a deployed Q&A workflow is the right call
Choose a workflow when the same questions arrive in volume from front-line teams, when every answer needs a citation, and when you need a record of what was asked and answered. A workflow runs the same steps every time, and you can test those steps before staff rely on them.
One question, one cited answer, one record
Workflow · Policy Q&A
- 01Question arrivesA Webhook trigger receives the question, the asker’s team and the product it concerns.
- 02Search policiesA Knowledge block finds the relevant passages in current, approved policies and procedures.
- 03Draft a cited answerAn Agent block answers only from the passages found and names each document and section.
- 04Check the answerGuardrails run a hallucination check against the passages and mask personal data.
- 05Policy owner if neededUnsupported or sensitive questions pause at a Human block for the policy owner.
- 06Log and replyThe exchange is written to a Q&A table and the answer is posted to Teams or Slack.
The workflow is built in the workflow builder from standard blocks:
- A Webhook trigger receives the question from your intranet form or helpdesk tool, with the asker’s team and product.
- A Knowledge block searches the policy Knowledge Base. Connect it to the system that holds approved versions, such as Confluence, Google Drive or OneDrive, so superseded drafts never enter the search.
- An Agent block drafts an answer from the passages it was given and must name the document and section for each statement.
- A Guardrails block runs a hallucination check against those passages and PII detection that masks any customer details staff paste into a question.
- A Condition block sends unsupported answers, and questions on topics you always want a person to handle, to a Human block, which pauses the run until the policy owner replies.
- A Table block logs the question, answer, sources and route, and a Microsoft Teams or Slack block posts the answer back where the asker works.
What the solution produces
Answer posted to the operations channel (illustrative)
MessageQuestion: Can we accept a utility bill older than three months as proof of address for a joint account?
Answer: No. The procedure requires proof of address dated within the period it sets for each applicant, and lists the alternative documents you can accept instead.
Source: Customer identification procedure, section 3.4 “Proof of address”, version effective 1 July.
If the customer cannot provide any listed document, raise it with the KYC policy owner. Do not open the account.
Every run is traced block by block in Logs, so if an answer is challenged you can see which passages it was drawn from. Workflows run from a deployed version, so a change to the prompt or the routing is reviewed before staff see it.
When only the policy team will do
Some questions are interpretation calls: a product the procedure did not anticipate, a customer situation with conflicting rules, a request to make an exception. These belong with the policy owner. The point of the workflow is to protect their time for these, by taking the routine questions off their desk and sending them the hard ones with the relevant passages already attached.
How to choose, and how to start
A simple test sorts most cases:
- Is the answer written down, unambiguous and asked often? Use the deployed workflow.
- Is the asker a specialist working through a problem? Give them a Relay with the policy Knowledge Base.
- Does the answer need someone to interpret or decide? Route it to the policy team.
- Is the person reading to learn rather than to act? The intranet is fine.
To start, take one policy area with high question volume, such as account opening. Collect fifty past questions with the answers the policy team gave, build the workflow, and run those questions through it before go-live. Review the Q&A table weekly: questions that keep reaching the policy owner usually point at a procedure that needs rewriting.
Controls and governance
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
Bring your own keys
Use your organisation’s own model provider keys at organisation or workspace level.
More on how Agent Serve handles access, data and audit on the security page.
For turning the same policies into checkable controls, see policy to control mapping. For a workflow that applies the account opening procedure to real files, see KYC onboarding review.
Questions teams ask
Does the workflow change or approve policies?
No. It reads approved documents and answers from them. Policy changes go through your normal governance, and the Knowledge Base is updated when a new version is approved.
What happens when the policy does not cover the question?
The hallucination check and a condition on the search results catch answers the passages do not support. The question then pauses for the policy owner instead of getting a guessed reply.
What you need
- Current, approved versions of your policies and procedures in one place
- A Knowledge Base connected to that source, such as Confluence, Google Drive or OneDrive
- A list of topics that must always go to a person, such as complaints or sanctions
- A named owner per policy area to answer routed questions
- A sample of past questions and correct answers to test against
- A Teams or Slack channel, or a helpdesk form, where staff already ask