Back to insights

ATI Lab insight

Automation Consulting for Banks: Where to Start Safely

Start with the workflows that are not models. Under the revised US model risk guidance issued on 17 April 2026, a deterministic rules-based process sits explici...

Analysis for technology leaders and operators planning, buying, and governing AI systems.

Automation Consulting for Banks: Where to Start Safely

Start with the workflows that are not models. Under the revised US model risk guidance issued on 17 April 2026, a deterministic rules-based process sits explicitly outside model risk management scope — so document intake, KYC chasing, review-pack assembly and exception flagging can ship on ordinary change control. Scoring, forecasting and generative agents cannot. Automation consulting for banks earns its fee by sequencing work along that line, not by picking whichever use case demos best.

Two disclosures. ATI builds and operates AI automation for a living, so we have a commercial interest in you automating something — the section below on when not to automate is there for that reason. This piece was researched and drafted with AI assistance and fact-checked against the primary sources linked throughout; every regulatory claim points at the document it came from.

What counts as automation consulting for banks in 2026?

The category has quietly split in two. One half is the RPA inheritance: screen-scraping bots, macro replacement, ticket routing — mature, unglamorous, and largely a systems-integration purchase. The other half is agent-era work: models and language systems that make or shape a decision, which drags in a supervisory apparatus the RPA half never had to touch.

Most vendor pages on this query describe capability — onboarding, wire processing, reconciliation, servicing. That is not the constraint. Every mid-size bank already knows which processes are painful. What gates the programme is evidence: can you show a supervisor how the thing decides, who challenged it, what data it learned from, and what happens when it is wrong.

So a useful engagement is structured around evidence production, not feature delivery. In practice that means four things: classify each candidate workflow by which control regime it falls under, design the control and audit trail before the build, ship the ones that need the least new governance first, and hand over documentation your second line can defend without the consultant in the room.

Which rulebook actually gates your first build?

Three developments in 2026 changed the answer, two of them recent enough that most banking-automation content predates them.

The US model risk guidance was rewritten. On 17 April 2026 the Federal Reserve, OCC and FDIC issued SR 26-2, Revised Guidance on Model Risk Management, which supersedes and replaces both SR 11-7 (April 2011) and SR 21-8, the interagency statement covering BSA/AML systems. The Fed states it is "expected to be most relevant to banking organizations with over $30 billion in total assets," though it notes the guidance may still be relevant to smaller organisations with significant model exposure. Fifteen years of supervisory practice compressed into a risk-based framework that scales rigour to what the agencies call model materiality — a function of the model's exposure and its purpose.

The EU deferred its high-risk deadline — but not the transparency one. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July. It moves the application date for stand-alone Annex III high-risk systems — the bucket that contains creditworthiness assessment of individuals — from 2 August 2026 to 2 December 2027, and pushes high-risk systems embedded in regulated products to 2 August 2028. What it did not move is Article 50: the transparency obligations, including telling people when they are dealing with an AI system, still applied from 2 August 2026. If your EU programme was planning around a single August 2026 cliff, the cliff moved and a smaller one stayed put.

UK supervisors are testing in the open. The FCA announced its second AI Live Testing cohort on 21 April 2026 — Barclays, Lloyds Banking Group (Scottish Widows), UBS, Experian, GoCardless, Aereve, Coadjute and Palindrome — testing from April through year end, with an evaluation report due in Q1 2027. The published use cases are worth reading closely: agentic payments, AML detection, KYC, credit-score insights. That is a fair map of where large UK institutions think the supervisory uncertainty actually sits.

Is your workflow a model? The question that decides your timeline

SR 26-2 tightened the definition, and the tightening is the most commercially useful sentence in the document. A model is "a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates." The guidance then excludes simple arithmetic such as spreadsheet calculations, and — this is the part that matters for automation — "deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use."

Read that as a routing rule. A workflow that reads an inbound document, extracts fields against a fixed schema, validates them against reference data and queues an exception for a human is not producing a quantitative estimate from financial theory. It is not a model. It does not enter the model inventory, does not queue for independent validation, does not consume effective-challenge capacity. It still needs change control, access control, data lineage and an audit trail — but those you already have.

A behavioural scorecard, an AML threshold tuner or a provisioning forecast is a model, in scope, with the full lifecycle attached. The distance between those two outcomes is usually two or three quarters of programme time.

Which control regime does this workflow fall into? Does it apply statistical, economic or financial theory to turn input data into a quantitative estimate? NO — DETERMINISTIC RULES Email and document intake, extraction against a schema KYC document chasing and status tracking Review-pack and report assembly for sign-off OUTSIDE MODEL RISK SCOPE Start here. Controls are audit trail and human sign-off. YES — STATISTICAL MODEL Credit and behavioural scoring AML alert tuning and threshold setting Forecasting, provisioning, segmentation IN SCOPE — FULL LIFECYCLE Validation, effective challenge, ongoing monitoring. GENERATIVE OR AGENTIC Drafting client and provider correspondence Summarising case files and policy documents Agents taking actions across systems NOT COVERED BY SR 26-2 No supervisory template. You define the controls. Footnote 3, SR 26-2 (17 April 2026): generative and agentic AI models are out of scope because they are novel and rapidly evolving — your own risk management and governance practices decide the controls.

Which workflows are the compliance-safe starting points?

Compliance-safe here means a specific thing: the workflow produces no quantitative estimate, a human remains the decision-maker of record, and every step leaves a log a reviewer can reconstruct. Five candidates meet that bar in most banks.

Inbound document intake and classification. Statements, mandates, invoices, provider correspondence — read, extract to a fixed schema, validate against reference data, route. The highest-volume, lowest-argument automation in banking operations. ATI's closest analogues are outside banking: an email intake build that removed 95% of manual handling with zero monthly entry errors, and a mobile OCR flow for paper travel sheets that cut processing time 85% with zero lost documents, both documented on our solutions portfolio. Neither is a bank deployment and we will not present them as one — they are evidence about the shape of the workflow, not about your regulatory environment.

KYC and AML document chasing. Track what is outstanding, nudge on a schedule, escalate to compliance only when a document is missing beyond the allowable window. The detection logic stays where it is; you are automating the chase, not the judgement. This pattern and its adjacent blueprints are set out on our financial services automation briefing.

Review-pack and suitability-report assembly. Aggregate from source systems, apply the narrative template, queue for adviser validation with the data lineage attached. The adviser still signs. What disappears is the two days of copying.

Reconciliation exception flagging. Rules-based comparison against contract or expected terms, with the exception queued for human disposition. Note the boundary: flagging discrepancies against fixed terms is deterministic; predicting which discrepancies are likely to be genuine is a model.

Provider and third-party correspondence logging. Unglamorous, and the one that most often surprises people in an audit — a timestamped record of who was chased, when, and what came back.

The pattern across all five: they attach to the work around a decision, not the decision itself. That is what makes them shippable this quarter. Our financial services solution page collects the published outcomes we track in this sector, with sources named on each.

What the generative carve-out means in practice

Footnote 3 of SR 26-2 is the sentence to take to your risk committee. Generative and agentic AI models are "novel and rapidly evolving" and, as such, "are not within the scope of this guidance" — while the guidance's principles do apply to traditional quantitative models and to non-generative, non-agentic AI models. The footnote adds that a banking organisation's own risk management and governance practices should determine appropriate governance and controls for anything not covered.

Two readings are wrong. The first is that generative AI is therefore unregulated — it is not; it is unscoped by this particular guidance, which is a harder position, because there is no supervisory template to point at when you are asked to justify your controls. The second is that you can route a generative workflow through the model risk framework and inherit its credibility. You cannot, and a validation team that accepts one is signing up to defend a framework the agencies explicitly said does not apply.

The practical consequence for a first build: put the generative component where its output is read by a person before anything happens. Drafting, summarising, retrieving. Not deciding, not executing. Then write your own control standard — evaluation set, refusal behaviour, escalation path, logging — and get it approved on its own merits rather than borrowing model risk management's. We walk through the same sequencing problem for language-model rollouts in our Claude enterprise rollout guide.

What should you hold an automation consultant accountable for?

Ask for the evidence artefacts by name, in the contract. Six that matter:

A control design that precedes the build. If the first deliverable is a working prototype rather than a control specification, the governance work is being deferred to your second line, who will price it as a delay.

Decision-level logging as a default. Every automated action recorded with its inputs, the rule or model version applied, and the disposition. Retrofitting this is expensive; specifying it upfront is free.

Documentation rights over vendor components. SR 26-2 is direct about the problem: because components may be proprietary, banks "may not receive from the vendor the underlying code, data, or methodology" they would have for an internal build — and the principles of model risk management apply anyway. If your automation partner is assembling third-party components, your contract needs to reach conceptual soundness, development data and performance evidence, or your validators will be asked to sign off on a box they cannot open.

Participation in effective challenge. The builder should be available to be challenged by people with the independence and standing to force a change — not just to present.

A named rollback. What happens to in-flight work when the automation is switched off mid-day — surprisingly often unanswered.

Run-state ownership. Who watches drift, exception rates and cost after go-live, on what cadence. We publish ours: weekly, per workflow, not per provider invoice.

What does it cost, and how long does it take?

Honestly: it depends on the control regime, which is the whole argument of this piece. A deterministic intake workflow with human sign-off is a matter of weeks. A scoring model that has to clear independent validation runs on your validation team's calendar, not your vendor's.

ATI's published planning figure for a first deployment is 6 to 12 weeks, for a focused workflow in a normal enterprise environment — assume the upper end or beyond where a control review, model inventory entry or third-party risk assessment sits in the path. On run cost we model three layers: usage (model calls, context, retries), runtime (infrastructure, orchestration, observability) and operations (human review, exception handling, support). Banks systematically underestimate the third, because compliance-safe designs deliberately keep a human in the loop — that human is a permanent line item, not a transitional one. The full breakdown is on our AI agent cost guide, and the ROI calculator will give you a first-pass estimate, with the caveat the page itself carries: it is a decision aid, not a guaranteed return.

When should a bank not automate?

Three cases where our answer is don't, or not yet.

When the process is contested. If two departments disagree about the correct outcome, automation does not settle it — it hard-codes whichever version the builder heard first, at volume.

When the volume does not justify the control overhead. A workflow running forty times a month, in a regime where every automated decision needs a logged rationale, will not repay the governance cost. Fix the template instead.

When the real problem is data quality. Automating on top of inconsistent reference data produces confident, fast, wrong output — and an audit trail proving you did it consistently.

Frequently asked questions

Does SR 26-2 apply to my bank?

The Federal Reserve states the guidance is expected to be most relevant to banking organisations with over $30 billion in total assets, and notes that organisations at or below that threshold are generally covered instead by internal risk management practices proportionate to their size and risk profile — while adding that it may still be relevant to smaller banks with significant model exposure. Check the letter itself rather than a summary, including this one.

Is a rules-based automation a model?

Under SR 26-2, no. The guidance explicitly excludes deterministic rule-based processes and software with no statistical, economic or financial theory underpinning their design or use, along with simple arithmetic such as spreadsheet calculations. The exclusion is from model risk management scope — not from change management, access control or audit.

Did the EU AI Act deadline move for banks?

Partly. Regulation (EU) 2026/1744 moved stand-alone Annex III high-risk obligations, which cover creditworthiness assessment of individuals, from 2 August 2026 to 2 December 2027, and embedded high-risk systems to 2 August 2028. Article 50 transparency obligations kept their 2 August 2026 date. A deferral is not a repeal, and the conformity work for a 2027 date starts well before 2027.

Can we use generative AI in a regulated banking workflow?

Yes, and firms in the FCA's second AI Live Testing cohort are doing so under supervision. What you cannot do is inherit model risk management's credibility for it, because SR 26-2 places generative and agentic AI outside its scope. Design the controls yourself, keep a human between the output and any consequence, and document the reasoning.

How long before we see a result?

For a deterministic workflow with a clear owner, our published planning range for a first deployment is 6 to 12 weeks. Anything entering the model inventory should be planned against your validation calendar instead, which is usually the binding constraint.

What is the single best first project?

The highest-volume inbound document workflow where a human already checks the output. It is out of model risk scope, the error mode is visible immediately, and the time saved is measurable in the first month without any argument about attribution.

If you want this mapped against your own workflow inventory — which items are models, which are not, and what evidence each one needs — book a strategy call and bring the list.

Next step

Turn the analysis into an implementation decision

Bring us the workflow, business constraint, or architecture question. We will help define the practical next step.