Notifications
Clear all
Topic starter
18/08/2026 2:29 pm
TL;DR: AI-assisted development can speed software delivery in financial services, but Sonar’s analysis argues that continuous code verification is now essential to keep quality, security, maintainability, and supply chain risk visible across the SDLC, while aligning with FFIEC Development, Acquisition, and Maintenance expectations. The governance problem is not code generation itself, but whether institutions can still prove review, testing, and remediation are happening before release.
NHIMG editorial — based on content published by Sonar: AI-assisted development in financial services needs continuous code verification
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
Questions worth separating out
Q: How should financial institutions verify AI-assisted code before release?
A: They should place automated verification in the development path, not after it.
Q: Why does AI make software supply chain risk harder to control?
A: AI increases the amount of code produced, which reduces the time available for review and makes malicious or unauthorized changes harder to spot.
Q: What do identity teams get wrong about automated verification?
A: They often treat automation as a way to remove human review entirely, when the real value is selective escalation.
Practitioner guidance
- Embed code verification into every change path Run static analysis, security checks, and quality gates in IDEs, pull requests, branches, and CI/CD so findings appear before merge decisions are made.
- Track software supply chain evidence alongside source review Require dependency analysis, component visibility, and SBOM-style records for third-party and open-source code so inherited risk is visible during release approval.
- Scan for secrets and privileged automation in repositories Treat API keys, certificates, tokens, and embedded access logic in code as identity exposures and block promotion until they are removed or governed.
What's in the full article
Sonar's full article covers the operational detail this post intentionally leaves for the source:
- Specific mappings between FFIEC Development, Acquisition, and Maintenance sections and code-verification capabilities
- Detailed examples of quality gates, remediation reporting, and issue-tracking evidence used in financial services pipelines
- Repository, pull request, and CI/CD workflow controls that show how continuous analysis supports audit readiness
- Open-source and third-party component checks, including software composition visibility and licence-policy review
👉 Read Sonar's analysis of AI-assisted development and FFIEC code verification →
AI-assisted development in financial services: is verification keeping up?
Explore further
18/08/2026 3:16 pm
AI-assisted development does not weaken governance by itself, but it does compress the time available to prove control. Financial institutions are not just reviewing more code, they are reviewing more machine-assisted change that may arrive faster than manual assurance can keep up. That changes the control objective from approving code to continuously evidencing secure development. The right framing is operational governance, not developer productivity. Practitioners should treat verification latency as a control risk.
A question worth separating out:
Q: Who is accountable when AI-generated code creates a control failure?
A: Accountability stays with the organisation that ships the software. Development, security, risk, and compliance teams all need defined ownership for review standards, exception handling, and remediation follow-through. Frameworks such as FFIEC DAM and NIST CSF expect control operation to be demonstrable, not implied by tooling.
👉 Read our full editorial: AI-assisted development in financial services needs continuous code verification
