Hermes Wiki
opportunities/2026-08-20-incremental-RBC_Work

Incremental Opportunities: RBC_Work (2026-08-20)

Scope: Architecture/Challenges/design-a-kyc-aml-onboarding-pipeline (new this window) against RBC_Work's own compliance-automation items.

Finding

Projects/RBC_Work.md names several live/near-term compliance-automation initiatives that all share one unstated design requirement: a provable, immutable decision trail that survives both a regulator's audit request and a data-retention/deletion obligation at the same time — "OSFI ready compliance, AI generated DR assessment... We certify the infrastructure for the 9 ADT program" (line 47), "AI SDLC... requirements -> architecture -> intra code -> compliance evidence" (line 67), and "Document and standard compliance. Analyzer. AI powered gap analysis for policy documents against regulatory standards" (line 121). None of these items describe how the evidence trail itself is structured to be tamper-evident and retention-safe — they describe the automation that produces the evidence, not the storage/audit model underneath it.

Architecture/Challenges/design-a-kyc-aml-onboarding-pipeline (new this window) is a directly-applicable reference architecture for exactly this class of problem, even though its literal scenario (identity/sanctions screening) is narrower than RBC_Work's compliance-automation scope: a per-applicant/per-decision event-sourced audit ledger as the single source of truth (not a mutable status field that gets overwritten), diff-driven re-screening triggered by upstream list/policy changes rather than periodic full re-checks, and crypto-shredding to reconcile a data-subject deletion request against a regulator's multi-year retention requirement — splitting PII (deletable via key destruction) from the decision/audit record itself (permanent, non-PII, retained).

Suggested next step

The next time an RBC compliance-automation item (the gap-analysis Analyzer, the AI-generated DR assessment, or the AI SDLC's "compliance evidence" stage) needs its own storage/audit design specified rather than just "generates compliance evidence," use this challenge's three mechanisms as the starting reference: (1) event-sourced, append-only decision log instead of a mutable record, so "what did the system decide and when" is provably reconstructable — directly useful for the ADT certification/audit-ready framing already named in RBC_Work; (2) diff-driven re-evaluation triggered by policy/standard changes, which maps onto the gap-analysis Analyzer's own job (a policy document changes → what previously-certified items are now out of compliance, without re-running every check from scratch); (3) crypto-shredding as the concrete mechanism if any of these compliance systems ever need to reconcile a deletion request against OSFI-style retention — a distinction worth having on hand before it becomes a live design question rather than after.

Hermes Wiki