How a bank uses AI for sanctions screening and AML checks without exposing customer financial identifiers to the language model

How a bank uses AI for sanctions screening and AML checks without exposing customer financial identifiers to the language model.

The Situation

A mid-size European bank processes 1,500 wire transfer requests per day. Each request contains the sender's name, IBAN, recipient IBAN, BIC/SWIFT code, and sometimes a national ID or tax number in the payment reference. The compliance team wants to use AI to pre-screen transfers against sanctions lists and flag suspicious patterns, reducing manual review from 45 minutes to under 5 minutes per case.

The regulator's position is clear: customer financial identifiers (IBANs, account numbers, national IDs) must not leave the bank's infrastructure to reach a third-party AI provider. The bank's information security team adds a further constraint -- even internal AI models running in the bank's cloud must not receive raw IBANs in logs or training data.

The Solution

OGuardAI sits between the bank's transfer processing system and the compliance AI model. Financial identifiers are tokenized before reaching the model. The model receives enough context to make compliance decisions (country codes, transfer amounts, payment purpose) without seeing raw account numbers.

Step-by-Step: A Wire Transfer Review

A customer submits a wire transfer to a recipient in a high-risk jurisdiction.

Step 1: Transfer Request Arrives

Sender: Hans Mueller
Sender IBAN: DE89 3704 0044 0532 0130 00
Recipient: Dmitri Volkov
Recipient IBAN: RU02 0445 2080 0000 0640 2357
BIC: SABRRUMM
Amount: EUR 48,500.00
Reference: Invoice INV-2026-0891, Tax ID 7712345678
Purpose: Consulting services Q1 2026

Step 2: OGuardAI Transforms the Request

curl -X POST http://localhost:3000/v1/transform \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Sender: Hans Mueller\nSender IBAN: DE89 3704 0044 0532 0130 00\nRecipient: Dmitri Volkov\nRecipient IBAN: RU02 0445 2080 0000 0640 2357\nBIC: SABRRUMM\nAmount: EUR 48,500.00\nReference: Invoice INV-2026-0891, Tax ID 7712345678\nPurpose: Consulting services Q1 2026",
    "policy": "financial-compliance"
  }'

Detected entities:

Original Value	Entity Type	Token	Metadata
Hans Mueller	person	`{{person:p_001}}`	role: sender, country: DE
DE89 3704 0044 0532 0130 00	iban	`{{iban:ib_001}}`	country: DE, bank: Commerzbank
Dmitri Volkov	person	`{{person:p_002}}`	role: recipient, country: RU
RU02 0445 2080 0000 0640 2357	iban	`{{iban:ib_002}}`	country: RU
SABRRUMM	bic*	`{{bic:bc_001}}`	country: RU
7712345678	tax_id*	`{{tax_id:t_001}}`	country: RU

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

The safe text sent to the AI:

Sender: `{{person:p_001}}`
Sender IBAN: `{{iban:ib_001}}`
Recipient: `{{person:p_002}}`
Recipient IBAN: `{{iban:ib_002}}`
BIC: `{{bic:bc_001}}`
Amount: EUR 48,500.00
Reference: Invoice INV-2026-0891, Tax ID `{{tax_id:t_001}}`
Purpose: Consulting services Q1 2026

The amount, invoice number, and purpose pass through -- they are needed for compliance analysis. The entity metadata tells the model that the recipient is in Russia (high-risk jurisdiction) and the sender is in Germany.

Step 3: AI Performs Compliance Analysis

The model receives the tokenized transfer with entity context and generates:

COMPLIANCE SCREENING REPORT

Transfer: `{{person:p_001}}` (DE) -> `{{person:p_002}}` (RU)
Amount: EUR 48,500.00

Risk Flags:
1. HIGH - Recipient jurisdiction (RU) is on enhanced due diligence list
2. MEDIUM - Amount exceeds EUR 15,000 threshold for enhanced monitoring
3. LOW - Payment reference contains tax identifier from high-risk jurisdiction

Sanctions Check:
- `{{person:p_001}}`: No match found in OFAC/EU sanctions lists
- `{{person:p_002}}`: No exact match. Partial name similarity to sanctioned
  entity "D. Volkov" (SDN List ref. 29847) -- requires manual verification.

Recommendation: HOLD for manual review. Escalate to Level 2 compliance
officer for recipient identity verification before processing.

Required Actions:
- Verify recipient identity against passport/ID documentation
- Confirm business relationship (consulting agreement on file?)
- Document enhanced due diligence findings

The AI made a meaningful compliance decision using country metadata and risk patterns, without ever seeing the actual IBANs or tax ID.

Step 4: Restore for Different Channels

Internal compliance system -- full restore:

curl -X POST http://localhost:3000/v1/rehydrate \
  -H "Content-Type: application/json" \
  -d '{
    "output": "<compliance report with tokens>",
    "session_state": "<encrypted-blob>",
    "output_channel": "compliance_internal"
  }'

The compliance officer sees the full report with all IBANs and names restored for the manual review step.

Audit log -- masked restore:

curl -X POST http://localhost:3000/v1/rehydrate \
  -H "Content-Type: application/json" \
  -d '{
    "output": "<compliance report with tokens>",
    "session_state": "<encrypted-blob>",
    "output_channel": "audit_log"
  }'

The audit log records the screening decision, risk flags, and recommendation, with IBANs masked to last-four and names replaced with anonymized identifiers.

Policy Configuration

name: financial-compliance
version: "1.0"
rules:
  - entity_type: "person"
    action: "tokenize"
    metadata: [country, role]
    restore_mode: "full"
  - entity_type: "iban"
    action: "tokenize"
    metadata: [country, bank]
    restore_mode: "masked"
  - entity_type: "bic"
    action: "tokenize"
    restore_mode: "masked"
  - entity_type: "tax_id"
    action: "tokenize"
    metadata: [country]
    restore_mode: "none"
  - entity_type: "ssn"
    action: "block"
  - entity_type: "passport"
    action: "block"

channel_rules:
  compliance_internal:
    person: { restore_mode: full }
    iban:   { restore_mode: full }
    bic:    { restore_mode: full }
    tax_id: { restore_mode: full }
  audit_log:
    person: { restore_mode: abstract }
    iban:   { restore_mode: masked }
    bic:    { restore_mode: masked }
    tax_id: { restore_mode: none }
  customer_notification:
    person: { restore_mode: full }
    iban:   { restore_mode: masked }
    bic:    { restore_mode: none }
    tax_id: { restore_mode: none }

What OGuardAI Made Possible

Regulatory compliance without crippling AI. IBANs and tax identifiers never leave the bank's trust boundary. The AI receives country-level metadata -- enough to flag jurisdiction risk and check sanctions patterns.

Separation of screening and identity. The AI evaluates risk patterns (high-risk country, amount thresholds, name similarity) without accessing the actual financial identifiers. This satisfies both the regulator and the bank's infosec policy.

Channel-specific access control. Compliance officers see everything for manual review. Audit logs keep masked versions for regulatory record-keeping. Customer notifications reveal only what the customer should see.

Blocked entity types. SSN and passport numbers in payment references are blocked entirely -- they never reach the model, not even as tokens. The policy enforces this at the engine level.

Financial Compliance