Finance & PCI-DSS

Protect financial PII -- credit card numbers, IBANs, SSNs, and account identifiers -- when using AI for fraud detection, customer support, and financial reporting.

The Problem

Financial institutions process vast quantities of sensitive data: credit card numbers, bank account identifiers, Social Security numbers, tax IDs, and transaction details. AI can transform fraud detection, customer service, and regulatory reporting -- but every AI interaction creates a data exposure risk.

PCI-DSS requires that cardholder data is protected wherever it is stored, processed, or transmitted. Sending raw credit card numbers or account identifiers to a third-party LLM provider violates PCI-DSS Requirement 3 (protect stored cardholder data) and Requirement 4 (encrypt transmission of cardholder data). Financial regulators in the EU, US, and Asia impose additional constraints on where customer financial data may be processed.

Naive approaches fail. Stripping all numbers from transaction data makes fraud detection impossible -- the AI cannot analyze patterns without transaction metadata. Replacing account numbers with generic placeholders like [ACCOUNT] loses the ability to distinguish between sender and recipient accounts in multi-party transactions.

How OGuardAI Solves It

OGuardAI intercepts financial data before it reaches the AI model. Sensitive identifiers are replaced with semantic tokens that preserve analytical context -- country codes, institution identifiers, transaction roles -- while removing the actual account numbers and cardholder data. The AI model receives enough structure to perform fraud analysis, generate compliance reports, and draft customer communications without ever seeing raw financial PII.

Banking / Fintech Application
    |
    v
OGuardAI Runtime (financial PII exists only here, transiently)
    |
    +---> Tokenized data (no raw PII) ---> LLM Provider
    +---> Encrypted session blob --------> Your Application
    |
    v
Restored output (channel-specific)
    +---> Compliance team: full restore
    +---> Customer notification: masked accounts
    +---> Audit trail: abstract identifiers

Detected Entity Types

Entity types marked with * are custom types defined via policy rules, not built-in. See the Extending Entities guide for how to add custom types.

Example Policy

name: finance-pci
version: "1.0"
description: "PCI-DSS compliant financial PII protection for AI workflows"

rules:
  - entity_type: "credit_card"
    protection_level: 1
    action: "block"
    conditions: []

  - entity_type: "ssn"
    protection_level: 1
    action: "block"
    conditions: []

  - entity_type: "iban"
    protection_level: 1
    action: "block"
    conditions: []

  - entity_type: "bic"
    protection_level: 2
    action: "tokenize"
    conditions: []

  - entity_type: "person"
    protection_level: 2
    action: "tokenize"
    conditions: []

  - entity_type: "customer_id"
    protection_level: 2
    action: "tokenize"
    conditions: []

  - entity_type: "tax_id"
    protection_level: 2
    action: "tokenize"
    conditions: []

  - entity_type: "account_number"
    protection_level: 2
    action: "tokenize"
    conditions: []

defaults:
  protection_level: 2
  action: "tokenize"
  restore_mode: "masked"

channel_rules:
  compliance_internal:
    person:         { restore_mode: full }
    bic:            { restore_mode: full }
    customer_id:    { restore_mode: full }
    tax_id:         { restore_mode: full }
    account_number: { restore_mode: full }
  customer_notification:
    person:         { restore_mode: full }
    bic:            { restore_mode: none }
    customer_id:    { restore_mode: masked }
    tax_id:         { restore_mode: none }
    account_number: { restore_mode: masked }
  audit_trail:
    person:         { restore_mode: abstract }
    bic:            { restore_mode: masked }
    customer_id:    { restore_mode: none }
    tax_id:         { restore_mode: none }
    account_number: { restore_mode: none }

Note that credit_card, ssn, and iban use action: block. Blocked entities are rejected before tokenization -- they never reach the AI model, not even as tokens. This satisfies PCI-DSS Requirement 3 by ensuring cardholder data is never transmitted to the model provider.

Example API Call

Transform a fraud alert

curl -X POST http://localhost:3000/v1/transform \
  -H "Content-Type: application/json" \
  -H "X-API-Key: your-key-here" \
  -d '{
    "input": "Fraud alert: Customer James Whitfield (ID: CUST-88421) reported unauthorized transactions on card 4532-8891-0042-7756. Three charges totaling EUR 12,450 from merchant accounts in Romania and Cyprus. Customer IBAN: GB82 WEST 1234 5698 7654 32. Contact: james.whitfield@bankmail.com.",
    "policy": "finance-pci"
  }'

Response (tokenized)

{
  "safe_text": "Fraud alert: Customer {{person:p_001}} (ID: {{customer_id:c_001}}) reported unauthorized transactions on card [BLOCKED]. Three charges totaling EUR 12,450 from merchant accounts in Romania and Cyprus. Customer IBAN: [BLOCKED]. Contact: {{email:e_001}}.",
  "session_id": "01916b4f-3a1c-7000-8000-000000000002",
  "session_state": "eyJ2IjoxLCJzaWQiOi...",
  "entity_context": [
    { "token": "{{person:p_001}}", "type": "person", "role": "account_holder", "country": "GB" }
  ],
  "stats": {
    "entities_detected": 5,
    "entities_transformed": 3,
    "entities_blocked": 2
  }
}

The credit card number and IBAN are blocked entirely -- they appear as [BLOCKED] in the safe text. The AI model can still analyze the fraud pattern: it knows the account holder is in the UK, the charges came from Romania and Cyprus, and the total amount. That is enough context for fraud classification and recommended actions.

Rehydrate for the compliance team

curl -X POST http://localhost:3000/v1/rehydrate \
  -H "Content-Type: application/json" \
  -H "X-API-Key: your-key-here" \
  -d '{
    "output": "<LLM-generated fraud analysis with tokens>",
    "session_state": "eyJ2IjoxLCJzaWQiOi...",
    "output_channel": "compliance_internal"
  }'

The compliance team sees the full report with all identifiers restored (except the blocked credit card, which remains [BLOCKED] even for internal users -- by policy, blocked entities are never recoverable).

PCI-DSS Compliance Notes

Additional Regulatory Considerations

• EBA Guidelines on ICT risk (EU): OGuardAI's trust boundary model ensures financial data does not leave the institution's infrastructure boundary when using third-party AI.
• FFIEC Guidance (US): The sealed session model with automatic expiry supports the FFIEC's requirements for data retention limits and access controls.
• MAS TRM (Singapore): Tokenization with metadata preservation satisfies MAS requirements for data protection in outsourced AI processing.

OGuardAI is one component of a broader PCI-DSS compliance program. It addresses the specific risk of cardholder data exposure during AI interactions. Consult your QSA and compliance team for your complete compliance posture.

Related Resources

• Financial Compliance Case Study -- Step-by-step walkthrough of a wire transfer screening workflow
• Compliance Controls Mapping -- PCI-DSS, HIPAA, GDPR, SOC 2 control mapping
• Security Whitepaper -- Trust boundary model, encryption, session isolation
• Policy Authoring Guide -- How to write and customize policies