AI for Compliance Evidence in Banking

In a bank, operating a control and proving you operated it are two different pieces of work, and only one of them is staffed. The maker checker on a payment happens because the system forces it. The artefact showing it happened, for a named period, over a population somebody can vouch for, gets built later by a person who was not in the room.

That gap is where examination pain comes from. The control was fine. The evidence was reconstructed under deadline from screenshots, ticket exports and somebody's memory of how the process ran two quarters ago. Agents are useful here for an unglamorous reason: most evidence work is retrieval, reconciliation and formatting against a standard already written down.

The three lines want different things from the same artefact

The same extract serves the control owner attesting that the control operated, the second line testing whether it operated as designed, and internal audit asking whether either of them would have noticed if it had not. Each pulls it separately, at a different time, to a different standard. A useful deployment does not automate three pipelines. It produces one extract with its provenance attached and lets each line use it for their own purpose.

First line attestation that runs on evidence rather than recollection

Quarterly control attestation is where the rot starts. A control owner receives a list of control descriptions, some written four years ago, and confirms they operated effectively. Nobody checks the description still matches the procedure, and the attestation carries no data behind it.

An agent can invert that. For each control in the owner's inventory it retrieves what happened in the period: how many times the control ran against its stated frequency, how many items it covered, how many exceptions it raised and what became of them. The owner attests against a populated view, and the interesting output is the mismatch. A monthly control showing nine executions in twelve months. A control whose description names a decommissioned report. A control whose stated population does not reconcile to the system it claims to cover. Those are findings a bank would rather self identify, at attestation time rather than two years later in somebody else's workpaper.

Control testing and the question that actually gets asked

Second line and internal audit testing both start from a sample, and the first challenge a tester faces is rarely about the sample. It is about the population. How do you know the extract was complete, that nothing was filtered out, that the as-of date matches the period under review.

Population completeness

This is where an agent earns its place. Every extract it produces is logged with the source system, the exact query, the parameters, the execution time, the row count and an independent reconciliation where one exists, such as tying the count to a control total. Completeness is evidenced at the moment of extraction rather than argued afterwards, which removes the most common reason a workpaper gets reopened.

Selection and reperformance

Selection follows the methodology your standards already define, with the method, the seed and the excluded items recorded so it can be reproduced exactly. For each selected item the agent reperforms the documented attributes: was the approval captured before the action, by somebody with the authority in force on that date, with the supporting reference present and matching. The workpaper carries the attribute, the evidence relied on and the observed result for each item.

What it does not produce is a conclusion. Whether a failed attribute is a control failure, an isolated error or a documentation gap is a judgement with consequences for the issue log, and it belongs to the tester.

Access reviews and the closure loop nobody checks

Entitlement recertification fails often, and the reason is not effort. Reviewers are shown cryptic entitlement names they cannot interpret, so they approve everything, and the review generates a clean artefact that proves nothing.

An agent improves the review before it improves the evidence. It translates each entitlement into a plain description of what the holder can do, reconciles the user list against the HR feed so leavers and movers surface rather than hide, marks every entitlement changed since the last cycle so the reviewer reads twenty lines instead of six hundred, identifies service and shared accounts with no owner, and applies your segregation of duties rules.

Then it closes the loop, which is the part that fails audit. A revocation decided in the review is worthless if the entitlement is still there next quarter. The agent takes the next extract, checks every revocation took effect within the window your policy allows, and reports the ones that did not. That report is evidence of an operating control. A signed review with no verified removal is evidence of an exercise.

KYC and AML remediation evidence at programme level

A remediation or look back programme produces two things: remediated files, and proof the remediation met the standard in force. Teams staff the first and improvise the second, which is why these programmes run long and get reopened.

An agent works the programme layer rather than the individual file. It reconciles the in scope population against source systems and evidences how scope was derived, because the population definition is the first thing challenged. It tracks each file through its states, including the awkward ones that distort reporting: customer unreachable, restricted, exited, out of scope on review. It applies your quality checklist consistently, which matters most where work is split across offshore teams and vendors who drift apart over months. And it reports pass rates with the failed checks named rather than aggregated into a percentage.

Escalation stays human. Whether a file is acceptable, whether a relationship should exit, whether activity warrants a report: none of that moves.

Model risk documentation, including the agent's own

Model risk teams lose time to document logistics rather than analysis. An agent can reconcile the model inventory against what is actually running, flag models past their validation or annual review date, check that development documentation, validation reports, approval records and monitoring results exist for each entry, and draft the periodic monitoring pack so the validator reviews evidence rather than assembles it. It also catches the two silent failures: a model in production that is not in the inventory, and documentation still describing superseded data or a superseded owner.

The recursion deserves stating plainly. An agent placed inside a control process will attract attention from model risk, and should. Scope the intended use narrowly and write it down. Version the prompts, the retrieval configuration and the model behind it as change controlled items. An agent that drafts for a named reviewer is a far smaller governance exercise than one that concludes.

Issues, actions and proving closure

Issue logs fail in a particular way. Actions get closed against a checklist rather than evidence, internal audit validates closure, reopens a share of them, and confidence in the whole log drops.

An agent can hold each action's own success criteria and refuse to assemble a closure pack until the artefact exists: the revised procedure at its effective version, the completed training, the system change with its release record, the post implementation testing result. It flags actions closed on assertion alone, surfaces repeated extension patterns by theme or owner, and identifies the gap behind most reopenings, where the process was fixed going forward but the population already affected was never remediated.

It can also read the log thematically, which people do badly at volume. Several issues raised separately across business lines with one shared root cause is a different conversation with your regulator than several unrelated ones, and finding that pattern first is better than being shown it.

The request for information cycle during an exam

The opening request list is the predictable part. The cost is in what follows: the second and third waves that arrive after examiners read the first production, each referencing something specific inside a document you already sent.

Two contributions matter. The first is a production register: what was produced, in which version, to whom, on which date, against which numbered item. Without it, teams answer follow ups from copies and send inconsistent versions of the same document. The second is consistency checking. Before an answer goes out, an agent compares it against prior productions, the last supervisory correspondence and the relevant policy as it stood in the period under review. An inconsistency found internally is a correction. Found by an examiner, it is a credibility problem that outlives the finding.

The as-at requirement runs through all of it. Examiners want the procedure that applied in the period, not the improved one you published last month, and producing the current version by accident is a common and avoidable own goal. Every item still leaves the bank through compliance and legal review.

Where AI fails here

Completeness is the limit it cannot overcome. If the source extract is wrong, the agent assembles the wrong thing with a tidy index and a provenance log, and tidy is more persuasive than messy. Provenance proves where data came from, never that the system holds truth.

Historical accuracy is fragile where your systems do not retain it. Retrieving a policy, a delegation of authority or an entitlement set as it stood eighteen months ago is only possible if that history was kept, and quietly citing today's version is a serious error.

Judgement does not transfer. Whether an exception is a control failure, how issues aggregate, whether a finding is systemic, what to tell a supervisor and when: these carry personal accountability under your regime and stay with named individuals.

Volume creates its own exposure. An agent that can produce more evidence encourages teams to produce more than was asked, which widens what can be contradicted later. And once output is usually right, reviewers stop reading properly, which is when the wrong document reaches the front room.

A sensible first deployment

Start read only, where ground truth is checkable within one cycle. Access review preparation and revocation verification is usually the best candidate: the data is structured, the standard is written, the failure is visible, and nothing changes a system state. Issue closure evidence is a close second.

Run it alongside the current cycle and keep the comparison, because that record is both your acceptance evidence and your answer when second line asks how you know it works. Bring internal audit and model risk in during design. Auditors who helped define the trail tend to accept the output.

If you want a plain view of which parts of your control environment an agent could carry and which it should not touch, describe the process to Adopt AI Partners and we will tell you straight.