Banks can use AI in software development without compromising security or compliance when tools operate in approved environments, access to code and data is controlled, and every change passes standard verification procedures. The essential safeguards include data classification, model usage policies, access auditing, security testing, and human accountability for production code. Deploying an AI coding assistant alone does not ensure compliance with a bank’s requirements.
In practice, the goal should be to move from individual developer experiments to a managed AI-assisted software development model. AI supports the preparation of changes without gaining uncontrolled system access or taking over responsibility for production deployments.
Where Can AI Deliver Real Efficiency Gains in Banking Software Development?
AI in software development goes beyond code generation. It can support multiple stages of the Software Development Life Cycle (SDLC), from requirements analysis to incident investigation. However, the business value only materializes when time saved at one stage does not create additional defects or verification costs later in the process.
| SDLC Stage | AI Application | Required Control |
|---|---|---|
| Requirements analysis | User stories, acceptance criteria, gap identification | Verification of completeness and regulatory requirements |
| Development | Code suggestions, refactoring, boilerplate generation | Code review, testing, security analysis |
| Legacy modernization | Explaining dependencies and documenting existing code | Repository access controls |
| QA | Test scenarios, unit tests, synthetic data | Review of assertions and edge-case coverage |
| Code review | Identifying potential defects and inconsistencies | Independent assessment by an authorized reviewer |
| Documentation | API, component, and data flow documentation | Accuracy and confidentiality checks |
| Maintenance | Log analysis and diagnostic suggestions | Removal or masking of sensitive information |
Which Tasks Should Banks Automate First?
The best starting point is a task with limited risk, an easily verifiable output, and no need for production data access. Examples include generating unit tests with synthetic data, preparing public API documentation, or refactoring an isolated component.
These tasks make it possible to compare execution time before and after AI adoption. They also avoid the need to expose entire repositories or grant tools access to production environments.
It is important to distinguish faster coding from faster end-to-end delivery. If code is produced more quickly but still waits weeks for integration, testing, and approval, the actual business impact remains limited. Reducing time-to-market in digital banking therefore requires optimizing the entire delivery workflow, not just the development stage.
What Risks Does AI Introduce into Banking Software Development?
An AI coding assistant can increase development speed, but it also creates new information flows and potential failure points. Banks should assess these risks as systematically as those associated with other development tools.
1. Leakage of Data and Confidential Source Code
A prompt may contain a code fragment, customer information, a session identifier, or a secret accidentally copied from a configuration file. If this information reaches an unapproved service, the bank may lose control over how it is processed. Data classification policies, context restrictions, and secret detection controls are essential.
2. Vulnerabilities in AI-Generated Code
A model may suggest code that works functionally but lacks appropriate authorization, input validation, or protection against attacks. Successful compilation and a passing test do not prove that the code is secure. Security scanning and code review remain necessary.
3. Incorrect Business Logic
AI may not understand exceptions in banking processes, specific accounting rules, or transaction status handling. It may also suggest API methods that do not exist. Verification by an engineer familiar with the banking domain remains essential.
4. Software Supply Chain Risks
An assistant may recommend a dependency that is not included in the approved library catalog or suggest a package with a misleading name. Teams should use approved package repositories, dependency scanning, and Software Bill of Materials policies where required.
5. Prompt Injection
Instructions embedded in comments, documentation, repository files, or tool outputs may attempt to redirect an agent’s behavior. These materials must be treated as untrusted data, not as a source of authority. Restrictions must be enforced outside the model.
6. Excessive Agent Permissions
An agent with access to terminals, repositories, and infrastructure may perform actions beyond the developer’s original intent. Combining the ability to modify code, approve changes, and deploy them without independent oversight is particularly dangerous.
7. Lack of Auditability
If a bank cannot establish which tool was used, who prepared a change, what checks were performed, and who approved it, incident investigation and audit preparation become more difficult and expensive. The development process must provide appropriate traceability.
Why Must AI-Generated Code Still Undergo Code Review?
AI-generated code should meet the same standards as code written by humans. Verification must cover functional correctness, security, architectural consistency, readability, and the impact on dependent systems.
AI may help reviewers identify potential issues, but it should not be the only mechanism approving its own output. Accountability for the change must remain with an authorized team.
What Data and Source Code Can Be Shared with AI Tools?
Secure AI adoption starts with information classification. Banks must determine not only which models can be used, but also what categories of information may be shared with them, by whom, and for what purpose.
| Category | Example | Recommended Rule |
|---|---|---|
| Public | Public API documentation | Permitted in approved tools |
| Internal | Architecture documentation | Subject to information classification policies |
| Confidential | Internal source code | Only within approved environments and defined scope |
| Highly restricted | Customer data, secrets, authentication credentials | Do not share unless the use case and safeguards have been separately authorized |
AI Usage Permission Matrix
| Status | Example Applications | Condition |
|---|---|---|
| Permitted | Public API documentation, testing with synthetic data | Approved tool and environment |
| Conditionally permitted | Internal code analysis, refactoring, analysis of sanitized logs | Risk, data scope, and permissions assessment |
| Prohibited without separate authorization | Secrets, production customer data, autonomous production operations | Separate approval, valid justification, and appropriate safeguards |
This is a reference model. The final classification and permitted use cases must follow the individual bank’s policies.
Can a Bank’s Source Code Be Sent to an External AI Model?
This may be acceptable under specific conditions, but it requires an assessment of code classification, the provider, contractual terms, data location and retention, access controls, and further processing arrangements. A provider’s assurance that customer data is not used for model training does not resolve every security concern.
It also matters whether a tool sends only selected code, automatically retrieves context from an entire repository, indexes files, or stores interaction history. These capabilities can significantly change the risk profile.
How to Design a Secure AI-Assisted Development Architecture
AI access in a bank should be governed through both organizational and technical controls. Individual developers should not decide independently which repositories, secrets, or environments are accessible to a selected model.
A practical architecture separates the user interface, access control layer, AI model, and standard software delivery process.
Secure AI Usage in Banking SDLC
↓
Controlled AI Access
↓
Approved AI Model
↓
Pull Request + Code Review
↓
CI/CD + Security Gates
↓
Controlled Deployment
AI proposes a change. It does not replace access controls, testing, or deployment authorization.
SaaS, Private Deployment, or a Locally Hosted Model?
| Deployment Model | Advantages | Limitations |
|---|---|---|
| SaaS | Faster rollout, vendor-managed updates, IDE integrations | Vendor dependency, need to assess data processing and contractual terms |
| Private deployment | Greater control over configuration and environment integration | Higher operational complexity, maintenance costs, and infrastructure dependencies |
| Locally hosted model | Potential to limit external data transfers | Own infrastructure, updates, monitoring, and security responsibility |
No deployment model is automatically the most secure. A local model with excessive permissions and weak monitoring may create greater risk than a properly configured external service. The decision should be based on data classification, required functionality, cost, and operational requirements.
How to Secure AI Coding Assistants and Development Agents
A conventional coding assistant typically suggests code fragments. A development agent may go further by analyzing repositories, modifying files, running tests, executing commands, and preparing pull requests. The greater its autonomy, the more important it becomes to restrict permissions.
Least Privilege and Separation of Duties
Banks should separate repository read access from permission to edit code, execute commands, and approve changes. An agent generating unit tests does not need access to production databases or infrastructure administrator privileges.
Permissions should be limited to the specific task, repository, and environment. Short-lived credentials, isolated execution environments, and controls preventing access to secrets are recommended.
Controlling Tool Execution
The ability to execute a system command should not imply permission to perform arbitrary operations. Allowlisted actions, network access controls, and restrictions on infrastructure-modifying operations are necessary.
An agent should not independently approve its own pull request, disable security gates, or deploy code to production without the required authorization. Its activities should leave an appropriate audit trail.
Example: Defining the Limits of Agent Autonomy
An agent may analyze an isolated module, prepare tests, and create a pull request. A developer verifies the tests, a reviewer approves the change, and the pipeline runs mandatory controls. Only then can the code enter the deployment process. None of these stages should be skipped simply because AI prepared the change.
It is also important to distinguish development agents from solutions operating directly within banking processes. Integrating AI agents with core banking and transaction systems requires separate operational controls because such systems may directly affect customer data and transactions.
How to Integrate AI with Secure SDLC and DevSecOps
AI should not create a parallel, less controlled software delivery path. AI-generated code must pass through the same process as other changes, from review and testing to security scanning and deployment approval.
Which Controls Should Remain Mandatory?
- Code reviews performed by authorized personnel.
- Unit and integration testing.
- Static Application Security Testing (SAST).
- Dependency scanning and software supply chain controls.
- Secret scanning.
- Code quality checks and repository policies.
- Security testing proportionate to the risk of each change.
- Required approvals before deployment.
Automation can accelerate these controls, but it must not reduce their effectiveness. In particular, AI cannot be treated as proof that its own code is correct.
How Should AI-Generated Changes Be Governed?
Development policies should specify when and how the use of AI tools is recorded. Code provenance may provide useful audit context, but the most important elements remain change ownership, control results, approvals, and deployment history.
If a model suggests a modification to fee calculation logic, the fact that AI generated the change has no bearing on business approval. The team must verify requirements, edge cases, and consequences for dependent processes.
Can AI Support Test Automation?
Yes. AI can suggest test scenarios, generate synthetic data, identify missing edge cases, and assist with defect analysis. However, not every generated test provides value.
A model may produce a test that always passes without verifying meaningful system behavior. QA engineers must therefore evaluate assertions, coverage of critical scenarios, and the independence of tests from the implementation.
In practice, banks should measure the time required to prepare a valuable regression suite and the number of defects identified before production, rather than simply counting generated tests.
Which Compliance Requirements Apply to AI in Banking Software Development?
AI adoption by banking IT teams should be assessed against regulatory obligations, vendor risk, and internal policies. A vendor’s security statement does not automatically mean that the bank’s particular use of the service meets all applicable requirements.
DORA – ICT Risk Management
The Digital Operational Resilience Act (DORA) is relevant to information and communication technology risk management, operational resilience, and applicable relationships with ICT service providers. Introducing an AI tool may require an assessment of vendor dependencies, business continuity, monitoring capabilities, and incident response arrangements.
The exact obligations depend on the nature of the service and how it is used. A bank should not assume that a tool is DORA-compliant solely because its provider makes such a claim.
GDPR – Personal Data Protection
If personal data is sent to an AI model, the bank must determine the purpose and legal basis for processing, the scope of information shared, the parties’ roles, retention arrangements, and any international data transfers. For development tools, avoiding production data and using synthetic datasets is a practical way to reduce risk.
Anonymization or pseudonymization should not be claimed without verifying whether individuals can still be identified in the relevant context.
EU AI Act – Assessing the Specific Use Case
The EU AI Act establishes obligations that depend, among other factors, on an organization’s role, the intended purpose of the AI system, and its classification. Not every AI programming tool used by a bank automatically qualifies as a high-risk AI system.
Assessment should consider the specific use case, tool functionality, and the legal provisions and application dates currently in force. Before publishing policies or deploying a solution, banks should verify the current legal position with their compliance teams.
Internal Banking Policies
Even when a particular use case does not trigger specific AI Act obligations, the bank’s policies on information classification, access management, third-party services, software security, and change management still apply.
The practical rule is simple: approval should follow a documented assessment of the tool’s functionality, data, permissions, and risks, rather than its popularity.
Primary regulatory sources:
DORA,
GDPR, and
the EU AI Act.
How to Implement AI in a Bank’s Development Team: Step by Step
Secure AI implementation should be treated as a change to the engineering process. Purchasing licenses and making them available to all developers is not enough. Banks need a plan covering risk, configuration, measurement, and gradual expansion.
Step 1 – Identify Potential Use Cases
Select tasks for which a baseline and measurable outcome can be established. Unit testing, documentation, and analysis of isolated modules are good candidates. Initially, avoid scenarios requiring production data or broad infrastructure access.
Step 2 – Assess Risks and Vendors
Determine what data the tool processes, where it is stored, how long it is retained, and what administrative capabilities are available. Review contractual terms, access management, auditability, identity integration, and service exit arrangements.
Step 3 – Establish Policies and Technical Configuration
Define permitted repositories, data categories, tools, and permission levels. Introduce safeguards against sharing secrets and establish mandatory code review and CI/CD controls.
Step 4 – Run a Pilot with a Selected Team
Launch a limited use case and compare results with a baseline period or an appropriately selected comparison group. Monitor task completion time, code quality, rework, tool usage, and any incidents.
Step 5 – Evaluate Results
Measure not only the time needed to generate code but also the effort required for review, corrections, and testing. If AI accelerates initial development but significantly increases review time, the actual benefit may be smaller than expected.
Step 6 – Scale in a Controlled Manner
Once pilot results have been approved, AI usage can expand to additional teams. Every new use case should undergo a data, permissions, and risk assessment. Policies must evolve as tool capabilities change.
Pilot Completion Criteria
- Approved scope of data and repositories has been confirmed.
- No unapproved deviations from mandatory controls remain.
- Comparable measurements of task time, quality, and cost are available.
- Tool limitations and response procedures are documented.
- The scaling decision is based on outcomes, not the number of active users.
Example: Using AI to Prepare Regression Tests for Legacy Code
Consider a hypothetical banking team maintaining an older backend module. A planned refactoring initiative aims to simplify the architecture, but documentation is incomplete and existing tests do not cover every important scenario.
The team wants to use AI to analyze selected components and propose regression tests. It does not intend to share customer data or grant the agent production access.
A Controlled Implementation Workflow
- The bank approves the tool and defines which code can be analyzed.
- Developers provide selected components in a controlled environment.
- AI proposes test scenarios, including edge cases and invalid inputs.
- Engineers verify assertions, expected outcomes, and business logic coverage.
- Validated tests enter the repository through a pull request.
- The CI/CD pipeline runs standard tests and security checks.
- The team compares test preparation time, rework, and defect detection quality against the baseline.
The potential benefit to validate is a reduction in the time required to prepare meaningful tests and greater confidence before refactoring. However, no specific savings should be assumed without measurement.
This scenario is illustrative and does not describe a verified Edge One Solutions implementation.
How to Measure the ROI and Productivity Impact of AI in Software Development
The number of generated lines of code is not a reliable productivity metric. More code may also mean more defects, duplication, and maintenance costs. CTOs should evaluate the efficiency of the entire change delivery process.
| KPI | What It Measures | What to Watch For |
|---|---|---|
| Lead time for changes | Time required to deliver changes | Dependencies unrelated to AI |
| Pull request cycle time | Review and integration speed | PR size and complexity |
| Test preparation time | QA efficiency | Assertion quality and coverage |
| Defect escape rate | Defects discovered after deployment | Changes in scope and risk |
| Rework rate | Effort required to correct changes | AI-generated code verification costs |
| Security findings | Identified security issues | Severity, not just quantity |
| Cost per completed task | Total task delivery cost | Licenses, tokens, reviews, and corrections |
| Developer experience | Tool usability | Subjectivity of feedback |
How to Calculate the Actual Business Impact
Compare similar tasks completed by teams with comparable experience. Measurements should cover solution preparation, review, testing, rework, and deployment.
The total cost of AI includes licenses or model consumption, integration, infrastructure, training, oversight, maintenance, and error handling. Only after accounting for these costs can a bank determine whether the tool reduces the cost of delivering a task.
Quality and security must also be evaluated. Faster development is not a success if production defects or the workload of the security team increase at the same time.
Common Mistakes When Implementing AI in Banking IT Teams
1. Providing AI Access Without a Data Policy
This can result in uncontrolled sharing of code and internal information. The solution is an approved tool catalog, data classification, and clear model usage policies.
2. Assuming AI-Generated Code Is Secure
Models can introduce vulnerabilities and incorrect business logic. All changes must undergo the required testing, code reviews, and security controls.
3. Granting Agents Excessive Permissions
An agent with repository, terminal, and production access can increase the impact of an incident. Apply least privilege, environment isolation, and independent approval of actions.
4. Skipping Vendor Assessment
Failure to assess data retention, contractual terms, and technology dependencies makes ICT risk management more difficult. A service and configuration assessment should precede deployment.
5. Measuring Success by Lines of Code Generated
This metric ignores quality, rework costs, and business value. Better indicators include task completion time, change stability, and total delivery cost.
6. Failing to Update Policies
AI tools rapidly gain new capabilities, including terminal access, repository operations, and integrations. Banks should periodically review permissions, configurations, and permitted use cases.
When Should a Bank Involve a Technology Partner?
Implementing AI in software development requires an understanding of application architecture, engineering practices, test automation, and security requirements. An external partner can help when internal teams have limited capacity to prepare a pilot, build integrations, or modernize delivery processes.
Edge One Solutions supports organizations in the banking and financial services sector with software development, system integration, and technology modernization.
Potential areas of collaboration in AI-assisted development include:
- Analyzing development processes and identifying AI use cases with measurable value.
- Designing secure integrations between AI tools and development workflows.
- Supporting legacy code analysis and modernization.
- Automating testing and improving DevSecOps practices.
- Building backend services and internal tools.
- Strengthening engineering teams and transferring knowledge.
The bank must retain control over its repositories, access policies, change approval process, and documentation. The objective should be lasting improvements in engineering efficiency, not dependence on another tool.
Conclusion: AI Can Accelerate Development, but Banks Must Retain Control Over Their Code
AI in banking software development can support requirements analysis, code generation, testing, documentation, and system maintenance. However, this does not mean AI tools should have unrestricted access to repositories, customer data, or production environments.
A secure implementation model relies on approved tools, information classification, least-privilege access, mandatory Secure SDLC controls, and a measurable pilot.
The most important decision for a CTO is not whether to give every developer access to AI. It is deciding which tasks are worth improving, which risks the bank can control, and how to demonstrate real business value.
AI-assisted Software Development
Want to Accelerate Software Development with AI Without Compromising Security?
Combine AI capabilities with a secure SDLC, access controls, and automated testing. Edge One Solutions can support your team with software development, AI tool integration, and improvements to engineering workflows.
FAQ – AI in Banking Software Development
Can Banks Use AI Coding Assistants Securely?
Yes, provided the bank approves the tool, defines which data and repositories can be accessed, and implements appropriate controls. Important safeguards include identity management, restrictions on shared context, vendor assessment, and auditing. AI-assisted code must undergo standard code reviews and security testing. Purchasing an enterprise license does not automatically mean the solution meets the bank’s requirements.
Can Developers Send a Bank’s Source Code to AI Models?
It depends on code classification, the bank’s policies, and the model’s terms of use. Before permitting this, the bank should assess the provider, processing arrangements, data retention, infrastructure location, and the scope of automatically retrieved context. Confidential code should only be shared within approved environments and defined limits. A promise not to train models on customer data does not eliminate every risk.
How Can Banks Protect Customer Data When Using AI in Development?
The safest starting point is to use synthetic data and avoid sending production customer information to development tools. Banks should apply information classification, data minimization, access controls, and secret detection. If a specific use case requires personal data processing, the legal basis, purpose, provider, and safeguards must be assessed. Data masking should also be checked for re-identification risks.
Does AI-Generated Code Require Additional Security Testing?
AI-generated code must pass at least the same controls as human-written code, including code review, functional testing, SAST, dependency scanning, and secret detection. Additional testing may be justified by the nature of the change, especially when it affects authorization, transaction processing, or sensitive information. The level of verification should be based on risk rather than code origin alone.
How Does DORA Affect the Use of AI in Banking IT Teams?
DORA is relevant to ICT risk management, operational resilience, and applicable relationships with technology providers. Using an AI coding assistant may require an assessment of vendor risk, access controls, business continuity, and incident response. The specific obligations depend on the tool’s role within the bank’s environment. Vendor security statements do not replace the institution’s own compliance assessment.
Does the EU AI Act Apply to AI Programming Tools Used by Banks?
The EU AI Act may apply to AI tools used by banks, but the scope of obligations depends on the specific use case, the organization’s role, and the applicable provisions. Using a coding assistant within a financial institution does not automatically make it a high-risk AI system. Banks should assess the use case, check the current application dates of relevant provisions, and consider internal and sector-specific requirements.
Can AI Automatically Create and Approve Pull Requests?
AI can prepare changes and create pull requests within its assigned permissions. However, it should not independently approve its own code, bypass security controls, or deploy changes to production without the required authorization. Read, edit, approval, and deployment permissions should be separated. Every change should have an accountable owner and a traceable history of testing and approval.
How Can AI Be Used to Automate Testing in Banking?
AI can propose unit tests, regression scenarios, synthetic data, and edge cases. It can also help analyze test results and identify areas requiring additional coverage. Engineers must still verify assertions and ensure tests reflect business requirements. Effectiveness should be measured by the time needed to prepare valuable tests and the number of defects detected, not simply by the number of generated test cases.
What Is the Difference Between SaaS AI Tools and Locally Hosted Models?
SaaS tools usually enable faster adoption and provide vendor-managed updates, but they require an assessment of external data processing and service dependencies. Locally hosted models can limit external information flows but increase responsibility for infrastructure, updates, and monitoring. Neither model automatically guarantees security. The decision should account for data classification, permissions, cost, and the bank’s operational capabilities.
How Should Banks Measure the ROI of AI in Software Development?
ROI should be assessed by comparing the cost and quality of similar tasks before and after AI adoption. Useful metrics include lead time, pull request cycle time, test preparation time, rework rate, and defect rates. Costs should include licenses, model usage, infrastructure, reviews, and corrections. The number of generated lines of code is not a sufficient measure of productivity or business value.
