Threat model

How OpenClear could be attacked, and what stops it. It's kept as code with OWASP pytm (threat_model/openclear.py) so it changes in the same pull request as the system it describes, and a test fails when this page falls behind. Terms are as in CONTEXT.md. It isn't legal advice, and it doesn't replace each bank's own assessment of how it runs OpenClear.

Data flows

flowchart LR
  subgraph b0["Internet"]
    n0["Bank staff"]
    n1["Customer user"]
    n2["Platform staff"]
  end
  subgraph b1["Bank's network"]
    n3["Embedding host (online banking)"]
    n4["Bank core and API clients"]
    n5["Teller platform (branches)"]
    n6["Identity provider (OIDC / SAML)"]
    n7["Directory (SCIM client)"]
    n8["SIEM"]
    n9["Webhook receiver"]
  end
  subgraph b2["Edge (WAF / CDN)"]
    n15["Edge / WAF"]
  end
  subgraph b3["OpenClear installation (service provider)"]
    n13["ClamAV daemon (optional)"]
    n16["OpenClear web and API"]
    n17["Background worker"]
    n18["Plugins (in process)"]
  end
  subgraph b4["Data stores (service provider)"]
    n19["Database (Postgres, row-level security)"]
    n20["File storage (local, S3, Azure)"]
    n21["Redis (rate limits, optional)"]
    n22["Keys and secrets (files / environment)"]
  end
  subgraph b5["Outside services"]
    n10["Email and SMS providers"]
    n11["Cloud OCR (optional)"]
    n12["Release feed (GitHub)"]
    n14["VirusTotal (optional, hashes only)"]
  end
  n0 -->|"Bank staff use the web UI"| n15
  n1 -->|"Customer users use the web UI"| n15
  n2 -->|"Platform staff use the operator view"| n15
  n3 -->|"Embedded session launched from online banking"| n15
  n4 -->|"Core and API clients call the API"| n15
  n5 -->|"A check verified before cash is paid at a branch, then recorded cashed"| n15
  n6 -->|"SSO sign-in responses (browser-relayed)"| n15
  n7 -->|"SCIM provisioning"| n15
  n15 -->|"Edge forwards to the origin"| n16
  n16 -->|"OIDC discovery, token and JWKS requests"| n6
  n16 -->|"Queries, scoped to one bank"| n19
  n16 -->|"Uploads, images and exports"| n20
  n16 -->|"Rate-limit counters"| n21
  n16 -->|"Signing and encryption keys read at start"| n22
  n16 -->|"Plugin hooks"| n18
  n17 -->|"Jobs read and write, per bank"| n19
  n17 -->|"Exports, archives, OCR input"| n20
  n17 -->|"Security events (HEC, syslog over TLS)"| n8
  n17 -->|"Signed webhooks"| n9
  n17 -->|"Decisions delivered to the core"| n4
  n17 -->|"Email and SMS"| n10
  n17 -->|"Incident notices emailed to each bank's incident contacts"| n10
  n17 -->|"Check images for OCR (if configured)"| n11
  n16 -->|"Release check"| n12
  n16 -->|"Every upload streamed for a malware scan (if configured)"| n13
  n16 -->|"Each upload's SHA-256 looked up, never the file (if configured)"| n14
  n17 -->|"Hashes it couldn't answer for, asked again"| n14

Threats specific to OpenClear

Positive pay's own threats, by STRIDE category (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege). Evidence names OpenClear's controls, code and ASVS 5.0 requirements. "CUEC" means the protection depends on the service provider or the bank (CUECs).

Generic threats (pytm's library)

pytm matches every element and flow against its threat library (based on CAPEC). These are the threats it raises for this model, most severe first. Most are answered by the controls above and by the ASVS assessment; they're listed so that a change to the model that raises a new one shows up in review.

264 findings across 76 threats.

Privacy (LINDDUN GO)

A pass over the LINDDUN GO cards, by category:

Built from docs/security/threat-model.md in the OpenClear repository. Last changed October 28, 2026.