Security

ClearedToFile handles campaign finance data. The custody model is designed so the blast radius of any breach is narrow and the regulatory triggers are minimized.

Custody model

ClearedToFile sits between the committee (private custody) and the state (verdict and opt-in drill-down). The boundary is deliberately narrow.

What we store

  • Institution name
  • Treasurer-chosen account label
  • Last four digits of account number
  • Transaction date, amount, direction, and memo
  • SHA-256 hash of every source file ingested
  • Upload audit trail: who, when, source IP, user agent, file hash, parser, row count

What we never store

  • Full bank account numbers
  • Routing numbers
  • Bank login credentials
  • Raw uploaded files after parsing — originals are purged; only the hash and metadata survive

What the state sees

The state never receives raw bank data.

Default (every filing)

  • The filed report (same content the committee already submits publicly)
  • Reconciliation verdict: green, yellow, or red
  • Summary counts and dollar deltas across the three reconciliation legs
  • Audit follow-up notes and committee responses

Opt-in drill-down (committee consent required)

  • Row-level matched and unmatched transaction view
  • Revocable by the committee at any time

Encryption and access controls

In transit

TLS 1.3 on all connections. No exceptions.

At rest

Database encryption via managed disk. Per-tenant envelope keys for aggregator access tokens.

Access controls

Role-gated, per-organization scoping. No cross-tenant read access by design.

Aggregator tokens

Encrypted with per-tenant keys. Never logged in plaintext. Immediate revocation on breach detection.

Breach posture

Most state data-breach notification laws trigger on unauthorized acquisition of name plus financial account number or routing number. Because ClearedToFile never stores full account numbers or routing numbers, a breach of our transaction store does not trigger most state breach notification statutes. This is not a workaround — it is an architectural decision. We never carry the data that triggers the law.

Aggregator access tokens carry a different risk profile. Mitigations: per-tenant envelope encryption, key isolation, immediate revocation via the aggregator's API on breach detection, and no plaintext logging anywhere.

Integrity layers

The product asserts a "cleared to file" verdict. The strength of that verdict depends on how we verify what comes in. We use a layered model:

  • Format validation and parser strictness — rejects unknown formats and structurally tampered files
  • SHA-256 audit trail — every uploaded file is hashed on receipt; immutable upload record
  • Bank-emailed statement verification (DKIM) — verifies statements forwarded from the bank are cryptographically signed by the bank's mail server
  • PDF signature verification — validates bank-signed PDF statements from institutions that digitally sign their documents
  • Bank aggregator pull — direct OAuth connection to the bank via Plaid or Akoya; data flows bank-to-us with no treasurer intermediary
  • State-portal SHA cross-check — compares committee-uploaded filing against the state portal's published copy
  • Statistical detection — flags numerically implausible patterns (Benford's law, just-under-threshold clustering, round-number bias)

Compliance references

GLBA Safeguards Rule — written information security program, encryption in transit and at rest, access controls, vendor due diligence on bank aggregators, incident response plan.

CFPB Rule 1033 — consumer-authorized bank data sharing via standardized APIs. Our aggregator strategy aligns with the rule's intended OAuth-based access model.

State campaign-finance privacy rules — bank account information is treated as non-public. Our custody model matches: the state sees the public filing and our verdict, not the bank-derived backup.

Questions

Security questions? Reach us at codewavesfl@gmail.com.