Technical Guide

PII-Safe AI for Financial Services: Automate Without Leaking

How banks, insurers, and fintechs use AI on regulated data safely. Tokenize card and account data before the model, keep an audit trail, and pass a compliance review.

July 22, 202618 min readOronts Engineering Team

The Reason Finance Stalls on AI

Let me be direct: the block on AI in financial services is almost never the model. It is the data. The moment you point an LLM at a customer email, a claims file, or an account statement, you are about to send card numbers, IBANs, and national IDs to a third-party model provider, a vector store, and your logs. Compliance sees that, and the project dies in review, correctly.

So most banks and insurers do one of two unhappy things. They ban AI on anything with customer data, which means AI never touches the work that actually costs money. Or they let it through with a hand-wave, and carry a data-leakage risk they cannot defend to a regulator. There is a third path, and it is an engineering one: make sure the sensitive values never cross into an untrusted system, while the model still does its job.

In finance, the question is not "is AI accurate enough." It is "can you prove the customer's card number never left your trust boundary." Answer that, and the rest of the project is ordinary engineering.

We build this discipline into regulated systems, and our own OGuardAI runtime exists specifically to solve it. This guide is how AI ships in financial services without the compliance rebuild. For the general mechanics, pair it with our PII-safe RAG guide, and this is core AI services work.

Who Cares About What

RoleThe real questionWhat good looks like
CISOWhere does regulated data actually go?Never past the trust boundary, provable
Compliance / DPOCan we defend this to a regulator?Audit trail, legal basis, erasure
Head of operationsWhich manual process gets faster?Claims, onboarding, support cut down
EngineerCan I build on this without a leak?A protection layer as a seam
CFOWhat is the payback versus the risk?Cost cut, risk contained and documented

What Finance Actually Wants to Automate

The high-value targets in a bank or insurer are document-heavy and repetitive, which is exactly where AI helps and exactly where the data is most sensitive.

WorkflowSensitive data involvedThe win
Customer supportNames, account IDs, card dataAnswer from policy, cut handle time
Onboarding and KYCID documents, addresses, tax IDsExtract and check faster
Claims processingHealth data, personal detailsTriage and summarize
Analyst researchClient holdings, positionsRetrieve across internal reports

Every one of these is blocked by the same thing: the model would see data that must not leak. Solve the data problem once and all of them open up. We help firms find the right first target in our consulting practice.

The Data That Cannot Leak

Get specific about what you are protecting, because vague "PII" leads to vague controls. In finance, the non-negotiables are structured and well-defined, which is good news, because structured data is the easiest to detect with certainty.

Data typeWhy it is sensitiveTypical handling
Card numbersPCI scope, fraudNever reaches the model, removed
IBANs and account numbersDirect financial identifierRemoved or tokenized
National and tax IDsIdentity, regulatedRemoved or tokenized
Names and addressesPersonal data under GDPRTokenized, restored by channel

A format-based detector catches card numbers, IBANs, and tax IDs with near-certainty, because they have checksums and fixed shapes. This is the reliable floor of the whole system, and it does not depend on a model guessing. Our data leakage prevention guide covers the detection layer in depth.

The Pattern: Tokenize Before the Model

The core move is to protect data at the boundary, before it reaches the model, and restore it on the way back. The decision of what to do with each data type is declared in policy, so a compliance owner can read and approve it without touching code.

name: financial-pci
version: 1.0.0
defaults:
  restore_mode: masked
rules:
  - entity_type: credit_card
    action: redact          # PCI: never reversible, never reaches the model
  - entity_type: iban
    action: redact          # account identifier, removed
  - entity_type: tax_id
    action: redact
  - entity_type: person
    action: tokenize        # reversible, restored to the customer
    restore_mode: full
  - entity_type: email
    action: tokenize
    restore_mode: masked    # masked in logs, full to the user

Card data is redacted outright, so it never reaches the model at all and stays out of PCI scope for the AI pipeline. Names are tokenized reversibly, so the model can write a coherent reply and the customer still sees their real name, while the internal log sees only a masked form. This channel-aware restoration is what lets you serve a useful answer to the customer while keeping your logs clean. OGuardAI ships policy templates for exactly this, and the six restore modes give you fine control per field. The PII-safe RAG guide covers the tokenization protocol in detail.

RAG Over Financial Documents Without Leaking

Analysts want to ask questions across internal reports, policies, and client files. That is retrieval over documents full of regulated data, which naively means embedding personal data into a vector store, a leak that persists.

The fix is deterministic, corpus-scoped tokenization: within a document corpus, a value tokenizes identically every time, in the stored documents and in the query, so a masked query still matches masked documents and retrieval works over protected data. The vector store never holds a raw account number, yet the analyst gets correct answers. We explain this mechanism fully in our enterprise RAG systems guide and the protection side in the PII-safe RAG guide. Combined with the memory patterns in our agent memory guide, an assistant can hold a conversation about a client without ever storing that client's raw identifiers.

A Worked Example: A Support Reply

Walk one support ticket through the pipeline end to end, because the whole design is easiest to see in a full cycle.

A customer writes in: "My card ending 4821 was charged twice for order 55-2231, I am Max Mustermann, please refund one." Here is what happens.

1. Detect   card number, order id, and person name found in the message
2. Protect  card -> redacted (never reaches the model, out of PCI scope)
            person -> tokenized  {{person:p_001}}
            order id -> tokenized {{custom:order:o_002}}
3. To model "Refund one charge for {{person:p_001}} on order {{custom:order:o_002}}.
             A card ending in a masked value was charged twice."
4. Model    drafts a reply and proposes a refund action, seeing no raw data
5. Restore  to the customer: real name, masked card, order number restored
            to the internal log: tokens only, no identity
6. Gate     the refund is over the auto-approve threshold, so it routes to
            a human, who approves it in one click
7. Audit    the full cycle is recorded with entity types and counts, no raw PII

The card number never reached the model, the vector store, or the log. The model still wrote a coherent, personal reply because the name stayed consistent as a token. The refund, because it moves money, waited for a human. And the audit trail can prove all of it without containing a single raw personal value. That is the complete pattern, and every regulated workflow is a variation on it. Our human-in-the-loop guide covers the approval gate in depth.

Audit and the Regulator

A financial regulator will ask two questions: what did the system do, and can you prove it. Your architecture answers both before they ask.

Every automated action is recorded in a durable, tamper-evident audit trail, with who, what, when, and against which data, and the trail itself contains no raw personal data, only entity types, counts, and fingerprints. A right-to-erasure request is honored by revoking the token mapping, which restores to a deletion marker regardless of any cached state, giving you a provable erasure with a receipt. This is the compliance spine, and it is the difference between "we think it is fine" and "here is the record." Our AI decision traceability guide and GDPR and AI guide go deeper, and our trust and GDPR pages describe how we handle it in delivery.

Human in the Loop for Money Decisions

Automation handles the volume. A person owns anything that moves money or makes a regulated decision. This is not a limitation, it is the design that makes automated finance defensible.

An assistant can draft a response, summarize a claim, or surface the relevant policy, and a human approves before anything binding happens. High-value or irreversible actions route to a review queue with a named approver. This is the human-in-the-loop pattern, and in a regulated setting it is also your EU AI Act human-oversight story. Our AI governance guide covers the accountability model.

Getting Started

  1. Map the regulated data flows. Find every point where customer data would reach a model, a store, or a log.
  2. Start with structured PII. Cards, IBANs, tax IDs are the highest-certainty wins. Protect them first.
  3. Declare the policy. Put the redact-or-tokenize decisions where compliance can read them.
  4. Prove one workflow. Support or claims triage, measured against a baseline, with the audit trail on.
  5. Add the human gate. Keep a person on anything binding, and log the approval.

This is staged, low-risk, and it fits the phased delivery in our methodology. Our custom software and consulting teams build it. Start at contact or get a scoped quote.

Common Ways This Goes Wrong

  1. Banning AI entirely. You leave the expensive manual work untouched. Solve the data problem instead.
  2. Letting data through with a hand-wave. An undefendable leak. Protect at the boundary, provably.
  3. Redacting so hard the model is useless. Tokenize reversibly so the model keeps context.
  4. Embedding raw PII into the vector store. A persistent leak. Use corpus-scoped tokens.
  5. No audit trail. You cannot answer the regulator. Record every action, tamper-evident, PII-free.
  6. Automating a money decision fully. Keep a human on anything binding.

Who Builds This

Oronts is a founder-led software company in Munich. Refaat Al Ktifan, our founder and solution architect, leads a senior team across backend, security, and AI. OGuardAI is our own data-protection runtime, built because regulated AI needs this discipline at the core, not bolted on. We map your regulated data flows, add the protection layer as a seam, prove one workflow, and hand you a pipeline you can defend in a compliance review. See our services, solutions, and trust pages.

Takeaways

  • The block on AI in finance is the data, not the model. Solve the data problem and the workflows open up.
  • Protect structured PII, cards, IBANs, tax IDs, at the boundary with near-certain detection.
  • Redact what must never return, tokenize what should, and restore by channel.
  • Use corpus-scoped tokens so retrieval works over protected documents without leaking.
  • Keep a tamper-evident, PII-free audit trail and a human on every binding decision.

Regulated AI is not about a cleverer model. It is about proving that the sensitive value never left your control. Get that right and finance becomes one of the best places to apply AI, because the repetitive, document-heavy work is exactly what it is good at.

If regulated data is blocking your AI plans, tell us how it flows today. Start at contact or get a scoped quote.

Topics covered

AI financial servicesPII protection financePCI DSS AIbanking AI complianceinsurance automationfinancial data securitytokenizationGDPR financeregulated AIfintech automation

Building something like this?

We design and ship production systems like the one in this guide. Talk to the engineers who wrote it, no sales pitch.

Start a conversation