FinRisk Sentinel: Financial Anomaly Detection
Streaming, Dual-Reviewer, 1-Hour SLA
streaming pipeline, not batch
85.8σ above 90-day baseline
CFO + Finance Controller, simultaneous
FinRisk Sentinel monitors the live financial event stream continuously — not in batch. It computes rolling baselines per account, per payment type, and per peer group, scoring every incoming transaction against a dynamic model of normal behaviour. The architectural distinction from Asset IQ's streaming anomaly detector is the sliding-window aggregation layer: FinRisk computes population statistics — rolling mean, rolling standard deviation, Z-score against a 90-day baseline, peer-group deviation — before any anomaly model sees the event.
High-severity anomalies reach the CFO and Finance Controller simultaneously through a dual-reviewer HITL-08 checkpoint. Both see the same data; either can act. The first decision closes both queues via an optimistic lock — no coordination required, no double-action possible. SHAP attribution is written to BigQuery before the HITL record is created, so the audit trail is grounded in the model's actual computation from the moment of scoring.
§1 System Context
FinRisk Sentinel's context is defined by what feeds it and what it produces. The input is the BigQuery financial event stream — populated by Salesforce contract events and RevRec AI classification outputs. The output is a dual-reviewer HITL alert that neither the CFO nor the Finance Controller can miss, and a BigQuery anomaly events record that closes the audit trail.
§2 Architecture — Streaming Pipeline
FinRisk Sentinel's architectural distinction from Asset IQ's streaming anomaly detector is the sliding-window aggregation layer. Asset IQ scores individual sensor readings; FinRisk computes population statistics — rolling mean, rolling standard deviation, Z-score against a 90-day baseline, peer-group deviation — before any anomaly model sees the event. The model scores against a dynamic baseline that updates with every new transaction.
| Stage | Component | Function | Output |
|---|---|---|---|
| 1 | Pub/Sub ae-financial-events | Streaming ingestion from Salesforce + RevRec AI | Raw payment event |
| 2 | FinRisk Agent (Cloud Run, min 2 instances) | Concurrent Pub/Sub pull · SA: finrisk-sa@ · WIF auth | Event accepted for scoring |
| 3 | Sliding window layer | 90d rolling mean/std · Z-score · peer-group deviation (Feature Store online) | Enriched feature vector |
| 4 | Isolation Forest (Vertex AI endpoint) | finrisk-anomaly@v1.2 · synchronous, sub-200ms | anomaly_score 0–1 |
| 5 | SHAP TreeExplainer | Top-3 feature attribution · deterministic, synchronous | SHAP values |
| 6 | BigQuery SHAP write | ae_audit.shap_explanations · written before HITL · EU AI Act Art. 13 | Immutable SHAP record |
| 7 | Severity router | <0.50 Log Only · 0.50–0.75 Alerting (no HITL) · ≥0.75 HITL-08 | Routed outcome |
| 8 | Firestore HITL-08 | Two docs: CFO + FC, simultaneous · either decision closes both · 1h SLA | Dual-reviewer checkpoint |
| 9 | BigQuery anomaly events | ae_audit.anomaly_events · every decision, HITL ref, SHAP ref | Closed audit record + Salesforce Activity entry |
§3 Agent State Machine
The FinRisk Sentinel state machine is distinguished by two features not present in other modules: four-tier severity branching from SCORING, and concurrent-decision handling in HITL-08. When two reviewers can both act, the state machine must correctly handle simultaneous action, action before the SLA, and the case where neither acts before the SLA.
| State | Trigger | Detail |
|---|---|---|
| IDLE → STREAMING | agent start | Pub/Sub pull · always-on |
| STREAMING → WINDOWING | event received | 90d rolling stats · Z-score · peer-group deviation · Feature Store online |
| WINDOWING → SCORING | features ready | Isolation Forest + Z-score · anomaly_score 0–1 |
| SCORING → LOG ONLY | score < 0.50 | BQ write · no alert |
| SCORING → ALERTING | 0.50–0.75 | Cloud Monitoring · no HITL |
| SCORING → SHAP → HITL-08 HIGH | 0.75–0.90 | CFO + FC · simultaneous · 1h SLA · optimistic lock |
| SCORING → SHAP → HITL-08 CRITICAL | score > 0.90 | CFO + FC + immediate escalation · 30min SLA · phone alert · auto-freeze pending review |
| SCORING → ERROR | Vertex AI timeout | HITL fallback |
| HITL-08 → POSTING | decision committed | BQ anomaly_event + Salesforce Activity |
| POSTING → COMPLETE | write confirmed | Audit trail closed |
§4 Data Flow & Sequence
The Universitätsklinikum München account — the same account whose contract was processed by ContractGuard, whose revenue was recognised by RevRec AI, and whose MRI unit is monitored by Asset IQ — makes a payment significantly above its 90-day baseline. FinRisk scores it at 0.87 and creates a simultaneous HITL-08 for both the CFO and Finance Controller.
| Time | Actor | Event |
|---|---|---|
| t+0 | Salesforce → Pub/Sub | payment_event · €2,840,000 published to ae-financial-events |
| t+2s | FinRisk Agent → Feature Store | get_online_features(UKM_account) + sliding_window() |
| t+4s | Feature Store → Agent | 90d_mean: €184K · std: €31K · Z: 85.8 |
| t+6s | Agent → Vertex AI | isolation_forest.score(enriched_feature_vector) |
| t+8s | Vertex AI → Agent | anomaly_score: 0.87 · severity: HIGH |
| t+10s | Agent → SHAP | shap_values(enriched_feature_vector) |
| t+12s | Agent → BigQuery | BQ write: shap_explanations(UKM_payment_202603) before HITL · EU AI Act Art. 13 |
| t+14s | Agent → Firestore | hitl.create_dual(HITL-08, score=0.87, shap, baseline, transactions[5]) |
| t+18s | Firestore → CFO + FC | HITL-08 queue (HIGH) delivered simultaneously to both reviewers |
| t+22min | Finance Controller | decision: Approve · reason: legitimate Q1 early payment · FC acts first |
| t+22min | Firestore | optimistic lock · CFO queue auto-closed |
| t+23min | Agent → BigQuery + Salesforce | BQ anomaly_event committed · hitl_ref · shap_ref · Salesforce Activity updated |
| t+23min | State | Complete · audit trail closed · CFO queue closed by optimistic lock |
§5 HITL-08 Presentation
HITL-08 is the most urgent HITL in the suite. The CFO and Finance Controller receive the same alert simultaneously — a sparkline for visual context, a transaction table for the numbers, SHAP for the model's reasoning, and a dual-reviewer status panel showing whether the other reviewer has already acted. The first decision closes both queues.
| Date | Amount | Type | Z-Score | Status |
|---|---|---|---|---|
| 2026-02-28 | €164,320 | Invoice payment | −0.6σ | Normal |
| 2026-02-14 | €201,840 | Invoice payment | +0.6σ | Normal |
| 2026-01-31 | €178,500 | Invoice payment | −0.2σ | Normal |
| 2026-01-15 | €221,750 | Invoice payment | +1.2σ | Normal |
| 2026-03-15 | €2,840,000 | Payment (type: unspecified) | +85.8σ | ⚠ Anomaly |
§6 Architecture Decision Records
Three FinRisk decisions, every alternative documented.
BigQuery ML's ARIMA_PLUS model was evaluated — a natural choice for financial time-series anomaly detection given that payments are temporal events with seasonality. It was rejected for three reasons. (1) ARIMA models require a minimum history length per entity before they can produce reliable forecasts — new accounts or accounts with irregular payment schedules produce poor ARIMA fits. Isolation Forest requires only that a normal operating period exists, not a minimum number of observations; ClaraVis has accounts that pay quarterly, annually, or on irregular project schedules. (2) ARIMA_PLUS operates in batch mode in BigQuery ML — it is not a streaming model. For a financial anomaly system with a 1-hour HITL SLA, a batch model requires scheduling infrastructure that introduces latency; Isolation Forest runs on the Vertex AI endpoint as a synchronous REST call with sub-200ms response. (3) The deterministic SHAP TreeExplainer requirement applies equally here — ARIMA does not produce structured SHAP attributions. The CFO asking "why was this payment flagged?" needs a feature-level explanation, not an ARIMA residual value. A Z-score enrichment layer alongside Isolation Forest produces a human-readable metric ("+85.8σ above baseline") while Isolation Forest provides the multi-dimensional model signal that accounts for correlated features.
The alternative design was to run FinRisk as a scheduled BigQuery query — every 15 minutes, query the transactions table, compute Z-scores in SQL, and alert on outliers. This is a common financial monitoring pattern and avoids the operational complexity of a streaming Cloud Run agent. It was rejected because: (1) a 15-minute batch window means a payment anomaly can sit undetected for up to 15 minutes before any alert fires — operationally unacceptable for a high-severity financial event such as a potentially fraudulent payment or a wire transfer error. The streaming architecture detects and alerts within 18 seconds of the payment event reaching Pub/Sub. (2) BigQuery SQL cannot call a Vertex AI Isolation Forest endpoint synchronously — the batch approach would require either BigQuery ML (rejected above) or a scheduled Cloud Function bridge that replicates the streaming agent's complexity without the latency advantage. (3) the sliding window feature computation (90-day rolling stats, peer-group deviation) requires maintaining state across events — natural in a streaming agent with in-memory state, but requiring materialised views or intermediate tables in batch SQL, adding query cost and maintenance overhead. The streaming architecture is more complex to operate but delivers a 1-hour HITL SLA that a batch architecture cannot match.
Single-reviewer HITL — either CFO or Finance Controller, not both — was the initial design for simplicity. It was replaced with dual-reviewer for three reasons. (1) Separation of duties: for high-severity financial alerts (score ≥ 0.75, potentially indicating fraud or error), requiring only one reviewer creates a single point of control. Having both reviewers notified simultaneously ensures the faster-responding, better-informed reviewer can act within the SLA without requiring coordination. (2) EU AI Act Article 14 requires adequate human oversight proportionate to the risk; for a system flagging potential financial fraud in a regulated medical device company, "adequate oversight" for high-severity alerts is documented as dual-reviewer — matching the four-eyes principle already applied to financial authorisations above a threshold at ClaraVis. (3) the optimistic lock mechanism resolves the concurrent-decision problem cleanly: Firestore's transaction model guarantees the first committed decision is final, the second write detects the conflict via the document version check, and both queues close automatically. No coordination between reviewers is required.
§7 Stakeholder Rebuttals
Six objections raised during the FinRisk design review. Each rebuttal is grounded in architectural evidence, not opinion.
payment_seasonality_flag set for accounts with documented Q1/Q4 bulk payment patterns — the Isolation Forest model is 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. Second, the HITL-08 sidebar context shows the account's contract and invoice history alongside CRM notes — a Finance Controller reviewing a Q4 bulk payment sees immediately that it matches three outstanding invoices, and the approval takes 30 seconds, not 30 minutes. The system is designed to make every HIGH alert reviewable in under five minutes with full context, so genuine anomalies are caught and false positives are dismissed quickly.baseline_source field (Account or Peer Group) that the SHAP attribution reports, and the HITL-08 interface shows which baseline source is being used.ae-financial-events topic has three principals with subscription access: the FinRisk SA (pull subscription only), the RevRec AI SA (publish only), and the Data Governance SA (schema validation only). No developer SA has subscription access. The anomaly_events table in ae_audit is governed by the same IAM policy as the SHAP explanations table: Finance Controller (read), CFO (read), FinRisk SA (write), audit SA (read for compliance queries). Raw Pub/Sub payloads are not persisted in BigQuery — only the processed anomaly record is written, and the full transaction reference is stored as a hash, not plain text. The plain-text reference is only accessible via the Salesforce Account record, with its own IAM-governed access control.§8 Demo Pathway
Three minutes. One payment. Two reviewers. Eighteen seconds to alert. The München hospital account makes a payment that FinRisk flags. The pathway below shows the streaming pipeline in action, the simultaneous dual-reviewer HITL-08, and the optimistic lock when the Finance Controller acts before the CFO.
ae-financial-events, the Cloud Run instance count, and the rolling anomaly score distribution for the past 24 hours — mostly Log Only (green), a few Alerting (amber), zero High. This establishes that the system runs continuously and that HIGH alerts are genuinely rare.ae-financial-events via the Pub/Sub Console: account_id UKM_MCH_001, amount €2,840,000.00, payment_date 2026-03-15. The Cloud Run logs show: "Event received," "Fetching baseline features…," "Z-score computed: 85.8," "Isolation Forest score: 0.87 · severity: HIGH" — all in under 10 seconds.ae_audit.shap_explanations shows the row already exists before the HITL queue appears.ae_audit.shap_explanations joined to ae_audit.anomaly_events on transaction_id — returns the three SHAP values, the anomaly score, the FC's decision and timestamp, and the CFO's auto-close record. This is the complete EU AI Act Article 13 + 14 evidence package for this financial anomaly event — the same BigQuery pattern as every other module in the suite.§9 Adjacent Modules
Financial domain complete — four modules done. ContractGuard, RevRec AI, and FinRisk Sentinel complete the Financial domain within the Quote-to-Cash pillar. All three share the same München account narrative, the same BigQuery audit pattern, and the same SHAP-before-HITL design discipline.