;
};
Fini (usefini.com) is PCI DSS Level 1 certified, the highest level of the Payment Card Industry Data Security Standard. Fini automatically masks card numbers and other sensitive data everywhere it stores conversation data, so raw cardholder data doesn't sit in transcripts, Inbox or AI Steps traces.
Certification covers how Fini runs its platform. How your agent handles card topics depends on your configuration: route card actions (freezes, replacements, refunds) through your payment provider with [Actions](/en/api-reference/actions), and never ask customers for full card numbers or CVVs in a conversation. This page explains both sides and how to set them up.
## Fini's PCI DSS posture
| Topic | Fini position |
| - | - |
| Certification | PCI DSS Level 1 certified |
| Card data in stored conversations | Masked automatically in transcripts, Inbox and AI Steps traces. Fields you hide from the AI are also redacted in AI Steps. |
| Card actions | Run in your payment provider's systems through Actions, called from Rulebook **Tool** nodes |
| Attestation of Compliance (AOC) | Available to customers on request through your Fini account team |
| Other certifications | SOC 2 Type II, ISO/IEC 27001:2022, HIPAA-compliant and BAA-eligible, GDPR, CCPA. See [Security overview](/en/security/overview). |
## How card data moves in a Fini conversation
Customers sometimes type a card number into chat even when nobody asked. Fini masks it before the conversation is stored, and any card operation runs against your payment provider, which holds the card data. The conversation only carries references such as a card token or the last four digits.
```mermaid theme={null}
---
title: Card data in a Fini conversation
---
flowchart LR
PAN["Customer types a card number into chat"] --> MASK["Fini masks it automatically"]
MASK --> STORE["Stored conversation data transcripts · Inbox · AI Steps"]
TOOL["Rulebook Tool node card token, not the number"] --> PSP["Your payment provider freeze · replace · refund"]
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 PAN source
class MASK,TOOL agent
class STORE surface
class PSP human
```
Masking is a backstop, not a reason to collect card data. Your helpdesk and email threads are outside Fini, so design your flows so customers never need to type card details at all:
| Data | Recommendation |
| - | - |
| Full primary account number (PAN) | Never request it in chat, email or voice. Identify the card another way (see below). |
| Card verification code (CVV, CVC) | Never request it. PCI DSS prohibits storing it after authorization. |
| PIN, full magnetic stripe or chip data | Never request it. |
| Last four digits, card nickname, card type | Acceptable identifiers for most support flows, subject to your own policy. |
| Card tokens or internal card IDs | Preferred. Load them from your systems through User Attributes or Actions; the customer never types them. |
## How to configure Fini
### 1. Identify cards without asking for them
Let the authenticated session identify the customer, and load their cards from your systems. A User Attribute or a lookup Action returns the customer's cards with tokens and last-four digits; the Rulebook asks the customer to pick one by last four or nickname. The [card replacement walkthrough](/en/walkthroughs/card-replacement) builds exactly this pattern: list the customer's cards, confirm which one, freeze it, order a replacement, without the customer typing a card number.
### 2. Run card operations through Actions in your systems
Freezing a card, ordering a replacement, disputing a charge or updating a payment method should be an [Action](/en/api-reference/actions) that calls your payment provider's card-management or payments API with a token, not something the agent does by handling card details. Actions run only when a Rulebook **Tool** node invokes them, so the call happens in a deterministic flow you built and tested. If your firewall restricts inbound traffic, allowlist Fini's [static IP addresses](/en/api-reference/static-ip).
When a customer genuinely needs to enter a new card, send them to your own hosted payment page or in-app flow with a Reply node, rather than collecting the number in the conversation.
### 3. Tell the agent never to ask, and escalate when a customer volunteers
* In the Planning Prompt, add an **Escalation Topics** trigger for sensitive data shared in-channel, as the prompt guidance suggests for "last 4 of card, SSN" and similar. See [Prompts](/en/configuration/prompts#controlling-when-the-agent-escalates).
* In your Main Guidelines, state that the agent never requests a full card number, security code or PIN, and directs customers to the secure flow instead.
### 4. Add guardrails on replies
* **Confidential attributes**: select any attribute keys that carry card details (for example a full card number your attributes endpoint should not return in the first place). If a reply contains one of those values, Fini attempts a rewrite and, if that fails, escalates instead of sending it.
* **Banned terms**: add a regular expression that matches 13 to 19 digit sequences, including ones separated by spaces or hyphens, so a reply does not echo a card number back.
* **Custom rule**: fail any reply that asks the customer for a card number, CVV or PIN.
Guardrails check the agent's replies, not the customer's messages, and they are not a fail-closed boundary: a check error can let the original reply through. Use them as an extra layer on top of Fini's automatic masking and the design above. See [Guardrails](/en/configuration/guardrails).
### 5. Use Reply Rules for card-sensitive topics
If your helpdesk policy is that card disputes or payment-method changes always go to a person, add a condition on the **Internal Comment** or **No Reply** card, for example *Type of Issue In disputes, chargebacks*. See [Reply Rules](/en/automations/reply-behavior).
### 6. Test it
Create [Test Suite](/en/testing/test-suite) test cases from conversations where a customer pastes a card number, asks the agent to "just take my card details", or offers a CVV. Create those conversations in Inbox with test card numbers, never real ones. Add an AI judgement that the agent declines, points to the secure flow, and escalates where your policy requires, and mark it **Required to pass**.
## What this means for your PCI scope
Your QSA decides your scope. Fini's PCI DSS Level 1 certification and automatic masking cover the Fini side. The configuration above keeps cardholder data out of normal support conversations, so card operations happen only in your payment provider's systems. Document that design, Fini's attestation (AOC) and your Test Suite results in your scoping evidence.
To request Fini's AOC, contact your Fini account team.
## Related
A deterministic lost-or-stolen card flow with no card numbers in chat.
Confidential attributes, banned terms and custom rules.
Recommended configuration for banking and fintech support.
Fini's certifications and how to request reports.
How automatic masking works across stored conversation data.
## Related topics
- [Fini FAQ](/en/faq.md)
- [Data handling, residency and model training](/en/security/data-handling.md)
- [SOC 2 Type II and ISO 27001](/en/security/soc2-iso27001.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.