Regulatory Change Management in Banking: A 2026 Workflow

Regulatory change management is the discipline of detecting, assessing and acting on new or amended rules so that policies, controls and evidence stay aligned with what supervisors expect. In a bank it works as a repeatable chain: monitor official sources, map each change to policies and controls, draft an impact assessment, obtain owner approval, and keep an audit trail. AI can speed up the first three links. It does not replace the compliance sign-off at the end.

This article walks through that chain step by step, using three real 2026 developments as worked examples, each taken from a primary source. It is written for CCOs, COOs, CIOs and Heads of Compliance at banks, wealth managers and fintechs operating in Switzerland and the EU.

TL;DR

• A working process has five stages: monitor, map, assess, approve, evidence. The last stage is what examiners test, not the alert itself.

• Horizon scanning (what is coming) and monitoring (what is binding) are different feeds. Both go into the same intake queue.

• AI is useful for scanning, summarizing and first-draft mapping. A named human owner approves every impact assessment.

• The 2026 examples show why: an EU deadline shifted, a supervisory statement added no new requirements, and a Swiss consultation draft is still pending. Each needed a different response.

• Build the workflow before the tooling. Software that sits on a vague process only produces faster confusion.

Table of Contents

• What regulatory change management covers in a bank

• Step 1: Monitor official sources

• Step 2: Map each change to policies and controls

• Step 3: Draft the impact assessment

• Step 4: Owner approval, with a human in the loop

• Step 5: Execute and keep an audit trail

• Three 2026 changes, as illustrations

• Where AI helps and where it stops

• Common reasons programs stall

• Our perspective

• Taking the workflow into production

• FAQ

• How S-PRO helps

• Sources

What regulatory change management covers in a bank

The definition is simple. It is the process of detecting, assessing and responding to changes in laws, regulations and supervisory guidance that affect the institution. The ServiceNow overview describes a lifecycle of monitoring, impact assessment, communication and training, execution and policy updates, and an audit-ready feedback loop. The five steps below use the same backbone and add the roles that make it work in a regulated bank.

Three boundaries are worth setting at the start.

• Scope. Binding law, supervisory circulars, guidance, consultations, enforcement trends and industry standards. Not every item needs action, but every item needs a recorded decision.

• Owners. Compliance coordinates. Business lines and IT own execution. Good-practice research on regulatory change programmes stresses a clear design structure, with a stated purpose and priorities that staff understand.

• Evidence. The output is not an updated policy. It is a traceable record of why a control did or did not change, who approved it and when.

Step 1: Monitor official sources

The first stage is building a source register. List every body whose output can affect your institution, and record for each one what it publishes, how you receive it and who reads it.

For a Swiss bank with EU exposure, a minimal register looks like this:

Two feeds, not one. Horizon scanning looks ahead at proposals, consultations and speeches. Monitoring tracks what has been published as binding or is already in force. Treating them as one stream is a common reason teams miss early signals or over-react to drafts. A Wolters Kluwer article makes a related point: horizon scanning works best as an early-stage feed into internal decision-making, not as an isolated task.

Where AI helps here: reading long official documents, extracting the date, the legal basis and the affected entity types, and writing a three-line summary for the intake queue. Where it does not: deciding what is relevant to your licence and business model. That decision belongs in the register, owned by compliance.

Step 2: Map each change to policies and controls

Once an item is accepted into the queue, link it to your obligations inventory. This is the step most programs under-invest in. If your policies, controls and systems are not already tagged to the rules they implement, nothing can be mapped, whether by a person or a model.

A useful mapping record has these fields:

1. Source document and exact provision.

2. Legal status: in force, adopted with a future date, draft, or non-binding statement.

3. Affected policies, procedures and controls, each with an ID.

4. Affected systems and data flows.

5. Business owner for each affected item.

The Wolters Kluwer analysis describes mature programs as built on normalized regulatory content, standardized taxonomies for impact assessment and linked evidence from end to end. In practice that means one vocabulary across compliance, risk, legal and IT, so that “high-risk AI system” or “critical ICT service” means the same thing in every document.

AI is a good first-pass mapper. It can propose candidate policies and controls from your inventory for a human to confirm or reject. Keep the proposals, and the human corrections, in the record. They become useful evidence of how the process works.

Step 3: Draft the impact assessment

The impact assessment answers five questions in plain language:

• What exactly changed, and from when?

• Which of our activities, products or systems are in scope?

• What is the gap between the current control and the new expectation?

• What must be done, by whom, with what effort and by which date?

• What is the residual risk if we do nothing, or do less?

An AI agent can draft this from the mapped record, and it saves real time on the first version. The draft must cite the provision it relies on, so the reviewer can check it against the source in seconds. Drafts that cannot point to a provision are rejected automatically, not by the reviewer’s goodwill.

Optimism bias is a common risk: teams can underestimate the time needed for policy alignment, IT integration and staff training. Build contingency into the roadmap, and pilot on a small scope before an enterprise-wide rollout.

Step 4: Owner approval, with a human in the loop

This is the control point. A named policy owner, and where required the CCO or an equivalent function, reviews the impact assessment and records one of four outcomes: no action, monitor, update controls, or escalate.

Three rules keep this honest:

• No self-approval by software. The AI output is a proposal. Approval is a human act with a name and a timestamp.

• Rationale is mandatory. Record why the control changed, not only that it did. Record this lineage of business rationale, not just a system notification.

• Dissent is kept. If the owner overrides the AI proposal, store both versions.

This also applies to the AI tooling itself. If you use AI in compliance processes, the EU AI Act and your own model risk and ICT risk frameworks apply to that tooling too, so its classification, logging and oversight belong in your own inventory.

Step 5: Execute and keep an audit trail

Approval triggers execution: policy updates, control changes, system tickets, training. The loop closes only when you can show the change is embedded, not simply that a deadline passed. The aim is to evidence embedding, not just implementation.

An audit-ready file for each change contains:

• The source document and the date you received it.

• The mapping and the impact assessment, including AI drafts and human edits.

• The approval record with name, role and date.

• Linked tasks, owners and completion evidence.

• A post-implementation check, for example a sample test of the updated control.

If your reporting obligations are also changing, our article on regulatory reporting automation for Swiss and European banks covers the reporting side of this loop, and our page on regulatory reporting automation for banks describes how we build it.

Three 2026 changes, as illustrations

The workflow is easiest to judge on real items. The three 2026 changes below are illustrations of how each could be run through the workflow. They are not descriptions of client work, and each calls for a different outcome.

Example 1: Regulation (EU) 2026/1744, the AI Omnibus

Intake. Regulation (EU) 2026/1744 was published in the Official Journal on 24 July 2026. It amends the application timeline of the EU AI Act, Regulation (EU) 2024/1689.

Mapping. According to the European Commission, rules for high-risk AI systems listed in Annex III now apply from 2 December 2027. Rules for high-risk AI embedded in products covered by Annex I apply from 2 August 2028. For a bank, the relevant question is which of your systems fall under Annex III, for instance AI used to evaluate creditworthiness of natural persons. Map those systems and the projects that depend on them.

Impact assessment. The change moves dates, so the likely outcome is a revised roadmap, not a cancelled one. Note what has not changed: do not assume that other provisions moved. Check each provision against the regulation text rather than relying on a headline.

Decision. Update the AI governance plan and the project calendar. Keep building classification, logging and oversight, because the obligations were deferred, not removed.

Example 2: ESAs statement JC 2026 25 on frontier AI

Intake. In July 2026 the European Supervisory Authorities issued a statement on ICT risks from frontier AI models. It addresses how AI-enabled cyber tools can accelerate the discovery and exploitation of vulnerabilities.

Mapping. Read the statement for any new requirement. If it only points back to the existing DORA framework, the mapping goes to existing items: ICT risk management, incident response, third-party risk and testing.

Impact assessment. If no new obligation arises, no new control is needed by default. The useful question is whether current controls still look adequate against faster, AI-assisted attacks, and whether your risk assessment reflects that.

Decision. Likely “monitor and review”: the ICT risk owner confirms or updates the assessment, and the record shows why no new control was created. This outcome is exactly the type a keyword alert would misclassify as urgent. A documented “no new requirement” decision is a legitimate and auditable result.

Example 3: Switzerland’s planned consultation draft on AI rules

Intake. The State Secretariat for International Finance describes Switzerland’s approach to AI in the financial sector as promoting innovation while limiting risks. Existing, technology-neutral financial market law applies to AI. The Federal Council is working toward a consultation draft on AI rules by the end of 2026.

Mapping. Nothing is binding yet, and no new FINMA AI circular should be assumed. This item belongs in horizon scanning, not in monitoring.

Impact assessment. Assess exposure at the level of principles: which AI systems you run, who owns them, how they are documented. Prepare to respond to the consultation if the draft touches your activities.

Decision. Place on the watch list with a review date tied to the publication of the draft. Existing FINMA expectations on governance, risk management and outsourcing continue to apply in the meantime.

Three items, three different decisions. That is the point of the process: the value is in classification and rationale, not in volume of alerts.

Where AI helps and where it stops

We would not claim that AI tracks all regulation automatically. Coverage depends on your source register, and gaps in that register are gaps in the process. Treat AI output as a draft that always cites its source.

Common reasons programs stall

• Monitoring mistaken for management. Alerts arrive, nothing links to controls.

• No business ownership. Compliance coordinates, but execution owners are never named. Research on good practice points to central governance combined with decentralized execution.

• Optimism bias. Timelines ignore policy alignment, IT integration and training.

• Thin evidence. The system shows a notification, not a rationale and an approval.

• Tooling first. A platform is bought before the inventory of obligations, policies and controls exists.

Our perspective

The model is the smaller part of the problem. The harder parts are an obligations inventory that is current, an approval path with named owners, and logging that lets a supervisor reconstruct what happened.

For regulatory change, a sound agent design reads official sources, proposes mappings and drafts impact assessments, and then stops. The compliance owner decides. Every proposal carries its source citation and every decision is stored, so that EU AI Act, FINMA and DORA expectations on oversight and traceability can be met by design and not retrofitted.

It is also sensible to start narrow. Pick one source family, for example EU Official Journal items affecting your AI governance, run the five steps with a small team for a quarter, and measure how often owners accept or correct the draft mappings. Expand once the process is stable.

— Igor Izraylevych

Taking the workflow into production

If you want to move a regulatory change pilot into production, the questions are practical. Which systems hold your policy and control inventory? How will drafts be logged? Who approves, and how is that recorded? Our AI agent development service covers these integration and governance questions for banks and financial institutions, with human-in-the-loop controls and audit trails built in from the first sprint.

FAQ

What is regulatory change management?

It is the process of detecting, assessing and responding to changes in laws, regulations and supervisory guidance. In a bank it runs from monitoring through impact assessment and owner approval to an audit trail. The goal is to show that controls stay aligned with current expectations.

What is the difference between horizon scanning and regulatory change monitoring?

Horizon scanning looks ahead at proposals, consultations and supervisory signals that are not yet binding. Monitoring tracks rules that are published as binding or already in force. Both feed the same intake queue, but they trigger different decisions and different timelines.

Can AI manage regulatory change on its own?

No. AI can scan sources, summarize them and draft mappings and impact assessments. A named human owner must approve the outcome, and the record should show who decided and why. AI used inside compliance processes is also subject to the EU AI Act and your own risk frameworks.

How do I know whether a change needs action?

Check its legal status, then its scope against your licence, activities and systems. A binding act with a date usually needs a plan. A non-binding statement that adds no new requirements may need only a documented review of existing controls.

How S-PRO helps

S-PRO is a Zurich-based software development company for banks, wealth managers, asset managers and fintechs. We take AI agents from pilot to production with audit trails, human-in-the-loop controls and documentation aligned to the EU AI Act, FINMA and DORA. S-PRO is a Certified partner in the Claude Partner Network, and our team includes Claude-certified engineers and architects. We are ISO 27001 and ISO 27701 certified. If you want to design a regulatory change workflow where AI assists and your compliance team signs off, talk to our team about AI agents for banks.

Sources

• Regulation (EU) 2026/1744, EUR-Lex

• AI Omnibus enters into force, European Commission

• ESA Statement JC 2026 25 on frontier AI models

• Artificial intelligence, State Secretariat for International Finance

• Why regulatory change management programs stall, Wolters Kluwer

• What is regulatory change management, ServiceNow

Recommended

• Digital Banking Regulatory Compliance in 2024: The Latest Updates

• Regulatory Reporting Automation for Swiss and European Banks