Regulated Banks Embed AI in Engineering Workflows for Compliance

Many banks initially consider AI adoption by debating whether developers should be granted access to large language models and by tracking any efficiency improvements. A more effective strategy, however, treats AI as a component woven through the entire software-engineering workflow, ensuring compliance with technical, architectural, security and regulatory standards. In a regulated financial firm, the software engineering function operates as a tightly coupled ecosystem that includes version control, continuous integration and delivery pipelines, architectural guidelines, secure coding policies, software-development-life-cycle controls, testing suites, vulnerability management, release governance, audit mandates and regulatory duties. Consequently, any AI tool must be incorporated into this ecosystem and governed by its controls rather than existing as a peripheral add-on.

Regulatory Context

The European Union’s AI Act designates certain financial-sector AI applications as high-risk, notably those used to assess an individual’s creditworthiness or to calculate a credit score. Tools aimed at anti-money-laundering (AML) or fraud detection are not automatically placed in the high-risk category; they require a separate risk-assessment to determine the appropriate classification. For development-tooling concerns, the immediate regulatory framework is the Digital Operational Resilience Act (DORA), which has been in force since January 2025. When AI-generated code modifies an information-and-communication-technology (ICT) system, that modification must be processed through the institution’s existing DORA-mandated change-management procedures, encompassing risk evaluation, testing, approval and controlled rollout.

DORA assigns ultimate ICT-risk accountability to the institution’s governing body and obliges the organization to apply risk-based change-management and oversight throughout its ICT environment. This requirement means that code produced by AI is subject to the same stringent controls applied to manually written code, from initial creation through to deployment and ongoing monitoring.

Why Isolated Code Generation Fails

Imagine a programmer tasked with adding a new payment-processing service. The work begins with a brief textual prompt. In the absence of the firm’s internal context, the model may output code that appears technically sound but is ill-suited to the institution’s environment in multiple respects. It might reference a library that is not on the approved dependency list, employ an authentication approach that passes unit tests yet breaches the organization’s secure-coding policy, create a data structure that, under the firm’s data-classification rules, must never be persisted in the selected storage medium, or duplicate functionality that already exists in the enterprise service catalogue.

These shortcomings arise because the model lacks access to essential organisational artefacts such as architecture decision records, API contracts, approved dependency manifests, secure-coding standards, data-classification policies and regulatory constraints. Retrieval-augmented generation (RAG) can supply some of this information, but whenever a definitive answer is available from an internal system or policy engine, deterministic controls must take precedence.

Code produced by AI should be subjected to the same engineering gate-checks as any developer-authored artifact. The initial prompt is first enriched with relevant architecture documentation, API specifications and organisational constraints before being sent to the model. The resulting output then undergoes static analysis using rule sets tailored to the firm’s standards. Every new dependency introduced by the model is verified against the approved registry and scanned for known vulnerabilities. Because certain language models can inadvertently embed credential-like strings, secret-detection scans are also required.

AI-driven generation ought to include test scaffolding alongside the implementation. Before a pull request is opened, the generated solution must be assessed against enterprise-architecture principles, employing policy-as-code tools such as Open Policy Agent. For modifications that affect regulated areas—payments, credit, AML or customer data—additional validations should confirm compliance-related attributes like data residency, consent management, audit-logging and encryption requirements.

Related Post: Fed’s Logan: Rates Must Rise 50 Bps to Tame Inflation

Legacy codebases in large financial firms present both opportunities and hazards for AI-augmented development. These institutions often maintain decades-old applications with detailed business logic that is poorly documented. While AI can speed up modernization, the risk environment differs markedly from that of greenfield projects. Historical financial code frequently embeds correct but domain-specific behaviours, such as rounding rules in payment calculations, fiscal-calendar date handling, or edge-case logic for regulatory reporting, that only seasoned experts can interpret.

Prior to employing AI for modernization, teams should create a characterisation test suite that captures the system’s existing behaviour rather than its intended design. For critical financial calculations, running parallel or shadow processes against representative production data provides the strongest evidence of behavioural parity before decommissioning legacy pathways.

Governance Framework and Evidence Retention

Documentation changes might require peer review and automated checks. Payment processing modifications demand senior engineering, security, and architecture review. The institution must retain sufficient evidence to reconstruct AI usage, including task specifications, context provided to the model, model and version details, generated outputs, validation results, and human approvals, subject to data-retention and privacy rules. The architectural principle treats model output as untrusted input.

Where AI components exist within testing scope, the governance model distinguishes between AI assisting engineers, AI acting in toolchains, and AI in production processes. Applying identical oversight to all AI output creates friction engineers avoid rather than meaningful control. Governance should be proportionate to the AI’s role and risk.

Documentation and Security Challenges

In sizable financial engineering organisations, documentation often suffers from insufficient funding and rapid obsolescence, leading to slower onboarding, prolonged incident resolution and audit difficulties. AI demonstrates particular value in producing documentation with a lower risk of inaccuracy compared with code generation. Suitable targets for AI-assisted authoring include API references, architecture decision records, runbooks, regulatory-mapping documents and explanations of legacy code, provided that human reviewers validate the output. DORA obliges firms to keep ICT risk-management frameworks and related asset, function and dependency inventories up-to-date and accessible to regulators upon request; AI-driven authoring offers a scalable method to satisfy this requirement.

The introduction of AI-generated code alters security-testing responsibilities in two ways: it expands the volume of code that must be examined and may introduce defects that conventional static analysis tools are not tuned to detect. Consequently, static analysis, dynamic testing, dependency scanning, secret detection, container scanning and infrastructure-as-code scanning must all be applied to AI-produced artifacts with the same level of diligence as to human-written code. For applications where AI participates directly in business workflows rather than merely assisting developers, the risk of prompt injection becomes prominent. A prompt-injection attack can cause the model to stray from its intended instructions, potentially emitting unauthorized outputs or triggering unintended actions within autonomous workflows.