To confirm (internal, remove before publish): The usefini.com homepage lists “PCI DSS Level 1” and the Fini on Microsoft Azure page lists “PCI DSS Compliant”, but the Trust Center (security.usefini.com) lists only GDPR, ISO/IEC 27001 and SOC 2. Before publishing, confirm: (1) Does Fini hold a current PCI DSS Attestation of Compliance (AoC)? (2) Is it a service provider AoC, at which level, under which PCI DSS version, and from which QSA? (3) What is in scope: does any Fini system store, process or transmit cardholder data, or is the attestation for a narrower scope? (4) Date of the last assessment, and can customers request the AoC through the Trust Center? If there is no current AoC, the homepage and Azure page claims must be corrected and this page should say Fini is designed to stay out of PCI scope.
Fini (usefini.com) states PCI DSS Level 1 on its homepage, but the Trust Center at security.usefini.com, the source of record for attestations, lists GDPR, ISO/IEC 27001 and SOC 2 and does not list PCI DSS. Ask Fini for current PCI DSS documentation through the Trust Center. Whatever the attestation covers, the recommended design is the same: card numbers and security codes should never enter a Fini conversation, and every card operation should run in your own PCI-compliant systems through Actions. This page explains why that design is safer, and how to configure it.

​
Why card data should stay out of support conversations

A support conversation is copied to several places: your helpdesk, Fini’s Inbox mirror, the AI Steps trace, analytics, and any email thread. If a customer types a full card number into chat, every one of those copies is now cardholder data, and each system that holds it can fall into your PCI scope. Keeping card data out of conversations removes that problem at the source, regardless of any vendor’s attestation:

​
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 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 that calls your 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. 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.
  • 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 a backstop to the design above, not as your PCI control. See Guardrails.
To confirm (internal, remove before publish): If a customer types a full card number into a conversation, does Fini automatically detect and mask it in stored transcripts, Inbox and AI Steps? The platform page says Guardrails mask PII such as phone numbers and emails, and the data protection policy mentions PII masking, but the product docs describe Guardrails as reply checks only. State the actual behavior for inbound card numbers here.

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

​
6. Test it

Build a Test Suite set with the Safety & boundaries judge and scenarios where a customer pastes a card number, asks the agent to “just take my card details”, or offers a CVV. The expected outcome is that the agent declines, points to the secure flow, and escalates where your policy requires.

​
What this means for your PCI scope

Your QSA decides your scope. The configuration above is designed so that Fini, your helpdesk and your conversation logs do not receive cardholder data during normal support, and card operations happen only in systems you already assess. Document that design, and the Test Suite results, in your scoping evidence.

End-to-end: card replacement

A deterministic lost-or-stolen card flow with no card numbers in chat.

Guardrails

Confidential attributes, banned terms and custom rules.

Fintech setup

Recommended configuration for banking and fintech support.

Security overview

Fini’s certifications and how to request reports.