The financial services AI platform.
Governed from the first decision.

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

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.

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 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.

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 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.

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.

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

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

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 (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.

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

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 (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

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

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 and the vision board), 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.

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.

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 for step-by-step how-tos and the starter templates 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.