# Financial services AI platform architecture, governance and model risk operating model

Version 1.0 · September 12, 2026 · Free public reference architecture

This report defines a proposed AI-enabled financial services platform across customer, product, decisioning, transaction, risk, data, integration, security and governance concerns. It explains where AI and models can assist, what must govern them, and how AutoGovern could support the resulting evidence. It is a design reference, not a claim that AutoGovern is a core banking or policy administration system or that these capabilities have been built.

The reference setting is a US retail and commercial bank with more than $30 billion in assets, consumer and small-business lending, deposits and payments, a fraud and anti-money-laundering programme, a contact centre, an insurance affiliate, and branches in the European Union and United Kingdom. Smaller institutions, credit unions, non-bank lenders, insurers and investment firms can drop modules that do not apply; the supervisory expectations that remain are proportionate to size and model materiality. Capacity figures, service targets and delivery estimates are planning assumptions, not statutory requirements or validated production results.

## 1. What the platform is responsible for

A financial services platform maintains the authoritative record of customers, accounts, products, contracts, decisions and transactions, and supports the work of serving customers safely: onboarding and verification, originating and pricing credit, moving money, detecting fraud and financial crime, underwriting and paying claims, executing and supervising trades, and reporting to the board, auditors and supervisors. Models have made many of these decisions for decades; AI extends the range of decisions and the speed at which they can go wrong.

The proposed platform has three connected responsibilities:

- **System of record and decision engine:** authoritative customer, account and transaction facts, approved policy rules, decision records, notices and ledger entries. The core systems own these transactions.
- **Model and AI services:** bounded scoring, classification, extraction, generation and recommendation using approved data and tools. Output is a proposal until the applicable policy, human review or automated control completes.
- **Governance, model risk and evidence:** inventory, tiering, validation, approvals, third-party decisions, monitoring coverage, incidents and attestations. AutoGovern can be extended in this role.

Customers use digital channels, branches and the contact centre; underwriters, analysts, adjusters, traders and relationship managers use origination, case and servicing workspaces; model owners, validators, compliance, internal audit and the board use governance and reporting views. A validator does not need customer account access to validate a model; an auditor does not need production credentials to inspect evidence.

Success means correct customers get correct decisions with reasons they can act on, money moves reliably, suspicious activity is found, controls demonstrably work, and every material model decision can be reconstructed. A dashboard score alone cannot establish any of these outcomes.

## 2. Functional architecture and business modules

| Module | Core responsibilities and records | Governance, conduct and model-risk requirements |
| --- | --- | --- |
| Customer identity, KYC and KYB | Customer master; identity verification; beneficial ownership; sanctions and PEP screening; risk rating; periodic review | Approved screening engine; analyst decisions on matches and exits; provenance for identity changes; no autonomous onboarding decisions from unvalidated extraction |
| Products, pricing and eligibility | Product catalogue; rate sheets; eligibility rules; risk-based pricing factors; offers | Approved rule and factor versions; fairness review of pricing factors and proxies; disclosure of terms; change control |
| Origination and credit decisioning | Applications; bureau and consumer-report pulls; scoring; policy rules; decisions; counter-offers; exceptions | Independent model validation; permissible purpose; specific adverse-action reasons; human review of near-threshold declines; immutable decision records |
| Servicing and collections | Accounts; payments; hardship; collections strategies; disputes; hardship and vulnerability flags | Conduct duties; fair treatment in collections; complaint routes; human authority for concessions and enforcement actions |
| Payments and transaction processing | Payment initiation; clearing and settlement; ISO 20022 messages; reconciliation; exceptions | Idempotent processing; reconciliation to ledger; segregation from analytical systems; resilience targets by rail |
| Fraud and AML monitoring | Transaction monitoring; alerts; case management; suspicious-activity reporting; sanctions screening | Validation of monitoring models (SR 26-2 scope); threshold governance; typology coverage; analyst decisions; audit trail |
| Insurance underwriting, pricing and claims | Quotes; underwriting; rating; policy administration; claims intake, triage, adjustment and payment | AI Systems Program (NAIC bulletin states); proxy and bias testing (NY DFS, Colorado); actuarial governance (ASOP 56); appeals |
| Trading, execution and surveillance | Order management; algorithmic execution; pre-trade risk controls; surveillance; recordkeeping | SEC Rule 15c3-5 controls and kill switch outside the model; Reg SCI resilience; FINRA supervision; retained AI outputs |
| Advice, wealth and marketing | Suitability; recommendations; campaigns; communications; disclosures | Advisers Act compliance and marketing rules; FCA Consumer Duty; substantiated AI claims; supervision of AI-assisted communications |
| Complaints, notices and rights | Adverse-action and FCRA notices; complaints; disputes; GDPR/CCPA rights requests; regulator correspondence | Deadlines owned by compliance; notices generated from decision records; corrections flow back to models and data |
| Finance, risk and regulatory reporting | Ledger; capital and liquidity; risk aggregation; regulatory returns; board reporting | BCBS 239 lineage and reconciliation; model inventory and attestation reporting; audit-ready evidence |

Each module has a product owner, an accountable business owner, a data steward, a risk record and an acceptance test set. A marketing model can tolerate a different outage and error pattern from a payment fraud model; classify criticality and tier by decision, not by department.

## 3. Complete logical architecture

Read the architecture from users to business transactions to data. External exchange, model execution and governance cross these layers only through authorized interfaces. Public education content occupies a separate, anonymous boundary with no connection to customer records.

```text
CUSTOMERS / APPLICANTS   EMPLOYEES / ANALYSTS      RISK, COMPLIANCE / AUDIT
        |                        |                          |
[Digital channels]    [Origination, servicing,     [Governance & model-risk
 / branch / contact     case workspaces]              workspace]
        |                        |                          |
======== Identity, device, network and application trust boundary ========
[Edge / TLS / WAF / API gateway / rate limits / request correlation]
[Identity provider / MFA / service identity / entitlements & authorization policy]
        |                        |                          |
[Business domain services: customer & KYC, products, origination, decisioning,
 servicing, payments, fraud/AML cases, underwriting & claims, complaints]
        |                        |                          |
[Core banking / policy   [Data platform: lineage,   [Document & case stores]
 admin ledgers]           features, consumer reports]
        |                        |
[Transactional outbox -> event bus -> validated consumers / reconciliation]
        |                        |                          |
[Integration engine]    [Controlled model & AI     [Minimized evidence export]
 bureaus / payment       gateway: registry,                 |
 rails / open banking    approved endpoints,                |
 / market data           policy + scoped retrieval,         |
        |                decision review gate               |
[External partners &    [Decision engine API for            |
 regulators]             approved actions]                  v
[Governance: inventory -> tiering -> validation -> approvals -> monitoring -> attestation]
[Protected audit / security operations / incident & DORA reporting / recovery]
```

The API gateway authenticates requests and limits abuse, but domain services also authorize each record operation using organization, actor, role, customer relationship, product, purpose and entitlement. Never trust a customer or account identifier merely because the channel supplied it.

The decision engine is the single write path for customer-affecting decisions. Models return scores, classifications and reason codes; the engine applies approved policy, records the decision with its inputs and versions, generates notices and routes exceptions to people. A model that can write directly to the ledger or the account has bypassed every control in this report.

Start with modular services whose transaction boundaries are explicit. Split independently scaled model inference, monitoring and analytics from the transaction path. Publish architecture decisions explaining storage boundaries, deployment choices and failure behaviour. See the [Treasury/CRI Financial Services AI Risk Management Framework](https://cyberriskinstitute.org/artificial-intelligence-risk-management/) for a finance-specific control set that maps onto these layers. The diagram's gateway and governance components are proposed design controls; they are not evidence that a vendor already implements them.

## 4. Physical deployment, capacity and trust zones

Use separate production and nonproduction accounts, credentials, keys, networks and storage. Nonproduction starts with synthetic customers and transactions; any authorized use of real data needs its own reviewed controls. An environment label alone is not isolation.

| Zone | Components | Boundary and operational decision |
| --- | --- | --- |
| Public content | Free guides, architecture report, static assets | Anonymous content only; no customer, tenant evidence or production credentials; public cache allowed |
| Edge and access | Load balancer, web application firewall, identity integration, channel front ends | TLS termination with protected downstream transport; session protections; no account numbers or personal data in URLs or public caches |
| Business application | Domain services, decision engine, entitlement enforcement, notice generation | Private connectivity; workload identities; narrow service permissions; monitored egress |
| Transaction data | Core banking and policy administration ledgers, highly available relational clusters, encrypted document storage | No internet database access; tenant and entity isolation where shared; distinct backup and administration roles |
| Data platform | Lineage-tagged warehouse or lakehouse, feature store, consumer-report data domain, monitoring metrics | Permissible-purpose enforcement on consumer-report and special-category data; reconciliation to source; separate analytics credentials |
| Integration | Bureau, payment-rail, open-banking, market-data and KYC adapters; message broker; outbox workers; quarantine and replay | Partner-specific credentials and contracts; schema validation; retry and reconciliation; controlled outbound destinations |
| Model and AI processing | Model registry, approved inference endpoints, scoped retrieval, evaluation runner, prompt/template registry | Isolated egress; no arbitrary provider fallback; approved retention and training behaviour; no direct ledger writes |
| Governance and security | Evidence references, policy and model versions, monitoring aggregates, protected audit, incident tooling | Separate reviewer permissions; minimize customer linkage; restrict exports; customer detail stays in authorized systems |
| Recovery and administration | Backup vault, restore environment, key management, privileged access | Separate administration; time-limited access; tested restore; regional placement follows approved data flows and DORA/outsourcing rules |

Within the selected region, spread critical services and database replicas across independent availability zones. Cross-region recovery is an explicit decision based on payment-rail obligations, data-residency rules, latency and failure analysis. Managed hosting and a cloud provider's certifications do not by themselves prove the deployment is appropriately configured; EU entities must reflect the arrangement in the DORA register of information.

For initial sizing, assume 2 million customers, 5,000 concurrent staff sessions, a 1,500-request-per-second channel peak and a 250-decision-per-second origination peak, with a 300-millisecond budget for a synchronous credit decision including scoring; load-test at twice the estimated peak. These are example inputs, not a benchmark. Measure transaction writes, decision latency, fraud-scoring throughput at payment peaks, bureau-call concurrency and inference concurrency separately. Autoscale stateless readers and workers, bound inference concurrency, and protect ledgers with connection budgets. Shed optional AI and analytics load before payments, fraud controls and customer authentication.

## 5. Data architecture, lineage and record integrity

Every model input must trace to a golden source through documented transformations. Apply the [BCBS 239](https://www.bis.org/publ/bcbs239.htm) principles — accuracy, completeness, timeliness, adaptability and reconciliation — to model and monitoring data, not only to regulatory reports. A feature that cannot be traced cannot be validated, explained in an adverse-action notice or corrected after a dispute.

| Data class | Examples | Design and control requirements |
| --- | --- | --- |
| Customer and account records | Identity, contracts, balances, transactions | System-of-record ownership; entitlement-scoped access; immutable history with corrections as new entries |
| Consumer-report data | Bureau files, scores, tenant and employment reports, AI-derived scores that function as consumer reports | FCRA permissible purpose recorded per pull; accuracy and dispute procedures; adverse-action notice linkage; retention by purpose |
| Special-category and protected-class data | Race, ethnicity, sex, religion, disability, age; proxies such as geography and names | Collected only where lawful (for example HMDA and fair-lending testing); segregated from decision features; access limited to testing and compliance |
| Derived features and scores | Feature store values, model outputs, reason codes | Versioned with lineage; point-in-time correctness for backtesting; no unregistered feature enters a decision model |
| Decision records | Input snapshot, model and policy versions, score, reason codes, outcome, overrides, notices sent | Written once by the decision engine; retained for disputes, complaints, supervisory review and litigation; never regenerated after the fact |
| External and market data | Vendor data, market feeds, sanctions lists | Provenance, licence and quality checks; freshness monitoring; fallback behaviour when stale |
| Monitoring and evidence | Metrics with denominators, validation results, incidents | Freshness and coverage recorded; disconnected feeds display as unknown |

Record the legal basis for processing in the EU and UK, including GDPR Article 22 where a decision is solely automated, and the CJEU's SCHUFA judgment that a score itself can be such a decision. Define retention for inputs, features, outputs, explanations, prompts and monitoring data; delete vendor and cache copies on schedule and verify the outcome. Reconcile derived stores to source on a defined cadence and report unexplained differences as data-quality incidents.

## 6. Integration and reliable exchange

Financial platforms depend on partners whose failures look like model failures: a stale bureau file, a delayed payment message, a changed vendor score. Treat every external interface as a contract with schema validation, idempotency, reconciliation and an owner.

| Interface | Standards and patterns | Governance requirements |
| --- | --- | --- |
| Credit bureaus and consumer-report providers | Batch and real-time pulls; dispute and correction flows | Permissible purpose per pull; accuracy and dispute handling; source identified in FCRA notices; vendor in the third-party register |
| Payment rails and clearing | ISO 20022 messages; instant, ACH, card and wire rails; settlement reconciliation | Idempotent submission; exception queues; resilience targets by rail; fraud scoring within rail time budgets |
| Open banking and account aggregation | Consent-scoped APIs; token lifecycle | Consent evidence; data minimization; revocation propagated to features and models |
| KYC, identity and sanctions vendors | Document verification; screening lists; watchlist updates | List freshness; false-match handling; analyst decisions; vendor change notification |
| Market and reference data | Real-time feeds; end-of-day files | Licence and provenance; gap detection; no model decisions on stale prices |
| Core banking and policy administration | Ledger APIs; policy events | Single write path through the decision engine; reconciliation of decisions to bookings |
| Regulators and supervisors | Regulatory returns; incident notifications; attestations | Authoritative data lineage; DORA incident reporting timelines; retained submissions |

Use a transactional outbox to publish domain events only after the ledger commit, an event bus with validated consumers, and a reconciliation job that compares decisions, notices and bookings. Quarantine malformed or duplicate messages for review rather than dropping them. Every integration appears in the third-party register with contract, criticality, exit plan and monitoring cadence; EU entities record the same arrangements in the DORA register of information.

## 7. End-to-end workflows and AI insertion points

### Application to decision

1. The customer applies through a channel; the platform verifies identity and consent and records the application.
2. The decision engine requests bureau and internal data under a recorded permissible purpose and builds lineage-tagged features.
3. Approved models return scores and reason codes; policy rules apply eligibility, pricing and exception routing. AI can draft a case summary for the underwriter; it does not change the policy.
4. Near-threshold declines, counter-offers and exceptions route to underwriters with the model's reasons, the data used and the applicable policy.
5. The engine records the decision with input snapshot, versions, reason codes, outcome and reviewer, then generates adverse-action, counter-offer and FCRA notices from that record.
6. Disputes and complaints reopen the decision record; corrections flow back to data quality and, where systemic, to model revalidation.

### Fraud alert to case

```text
Payment -> Fraud scoring (within rail time budget): score + explanation
Fraud scoring -> Rules engine: approved thresholds; automated hold only within policy
Rules engine -> Case management: alert with reasons, data and priority
Analyst -> Case management: decision (release, hold, report, exit)
Case management -> Ledger / customer contact: authorized action + customer-safe release path
Case outcomes -> Monitoring: labels for precision/recall, threshold review, model revalidation
```

### Claim intake to settlement

1. The claimant reports through a channel; documents and images are captured under the existing retention schedule.
2. Extraction and classification models propose loss details, coverage matches and fraud indicators with confidence; low confidence routes to a person.
3. Triage rules assign the claim to straight-through, desk or field handling within approved authority limits.
4. The adjuster decides; automated settlement applies only within approved limits and product rules, with an appeal route.
5. The policy administration system records the decision and payment; outcomes feed monitoring for cycle time, leakage, reversals and fairness by segment.

At each insertion point, record the model version, the human authority, the fallback and the monitoring signal. An AI step that cannot answer those four questions is not ready for production.

## 8. Where AI fits: decisions, operations, customers and governance assistance

| Use | AI role | Human authority | Primary regimes |
| --- | --- | --- | --- |
| Credit scoring and pricing | Score, rank, reason codes | Policy rules and underwriters; declines explained | SR 26-2; ECOA/Reg B; FCRA; EU AI Act Annex III 5(b); GDPR Art. 22; FCA Consumer Duty |
| Fraud and AML monitoring | Alert, prioritize, explain | Analysts decide; automated holds within policy | SR 26-2 (BSA/AML models); FFIEC manual; DORA |
| Underwriting, pricing and claims | Classify, triage, propose | Underwriters, actuaries, adjusters | NAIC AIS Program; NY DFS CL 7; Colorado SB 21-169; ASOP 56; EU AI Act 5(c); EIOPA opinion |
| Customer assistants and servicing | Draft, answer, route | Staff for advice, concessions and changes | Consumer Duty; UDAAP; disclosure; recordkeeping |
| Trading and surveillance | Suggest, execute within limits, flag | Pre-trade controls and kill switch outside the model | SEC 15c3-5; Reg SCI; FINRA supervision |
| Advice, wealth and marketing | Personalize, draft | Advisers and compliance; suitability | Advisers Act; marketing rules; Consumer Duty |
| Operations and documents | Extract, reconcile, summarize | Analysts confirm; no autonomous closure | Third-party and operational-risk expectations |
| Governance assistance | Map obligations, draft tests, triage complaints | Control owners and validators decide | FS AI RMF; ISO/IEC 42001; three lines of defence |

Generative and agentic AI are outside the scope of SR 26-2, which covers models including supervised machine learning; they remain inside the institution's obligation to identify, govern and control risk, and inside conduct, third-party, security and, in the EU, AI Act and DORA expectations. Inventory them with the same discipline and validate them against task-specific acceptance criteria rather than treating "out of scope" as "ungoverned".

## 9. AI technical architecture and action controls

Maintain a release manifest per model and AI service linking intended use, tier, provider or endpoint, model version, prompt or template digest, retrieval corpus version, tool schemas, evaluation set, validation conclusion, approval conditions and expiry. Provider aliases that can change behaviour require change detection and a re-evaluation policy. Test fallback providers separately; never route customer data to an unapproved endpoint to maintain availability.

The controlled execution path is:

1. Authenticate the human or workload. Resolve organization, entity, customer and product context on the server.
2. Check the approved release, tier, role, purpose, entitlements and policy version. Reject unapproved combinations before retrieval.
3. Retrieve only authorized, lineage-tagged data. Apply permissible-purpose filtering for consumer-report data before search and recheck entitlements when fetching results.
4. Treat documents, transaction narratives, customer messages and model responses as untrusted content. They cannot change authorization, select a new recipient, alter a limit or expand tool permissions.
5. Send the approved minimum input to the approved endpoint. Bound context size, time, spend and concurrency. Keep account numbers and personal data out of general traces, analytics and crash reports.
6. Validate output structure, ranges and permitted actions. Reason codes and citations assist review but do not prove correctness; present uncertainty and distinguish source facts from generated inference.
7. Require the specified human review. For customer-affecting actions, bind approval to the exact action, argument digest, customer, product, source version and expiry.
8. Recheck authorization and source version at execution; use an idempotency key. Execute through the decision engine or core banking API, record the actual result, and reconcile uncertain outcomes before retrying.
9. Store minimized decision evidence and protected provenance. Apply the retention schedule to inputs, outputs, prompts, caches, embeddings and provider copies.

Do not let a language model construct arbitrary SQL, choose the entity scope, acquire credentials, move money or call unrestricted network destinations. Pre-trade risk limits, payment limits and fraud holds live outside the model and cannot be relaxed by it. Stop controls disable the relevant release, tools and queued actions while leaving the ordinary process available; test that revocation reaches workers and cached approvals.

## 10. Model risk management: inventory, tiering, validation and effective challenge

Model risk is the potential for adverse consequences from decisions based on incorrect or misused model outputs. [SR 26-2](https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm) (April 2026, superseding SR 11-7 for the Federal Reserve, OCC and FDIC) sets the US banking baseline for institutions over $30 billion: a complete inventory, risk-based tiering, sound development and implementation, independent validation with effective challenge, ongoing monitoring and governance. Supervised machine learning is in scope; generative and agentic AI are not, pending further interagency work.

| Element | Design requirement | Regimes that expect it |
| --- | --- | --- |
| Inventory | Every model and AI system with purpose, owner, type, version, tier, dependencies and status | SR 26-2; PRA SS1/23 (identification and tiering); OSFI E-23 (effective 1 May 2027); MAS AI MRM |
| Materiality tiering | Impact if wrong × exposure; tier drives validation depth, frequency and approval level | SR 26-2; SS1/23; E-23; MAS; EU AI Act risk classification |
| Development and documentation | Purpose, method, assumptions, data, limitations, implementation tests | SR 26-2; ASOP 56 for actuarial models; AI Act Art. 9–11 for high-risk |
| Independent validation | Conceptual soundness, outcomes analysis and backtesting, ongoing-monitoring design, by people independent of development with authority to reject | SR 26-2; SS1/23 principle 4; E-23; MAS |
| Effective challenge | Critical review with competence, influence and incentives; findings tracked to closure | SR 26-2; SS1/23 |
| Vendor models | Same expectations; compensate for limited transparency with outcomes analysis, benchmarking and sensitivity testing | SR 26-2; interagency third-party guidance; DORA |
| Ongoing monitoring | Performance, stability, limits and revalidation triggers with denominators and freshness | SR 26-2; SS1/23 principle 5; MAS |
| Governance and reporting | Policies, committee approvals, aggregate model-risk reporting to the board, attestation | SR 26-2; OCC heightened standards; NAIC AIS Program; Colorado Reg 10-1-1 attestation |

Tier by two questions: how bad is it if the model is wrong (customer harm, financial loss, regulatory breach, market impact) and how much is exposed (decisions per period, value, customer reach). High-tier models get full independent validation before use, annual or event-driven revalidation and committee approval; low-tier models get proportionate review. Record the rationale; a tier that cannot be explained will be challenged in examination.

Revalidation triggers include material model or data changes, performance or fairness breaches, portfolio or economic shifts, provider changes, incidents and regulatory change. Retain rejected and conditional validation conclusions; a validation function that only records approvals lacks credibility. Where the institution has no independent validation capacity for a tier, that gap is itself a finding to report.

## 11. Fair lending, consumer protection and explainability

| Obligation | Design requirement | Evidence |
| --- | --- | --- |
| ECOA / Regulation B §1002.9 — specific principal reasons for adverse action | Reason codes generated from the actual decision record; accurate, specific and consistent with model behaviour; counter-offers covered | Reason-code verification and stability tests; sample notices; dispute outcomes |
| FCRA §1681m and §1681e(b) — notices and accuracy when consumer reports or scores are used | Source identified in notices; consumer rights included; accuracy and dispute procedures; AI-derived scores treated as consumer reports where they function as such | Notice samples; dispute handling records; data-quality evidence |
| Disparate treatment and disparate impact | No prohibited-basis inputs or proxies used to discriminate; impact tested across bases and segments | Fair-lending testing results with the jurisdiction relied on; proxy analysis; remediation records |
| UDAAP / FTC Act §5 | No deceptive AI claims, dark patterns or unfair steering; marketing substantiated | Conduct review; marketing claim substantiation; complaint monitoring |
| FCA Consumer Duty (PRIN 2A) | Assess and prevent foreseeable harm before deployment; deliver good outcomes on products, price and value, understanding and support | Foreseeable-harm assessment; outcome monitoring; vulnerable-customer handling |
| GDPR Article 22 (EU/UK) | Solely automated decisions with legal or similarly significant effect need a lawful basis, information, human intervention and contestability; a credit score can itself be such a decision (SCHUFA) | Lawful-basis record; notices; human-review route |
| EU AI Act Annex III 5(b) and 5(c) | Credit scoring (fraud-detection carve-out) and life/health insurance pricing are high-risk; obligations apply from 2 December 2027 after the Digital Omnibus (Regulation (EU) 2026/1744) deferral; deployers complete an Article 27 fundamental rights impact assessment | Risk management, data governance, technical documentation, logging, human oversight and FRIA records |
| Insurance: NAIC Model Bulletin, NY DFS Circular Letter 7, Colorado SB 21-169 | Written AI Systems Program; quantitative proxy and bias testing of external data and models in underwriting and pricing; governance framework and attestation in Colorado | AIS Program document; proxy-testing results; attestations |

On the July 2026 change: the CFPB's Regulation B rule removed the disparate-impact effects test under ECOA with effect from 21 July 2026, and the rule is contested. Disparate impact remains actionable under the Fair Housing Act, by the Department of Justice, under many state laws and under the NY DFS and Colorado insurance regimes. The design decision is therefore unchanged: test for disparate impact, document the method and the jurisdiction each test supports, and keep disparate-treatment prohibitions absolute. The CFPB's 2022 and 2023 adverse-action circulars were rescinded in May 2025; the statutory duty to give specific reasons was not.

Explainability is a system property, not a model feature. The notice process, the reason-code generator, the decision record and the dispute route must all agree. Test that similar applicants receive consistent reasons, that reasons change when the driving factors change, and that a person can explain the notice to the customer.

## 12. Third-party, ICT and operational resilience

Model risk and operational risk are not transferred to a vendor. The 2023 interagency guidance on third-party relationships expects a lifecycle — planning, due diligence, contracting, ongoing monitoring and termination — proportionate to criticality. For EU financial entities, [DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) (applying since 17 January 2025) requires an ICT risk-management framework with the management body accountable, a register of information covering all ICT third-party arrangements including AI and cloud providers, contractual requirements on audit, incident notification, sub-outsourcing and exit, classification and reporting of major ICT-related incidents, and digital operational-resilience testing including threat-led penetration testing for significant entities. Critical third-party providers are overseen directly by the European Supervisory Authorities.

Design requirements:

- **Register every AI-relevant third party** — model vendors, inference providers, data vendors, cloud and platform services — with function, criticality, data exchanged, contract terms, sub-outsourcing, concentration and exit plan. One register serves the interagency lifecycle and the DORA register of information.
- **Validate vendor models** with the transparency available; where documentation is thin, compensate with your own outcomes analysis and record residual uncertainty. Contract for change notification, testing access and evidence.
- **Manage concentration.** A single inference provider behind credit, fraud and servicing is a resilience finding. Record alternatives and test exit and substitution for critical services.
- **Set resilience targets by process** (payments, authentication, fraud controls, decisioning) consistent with SR 20-24 and the institution's impact tolerances, and test recovery with the providers involved.
- **Contract for incidents.** Providers must notify within the timelines the institution needs to meet its own reporting clocks.

## 13. Monitoring: model performance, drift, fairness, conduct and AI risk

| Domain | Signals | Design requirement |
| --- | --- | --- |
| Outcome performance | Discrimination, calibration, loss and acceptance rates by segment; backtests | Limits set at validation; denominators and freshness recorded; breaches trigger revalidation |
| Drift and stability | Population and feature drift (for example PSI, KS), score distribution shifts, missing-data rates | Thresholds with owners; investigate causes before retraining |
| Fairness | Outcome and error rates by protected class and proxy; reason-code distribution | Cadence by tier; jurisdiction noted; remediation tracked |
| Explanations and notices | Reason-code stability, notice generation failures, dispute reversals | Any reversal pattern is a model and data-quality signal |
| Customer outcomes and conduct | Complaints, hardship, vulnerability, marketing claim substantiation, suitability reversals | Consumer Duty and UDAAP metrics reviewed by conduct owners |
| Operations and security | Latency, availability, provider changes, injection and leakage attempts, unauthorized tool calls | Runtime alerts to security operations; provider-change detection |
| Trading and market conduct | Limit breaches, execution quality, surveillance alert quality | Independent controls; kill-switch drills |
| Coverage | Which models, segments and channels are actually observed and when the last observation arrived | Disconnected feeds display as unknown, never as green |

Distinguish alerts from confirmed findings and from verified customer harm. Track trends with denominators. Review model-risk aggregates — models by tier, validation currency, open findings, breaches — at committee and board level as SR 26-2 and the NAIC bulletin expect.

## 14. Incident response, regulatory reporting and recovery

Classify incidents by type: model incidents (wrong decisions, breached limits, unexplained drift), data incidents (corrupted or stale inputs, unauthorized use of consumer-report data), ICT incidents (outages, security events), conduct incidents (misleading communications, unsuitable advice) and third-party incidents. Each has an owner, a containment plan, a reporting decision and a remediation path.

Reporting clocks start at classification, not at discovery of root cause. EU entities report major ICT-related incidents under DORA with an initial notification within hours of classification, followed by intermediate and final reports; the incident classification criteria and templates are set by the regulatory technical standards. US institutions face computer-security incident notification rules, suspicious-activity reporting where applicable, and supervisory engagement; broker-dealers must be able to halt order flow and record the event under SEC Rule 15c3-5 and, where applicable, Reg SCI. Compliance owns the decision and the clock; the platform supplies the evidence.

Model incidents require customer remediation: identify affected decisions from the decision records, correct notices, re-decision where policy requires, and record redress. Recovery includes rolling back to the last approved version or to a manual process (a staffed underwriting or claims queue), verifying that cached approvals and queued actions are cleared, and re-running the affected monitoring before restart. Rehearse the fallback with the people who would run it; a documented plan that has never been exercised is a risk, not a control.

## 15. Risk register and acceptance evidence

| Risk | Preventive/detective controls | Evidence needed before affected use |
| --- | --- | --- |
| Unlawful discrimination through inputs or proxies | Feature review, fairness testing, proxy analysis, governance approval | Fair-lending results by jurisdiction; remediation records |
| Inaccurate or missing adverse-action reasons | Reason codes from decision records, verification tests, notice QA | Reason-code stability tests; sample notices; dispute outcomes |
| Consumer-report data used without permissible purpose | Purpose recorded per pull; data-domain segregation; access controls | Access tests; purpose audit; FCRA notice checks |
| Unvalidated or stale high-tier model in production | Inventory, tiering, validation gate, revalidation triggers | Current validation conclusion; committee approval |
| Vendor model or data change without notice | Contract terms, change detection, benchmark monitoring | Change-notification evidence; benchmark tests |
| Model drift after portfolio or economic shift | Drift and outcome monitoring with thresholds | Fresh metrics with denominators; revalidation decisions |
| Prompt injection or unsafe tool call by an assistant | Untrusted-content boundaries, tool allowlist, bound approval | Adversarial tests; replay rejection |
| Money moved or limits changed by a model | Decision engine as sole write path; limits outside the model | Negative tests across APIs and tools |
| Concentration in one AI or cloud provider | Register, alternatives, tested exit plan | Exit and substitution drills |
| Major ICT incident reported late | Classification criteria, on-call ownership, provider notification terms | Incident drills with clock measurement |
| Misleading AI claims or unsuitable advice | Conduct review, substantiation, supervision | Marketing review records; suitability tests |
| Audit loss or alteration | Protected logging, separate permissions, integrity checks | Tamper and reconstruction tests |
| Unrecoverable outage of decisioning or payments | Backups, manual fallback, restore rehearsals | Measured restore and reconciliation results |
| Incomplete deletion or retention | Data-copy inventory, legal holds, provider deletion process | Verified deletion across caches, embeddings, backups and vendors |
| Silent monitoring gap | Coverage inventory and freshness checks | Disconnected-feed simulation and unknown-status handling |

Record severity, likelihood, exposure, treatment owner, due date, residual risk, decision authority and next review for each risk. A passed control test reduces a specific uncertainty; it does not make the platform compliant. Retain failed tests and restricted-use decisions, not only favourable evidence.

Before production, require: current independent validation, fair-lending and explainability evidence, third-party decisions, lineage and permissible-purpose review, notice and dispute process tests, access and isolation verification, adversarial and resilience tests, monitoring coverage, incident and fallback rehearsal, and the tier-appropriate approvals. Require evidence tied to the exact release and scope. Unresolved severe customer-harm risks cannot be hidden by averaging scores.

## 16. How AutoGovern fits and how much must change

AutoGovern's current finance capabilities are public education (this report, the [finance AI guide](https://autogovern.io/finance-ai-governance) and the [vision board](https://autogovern.io/finance-ai-vision)), a regulation catalogue with the finance instruments cited here, regulatory-horizon dates, three finance policy templates, three browser-based Workbench tools (Model Risk Management, Fair Lending, FS AI RMF and Resilience) and the organization-scoped Finance Governance workspace for metadata records. Their presence does not establish integration with decisioning systems, validation of any model, or regulatory readiness.

| Capability | Current state | Proposed change and magnitude |
| --- | --- | --- |
| Public finance architecture and education | This report, guide and vision board | Small content and navigation extension; no customer data or schema required |
| Regulation catalogue, horizon and policy templates | Eleven finance instruments, dated events and three templates | Extend to markets and APAC instruments and add a FRIA template; small to medium |
| Workbench finance tools | Client-side tiering, adverse-action notice and four-fifths calculators, representative FS AI RMF checklist, DORA register | Server-side persistence in the workspace, the full control-objective set and crosswalks; medium |
| Finance governance records | Metadata workspace: use cases, models, validations, fair-lending reviews, third parties, data flows, risks, controls, cases, releases, monitoring plans, observations, changes and domain reviews | Structured attestation packs, committee workflows and evidence acceptance; medium |
| Evidence from decisioning, validation and monitoring systems | References entered by users; no live connector | Tenant-scoped adapters, ingestion authentication, minimization, reconciliation and provenance; large |
| Runtime monitoring | Workspace does not observe live models | Versioned metric ingestion, coverage and freshness, thresholds, review queues and alerts; large |
| Decision enforcement | Workspace review is not deployment authorization | Approval binding, controlled execution through decision-engine APIs and revocation; very large and safety-critical |
| Customer-data-bearing processing | Not established as an approved environment for customer data | Operational, security and legal readiness, contracts, tested isolation, retention and incident capability; large |
| Core banking or policy administration | Not implemented | A separate major programme; buy and integrate before building |

The recommended product direction is a governance companion to established core, decisioning and monitoring systems. AutoGovern receives minimized metadata and evidence references under reviewed permissions, organizes decisions and exposes missing evidence; the transaction systems remain responsible for enforcement. Even metadata-only integration needs a privacy review because identifiers and small aggregates can reveal customer information.

A proposed governance model adds: FinanceUseCase, ModelRecord, ValidationRun, FairLendingReview, ThirdPartyService, DataFlow, RiskItem, ControlTest, ApprovedRelease, MonitoringPlan, MetricObservation, IncidentReference, ChangeRecord and ReviewDecision. Connect each record to organization, owner, version, evidence reference and lifecycle status. Approval binds a digest of the reviewed release and becomes stale when material inputs change. Never infer production authorization from a generic "reviewed" badge.

## 17. Delivery roadmap, effort and decision points

These are rough planning estimates for a governance companion, not quotations or a delivery commitment. Assume two application engineers, one integration engineer, part-time design, QA and security, and sustained model-risk, compliance and legal reviewers, plus a partner sandbox and timely contracting. Workstreams overlap; calendar durations must not be added as though all work is sequential. Vendor access, evidence quality and organizational readiness can dominate the schedule.

| Stage | Indicative effort | Deliverable and exit condition |
| --- | --- | --- |
| Public reference and education | Small, days | Anonymous architecture, guide, vision board and navigation; this content release |
| Discovery and partner design | 2–4 weeks | One decisioning or monitoring system, scoped use case, contract and data flow, interface specification |
| Structured model-risk extension | 4–8 weeks | Versioned use cases, validation runs, fair-lending reviews and release-specific decisions with isolation tests |
| Synthetic integration and monitoring | 6–10 weeks | Authenticated metadata connector, reconciled events and visible coverage; no customer data yet |
| Customer-data-bearing pilot readiness | 6–12 additional weeks depending on gaps | Approved environment and contracts, validated models, trained users and tested response and fallback |
| Controlled production expansion | 4–8 weeks after pilot evidence | Verified monitoring, independent acceptance and support handover for the approved scope |

A practical initial planning envelope is roughly 4–7 months for one controlled integration pilot if access and readiness work proceed in parallel. Re-estimate after discovery. Budget separately for partner API access, bureau and data licences, cloud and recovery capacity, inference, independent validation and security testing, training, migration and ongoing support. Use actual vendor quotes and staffing rates.

## 18. How to apply this architecture and decisions still required

1. **Choose a bounded decision.** Start with one product and channel, such as a credit model's reason-code process or a servicing assistant's bounded intents. Identify the customer decision and the forbidden actions.
2. **Draw the current system and data flow.** Name the actual core system, decision engine, bureau connections, identity provider, inference endpoints, data platform and recipients. Replace every generic box in the diagram.
3. **Tier and assign owners.** Complete the inventory and decision table with people, delegates, contracts and jurisdiction-specific reviews.
4. **Define evidence before building.** Specify validation acceptance limits, fairness tests, reason-code checks, access tests, monitoring coverage, fallback and release conditions.
5. **Build in a synthetic sandbox.** Validate entitlements, permissible-purpose filtering, duplicate events, stale approvals, unsafe prompts and provider outages.
6. **Review a controlled release.** Record the exact version, scope, safeguards, expiry and who can stop it. Conduct the separate model-risk, compliance and conduct approvals.
7. **Monitor and reassess.** Review outcomes, fairness, complaints and missing telemetry; reopen decisions after material changes or incidents. Expand only within evidenced scope.

Use the [free finance AI governance guide](https://autogovern.io/finance-ai-governance) for step-by-step how-tos and the [starter templates](https://autogovern.io/download/finance-ai-starter-kit) for initial records. In AutoGovern, open Solutions → Finance Governance → choose an organization → create a use case, then use Model inventory, Validations, Fair lending & consumer, Third parties & ICT, Data flows, Risk register, Controls & evidence, Cases, Releases, Monitoring plans and Review & export. These paths manage metadata today; they do not validate, deploy or monitor a model.

Before implementation procurement or committee approval, produce a site-specific pack: context, container and deployment diagrams; interface contracts and message examples; decision workflow and state diagrams; data lineage and permissible-purpose mappings; threat model and model-risk assessment; entitlements matrix; third-party and DORA register; validation protocol; release manifest; monitoring and incident runbooks; recovery plan; and operating responsibilities.

Open decisions include the actual core, decisioning and monitoring systems; entity types and jurisdictions in scope; products, channels and customer segments; bureau and data-vendor contracts; approved inference providers and hosting; achievable latency and recovery targets; evidence retention; validation capacity; and acceptable residual customer-harm and model risk. Record each decision with its owner and deadline. This report defines the complete reference structure; those site-specific decisions are required to turn it into an executable production design.