;
};
To set up Fini (usefini.com) for a fintech or bank, scope knowledge per agent and per customer segment, tag regulated intents such as disputes, fraud reports, complaints, and account closures, and send those intents to your team as internal notes through [Reply Rules](/en/automations/reply-behavior) while Fini resolves the routine account, card, and payment questions. Then identify logged-in customers with a signed widget token, give every Action a least-privilege credential, and gate every change with a [Test Suite](/en/testing/test-suite) run before it reaches customers.
This page is the configuration playbook, in the order most teams build it. For what Fini does for financial services as a product, see [usefini.com/industries/finance](https://www.usefini.com/industries/finance).
```mermaid theme={null}
---
title: Recommended configuration layers for fintech and banking
---
flowchart LR
subgraph WHO["Who is asking"]
JWT["Identify logged-in users server-signed JWT"]
end
subgraph FIRST["Routing signals"]
TAGS["Regulated Intent tags"]
ET["Escalation Topics fraud, takeover, legal, regulator"]
end
subgraph USE["What the agent can use"]
KN["Scoped knowledge agents and Attribute Filters"]
ACT["Least-privilege Actions read and write split"]
end
subgraph SEND["How the reply goes out"]
RB["Reply Rules Internal Comment, No Reply"]
GR["Guardrails reply checks"]
end
CUST(["Customer"])
HUM(["Your team Business Rules, Agent groups"])
subgraph AROUND["Around every change"]
TS["Test Suite before publish"]
INB["Weekly Inbox review"]
SSO["SSO for the dashboard"]
end
WHO --> FIRST --> USE --> SEND --> CUST
ET -.->|"escalate"| HUM
RB -.->|"internal note"| HUM
classDef source fill:#F7F7F7,color:#131415,stroke:#E8E8E8
classDef agent fill:#131415,color:#FFFFFF,stroke:#131415,stroke-width:3px
classDef surface fill:#FFFFFF,color:#131415,stroke:#131415
classDef human fill:#C3EE5E,color:#131415,stroke:#131415,stroke-width:2px
class JWT,TS,INB,SSO source
class TAGS,ET,KN,ACT agent
class RB,GR surface
class CUST source
class HUM human
```
## Compliance pointers
This page covers how you configure the agent. Fini's certifications, data handling, and contractual terms are documented separately; share these with your security and compliance reviewers:
| Topic | Page |
| - | - |
| Security program, certifications, and the Trust Center | [Security overview](/en/security/overview) |
| Encryption, data residency, model training, and sensitive data masking | [Data handling](/en/security/data-handling) |
| PCI DSS Level 1 certification and card data in conversations | [PCI DSS](/en/security/pci-dss) |
| Controls for disputes, complaints, and other regulated workflows | [Regulated industries: disputes and complaints](/en/security/regulated-industries-disputes-complaints) |
Fini automatically masks sensitive data, including card numbers and health details, everywhere it stores conversation data (transcripts, Inbox and AI Steps traces). Fields you hide from the AI are also redacted in AI Steps. The Guardrails in step 5 are an extra layer on what the agent says. See [Data handling](/en/security/data-handling#masking-sensitive-data).
## Recommended setup checklist
| # | Area | Recommended setting | Where |
| - | - | - | - |
| 1 | Knowledge scoping | One agent per audience; folder **Attribute Filters** for country, product, and plan | [Articles](/en/knowledge/articles) |
| 2 | Sensitive-intent tags | A custom `Regulated Intent` group, plus QA groups such as *Guardrail \| Regulatory Accuracy* | [Tags](/en/configuration/tags) |
| 3 | Reply Rules | **Internal Comment** for regulated intents; **No Reply** when a human is assigned | [Reply Rules](/en/automations/reply-behavior) |
| 4 | Escalation Topics | Fraud, account takeover, legal and regulator mentions, sensitive data shared in-channel | [Prompts](/en/configuration/prompts) |
| 5 | Guardrails | **Confidential attributes**, **Banned terms**, **URL allowlist**, **Internal reasoning leak**, custom rules | [Guardrails](/en/configuration/guardrails) |
| 6 | Identity | Widget **Identify logged-in users** with a server-signed JWT | [Widget](/en/deploy/widget) |
| 7 | Actions and keys | Least-privilege credentials, read and write split, idempotency keys | [Actions](/en/api-reference/actions), [API Keys](/en/deploy/api-keys) |
| 8 | Handoff | Business Rules for widget escalation; Agent groups for native queues | [Business Rules](/en/automations/business-rules), [Agent groups](/en/configuration/agent-groups) |
| 9 | Regression testing | A Test Suite collection run before every publish | [Test Suite](/en/testing/test-suite) |
| 10 | Review | Weekly Inbox review of guardrail hits, regulated tags, and thumbs-down replies | [Inbox](/en/testing/inbox) |
| 11 | Dashboard access | SSO for your team (Okta, Google, Slack or Microsoft Entra ID) | [Okta SSO](/en/sso-login) |
### 1. Scope knowledge to the right customers
Financial products differ by country, entity, and plan, and an answer that is correct for one segment can be wrong for another. Scope at the Articles layer, not by duplicating Sources:
* **One agent per audience.** Retail and business banking, or separate regional entities, usually warrant separate agents, each with its own folders toggled on in the Articles agent selector. See [Knowledge → Agent-specific scoping](/en/knowledge/overview#agent-specific-scoping).
* **Attribute Filters on folders.** Gate jurisdiction-specific folders on a User Attribute, for example `country = US` for US fee schedules. Filters on the same attribute combine with OR; different attributes combine with AND. See [Articles → Attribute filters](/en/knowledge/articles#attribute-filters).
* **Retire products in one click.** Turn a folder's **Active** toggle off when a product is sunset so no article in it can be retrieved.
* **Keep review on.** Leave the workspace "require review" setting on so new and changed articles pass a human in the [Review Queue](/en/knowledge/review) before agents use them.
A filter on a missing attribute silently excludes the folder. If a segment of customers suddenly gets no answers, check that the attribute the filter reads is populated for them.
### 2. Tag sensitive intents
Create a custom group that names the intents your compliance team treats as regulated. Turn on **Tag Group available in Rulebooks** and set **Tag Selection** to "Multiple tags can be selected", since one conversation can be both a dispute and a complaint.
| Tag | Example description (when to apply) |
| - | - |
| `dispute_or_unauthorized` | The customer says they didn't make or authorize a transaction, or wants to dispute a charge. |
| `fraud_or_takeover` | The customer reports fraud, a lost device with account access, or someone else in their account. |
| `complaint` | The customer expresses dissatisfaction and asks for it to be recorded, reviewed, or escalated. |
| `account_closure_with_balance` | The customer wants to close an account that still holds funds or owes a balance. |
| `hardship_or_collections` | The customer describes financial difficulty or asks about missed payments or collections. |
| `legal_or_regulator` | The customer mentions a lawyer, legal action, a regulator, or an ombudsman. |
Write each tag's description with "when not to apply" cases (for example, a question about the dispute *policy* is not a dispute). Then add QA groups that follow the Guardrails (QA) pattern in [Tags](/en/configuration/tags#custom-groups), such as *Guardrail | PII Redaction*, *Guardrail | Regulatory Accuracy*, and *Guardrail | Prompt-Injection Detection*, and assign them to every agent.
### 3. Route regulated intents to an internal note
On **Rulebook → Reply Rules**:
* **Internal Comment:** `Regulated Intent In complaint, legal_or_regulator, account_closure_with_balance, hardship_or_collections`. The agent drafts the reply and your team reviews and sends it.
* **No Reply:** `Human Agent Assigned Equals True`, plus `Escalated Conversation Equals True` if you want the agent fully out once a conversation is escalated.
The stricter card wins (No Reply, then Internal Comment, then Direct Reply), so broad Direct Reply rules never override these. Use `In` or `Contains` rather than `Equals` because the group allows multiple tags.
Reply Rules gate the final reply only. Tools inside an Intent Rule still run when Internal Comment matches: in [End-to-end: card replacement](/en/walkthroughs/card-replacement), the card is frozen and only the confirmation is held for review. When a human must approve before anything changes, keep the write Action for that intent out of the tree.
### 4. Add escalation topics
In the Planning Prompt, edit the *Escalation Topics* subsection of **Knowledge Search – Decision Logic**. Keep the defaults (legal or regulatory issues, persistent human requests) and add your high-risk operations: account-takeover signals, wire or high-value transfer problems, and customers sharing full card numbers or government ID numbers in the channel. The planner routes matching conversations to a human and skips knowledge search. See [Prompts → Controlling when the agent escalates](/en/configuration/prompts).
### 5. Configure guardrails
On **Guardrails**, per agent:
| Check | Fintech configuration |
| - | - |
| **Confidential attributes** | Internal account IDs, risk and KYC flags, and any attribute your rules use but customers should never see. It matches those values; it is not blanket personal-data detection. |
| **Banned terms** | Phrases compliance prohibits, such as promises of approval, guaranteed outcomes, or product claims your legal team hasn't approved. |
| **URL allowlist** | Your app, website, and help-center domains only, so the agent never links to a lookalike domain. |
| **Internal reasoning leak** | On, so prompt and pipeline text never reaches a customer. |
| **Custom rule** | For example: "Fail if the reply gives individual investment, tax, credit, or legal advice." Add pass and fail examples. |
Guardrails are not a fail-closed security boundary: a check error can leave the original reply unchanged. Review per-policy verdicts in AI Steps, not only the overall outcome. See [Guardrails](/en/configuration/guardrails).
### 6. Identify logged-in customers
Account-specific answers and account-changing Actions need a known customer. Embed the widget inside your authenticated app and pass a JWT as `customerToken`, signed server-side with the widget's **Signing Key** (HS256). Set `collectEmail` to `false` when your auth system already verified the email, and put only the fields your workflows need in `user_attributes`. See [Widget → Identify logged-in users](/en/deploy/widget#identify-logged-in-users).
On unauthenticated channels (a public website chat, inbound email), keep the agent to knowledge answers and read-only lookups, or add an explicit verification step before any Action that changes an account.
Identity verification and MFA resets have no separate feature to switch on. You build them as Agentic Actions: an Intent Rule plus Attributes and Actions that call your identity, KYC and MFA systems from **Tool** nodes, so the check runs the same way every time and the result is recorded in AI Steps. For logged-in users, the widget's signed JWT identity above supplies who the customer is. See the `Customer Identity` attribute pattern in [Card replacement](/en/walkthroughs/card-replacement) and [KYC and account changes](/en/use-cases/kyc-and-account-changes).
Card numbers and security codes should still not be requested in a support conversation. Route card actions (freeze, replace, dispute) through your payment provider with [Actions](/en/api-reference/actions), and add sensitive-data sharing to your Escalation Topics in step 4.
### 7. Give Actions least privilege
Two kinds of credentials are involved, and both should be scoped narrowly:
* **Credentials Fini uses to call your systems.** Attribute and Action Data Steps send your API credential in their Headers, and the Fini workspace is the secret boundary. Issue dedicated service credentials for Fini, read-only for lookup attributes and Actions, and a separate credential limited to the specific write endpoints each Action needs. If your write endpoints accept idempotency keys, pass one on every write. Turn on **Visible to AI** only for attribute fields the agent needs to mention.
* **Fini API keys your systems use to call Fini.** Created under **Deploy → API Keys** with **Read** and **Write** scopes. Uncheck **Write** for export and analytics jobs, use one key per system, and revoke keys the same day a teammate leaves or an integration is retired. See [API Keys](/en/deploy/api-keys).
### 8. Wire the handoff
For widget conversations, create a [Business Rule](/en/automations/business-rules) on the **On Escalation** trigger that opens a ticket in your helpdesk with the transcript and user attributes. For native tickets, map `dispute_or_unauthorized` and `fraud_or_takeover` to dedicated teams with [Agent groups](/en/configuration/agent-groups).
### 9. Run the Test Suite before every publish
Create test cases from real conversations covering each regulated intent and each automated workflow, and keep them in one collection. Put the checks every case shares in criteria groups: an AI judgement that regulated intents escalate or get only an internal note, an AI judgement that the agent makes no promises outside policy, and exact checks for the expected Action or handoff. Run the collection on every prompt, knowledge, rule, or Action change; you can select draft Behavior, rules, and articles for a run without publishing them. Test Suite uses recorded or mock Action responses and never calls your APIs, so do live end-to-end checks against sandbox endpoints or in a controlled pilot. See [Test Suite](/en/testing/test-suite).
### 10. Review in Inbox every week
Filter [Inbox](/en/testing/inbox) by the **Guardrail** filter under **Quality**, by your QA tag groups, and by **Feedback: Thumbs down**. The **AI Steps** panel on each conversation records which rule ran, every Tool input and output, and each guardrail verdict, which is the record your compliance team will ask for. The **Guardrail** filter also matches failures recorded in replays of a conversation, so check the replay's AI Steps before attributing a hit to the live reply.
### 11. Put dashboard access behind SSO
Fini supports single sign-on with Okta, Google, Slack and Microsoft Entra ID. The setup guide covers Okta: with [Okta SSO](/en/sso-login), your team signs in with Okta credentials and access follows your Okta assignments.
## Intents to automate first, and intents to escalate
| Automate first | Hand to your team |
| - | - |
| Balance, transaction, and payment status lookups (read-only Actions) | Disputes and unauthorized transactions |
| Card freeze and replacement, with a fraud gate ([walkthrough](/en/walkthroughs/card-replacement)) | Fraud reports and account takeover |
| Statement and document requests | Complaints, and anything mentioning a regulator or legal action |
| Fees, limits, and product questions from Knowledge | Account closure with a remaining balance |
| Address and contact-detail updates with a Form, on identified users | Hardship, missed payments, and collections |
| Transfer and deposit timing questions | KYC exceptions and document review |
Disputes are a common candidate for partial automation: the agent can collect the transaction details with a Form and open the case through an Action, with Reply Rules holding the reply for review. The pattern is in [Fini for disputes and chargebacks](/en/use-cases/disputes); design it with your compliance team using the controls in [Regulated industries: disputes and complaints](/en/security/regulated-industries-disputes-complaints).
## What to measure
* **AI Resolve Rate** per rule in the [Analytics](/en/analytics) **Intent rule breakdown**, and per regulated tag with the **Tags** filter. Use **Resolved by AI**, not deflection rate, as the headline: deflection counts conversations still **Waiting for Customer**.
* **Escalation reasons.** **Escalation Constraint** and **Guardrail or Safety Trigger** are expected for regulated intents; a spike in either on a routine intent means a rule or guardrail is too broad.
* **Guardrail activity** over **7d** and **30d** on the Guardrails page. Hits count initial failed checks, including replies that were rewritten successfully.
* **CSAT and sentiment** on automated intents, compared with the same intents before launch.
## Related
The fintech walkthrough: chained Actions, a Form, and a Reply Rules fraud gate.
Internal Comment and No Reply conditions and their priority order.
Reply checks, channel scope, and guardrail activity.
Rulebook-driven, observability, and QA tag groups.
Certifications, the Trust Center, and how Fini protects customer data.
The same checklist for PHI and HIPAA workflows.
## Related topics
- [Setting up Fini for healthcare](/en/industry-setup/healthcare.md)
- [Fini FAQ](/en/faq.md)
- [Regulated industries: disputes and complaints controls](/en/security/regulated-industries-disputes-complaints.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.