Setting up Fini for fintech and banking

To set up Fini 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 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 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.

​

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:

​

Recommended setup checklist

​

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.
• 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.
• 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 before agents use 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. 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, 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.

​

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.

​

5. Configure guardrails

On Guardrails, per agent: 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.

​

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. 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.

​

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.

​

8. Wire the handoff

For widget conversations, create a Business Rule 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.

​

9. Run the Test Suite before every publish

Build a test set from real transcripts covering each regulated intent and each automated workflow. Bind the Escalation behavior, Safety & boundaries, and Tool use correctness judges, and run the set on every prompt, knowledge, rule, or Action change. Test Suite runs don’t dry-run your Actions, and Execute live actions calls your real APIs, so use Simulate rule execution or point Actions at sandbox endpoints. See Test Suite.

​

10. Review in Inbox every week

Filter 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.

​

11. Put dashboard access behind SSO

Set up Okta SSO so your team signs in with Okta credentials and access follows your Okta assignments.

​

Intents to automate first, and intents to escalate

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; design it with your compliance team using the controls in Regulated industries: disputes and complaints.

​

What to measure

• AI Resolve Rate per rule in the 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