Skip to main content

Anti-Money Laundering AI: Explainable Decisions with Full Audit Trails

The safest way to use AI in AML operations is to make the gateway explainable even when the model is not. Keeptrusts can give you explicit policy outcomes for restricted-entity checks, customer-data redaction, provider-routing decisions, and exportable event history, which is exactly what operations teams need when an alert narrative or analyst copilot becomes part of a regulated workflow. That does not turn the gateway into a transaction-monitoring engine or a managed sanctions feed, but it does create a clear, reviewable control boundary for AML assistants.

Use this page when​

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Technical Engineers, AI Agents

The problem​

AML teams are usually not asking the model to make the final legal decision. They are using AI to accelerate the work around the decision: summarize an alert bundle, draft a case note, compare name variants, or help an investigator organize next steps. The danger is that these seemingly low-risk tasks still move sensitive customer data across provider boundaries, still shape downstream analyst judgment, and still need to be defensible months later.

There is also a common misconception that "explainable AML AI" means the model can explain itself. In operator practice, what teams really need first is explainable control flow. Why did the gateway allow one case through and block another? Which entity list matched? Was the prompt redacted before leaving the bank? Which provider targets were eligible? Those are questions Keeptrusts can answer through policy outcomes and event exports.

The limit is equally important. Keeptrusts does not ship a managed sanctions data feed, and Entity List Filter only enforces the blocked_entities list you configure. That means your compliance or risk team still owns list quality and update cadence. The gateway gives you deterministic screening behavior, not outsourced list governance.

AML programs also have to care about jurisdiction and retention. Suspicious activity investigations often carry names, account references, and narrative details that should not be routed through just any provider target. That makes Data Routing Policy and deployment topology part of the AML control surface, not just an infrastructure detail.

The solution​

The operator-safe pattern is to separate three jobs.

Use entity-list-filter for deterministic entity screening against your own restricted lists. This is the right control when you have named entities that should always block, escalate, or be removed from general-purpose analysis workflows. Because the current runtime can use case-insensitive and optional fuzzy matching, it is useful for spelling variation and transliteration problems as long as the list itself is curated.

Use pii-detector to protect customer and case data before the upstream call. In AML workflows, the key value is not theoretical privacy posture; it is practical minimization. Case IDs, account IDs, and investigator references should not flow raw when the model only needs the abstract narrative.

Use the platform event stream and exports as your explainability layer. When people say they need a full audit trail, what they often mean is a reconstructable sequence of policy decisions, not a mystical view into model internals. Keeptrusts can provide that gateway-level record, especially when you validate the export path before the assistant becomes part of production investigations.

Implementation​

This example shows a narrow AML assistant route for case summarization and sanctions-style screening. It uses only currently documented fields.

pack:
  name: aml-review-assistant
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: compliant-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0

  routing:
    strategy: ordered

policies:
  chain:
    - entity-list-filter
    - pii-detector
    - data-routing-policy
    - audit-logger

policy:
  entity-list-filter:
    blocked_entities:
      - Russian Direct Investment Fund
      - ACME Exchange House Ltd
    action: block
    fuzzy_matching: true
    max_distance: 1

  pii-detector:
    action: redact
    detect_patterns:
      - 'CASE-[0-9]{8}'
      - 'ACCT-[0-9]{8,12}'
    redaction:
      marker_format: label
      include_metadata: true

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    on_no_compliant_provider: block

  audit-logger: {}

Two practical notes matter here.

First, the blocked_entities list is yours. If your AML team wants sanctioned entities, internal watch-list names, or correspondent-bank restrictions enforced, the list has to be curated and reviewed as part of your own compliance process.

Second, if you need a workflow where high-risk output should stop and go to review, create a separate route that uses Human Oversight. The current policy is a simple escalation switch, so it is best used on dedicated review lanes rather than bolted onto every AML assistant indiscriminately.

For validation, a short operator loop is enough:

kt policy lint --file ./aml-review-assistant.yaml
kt gateway run --policy-config ./aml-review-assistant.yaml --port 41002
kt events tail --policy entity-list-filter
kt export create --format json --filter "policy=entity-list-filter,audit-logger"

That gives you a way to prove the three things an AML program usually needs first: the list blocks when it should, sensitive identifiers are redacted before model execution, and the export is usable for retrospective review.

Results and impact​

The practical outcome is not that AI becomes self-explaining. The outcome is that the gateway becomes auditable.

  • Restricted-entity checks are explicit and repeatable because entity-list-filter returns deterministic block behavior for configured names.
  • Customer and case identifiers are less likely to leave the bank in raw form because pii-detector minimizes them before the upstream call.
  • Provider routing is easier to defend because the allowed target set is constrained by declared data_policy metadata.
  • Investigations and internal audit reviews move faster because events and exports show policy-level reasons instead of leaving teams to infer what happened from model output alone.

For AML operators, that is a meaningful distinction. A clean audit trail at the gateway boundary often matters more than a polished assistant response when a case has to stand up to second-line review or retrospective examination.

Key takeaways​

  • In AML workflows, prioritize explainable control flow over claims of model explainability.
  • Use Entity List Filter for your curated restricted names, not as a substitute for list governance.
  • Use pii-detector and Data Routing Policy together when case content should be minimized and provider targets should be constrained.
  • Treat audit evidence as a tested operating path, not a theoretical feature.
  • Pair AML assistants with Spend & Wallets when multiple case-review tools share the same organization and budget boundary.

Next steps​