The Autonomous Finance · Page 08 · Compliance Architecture
Compliance as architecture. Not as a checklist.
Every regulatory obligation satisfied by a specific architectural component. GDPR is not a privacy notice — it is CMEK, VPC-SC, and europe-west3 residency. EU AI Act is not a policy — it is SHAP written to BigQuery before the HITL checkpoint is created. Each obligation below is documented with the design decision that satisfies it and the evidence a regulator can query.
Three agents. Three risk tiers. Each justified by design.
The EU AI Act does not classify systems uniformly — it classifies by use case and consequence. Each Autonomous Finance agent has been individually assessed against Annex III (High Risk) criteria. The classification is not aspirational — it is justified by specific architectural constraints that structurally prevent the agent from meeting the High Risk threshold.
Limited Risk · Art. 52
IC Reconciliation Agent
Transparency obligation · explanation required
Annex III High Risk requires AI to make or materially influence decisions affecting legal rights or access to essential services. The IC agent flags anomalies — it cannot post corrections to SAP without an explicit Group Controller approval (HITL-IC-01, ADR-AF-01). The decision is the human's. Annex III Art. 6(2) exclusion applies: the system outputs a ranked anomaly list with SHAP attribution and does not autonomously act on financial accounts. Veldtmann entities are classified under NACE Rev. 2 Section K (Financial and Insurance Activities) — the IC agent is not within critical infrastructure under Annex III point 2. Limited Risk applies: the system interacts with humans in a consequential context, triggering Art. 52 explanation obligations — satisfied by SHAP written to BigQuery before HITL creation.
✓ Art. 13 — SHAP to BigQuery before HITL-IC-01 created ✓ Art. 14 — SAP write structurally blocked without hitl_id ✓ Art. 52 — Explanation surfaced in Group Controller queue ✓ Annex III exclusion — Art. 6(2): no autonomous act on financial accounts
1
Limited Risk · Art. 52
Cash & Treasury Agent
Transparency obligation · HITL-gated execution
Annex III point 5(b) classifies AI for credit assessment or creditworthiness evaluation of natural persons as High Risk — the Treasury agent operates exclusively on legal entity cash positions and group FX exposure, not on individual creditworthiness. Annex III point 2 (critical infrastructure) does not apply: the agent produces a 7-day cash forecast and hedge recommendation for group treasury, not for critical national financial infrastructure. The agent cannot execute a bank instruction or intercompany sweep without Treasury Manager approval (HITL-TR-01). The hedge recommendation is not the hedge execution. The execution gate (HITL) is structural, not conditional — it cannot be bypassed by a confidence threshold or configuration flag. Art. 6(2) exclusion applies.
✓ Art. 13 — Forecast confidence interval + SHAP shown before HITL ✓ Art. 14 — Bank instruction API requires hitl_id parameter ✓ Art. 52 — Recommendation framed as recommendation, not decision ✓ Annex III pt. 5(b) — No natural person creditworthiness involved
2
Minimal Risk · No obligation
AP Exception Agent
Classification only · all exceptions human-approved
The AP Exception Agent classifies invoices into one of five exception types. It does not reject invoices, does not make payment decisions, and does not interact with suppliers. Every non-APPROVED classification routes to HITL-AP-01 for the AP Lead. The APPROVED class (auto-routed invoices) only fires at confidence > 0.92 — below that threshold, all invoices reach a human regardless. The agent is a classifier and sorter, not a decision-maker. Minimal Risk applies. No EU AI Act obligation is triggered — though SHAP is still written for every exception classification as a quality and audit practice.
✓ No autonomous payment decision — HITL for all exceptions ✓ SHAP written voluntarily — exceeds Minimal Risk obligations ✓ Override rate monitored as drift signal (Page 09 MLOps)
3
Shared EU AI Act obligations — all three agents
Art. 13 transparency + Art. 14 human oversight · satisfied by architecture, not policy
Art. 13 — SHAP written BEFORE HITL (immutable, not retrospective)
Art. 14 — Human reviews explanation, makes decision
Write guard — structurally unreachable without hitl_id
GDPR — Arts. 5 & 25 · Privacy by Design
No personal data in any feature vector. Ever.
GDPR compliance in the Autonomous Finance is architectural, not procedural. The system processes financial transactions between legal entities — not individuals. Feature vectors are entity-level aggregates. Where individual-adjacent data appears (AP — supplier invoice decisions), explanation rights are satisfied by SHAP queryable from BigQuery. All storage is europe-west3, CMEK-encrypted, within VPC-SC perimeter.
GDPR data architecture — europe-west3 perimeter
Data flow · residency · minimisation · CMEK · VPC-SC · no personal data in inference path
Art. 5(1)(c) — Data minimisation: entity aggregates only, no personal data in feature vectors
Art. 25 — Privacy by design: CMEK, europe-west3, Feature Store lineage
Art. 22 — Right to explanation: applies to AP agent only (supplier-adjacent data); IC & Treasury process legal entities — Art. 22 not applicable
Art. 5(1)(b) · Purpose Limitation
Financial data processed only for its stated purpose
IC entries are processed for reconciliation only. Treasury data is processed for cash positioning only. Invoice data is processed for AP exception routing only. No cross-purpose reuse. Documented in data processing register (DPA with each entity).
Evidence: BigQuery IAM dataset-level permissions · one dataset per use case · no cross-dataset query grants
Art. 5(1)(c) · Data Minimisation
Feature vectors contain no personal identifiers
IC features: entity_pair_id · amount · currency · posting_timing_delta · period. No individual names, employee IDs, or authoriser details enter any feature vector. These fields are in the raw SAP record — they are dropped at the feature engineering step.
Evidence: Feature Store feature group schema — fields listed · no PII fields included
Art. 25 · Privacy by Design & Default
CMEK + VPC-SC + europe-west3 = privacy by architecture
All storage (Firestore HITL state · BigQuery audit · Feature Store) is CMEK-encrypted with customer-managed keys in Cloud KMS, europe-west3. VPC-SC perimeter prevents any data from leaving the GCP boundary for inference or processing. Workload Identity Federation — no long-lived credentials.
Evidence: Terraform VPC-SC perimeter config · Cloud KMS key ring europe-west3 · WIF service account bindings
Art. 22 · Automated Decision-Making
Right to explanation — AP agent only · IC and Treasury not in scope
Art. 22 applies to automated decisions affecting natural persons. The IC Reconciliation and Treasury agents process transactions between legal entities — legal entities hold no Art. 22 rights (GDPR Recital 14). Art. 22 is therefore not triggered for those two agents. The AP Exception Agent is the sole agent where supplier-adjacent data appears. Any supplier whose invoice was classified as an exception can request the SHAP explanation. The explanation is written to BigQuery before the HITL checkpoint is created — immutable and immediately available.
Evidence: BigQuery ae_audit.shap_explanations · queryable by invoice_id · written before hitl_id exists · AP agent only
Immutability vs. Art. 17 (Right to Erasure) — Design Note: Audit records in ae_audit.shap_explanations and ae_audit.transfer_pricing contain no direct personal identifiers. The invoice_id field is a transactional reference to a legal entity transaction — it does not identify a natural person within the meaning of GDPR Art. 4(1) and Recital 26. The supplier company holds no Art. 17 erasure right. Individual contact data (authoriser names, email addresses) is excluded from all feature vectors and audit records by design at the feature engineering step. The immutability guarantee required for OECD BEPS Action 13 and IFRS audit trails therefore does not conflict with Art. 17 obligations.
Finance data as the foundation of ESRS G1 disclosure.
The CSRD requires Veldtmann to report sustainability-linked financial KPIs from 2025 onwards under ESRS standards. The Autonomous Finance is not a CSRD tool — but it produces the financial data architecture that makes CSRD reporting auditable at the transaction level. IC pricing governance and FX risk management data are disclosed under ESRS G1 (Business Conduct — tax transparency, transfer pricing governance, payment practices) — not as Scope 3 GHG emissions. The Treasury agent's FX and IC flow data feeds ae_finance.csrd_feed in BigQuery. GreenOps (M-06) schedules the monthly export. Final iXBRL tagging for the ESRS digital taxonomy is applied downstream by the Veldtmann Group finance system.
Foreign key to ae_audit.hitl_events — auditor traceability
csrd_category
STRING
System
ESRS topic code — G1 (Business Conduct) for IC governance and FX risk management data
written_at
TIMESTAMP
System
Immutable record timestamp — CMEK-encrypted
Monthly CSRD ESRS G1 export query — run by GreenOps scheduler or CFO directly
-- CSRD ESRS G1 governance export · ae_finance.csrd_feed · monthly · all Veldtmann entities-- FIX: DATE_TRUNC uses explicit timezone 'Europe/Berlin' to avoid UTC date boundary ambiguitySELECT
reporting_period,
entity_id,
SUM(ic_flow_eur) AS total_ic_flows_eur,
SUM(fx_hedge_notional_eur) AS total_fx_hedged_eur,
COUNT(DISTINCT hitl_approval_id) AS human_approved_decisions,
csrd_category,
CURRENT_TIMESTAMP() AS export_generated_at
FROM`ae_finance.csrd_feed`WHERE-- Explicit timezone prevents UTC vs CET boundary errors on month-end transactions
reporting_period = DATE_TRUNC(
DATE_SUB(CURRENT_DATE('Europe/Berlin'), INTERVAL 1 MONTH),
MONTH
)
AND hitl_approval_id IS NOT NULL-- only human-approved transactions in CSRD reportGROUP BY reporting_period, entity_id, csrd_category
ORDER BY entity_id, csrd_category;
PIPEDA · Canadian Subsidiary · Purpose Limitation
Veldtmann Canada data stays Canadian.
PIPEDA (Canada's Personal Information Protection and Electronic Documents Act) applies to Veldtmann's Canadian subsidiary — acquired 24 months ago, integrated into the group IC reconciliation flow. PIPEDA requires explicit purpose limitation: data collected for one purpose cannot be repurposed without consent. The architectural response is dataset separation, not field-level tagging — the PIPEDA auditor can verify compliance from the BigQuery IAM policy without inspecting query logs. Cross-border transfer to the EU group system is governed by PIPEDA Schedule 1, Principle 4.1.3 and is documented in the Data Processing Agreement as necessary for the performance of intercompany services contracts — satisfying the contractual necessity exception under PIPEDA S.7(3)(c). A Privacy Impact Assessment (PIA) was completed per OPC guidance at integration.
PIPEDA Cross-Border Transfer Basis: Canadian financial data transferred to the Veldtmann Group EU system for IC reconciliation is governed under PIPEDA Schedule 1 Principle 4.1.3 (accountability for third-party transfers). The legal basis is PIPEDA S.7(3)(c) — necessity for the performance of a contract between Veldtmann Canada Inc. and Veldtmann Group GmbH. This basis is documented in the Data Processing Agreement (DPA-CA-EU-2024-03). IAM dataset separation (ae_finance_ca) is the technical control — it does not itself constitute the legal basis for transfer. A Privacy Impact Assessment was completed per OPC "Accountability in the Cloud" guidance (2023). Cross-purpose use for EU model training is architecturally blocked as shown below.
PIPEDA data architecture — Veldtmann Canada separation
Canadian entity data · separate BigQuery dataset · purpose limitation enforced by IAM · cross-border flow documented · DPA-CA-EU-2024-03
ae_finance_ca — separate BigQuery dataset, Canadian data residency, PIPEDA IAM policy
Cross-purpose blocked — CA data cannot flow into EU model training datasets
Permitted IC reconciliation use — DPA-CA-EU-2024-03 · legal basis PIPEDA S.7(3)(c)
Transfer Pricing · OECD BEPS Action 13
Every IC transaction. Immutable. Queryable. No data engineer required.
OECD BEPS Action 13 requires contemporaneous documentation of intercompany pricing — not just the price, but the basis for it, the agreement it references, and evidence that a human reviewed it. The IC Reconciliation Agent generates this record automatically at every transaction. Tax counsel can query the full documentation trail from BigQuery without involving the data engineering team.
Transfer pricing audit trail — IC Reconciliation Agent → BigQuery → OECD BEPS Action 13
Every IC transaction · immutable record · entity pair · TP rate · agreement reference · HITL approval · queryable by tax counsel
ae_audit.transfer_pricing — immutable BigQuery record per IC transaction
Field
Value (example)
BEPS status
entity_pair
Veldtmann GmbH (DE) → Veldtmann BV (NL)
Action 13 ✓
transaction_id
ic_2026_03_de_nl_00891
Traceable ✓
amount_eur
87400.00
Documented ✓
transfer_price_rate
0.1842 (cost-plus 18.42% markup)
Arm's length ✓
agreement_reference
ICA-2024-07 · Intercompany Services Agreement · signed 2024-07-01
Contemporaneous ✓
anomaly_score
0.89 — flagged by IC Anomaly Detector · above 0.72 threshold
ML evidence
hitl_approval
hitl-2026-03-ic-089 — APPROVED · Group Controller K. Bauer
Human oversight ✓
approver_id
k.bauer@veldtmann-group.example · Finance Controller · DE entity
OECD BEPS Action 13 — tax counsel query · no data engineer required
-- Full TP documentation trail for OECD BEPS Action 13 audit · Veldtmann Group-- FIX: CURRENT_DATE uses explicit timezone 'Europe/Berlin' to avoid UTC date boundary issuesSELECT
tp.entity_pair,
tp.transaction_id,
tp.amount_eur,
tp.transfer_price_rate,
tp.agreement_reference,
tp.anomaly_score,
h.decision AS hitl_decision,
h.approver_id,
h.ts AS decision_timestamp,
s.top_feature_1, s.shap_value_1 -- Why the agent flagged this transactionFROM`ae_audit.transfer_pricing` tp
JOIN`ae_audit.hitl_events` h ON h.hitl_id = tp.hitl_approval
LEFT JOIN`ae_audit.shap_explanations` s ON s.transaction_id = tp.transaction_id
WHERE
tp.entity_pair LIKE'%DE%'-- filter by entity pair for audit scopeANDDATE_TRUNC(
TIMESTAMP_TRUNC(tp.written_at, DAY, 'Europe/Berlin'),
YEAR
) = DATE_TRUNC(CURRENT_DATE('Europe/Berlin'), YEAR)
ORDER BY tp.written_at DESC;