Banks want to connect LLMs to first-line support and application pre-processing, but Article 26 of the Banking Law and Federal Law GDPR prohibit sharing banking secrecy and personal data with third-party models. A cloud LLM is an untrusted third-party processor: everything sent to it must be cleaned on input and carefully restored on output (Ploomber, Presidio analysis).
LLM & Security Gateway solves this at the proxy level: it sits between the bank's application and the model, finds full names, account numbers, and card numbers in the text, replaces them with stable placeholders before sending, and inserts the real values back into the response. Below is an open breakdown of what can be built with this class of tools. This is not a KT.Team case study, but an overview of public components with links.
What business result does the bank get
The first-line operator or scoring pipeline receives the model's response for a real request, while the customer's card number and full name physically remain inside the bank's perimeter. The result is measurable: standard request handling time goes down, the share of manual application classification decreases, and the security team gets an auditable point where every message sent to the model is visible. Banking secrecy stays inside - the cloud only receives text like "customer `<PERSON>` on card `<CREDIT_CARD>` is disputing a transaction."
How obfuscation works with open tools
The reference stack is the combination of LiteLLM Gateway and Microsoft Presidio. Presidio is distributed under the MIT license and out of the box recognizes more than 50 entity types: names, credit card numbers, phone numbers, bank accounts, financial data - through a combination of NLP, regular expressions, and checksum validation (microsoft/presidio).
In LiteLLM, Presidio is connected through two containers - Analyzer (detects PII) and Anonymizer (masks it) - and the gateway runs the check in `pre_call` mode, before the request reaches the model. Which entities to mask and which to block is defined in YAML (docs.litellm.ai):
```yaml
pii_entities_config:
CREDIT_CARD: "MASK"
PERSON: "MASK"
US_BANK_NUMBER: "BLOCK"
```
`MASK` replaces a value with a placeholder like `<CREDIT_CARD>`, while `BLOCK` rejects the request entirely if it contains a forbidden entity. The confidence threshold (`presidio_score_thresholds`) suppresses false positives.
Restoring values in the response
The key to a seamless experience for the operator is reversibility. In LiteLLM, the `output_parse_pii: true` flag enables restoration: the user enters sensitive data, the model sees the masked version ("customer `<PERSON>`"), responds with a placeholder, and the gateway inserts the real value before returning it to the operator (docs.litellm.ai).
More advanced implementations use a local mapping vault. The cycle is Anonymize, Deanonymize, and Vault, which stores the link between placeholder and real value: the gateway creates a session ID, replaces PII with reversible tokens in the form `{{ENTITY_TYPE_randomhex}}`, stores the mapping locally, and restores the originals from it in the response (Microsoft PII Shield). The key point is that the mapping and detection run locally, so real data never leaves the bank's infrastructure (LaxmiKumar Reddy, Presidio analysis).
Scenario: request handling and scoring
In a bank chatbot scenario, the application sends raw text to the proxy, the proxy runs detection, replaces each piece of PII with a placeholder, and returns cleaned text - the model never sees the real account number or phone number (Microsoft PII Shield). The same logic applies to application scoring: the model classifies the request, assesses sentiment and risk from anonymized text, and the decision is returned to the operator with the customer identifiers restored.
Why this is a "minimal core modification"
The approach requires neither a model fork nor patches to the CRM or core banking system. The gateway is a separate microservice next to the business logic, OpenAI-compatible: integration comes down to changing one URL (philterd.ai). This follows the principle of not modifying the tool's core: the bank changes the entry point to the LLM instead of rewriting its systems. The components are mature and international (Presidio is MIT-licensed, LiteLLM is open source), which provides portability: the recognizer configuration and YAML policy can be handed over to another team without rewriting.
An important note from Presidio's own documentation: there is no guarantee the system will find all sensitive information, so detection is supplemented with allow/deny lists, `BLOCK`-based blocking for critical entities (accounts, SNILS), and logging for audit (microsoft/presidio). For the bank, this means a fail-closed policy: if in doubt, the request is blocked instead of being sent to the cloud.
Business process takeaway
The process intervention point is the gateway between the front office and the LLM. The customer's request passes through the gateway: full names, accounts, and cards are anonymized according to policy (MASK for names/cards, BLOCK for accounts/SNILS), the model works with anonymous text, and the response is deanonymized from the local vault and delivered to the operator. The bank gets LLM speed and auto-classification without taking banking secrecy beyond the perimeter, plus an auditable log of every request for security and regulators.
