The bank’s officer decides. Knox records.
A bank’s Bank Secrecy Act program performs KYC reviews, EDD reviews, alert dispositions, SAR drafts, and SAR filings every business day. Today the work lives inside the bank’s case-management tool — discoverable to an on-site examiner, opaque to anyone else. Knox sits one layer up: after the officer’s decision, the program posts a structurally-redacted event to /api/knox/bsa/attest. Knox hashes, chains, and anchors the receipt to the Bitcoin blockchain. The audit permanence layer is above the bank’s existing workflow, not in it.
The receipt is the record. Bitcoin is the witness.
- The gap. BSA program work is recorded inside the bank’s case-management tool. Internally discoverable; on-site discoverable to an examiner with appropriate access; not independently verifiable years later by anyone outside the bank without trusting the bank’s internal logs.
- What Knox accepts. 6 canonical event types covering the BSA lifecycle from periodic review through continuing-activity refile. Each event type has a dedicated schema with FFIEC-aligned vocabulary. Payloads accept only enums, integers, ISO timestamps and dates, bank-internal opaque references, sha256 hashes, and FinCEN SAR Activity Type codes. No PII field exists on any schema.
- What Knox anchors. SHA-256 of the canonical-JSON payload, hash-link to the previous Knox event, sequence number per stream, hourly Merkle root, Bitcoin block via OpenTimestamps. The chain commitment is what removes the bytes from after-the-fact rewrite — once anchored, the recomputed hash either matches or it does not.
- Verification (v1). Any third party — examiner, internal auditor, board member, plaintiff counsel, civil-rights bar — re-hashes the canonical-JSON payload locally and walks the chain link via the public endpoint at /api/knox/verify, both independent of Bonis cooperation. The Knox chain Merkle-aggregates and submits to the OpenTimestamps protocol calendars hourly for Bitcoin block confirmation; per-event raw .ots proof retrieval via public API for end-to-end Bitcoin-full-node verification is on the v1.1 roadmap.
- Posture. Substrate only. The bank’s officer makes every decision under the bank’s own program. Bonis never drafts a SAR, never files a SAR, never communicates with FinCEN on the bank’s behalf, and never holds bank-customer PII.
Where BSA work lives today, and what is missing from the record.
BSA program work is performed inside the bank’s case-management system — the alert disposition, the EDD memo, the SAR narrative, the filing receipt from FinCEN E-Filing. The work product is real, the analyst is trained, the officer signs off. What is missing is a tamper-evident audit layer that an outside party can verify without trusting the case-management tool, the vendor that built it, the operator that runs it, or the bank that owns it.
Knox does not replace the case-management tool. Knox sits above it. The bank’s program performs its work as it does today; at decision close, the program posts a structured redacted event to Knox. The Knox receipt is what an examiner walks years later, independent of the case-management tool’s availability or the bank’s cooperation.
What the seam looks like in practice
- Decision happens inside the bank. Analyst clears an alert; BSA officer signs off on an EDD memo; chief compliance officer authorizes a SAR for filing. The bank’s case-management system holds the narrative.
- Bank’s integration posts a structured record. A small adapter inside the bank’s BSA platform reads the closed case, maps the disposition to the appropriate Knox event type, drops PII fields, and POSTs the canonical payload to /api/knox/bsa/attest.
- Knox returns a receipt. event_id, payload_hash, previous_hash, sequence, chain_status, and an OpenTimestamps proof reference once the next anchor cycle commits.
- Bank stores the receipt alongside the case. The receipt is small (a JSON envelope, hundreds of bytes) and lives in the same case record. Years later, the receipt is the artifact an examiner re-verifies.
- Verification path is independent of Bonis. Re-hash the canonical payload → confirm match against payload_hash → walk the OpenTimestamps proof to a Bitcoin block header. The bank cooperates by surfacing the receipt; nothing else.
Six BSA event types. FFIEC-named, one schema each.
Each event type maps onto a discrete waypoint in the BSA program lifecycle. Each has its own Zod schema with strict field typing and unknown-key rejection. The full schema source ships at src/lib/knox-bsa-schemas.ts; the registered route ships at src/app/api/knox/bsa/attest/route.ts.
CDD-cycle close — initial or periodic Customer Due Diligence review.
Review period, review type (initial_cdd / periodic_cdd / trigger_event_cdd), current risk rating (low / moderate / high), prior risk rating + rationale code, CDD elements actually reviewed (identification, beneficial ownership, nature and purpose, expected activity, actual activity review), documents-reviewed count, reviewer role, outcome (passed / exception_filed / elevated_to_edd / exit_relationship), completion timestamp.
EDD-cycle close — Enhanced Due Diligence on a high-risk relationship.
EDD trigger code (high_risk_customer_category, high_risk_geography, high_risk_product, elevated_transaction_volume, negative_news, law_enforcement_inquiry, trigger_event_other), EDD elements reviewed (source of funds, source of wealth, expected activity re-documented, site visit, negative news screen, OFAC re-screen, ownership structure verified, third party payment review), negative news findings count + disposition, reviewer role, outcome (passed / elevated_to_sar / exit_relationship / continue_with_controls).
Alert lifecycle — close-out of a single AML alert from any source.
Alert source (transaction_monitoring, OFAC screen, negative news, manual referral, §314(a), subpoena_received, law_enforcement_request), alert received timestamp, disposition timestamp, disposition code (cleared_no_action, cleared_documented, escalated_to_case, filed_to_sar_queue, §314(b) share initiated, CTR filing required), rationale code (false_positive, expected_activity_consistent_with_profile, below_threshold_documented, exception_authorized_by_officer, unusual_activity_warrants_sar, structuring_indicator, other_documented), analyst role, aging in days, optional case linkage.
SAR drafting waypoint — pre-filing review chain.
Case ref + optional case-record hash, subject count, aggregate amount band (under_5k through over_5m — no raw dollar figures), activity summary codes (FinCEN SAR Activity Type format), activity window dates, draft completion timestamp, drafter role, awaiting-review-by role (bsa_officer / chief_compliance_officer / legal_review / ready_to_file).
SAR filing — initial, continuing, or correction filing to FinCEN E-Filing.
Case ref + optional case-record hash, subject count, aggregate amount band, activity summary codes, filing timestamp, BSA ID (FinCEN-issued), filing type (initial / continuing / correction), prior BSA ID (required when continuing or correction), filer role, days from detection to filing. Schema enforces prior_bsa_id presence when continuing or correction.
90-day continuing-activity refile — explicit chain link to prior filing.
Prior BSA ID, new BSA ID, continuing period dates, filing timestamp, filing number in series (≥ 2), filer role, account status at refile (open / frozen / exited / subpoena_hold). Continuity to the original SAR is structurally enforced — there is no path to file this event type without a prior_bsa_id.
The schema is the redaction. The runtime scan is defense-in-depth.
Redaction at Knox is not a configuration toggle. There is no PII field on any of the six BSA schemas. The accepted field types are listed below; what the schemas refuse to model is the primary privacy guarantee.
Every accepted field type is structural. No free-text field, no PII field. .strict() on every schema rejects unknown keys outright — a bank-side integration that adds a customer_name field receives a 400 schema_violation before any hashing occurs.
These fields do not exist on any of the six BSA schemas. The structural prohibition is the primary redaction; the bank cannot accidentally post PII because the schema layer has no path for it to land.
After Zod validation passes, a second-layer scanner walks every string value in the payload and rejects any match against SSN (xxx-xx-xxxx and bare 9-digit), email (RFC-shape), or US phone (xxx-xxx-xxxx) patterns. Catches the case where a bank pastes a raw value into an opaque-ref or hash field by integration mistake. Returns reason: 'pii_detected', HTTP 422.
Seven canonical bands cover the SAR-filing amount spectrum (under_5k through over_5m). Knox never sees a raw dollar amount, never sees a transaction descriptor, never sees a counterparty name. The band carries the supervisory signal without carrying the subject's privacy interest.
FinCEN's published SAR Activity Type code list evolves over time. Schemas accept the bank's canonical form (e.g. "31", "31a") rather than against a Knox-frozen enumeration — so a code-list update at FinCEN does not require a Knox redeploy. The format pattern is regex-enforced; semantically the bank's BSA program is the authority on which codes apply.
One POST. Six event types. A receipt the examiner verifies independently.
The BSA ingress reuses the canonical Knox gating stack — the same body-size, auth, rate-limit, monthly-cap, and JSON-parse order that protects /api/knox/anchor. Validation is BSA-namespaced; chain anchoring is shared.
BSA-namespaced ingress. Distinct from /api/knox/anchor — keeps BSA traffic, BSA rate limits, and BSA observability isolated from the generic Knox anchor path.
Same key-validation path as every other Knox ingress. Inactive or invalid keys receive HTTP 403. Missing keys receive HTTP 401.
event_type must be one of the six canonical BSA event types; payload must match the corresponding Zod schema. Unknown event types return HTTP 400 with the canonical type list. Schema violations return HTTP 400 with the failing field path and the violation reason.
Every field is a real return from the Knox anchor primitive. payload_hash is the SHA-256 of the canonical-JSON payload — re-computable by the bank, by the examiner, by any third party. The receipt sub-object carries a verify URL that resolves to the OpenTimestamps proof once the anchor cycle commits.
Public verify endpoint. Accepts the payload_hash and walks the chain commitment to OpenTimestamps to Bitcoin block headers. No Bonis cooperation required after the receipt is in the examiner's hands.
Reuses the canonical Knox gating stack from /api/knox/anchor. Body-size limit enforced before JSON parse. Rate limit and monthly cap enforced before validation work. Validation work is the most expensive gate and runs last.
Knox is audit substrate. Knox is not in the decision path.
- The bank’s officer decides. Risk rating, alert disposition, SAR draft, filing authorization — every supervisory judgment is made under the bank’s own BSA program by the bank’s own officers and analysts.
- The bank’s program posts. After the officer’s decision, the bank’s integration adapter posts a structured redacted record to Knox. The post is after-the-fact and idempotent on the bank’s opaque ref.
- Knox hashes and anchors. The canonical-JSON bytes get a SHA-256 commitment. The event hash-links to the previous Knox event in the chain. The hourly Merkle root commits to the Bitcoin blockchain via OpenTimestamps.
- Knox never operates the bank’s workflow. Never drafts a SAR, never files a SAR, never communicates with FinCEN on the bank’s behalf, never accesses customer PII, never operates inside the case-management tool. The decision belongs to the bank; the substrate belongs to Knox.
- Lawful authority does what lawful authority does. Examiners examine. Regulators regulate. Courts adjudicate. Knox provides the audit primitive; the verdict belongs to whoever has jurisdiction over the case.
Every claim on this page resolves to live code or an external authoritative source.
6 Zod schemas + cross-rail validator + defense-in-depth PII scan. The 6 types listed above are the literal exports from BSA_LIFECYCLE_EVENT_TYPES.
BSA-namespaced ingress. Reuses canonical validateApiKey, checkRate, checkMonthlyCap, and anchorEvent stack.
The canonical BSA/AML Examination Manual. Every enum value in the schemas is named for what an examiner reads in this manual.
Public verification surface. Accepts a payload hash + sequence and walks the chain commitment to a Bitcoin block header via OpenTimestamps.
The Knox chain submits hourly Merkle roots to the OpenTimestamps protocol calendars (alice / bob / finney). Bitcoin block confirmation status is recorded on the chain anchor descriptor as merkle.status. Per-event raw .ots proof retrieval via public API is on the v1.1 roadmap.
ML-DSA-87 (NIST FIPS 204) signing on canonical-JSON payloads via @noble/post-quantum. Standalone Layer 4; cross-rail hot-path integration in active build.
A Knox-anchored compliance receipt for each posted BSA decision, propagated into the canonical hourly OpenTimestamps Bitcoin-anchor process.
Differentiated from the bank’s case-management tool by independent-of-the-vendor verifiability. Differentiated from a regulatory portal by post-decision receipt rather than pre-decision workflow. Differentiated from a generic audit log by structural redaction plus FFIEC-vocabulary precision plus public-chain anchoring. Differentiated from a vendor-attestation SOC report by per-event cryptographic commitment rather than point-in-time controls statement.
Per-decision receipt. Examiner-grade vocabulary at the schema layer. Self-authenticating record delivered via a standard HTTPS POST. The bank’s officer keeps the decision. Knox keeps the proof that the record has not been mutated since.