Fini for KYC, onboarding and account changes

Fini handles the support side of KYC and onboarding: it reads the customer’s verification status and outstanding requirements from your onboarding or verification system through a User Attribute, explains what’s missing and how to provide it using your Knowledge articles, and makes account changes (address, contact details, plan) through Actions that call your APIs. Identity document review, verification decisions and risk decisions stay with your verification provider and your compliance team; Fini reports the status those systems return and never decides it. Most onboarding contacts are some version of “why isn’t my account verified yet?” or “what do you still need from me?”. Those are answerable precisely when the agent can read the real status, which is what this pattern is built on.

What Fini handles and what it hands to your team

Fini handles	Your verification provider or team handles
Verification status questions, from the live status your system returns.	Reviewing identity documents and deciding whether verification passes.
Telling the customer exactly which items are outstanding, and where to submit them in your app or verification flow.	Risk, fraud and sanctions decisions, and any manual review queue.
Explaining requirements, accepted documents and timelines, from Knowledge articles your compliance team approves.	Exceptions to your onboarding policy.
Account changes through Actions, such as an address or contact-detail update with a validated Form.	Account changes your policy reserves for people, or that look like account takeover.
Re-running a status lookup after the customer says they’ve submitted something.	Customers disputing a verification decision.
Escalating when the status is stuck or the customer reports a problem with the verification flow.	Fixing verification flow issues with your provider.

To confirm (internal, remove before publish): usefini.com/industries/finance describes “KYC-grade identity verification and MFA resets” and llms-full.txt lists “KYC checks” and “caller authentication” as Agentic Actions, but docs-local documents no native identity-verification or document-review capability, only the customer-built OTP pattern in the card replacement walkthrough. What exactly does Fini provide here (for example, is caller authentication on voice a native feature)? Until confirmed, this page describes Fini as reading status from, and calling, your own systems.

How it works in Fini

Building block	What it does for KYC and account changes	Where
User Attributes	A `Customer Identity` attribute with a chained Data Collection Step that reads verification state from your onboarding system: for example `kyc_status`, `missing_items` and `last_reviewed_at`, alongside `account_id` and `account_status`. Turn on Visible to AI for `missing_items` and `kyc_status` so the agent can explain them; keep risk flags and internal reason codes off it.	Attributes
Tags	A custom Rulebook-enabled group (the example uses `Topic`) with tags such as `kyc_verification` and `address_change`. Default groups such as Type of Issue have a locked tag list. The Tags page uses `kyc_verification` in its fintech example.	Tags
Actions	Write Actions for each change you allow, for example `Update Address` or `Update Phone Number`, returning a confirmation id and whether re-verification is required. Optionally a read-only `Refresh Verification Status` Action for after the customer submits something.	Actions
Intent Rule	A Fallback-rooted rule with one branch per intent: status, address change, contact change.	Intent Rules
Form	Typed, validated input for account changes. The address change example is the canonical pattern.	Intent Rules
Knowledge	Requirements, accepted documents, processing times and what each status means, written and approved by your compliance team.	Knowledge
Reply Rules	Internal Comment or No Reply for changes on high-risk accounts.	Reply Rules
Guardrails	Confidential attributes for fields whose values must never appear in a reply (for example a document number or date of birth, if your attribute returns them at all), and a URL allowlist so the agent only links to your own and your verification provider’s domains.	Guardrails

Example behavior tree

This tree is an example to adapt. The status values, fields and Actions depend on your onboarding system.

Fallback  (root, picks the first branch whose intent Check passes)
│
├── Steps  (verification status)
│   ├── Check: Topic Equals kyc_verification
│   ├── Check: kyc_status Is Not Null
│   └── Reply: explain kyc_status in plain language; list missing_items;
│              point to where to submit them in your app
│
├── Steps  (address change)
│   ├── Check: Topic Equals address_change
│   ├── Check: account_status Equals active
│   ├── Form:  "Your new address"
│   │     ├── Field: street, city, postal_code, country (String, required)
│   │     └── Form Error: postal_code invalid for country
│   ├── Tool:  Update Address
│   │     in:  account_id, street, city, postal_code, country
│   │     out: confirmation_id, reverification_required
│   └── Reply: confirm the change and confirmation_id; if
│              reverification_required, explain the next step
│
└── Reply: ask whether the customer needs a status update or an account change

How it runs:

Status questions never write anything. The branch reads the status the attribute fetched for this message and explains it. Because attributes fetch on every message, a customer who comes back after uploading a document gets the current status, not a cached one.
If kyc_status is null (the lookup failed or the customer isn’t found), the status branch fails and the root Fallback moves on. The address branch’s intent Check fails too, so the last Reply asks what the customer needs. To handle “we can’t find your application” explicitly, add a branch for it (a Check on kyc_status Is Null and a Reply that explains the next step or hands off).
The address branch gates on an active account, collects the new address in a validated Form, and calls your API. Your API, not Fini, decides whether the change triggers re-verification, and the Reply reports it.
If Update Address fails, the address branch fails and the Fallback moves on to the last Reply; nothing confirms a change that didn’t happen. To hand off instead, wrap the Tool and its Reply in a Fallback whose second child is a Reply telling the customer a teammate will follow up.

Reply Rules evaluate before any Intent Rule. High-risk accounts are held by No Reply (no tree runs) or Internal Comment. Under Internal Comment the tree, including its Tools, still runs and the reply becomes an internal note, so gate the Tool itself with a Check for changes that must not happen automatically (see below).

What you need

What	Why	Where
An authenticated channel	Status and account details are personal data. Use the widget with a signed JWT, or the helpdesk’s authenticated user. On unauthenticated channels, add an identity check before any account change, such as the one-time-code pattern described in the Card replacement walkthrough.	Widget
A status endpoint	Read-only. Returns verification status and outstanding items in customer-explainable terms. If your verification provider holds this, expose it through your own API in front of the provider.	Your onboarding system or verification provider, called through an Attribute
Account-change endpoints	One per change you allow, each returning a confirmation id and any follow-up requirement. Should accept an idempotency key. Endpoints you build should follow the API contract.	Your core account system, called through Actions
Credentials scoped to these operations	Stored in the Data Step Headers JSON or from a connected integration’s Connection Settings. Don’t grant the key access to document images or verification decisions it doesn’t need.	Attributes, Actions
Approved requirement articles	The agent explains requirements only from these.	Knowledge

Keep document submission in your verification flow. Point customers to the upload step in your app or your verification provider’s flow rather than asking them to send identity documents in chat. That keeps document handling inside the system that reviews it and out of support transcripts.

Guardrails and escalation

Contact-detail changes are a common account-takeover path, so treat them as high-risk operations.

Situation	Recommended behavior	How to configure it
Status is stuck past your stated processing time	Escalate with the status attached.	Have your status API compute a boolean such as `review_overdue` (Date operators compare against a fixed date, not a relative window), then add a branch with a Check on `review_overdue Equals True` and a Reply that hands off to your onboarding team.
Change of email or phone on a high-risk account	Hold for a human.	No Reply or Internal Comment in Reply Rules with `is_high_risk Equals True` AND the change tag. The Tools in a rule still run under Internal Comment, so for changes that must not happen automatically, gate the Tool with a Check in the rule.
Account-takeover signals or identity theft	Escalate at the Planning step, before knowledge search.	Escalation Topics in the Planning Prompt; the Prompts page lists account-takeover signals and sensitive data shared in-channel as triggers worth adding.
Customer shares an ID number or document details in chat	Don’t repeat it, point to the secure flow.	Confidential attributes for any attribute values, and a Main Guidelines Guardrails instruction for what to say instead.
Customer disagrees with a verification decision	Hand to your team.	A tag for verification complaints, routed by an Agent group or your helpdesk.
Customer asks for legal or regulatory advice	Decline and escalate if needed.	The “no medical, legal or financial advice” pattern in Main Guidelines Guardrails.

What to measure

Scope Analytics with the Tags filter (your verification and account-change tags) or the Intent rule filter.

Metric	Where	What it tells you
AI resolution rate for the intent	Conversation Status doughnut, share Resolved by AI	How many status and change conversations end without a human.
AI Resolve Rate and Escalated Rate	Intent rule breakdown for the rule; Knowledge performance for the requirement articles	Whether the rule or the articles are where conversations leak.
Human escalation rate	KPI card, filtered	Onboarding workload reaching your team.
Escalation reasons	Escalation reason filter	Missing API Access means the agent needed a system that isn’t connected, API or System Failure that a status or change call failed; Missing Knowledge means a requirement isn’t documented; Escalation Constraint is your own policy.
CSAT	Average CSAT and the CSAT filter	Onboarding friction as customers experience it.

Card replacement

Fintech walkthrough with chained attributes, a validated Form, a risk gate and the identity verification note for unauthenticated channels.

Order status and changes

Step-by-step build of a Fallback-rooted rule with a status branch and a Form-based change branch.

Attributes

Sources, chained Data Collection Steps, and the Use in Rulebooks and Visible to AI switches.

Guardrails

Confidential attributes, URL allowlist and custom reply checks.

Widget

Identify logged-in users with a signed JWT.

Escalation and handoff

Where escalated onboarding conversations land and what your team sees.

Use cases

Walkthroughs

Industry setup

How-tos

Fini for KYC, onboarding and account changes

What Fini handles and what it hands to your team

How it works in Fini

Example behavior tree

What you need

Guardrails and escalation

What to measure

Card replacement

Order status and changes

Attributes

Guardrails

Widget

Escalation and handoff

​What Fini handles and what it hands to your team

​How it works in Fini

​Example behavior tree

​What you need

​Guardrails and escalation

​What to measure

​Related

Card replacement

Order status and changes

Attributes

Guardrails

Widget

Escalation and handoff

What Fini handles and what it hands to your team

How it works in Fini

Example behavior tree

What you need

Guardrails and escalation

What to measure

Related