Skip to main content

Open Banking AI: Governing Third-Party Data Access

Open banking creates one of the most complex AI boundaries in financial services because the data relationship is already multi-party before the assistant is added. A support analyst may be working from bank data, third-party provider responses, customer-consent artifacts, and application-specific identifiers in the same workflow. An AI assistant can make that work faster, but it can also become an uncontrolled bridge between customer data, partner credentials, and providers that were never meant to see the raw material.

Keeptrusts is useful here because it lets the organization enforce that boundary at the gateway. The realistic baseline is to require attributable partner or workflow identity with rbac, minimize account and customer identifiers with pii-detector, block secrets and consent-token formats with dlp-filter, constrain provider eligibility with data-routing-policy, and keep review evidence through audit-logger. Open banking teams still own consent handling, third-party risk, and partner agreements. The gateway gives them a place to express those controls in runtime behavior.

Use this page when​

Primary audience​

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

The problem​

Open-banking AI creates two different failure modes at once. The first is classic data minimization failure: the assistant sees more customer-account data than it needs. The second is credential and consent failure: a prompt or note includes partner tokens, consent references, or identifiers that should never leave the controlled workflow. If the route is governed only by prompt instructions, both failures eventually happen.

The data side is straightforward. Customer names, account references, transaction context, and case IDs should be minimized before the model call whenever the assistant is being used for support or reconciliation. PII Detector is the right baseline control because it reduces exposure without destroying the workflow.

The secret-handling side is more specific. Open-banking teams often work with consent identifiers, callback secrets, and partner-specific token formats that the general model boundary will not understand automatically. That is why DLP Filter matters. It gives the program a way to block or detect the formats and terms that are unique to the partner ecosystem.

Provider selection matters too. Open-banking routes are not only about customer privacy; they are also about third-party contractual boundaries. Data Routing Policy is how the organization ensures that only approved provider targets remain eligible for these workflows.

The solution​

The safest open-banking pattern is to separate partner identity, secret filtering, and provider routing into explicit controls.

Use rbac so every request carries the user or service identity and the partner or workflow context. That helps the organization distinguish between internal support, third-party operations, and customer-resolution lanes.

Use pii-detector to minimize customer and account identifiers before the assistant call. In open banking, that keeps support and reconciliation assistants useful while reducing the amount of direct financial data that leaves the route.

Use dlp-filter for secret formats and consent-token patterns. This is the most open-banking-specific part of the stack because those tokens are often unique to the partner ecosystem and invisible to generic redaction logic.

Then apply data-routing-policy and audit-logger. The first keeps the provider boundary explicit. The second keeps the route reviewable when a partner, auditor, or internal control owner asks what happened.

Implementation​

This example assumes an internal support and reconciliation lane where partner tokens and consent references should block, not redact.

pack:
  name: open-banking-ops-lane
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: open-banking-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

policies:
  chain:
    - rbac
    - pii-detector
    - dlp-filter
    - data-routing-policy
    - audit-logger

policy:
  rbac:
    deny_if_missing:
      - X-User-ID
      - X-Partner-ID
      - X-Workflow-ID
    require_auth: true

  pii-detector:
    action: redact
    detect_patterns:
      - 'ACCOUNT-[0-9]{8,12}'
      - 'CUSTOMER-[A-Z0-9]{8}'
      - 'CONSENT-[A-Z0-9]{10}'
    redaction:
      marker_format: label
      include_metadata: true

  dlp-filter:
    detect_patterns:
      - 'Bearer [A-Za-z0-9._-]{20,}'
      - 'consent_[A-Za-z0-9]{20,}'
      - 'client_secret_[A-Za-z0-9]{16,}'
    action: block

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

  audit-logger: {}

This route is strict by design. Open banking is usually a bad place to be casual about secrets or provider drift.

kt policy lint --file ./open-banking-ops-lane.yaml
kt gateway run --policy-config ./open-banking-ops-lane.yaml --port 41002
kt events tail --policy dlp-filter

That validation loop is enough to prove the route lints, blocks partner-token formats, and produces visible policy events.

Results and impact​

The practical improvement is that third-party data access stops being an invisible property of the application and becomes a governable property of the route.

  • Customer and account identifiers are less likely to leave the route in raw form because pii-detector sanitizes the request.
  • Partner and consent secrets are easier to block deterministically because dlp-filter encodes the patterns that matter.
  • Provider eligibility remains explicit because Data Routing Policy filters the target set.
  • Internal and partner review gets easier because audit-logger keeps the route attached to an evidence trail.

For open-banking operators, that is a meaningful shift. The assistant becomes part of the access-control story instead of a side channel around it.

Key takeaways​

Next steps​