Financial Services Sector Guidance

Executive summary

Financial-services AI is not merely a technology issue. It can affect the balance sheet, customer access, financial crime exposure, market integrity, regulatory records, operational resilience, and confidence in critical financial services. SEC-038 translates GAISSF™ into financial-services implementation practices for organizations operating under adversarial pressure, real-time transaction conditions, interconnected dependencies, and strict expectations for accountability and evidence.

The guide is intended for boards, risk committees, CISOs, security architects, model risk teams, AI governance leaders, compliance and financial-crime functions, data and technology leaders, internal audit, and accountable business owners. It is implementation guidance rather than a new conformance standard. Conformance decisions must be made against the verified GAISSF normative catalogue and applicable obligations.

Successful implementation means that the organization can identify material AI use, assign accountable owners, constrain authority, validate outcomes, detect degradation, preserve reconstructable evidence, respond to incidents, protect customers, and demonstrate tested resilience. The accompanying workbook converts these expectations into a control-by-control implementation and evidence tracker.

Document control and use

Authority and hierarchy

Apply the following hierarchy: applicable law and binding regulatory or supervisory direction; verified GAISSF normative requirements; approved GAISSF interpretations; this sector guide; and organizational procedures. Where requirements conflict, obtain qualified legal, regulatory, standards, and risk advice.

International applicability

SEC-038 is designed for international use. Its source register includes global standards and selected EU financial-services and horizontal regulation because they provide useful implementation context. The register is illustrative, not exhaustive. Each entity must determine its applicable jurisdictions, legal entities, regulators, products, and supervisory expectations.

Demonstrating use of this guide

• Record consideration of relevant guidance in risk assessments, design reviews, validation plans, procurement decisions, and governance submissions.
• Use the checklist to evidence systematic review and identify non-applicable items with rationale.
• Document deviations and exceptions, accountable approval, compensating controls, residual risk, and expiry or reassessment date.
• Retain evidence proportionate to scale and consequence, not merely the technical complexity of the model.

Normative language and cross-reference status

Unless a statement quotes a verified GAISSF requirement, terms such as should, may, recommended, and consider are guidance. This edition maps implementation areas to the authoritative GAISSF v1.0 control baseline in GAISSF-NOR-001. Mappings indicate implementation relationships and do not convert sector guidance into new normative requirements.

Executive implementation principles

Accountability remains with the financial entity. Outsourcing a model, platform, data source, or operational process does not transfer accountability for customer outcomes, financial crime controls, prudential risk, market integrity, resilience, or compliance.

Risk-tiering reflects financial consequence. Classification must consider direct loss, restitution, conduct harm, financial crime exposure, regulatory action, capital and liquidity effects, market disruption, and correlated or systemic propagation.

Security and model risk operate as one assurance system. Threat modelling, model validation, secure engineering, data governance, operational resilience, change control, monitoring, and incident response must exchange evidence and escalation signals.

Human oversight must be operationally effective. A nominal reviewer is not effective oversight. The reviewer must have sufficient information, competence, time, authority, and a technically available intervention path before irreversible action.

Evidence must be decision-relevant and tiered. Institutions should distinguish T1 Primary Verified evidence, T2 Secondary Verified evidence, T3 Simulation or Test evidence, and T4 Anecdotal or Unverified evidence. Material assurance conclusions should not rely solely on T4 provider claims or policy statements.

Customer-impact controls are first-class. Controls must address discriminatory outcomes, unsuitable recommendations, wrongful denial, opaque adverse decisions, manipulation, exclusion, inaccessible challenge, and delayed remediation.

Proportionality does not remove minimum safeguards. Smaller institutions may combine governance forums and evidence processes, but critical actions, customer-impact decisions, financial crime controls, and critical-function dependencies still require explicit accountability and tested safeguards.

Translating AI risk to financial impact

Boards and executive committees should evaluate AI risk through the financial and governance consequences that can follow from control failure. The following examples are illustrative and do not replace entity-specific quantification.

Financial-services AI risk landscape

Severity labels describe an indicative sector baseline. Organizations must reassess severity using their own materiality, legal, prudential, customer, and systemic context. A High risk may become Critical where the system affects mandatory explainability, regulatory reporting, critical functions, vulnerable customers, or irreversible action.

Use-case materiality and classification

A use case should receive higher-tier treatment where one or more materiality factors are significant. The factors are not additive scoring rules unless the entity defines and validates a scoring method. A single critical factor may justify Critical classification.

Representative use cases

Evidence hierarchy and quality

Evidence tiers describe provenance; evidence quality describes sufficiency for the stated conclusion. A T1 record can still be weak if incomplete or out of scope, while a well-designed T3 exercise can be strong evidence of tested preparedness but not of sustained production effectiveness.

Implementation lifecycle

1. Initiation and approval

• Define purpose, prohibited outcomes, affected customers, legal entities, critical functions, and intended authority.
• Assign accountable executive, business owner, model owner, data owner, security owner, control owners, independent validators, and incident escalation authority.
• Ensure accountable executives and control owners have role-appropriate AI literacy.
• Classify inherent risk before production data access, procurement commitment, or pilot authority.

2. Data acquisition and preparation

• Establish provenance, legal basis, licensing, purpose, representativeness, quality, lineage, retention, and access controls.
• Test for sensitive-data leakage, prohibited attributes and proxies, temporal contamination, label error, manipulation, and economic-regime bias.
• Design and test privacy rights, minimisation, deletion, and correction processes where applicable.

3. Design and development

• Apply secure architecture, threat modelling, segregation, secrets management, dependency governance, and abuse-case testing.
• Constrain tools, identities, actions, transaction values, destinations, code execution, network access, retrieval, and delegation.
• Design reconstructable records and effective human intervention points before implementation.

4. Independent validation and challenge

• Independent validation requires sufficient organisational, reporting, intellectual, and access independence to reach and escalate an adverse conclusion.
• Validate conceptual soundness, data suitability, implementation correctness, calibration, discrimination, robustness, explainability, stress performance, and limitations.
• Record unresolved findings, conditions, compensating controls, expiry dates, and residual-risk acceptance.

5. Deployment and change control

• Use controlled release, versioning, approvals, phased rollout where appropriate, rollback, and predefined stop conditions.
• Govern changes to model, prompt, retrieval corpus, agent, tool, provider, feature, threshold, policy, data, hosting, and identity.
• Prevent unmanaged employee use and shadow AI in sensitive workflows.

6. Production monitoring

• Monitor technical, customer, fairness, fraud, financial-crime, security, operational, data, economic-regime, and concentration indicators.
• Tie every material threshold to ownership, action, severity, escalation, customer protection, and notification analysis.
• Review complaints, losses, appeals, overrides, near misses, and incidents as model-risk signals.

7. Incident response and remediation

• Use the SEC-038 incident taxonomy and integrate cyber, fraud, privacy, conduct, financial-crime, resilience, reporting, and crisis processes.
• Preserve model, data, prompt, policy, agent, tool, approval, identity, and transaction evidence.
• Assess customer remediation, reversal, suspension, disclosure, notification, and systemic propagation.

8. Retirement and exit

• Define archival, retention, access revocation, data return/deletion, customer-impact review, dependency removal, and provider exit.
• Test portability and continuity before a critical dependency becomes irreversible.
• Continue monitoring delayed complaints, claims, corrections, and reporting consequences.

9. Post-implementation review

• At 6-12 months or earlier when triggered, review control effectiveness, assumptions, realised outcomes, incidents, exceptions, concentration, and unintended effects.
• Document lessons learned, required control changes, risk re-approval, and improvement ownership.

Illustrative monitoring metrics

Metric selection must reflect the use case, class balance, decision cost, applicable law, and the risk of aggregate measures concealing subgroup or tail harm. The examples below are not mandatory metrics or universal acceptance thresholds.

AI incident classification

An incident may receive multiple classifications. Severity should consider financial loss, customer harm, legal and regulatory impact, control compromise, duration, scale, recoverability, and systemic propagation.

Terminology for human accountability

Sector interpretations and illustrative evidence

Specific implementation patterns

Fraud, AML, sanctions and KYC

• Separate model detection performance from alert handling, case management, list management, and investigator behaviour; each can fail independently.
• Estimate false negatives using confirmed events, look-backs, post-event investigations, emerging typologies, adversarial simulations, and external intelligence, not only labelled historical data.
• Protect features, lists, rules, thresholds, investigator notes, feedback channels, and case dispositions from unauthorized change and poisoning.
• Maintain reason codes and case reconstruction sufficient for internal challenge and applicable reporting; do not assume one explanation technique satisfies every legal context.
• Monitor de-risking, freezing, closure, escalation, and override outcomes for disproportionate customer harm and control evasion.

Credit, pricing, underwriting and collections

• Define permissible features and proxies, reason codes, fairness metrics, affordability logic, approval thresholds, exception routes, and adverse-decision processes before release.
• Validate across protected and vulnerable groups, thin-file populations, products, channels, geographies, and economic scenarios.
• Monitor calibration and realised outcomes through rate, employment, inflation, property, catastrophe, and liquidity changes.
• Test whether human overrides reduce harm or introduce inconsistent, undocumented, or discriminatory outcomes.

Trading, investment and market activity

• Set instrument, venue, order type, size, price, loss, position, exposure, latency, and market-condition limits outside the AI model.
• Implement deterministic kill switches and manual control that remain available during model, data, network, venue, or identity degradation.
• Assess manipulation, correlated strategy, information leakage, suitability, conflict, and hallucinated-market-fact risk.
• Reconstruct strategy/model version, market data, prompts, orders, cancellations, overrides, surveillance alerts, and approvals.

Generative AI and customer interactions

• Use approved grounding sources, explicit uncertainty handling, prohibited-content rules, escalation paths, and authenticated account-action boundaries.
• Protect retrieval stores, prompts, memory, tools, and conversation logs from injection, poisoning, disclosure, and cross-customer leakage.
• Test vulnerable-customer, accessibility, language, bereavement, scam, fraud, distress, complaint, and dispute scenarios.
• Disclosure that AI is used may support transparency but does not substitute for accuracy, safety, suitability, and redress.

Agentic and multi-agent workflows

• Assign each agent a unique workload identity and verify agent-to-agent authentication, delegation, provenance, and revocation across the complete chain.
• Apply both per-step and cumulative limits for transaction value, tool calls, execution time, data access, destinations, code changes, and retries; downstream agents must not reset upstream limits.
• Separate planning, approval, and execution agents where feasible; require independent authorization for irreversible, privileged, or high-value actions.
• Prevent orphaned execution by using leases, heartbeats, bounded retries, idempotency controls, compensating actions, and deterministic completion states.
• Use a circuit breaker independent of the agent stack that can halt anomalous behaviour using deterministic rules and can be tested without model cooperation.
• Log the entire plan and action chain: agent identity, delegation, prompt/context, policy decision, tool parameters, credential context, result, exception, approval, and rollback.
• Test cascading misinformation, conflicting agent goals, recursive delegation, shared-memory poisoning, partial completion, and control failure under degraded dependencies.

AI-assisted model validation

• Prevent circular validation in which the validator uses the same model family, training data, benchmark, or provider assumptions without disclosure and compensating challenge.
• Require human validators to understand generated analyses, reproduce material tests, and own conclusions rather than accepting automated reports.
• Record validator tool versions, prompts, source data, code, assumptions, exceptions, and independent challenge.

Software engineering and cyber operations

• Constrain copilots and agents from committing, deploying, rotating credentials, changing firewall or identity policy, or containing assets without approved authority.
• Require code review, testing, dependency controls, secret scanning, and environment segregation for AI-generated changes.
• Preserve incident evidence and prevent attacker-controlled content from directly invoking response tools.

Implementation roadmap

Organizations with limited AI deployment may combine phases and governance forums, but should not remove critical safeguards for high-consequence use. GAISSF mappings have been completed against the authoritative 59-control baseline. Organizations must still determine applicability through their Statement of Applicability and documented scope and risk analysis.

Common failure patterns

• Treating AI governance as a policy exercise without technical enforcement, deployment inventory, and operating evidence.
• Validating predictive accuracy while omitting adversarial, resilience, fairness, customer-outcome, fraud-adaptation, and extreme-event testing.
• Using provider documentation as a substitute for entity-specific threat assessment, validation, and exit testing.
• Placing human review after the transaction, communication, or customer impact has become irreversible.
• Failing to govern prompts, retrieval corpora, tools, agent identities, thresholds, features, and provider updates as controlled changes.
• Monitoring averages that conceal severe subgroup, product, channel, region, or tail-event failures.
• Keeping kill switches, circuit breakers, or fallback procedures that are untested, inaccessible, or too slow.
• Recording only the final output and losing the model version, input context, policy state, delegation chain, tool actions, and approvals.
• Treating complaints, fraud losses, near misses, overrides, and operational incidents as separate from model monitoring.
• Ignoring concentration and correlated failure across shared models, cloud, identity, market data, payment rails, and data providers.
• Assuming a low-volume system is low risk when it can move funds, alter rights, create regulatory records, or affect a critical function.

Notably Absent

• No claim that SEC-038 establishes legal or regulatory compliance.
• No universal list of applicable regulators, laws, supervisory expectations, or reporting thresholds.
• No presumption that explainability alone makes a model safe, fair, lawful, or suitable.
• No presumption that provider assurance replaces the financial entity’s own assessment, validation, and monitoring.
• No blanket prohibition or endorsement of generative, predictive, or agentic AI.
• No fixed materiality or residual-risk threshold applicable to every financial entity.
• No final GAISSF clause or control mapping until the released normative catalogue is independently verified.
• No assertion that human review is effective without evidence of timing, competence, information, authority, and intervention capability.
• No assumption that successful model validation eliminates cyber, fraud, conduct, privacy, resilience, or systemic risk.
• No representation that this guide supersedes law, regulation, supervisory direction, contract, or the GAISSF normative standard.
• No claim that the source register is exhaustive or that every listed source applies to every entity or jurisdiction.

GAISSF cross-reference register

The mappings below were completed against GAISSF-NOR-001 v1.0, the authoritative 59-control baseline. A mapping means that the referenced GAISSF control materially supports the implementation area; it does not imply that the control alone satisfies all financial-sector obligations or that every referenced control is applicable to every organization.

External source register

Bibliographic metadata and official locations were checked for this pre-release build. Applicability, interpretation, article-level mapping, and legal conclusions remain subject to qualified review. The register is illustrative and not exhaustive.

Versioning, maintenance and feedback

• Patch releases correct non-substantive errors, broken links, formatting, or clarifications that do not change implementation meaning.
• Minor releases add substantive guidance, examples, mappings, or appendices without breaking the core structure.
• Major releases introduce breaking changes to scope, control interpretation, structure, or conformance relationship.
• This guide should be reviewed at least annually and earlier when GAISSF, material financial-services AI regulation, supervisory expectations, threat conditions, or industry practice change materially.
• Public feedback and clarification requests should be submitted through the ODA3 Institute website or the designated GitHub issue process once publication channels are activated. Placeholder URLs must not be published as live CTAs.

Publication verification and gate status

Change log