CTO · S-01
Why not BigQuery ML ARIMA — it's already in the data warehouse?
"BigQuery ML has an ARIMA_PLUS model designed for time-series anomaly detection. ClaraVis already uses BigQuery. Why build a separate Cloud Run streaming agent and a separate Vertex AI endpoint when the anomaly detection capability is already in the tool we're paying for?"
Architectural response
ARIMA_PLUS is a batch forecasting model — it runs in scheduled query mode, not in a streaming, sub-second scoring mode. ADR-FR01 documents the latency argument: a 15-minute batch window is operationally unacceptable for a high-severity financial alert system with a 1-hour SLA. By the time a batch model fires an alert, 15 minutes have already elapsed. The streaming architecture detects and alerts in 18 seconds. There is also the SHAP requirement: ARIMA does not produce structured SHAP attributions that satisfy EU AI Act Article 13. The CFO and Finance Controller need to see "this payment was 15.4× the account baseline and 85.8σ above the rolling mean" — not an ARIMA residual value. The Isolation Forest plus Z-score combination provides both the model signal and the human-readable explanation in a single scoring pass.
Evidence: ADR-FR01 (streaming over batch) · ADR-011 (Isolation Forest over ARIMA) · HITL-08 UI (Z-score human-readable + SHAP) · EU AI Act Art. 13
CFO · S-03
What's the false positive rate — every spurious alert wastes senior executive time?
"Every HIGH severity alert lands in my queue and requires my attention within the hour. If FinRisk fires 20 false positives a week, that's 20 hours of executive time wasted. What is the expected alert volume and false positive rate?"
Architectural response
At ClaraVis's transaction volume (approximately 340 invoiced payments per month across all accounts), the Isolation Forest model with a 0.75 HIGH threshold and the Z-score enrichment is calibrated to fire HIGH alerts on approximately 1–3 events per month — not per week. The model's contamination parameter is set to 0.005 (0.5% expected anomaly rate), meaning approximately 1–2 of every 200 transactions score above the HIGH threshold. The vast majority of elevated payments — an account paying early, a large Q4 order, a multi-year prepayment — score below 0.75 and route to ALERTING (no HITL) or LOG ONLY. The sidebar context note in the HITL-08 interface specifically shows the account's contract activity on the same date, allowing the CFO to approve a legitimate early payment in under 60 seconds. The ADR-FR02 dual-reviewer design means that if the Finance Controller acts first, the CFO queue closes automatically — eliminating the CFO's time cost entirely for false positives that the FC recognises immediately.
Evidence: Page 06 FinRisk Model Card (contamination parameter 0.005 · expected HIGH alert rate) · HITL-08 UI context note (contract activity same date) · ADR-FR02 (dual-reviewer, first-act closes both)
Finance Controller
How does FinRisk distinguish genuine anomalies from planned large payments?
"At quarter-end, some of our largest accounts make bulk payments that cover 3–6 months of invoices simultaneously. These are expected and planned — but they'll look like massive anomalies to a model that only knows the 90-day rolling mean. Won't FinRisk flood us with false positives at Q1 and Q4 close?"
Architectural response
Two mechanisms address this specifically. First, the Feature Store account baseline features include a payment_seasonality_flag that is set for accounts with documented Q1/Q4 bulk payment patterns — the Isolation Forest model was trained on data that includes these seasonal payments, so the contamination rate accounts for them. The payment_frequency_anomaly SHAP feature captures whether the payment arrived on schedule or out-of-cycle — a Q4 bulk payment that arrives in the normal Q4 window scores lower on this feature. Second, the HITL-08 sidebar context note shows the account's contract and invoice history for the past 90 days alongside the CRM notes for the account. A Finance Controller reviewing a Q4 bulk payment sees immediately that it matches three outstanding invoices — the approval takes 30 seconds, not 30 minutes. The system is not designed to prevent all HIGH alerts — it is designed to make every HIGH alert reviewable in under 5 minutes with full context, so that genuine anomalies are caught and false positives are dismissed quickly.
Evidence: Page 06 FinRisk Feature Store (payment_seasonality_flag · payment_frequency_anomaly features) · HITL-08 UI (account context sidebar with contract and invoice history) · ADR-011 (Isolation Forest trained on seasonal data)
Enterprise Architect · S-08
How does the sliding window handle sparse payment schedules for smaller accounts?
"The 90-day rolling baseline assumes enough payment events to compute a meaningful mean and standard deviation. A small account that pays annually has maybe 1–2 payments in 90 days. The rolling statistics will be meaningless or undefined. How does FinRisk handle this?"
Architectural response
Accounts with fewer than 5 payment events in the rolling 90-day window fall back to peer-group-level baseline statistics rather than account-level statistics. The peer group is defined by account tier (Small, Mid, Enterprise), industry vertical (hospital, clinic, research), and region — accounts with similar payment frequency profiles. A small research institution that pays annually is compared against other annual-paying research institutions in the same region, not against its own sparse history. This peer-group fallback is explicit in the Feature Store account baseline features — the feature vector includes a baseline_source field (ACCOUNT or PEER_GROUP) that the SHAP attribution reports. The HITL-08 interface shows the Finance Controller which baseline source is being used. An annual-paying account is far less likely to trigger a HIGH alert from a peer-group baseline than from a statistical anomaly model applied to 2 data points — the contamination rate is effectively zero for accounts in their expected payment cycle within the peer group.
Evidence: Page 06 FinRisk Feature Store (baseline_source feature · peer-group fallback logic) · HITL-08 UI SHAP section (baseline source displayed) · Isolation Forest contamination parameter
CISO · S-09
Financial transaction data — what access controls apply?
"The ae-financial-events Pub/Sub topic carries actual payment amounts, account identifiers, and transaction references. This is classified financial data. Who has read access to this topic and the downstream BigQuery tables?"
Architectural response
The ae-financial-events Pub/Sub topic has three principals with subscription access: the FinRisk SA (finrisk-sa@, pull subscription only), the RevRec AI SA (revrec-sa@, publish only — RevRec writes classification events to this topic), and the Data Governance SA (datagovernance-sa@, schema validation only). No developer SA has subscription access. The BigQuery anomaly_events table in ae_audit is in the same dataset as the SHAP explanations table — access is governed by the same IAM policy: Finance Controller role (read), CFO role (read), FinRisk SA (write), audit SA (read for compliance queries). The raw Pub/Sub message payloads are not persisted in BigQuery — only the processed anomaly record (score, Z-score, SHAP values, HITL decision) is written. The payment amount is included in the anomaly record for audit purposes but the full transaction reference is stored as a hash, not in plain text, in the BigQuery audit table. The plain-text transaction reference is only accessible via the Salesforce Account record, which has its own IAM-governed access control.
Evidence: Page 07 Pub/Sub topic IAM (three SA principals) · BigQuery ae_audit dataset access policy · Page 07 CMEK configuration · transaction reference hashing in FinRisk agent
CCO · S-02
Does FinRisk fall under EU AI Act given it flags financial transactions?
"FinRisk flags financial transactions. The EU AI Act Annex III includes AI systems used in creditworthiness assessment and financial access decisions. Is FinRisk a high-risk system under that classification? And what are the obligations if it is?"
Architectural response
FinRisk Sentinel is a high-risk system under EU AI Act Annex III Category 5 (AI systems used in the area of employment and workers management) — not Category 5b (creditworthiness) because it does not assess ClaraVis's counterparties' creditworthiness or make access-to-financial-services decisions. It monitors ClaraVis's own incoming financial transactions for anomalies. The Annex III Category most directly applicable is Category 2 (critical infrastructure) by analogy with the financial system monitoring rationale, and Category 6 (law enforcement and justice) is not applicable. The conservative position — adopted in the architecture — is to treat FinRisk as High Risk regardless of the precise Annex III category, because the consequences of a false negative (a missed fraudulent transaction) or a false positive acted upon incorrectly (freezing a legitimate payment) are material. The dual-reviewer HITL-08 design satisfies Article 14 at the highest level of human oversight — two senior principals, 1-hour SLA, optimistic lock preventing double-action. The SHAP attribution per alert satisfies Article 13. The Model Card in Vertex AI Model Registry satisfies Article 11.
Evidence: Page 06 FinRisk Model Card (EU AI Act classification) · HITL-08 dual-reviewer design (ADR-FR02) · SHAP attribution (EU AI Act Art. 13) · VPC-SC + CMEK (Art. 15 robustness)