Generative AI is not only changing how banks write software or interact with customers. It is also changing the volume and character of many files moving through financial systems, often faster than the controls surrounding those systems were designed to handle.
Banks process a vast range of documents through payments, onboarding, lending, compliance and fraud workflows. Wire instructions, customer records, identity documents, invoices, risk reports and anti-money laundering files may pass through several platforms and applications before informing or influencing an action, transaction or decision.
The rapid adoption of generative AI means many of these files are now created automatically, so the problem for quality assurance teams is not simply whether an individual file contains malware.
It is whether the bank’s complete document-processing chain has been tested against machine-generated volumes, unfamiliar file structures and convincing synthetic content.
Dean Papa, an executive at OPSWAT based in North Carolina, argued that many existing controls retain a basic assumption that may no longer hold.
“Most file security controls in use today rest on an inherited assumption: that files are created by people,” he said.
That assumption has shaped more than security monitoring. It has also influenced the test data, traffic patterns and performance thresholds used to validate financial applications.
If file creation was previously limited by the number of employees, customers or counterparties producing documents, historical volumes offered a reasonable basis for capacity planning.
Generative AI breaks that relationship. A model can create thousands of plausible documents without the time or labour previously required. Testing based mainly on historic production traffic may therefore underestimate both the volume and variability that banks’ systems will encounter.
Testing the entire file journey
The risk begins when a document enters the organisation, but it does not end there. A file uploaded through a customer portal may pass through malware scanning, identity verification, document classification, case management and archiving systems. Information extracted from it could then be consumed by an AML engine, a credit model or an employee-facing AI assistant.
QA teams must establish whether controls remain effective at every handoff. A document rejected at the perimeter should not remain accessible through a downstream repository.
A sanitised file should retain the legitimate information required by the business. Metadata, permissions and audit records should survive processing intact.
That requires more than conventional functional testing. Banks need adversarial test sets containing legitimate, manipulated and fully synthetic documents, including files that appear structurally valid and carry no previously identified malicious signature.
“Most file security controls in use today rest on an inherited assumption: that files are created by people.”
– Dean Papa
The objective is not solely to determine whether a security product detects a bad file. Testing should establish how the entire financial workflow responds when a document is blocked, quarantined, rebuilt, misclassified or allowed through.
A control can perform its immediate function correctly while still causing a wider operational failure. A genuine payment instruction incorrectly rejected by an overly aggressive filter could delay a transaction.
A customer document stripped of essential information could interrupt onboarding. A file cleared by one system could subsequently behave differently when opened or processed by another. These are end-to-end quality problems as much as security problems.
Volume changes the risk
The increase in machine-generated content also creates a performance-testing challenge. File inspection, classification and sanitisation consume computing capacity. If inbound volumes rise sharply, banks need to know whether those services will slow down, create queues or become unavailable.
Testing should reproduce bursts rather than relying only on steady average traffic. A flood of automatically generated files could affect customer portals, payments processing and compliance operations even if none of the individual documents successfully compromises a system.
The failure behaviour matters. If a scanning service reaches capacity, does the surrounding application stop accepting files, hold them safely for later processing or allow them to proceed without inspection?
A security dependency that fails open could expose the bank, while one that fails closed could halt a critical business process.
Those choices need to be understood, tested and connected to the institution’s operational-resilience plans. Recovery testing should also establish whether delayed files are processed in the correct order, whether duplicate actions are avoided and whether audit trails remain complete after services return.
False positives become a business issue
Greater file diversity will also make false-positive and false-negative testing more important. Blocking every unfamiliar document is unlikely to be operationally sustainable, but relying on known signatures may miss novel content.
QA teams therefore need measurable acceptance criteria. Detection rates alone do not show whether a control is suitable for production.
Banks should examine how often genuine documents are interrupted, how quickly exceptions are resolved and whether human reviewers receive enough information to make a reliable decision.
The test data must reflect the institution’s actual business. A system validated mainly with standard office documents may perform differently when confronted with scanned identity papers, multilingual statements, complex spreadsheets, digitally signed contracts or files created by specialist financial software.
Synthetic data can help teams expand this coverage without exposing real customer information.
However, it also introduces another testing question: whether generated samples accurately represent the formats, anomalies and edge cases found in production. Large quantities of artificial data do not automatically produce a realistic test set.
Continuous validation
AI-generated files will not remain consistent. Models, prompts and attack techniques will change, while business teams will continue adopting new tools that create and exchange documents through different channels.
That weakens the value of a one-off certification exercise. Banks will need continuous regression testing to establish whether controls that performed effectively against one generation of synthetic files continue to work against the next.
Production monitoring should feed back into that process. Newly observed file types, misclassifications and processing failures can become regression cases, while changes to gateways, APIs, storage platforms and document-analysis models should trigger targeted retesting.
The evidence produced by these tests will be important for regulated institutions. Banks must be able to demonstrate not simply that a security control exists, but that it works at realistic volumes, across relevant entry points and without creating unacceptable disruption to critical services.
The central QA question is therefore whether banks are testing against the environment they now face or the human-paced environment for which their controls were originally designed. As Papa put it: “File risk is financial risk.”
The arrival of machine-generated documents does not make established testing disciplines obsolete. It makes performance, integration, adversarial, resilience and regression testing more closely connected. Banks that treat the issue purely as perimeter security may miss failures emerging deeper inside the transaction and decision-making chain.
NEXT MONTH
REGISTER TODAY – SIMPLY CLICK HERE
Why not become a QA Financial subscriber?
It’s entirely FREE
* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *
REGULATION & COMPLIANCE
Looking for more news on regulations and compliance requirements driving developments in software quality engineering at financial firms? Visit our dedicated Regulation & Compliance page here.
READ MORE
- Goldman puts AI coding to the test
- How to test AI models that banks do not control
- OpenAI, Filigran and SunTec: the latest vendor and product news
- Sygnum: Testing AI is ‘a measurement problem’
- Banks’ ‘code for all’ push raises testing risks
WATCH NOW
QA FINANCIAL PODCASTS
CLICK HERE TO LISTEN TO OUR EXCLUSIVE CONVERSATIONS
