From Regulation to Release: Where AI Helps a Banking Business Analyst – Webinar Recap
Authors: Maria Ericsson , Yaru Wang , Anders Ekman
AI can take a large share of the reading, comparing and linking off a banking business analyst's desk, but only if every result can still be traced, reviewed and defended in front of an auditor. That was the thread running through our webinar on 22 October 2026, "From Regulation to Release: Where AI Helps a Banking Business Analyst".
Celeris Consulting hosted the session together with Modern Requirements. Anders Ekman from Celeris was joined by Ron Alltree and Jaweria Owais from Modern Requirements. Together they walked through six everyday tasks of a business analyst in banking, and for each one asked the same question: where does AI genuinely help, and what must stay with the analyst?
Most of the week is extraction, not invention
A business analyst in a bank rarely starts from a blank page. Requirements come from regulation and supervisory texts such as Basel IV, BCBS 239, IFRS 9 and DORA. They also come from product sheets, internal policies, vendor release notes, legacy specifications, ticket history and from conducting workshops with business, risk and compliance specialists.
The bar for the result is high. Requirements must be unambiguous, testable and use consistent terms. Each one needs evidence of where it came from and a review sign-off that an auditor can follow months later. And all of this has to happen fast, because regulatory deadlines do not move.
The consequence is that most of an analyst's week is spent reading, comparing and linking volumes of text. That is exactly the kind of work where AI can help, and also where a credible but unfounded answer does the most damage.
AI is moving closer to doing the work
Anders traced how AI in business analysis has evolved in five steps. It started with rules and search: templates, checklists and keyword search, where the analyst still reads everything. Machine learning added classification and similarity, trained per task on labelled data. From late 2022, generative assistants began to draft, summarise and rephrase, but outside the work tools. The current step puts AI inside the tools, working on the actual work items, links and history in the repository. The emerging step is AI agents that take multi-step actions within permissions set by the organisation.
Each step brings AI closer to doing the work. The closer it gets, the more governance matters.
To make this practical, Celeris uses an AI Involvement Model with eight levels:
- Level 0, No AI
- Level 1, Ad hoc AI usage: private AI use by individuals
- Level 2, Organised AI usage: coordinated AI use, still beside the tools
- Level 3, Embedded AI: AI inside the tool, working on one artefact
- Level 4, System-aware AI: AI that understands dependencies between artefacts
- Level 5, Context-aware AI: AI that follows those dependencies over time
- Level 6, AI-supported decisions: AI evaluates options and recommends
- Level 7, Governed AI actions: AI executes permitted actions on the tools
The model gives a team a shared language for where it stands today and where it wants to go, use case by use case.
Celeris AI Involvement model
Six everyday use cases
The core of the webinar was a dialogue between Celeris and Modern Requirements. For each use case, Anders set out the objective and where business analysts in banks struggle. Ron and Jaweria then showed in the tool how Modern Requirements handles it with AI inside Azure DevOps.
1. Extract requirements from source documents. A chapter of BCBS 239 or Basel IV has to become a set of requirements. A requirement is only trusted when it can be traced to the paragraph it came from. The risk with generated text is that it reads fluently, so a requirement can look sourced while it has drifted from the text or covers it only in part. The session looked at how the link to the source paragraph is kept, and how the tool shows what an existing requirement set covers, partly covers or misses.
2. Prepare and run workshops. Workshops decide scope, yet notes mix decisions, open questions and opinions. Within days, nobody remembers which stakeholder said what. Detailed minute-taking slows the discussion, and an automatic summary can quietly turn an opinion into a decision. The focus was on separating decisions from open questions, attributing statements to stakeholders, and placing the result in Azure DevOps as draft, unapproved items.
3. Assure requirements quality. Reviewers check that wording is unambiguous, that each statement holds one requirement and that terms are consistent. A generic standard does not know a bank's own vocabulary, such as exposure or counterparty, and splitting or merging requirements can break trace links. The session covered customer-defined quality rules, what the analyst sees for each finding, and how the accept or reject decision is recorded.
4. Generate acceptance criteria and test cases. Tests written late tend to cover the happy path only. Generated test cases multiply quickly and can look complete while missing the boundary of a rule, such as an IFRS 9 staging threshold. The question was whether the tool proposes boundary and negative cases, links tests to the requirement from the start, and hands them to the test tool the testers already use.
5. Analyse the impact of change. A core-banking release or a regulatory amendment only reaches the right requirements if someone created the link beforehand. Full link discipline is costly, and a tool that suggests candidates also produces false positives that take up the change board's time. The demo explored finding affected requirements that were never linked, dismissing false positives in a recorded way, and the summary that reaches the change board.
6. Produce documents and compliance reports. Specifications, release notes, change summaries and status reports all have to be written. In a regulated bank, an auditor needs to see what the AI drafted, what the analyst edited and which requirements the document is built on. The session showed how Copilot4DevOps generates a reviewer-ready document straight from the requirements in Azure DevOps and keeps it traceable to its source work items.
Data and judgement
The session closed on the question that every bank asks first. Requirement text in a bank is confidential and carries regulatory consequence. Yet the value of AI support depends on exposing exactly that text to a model, while the responsibility for the result stays with the analyst.
The speakers discussed where Modern Requirements processes and stores the text, whether it is used to train the model, and where using the tool is not advised. The message was clear: AI can speed up the work, but the judgement, and the sign-off, remain human.
Where to go from here
Every bank starts from a different place, so Celeris offers a short, structured way to find yours:
- We identify the use cases that matter in your bank, starting from the six shown in the webinar. The result is a shortlist for your bank.
- We place each use case on levels 0 to 7, today and as a target, across people, process and tools. The result is a current and target level per use case.
- We agree the roadmap to close the gap, ordered by the gaps that block the next level. The result is a prioritised roadmap, including where Modern Requirements fits.
Missed the live session? The full recording, including the demos and the Q&A, is now available on our YouTube channel: Watch the webinar.
Would you like a copy of the webinar slides? We are happy to share them. For the slides, or to discuss your starting point, contact us at
Follow Celeris Consulting and subscribe to Celeris Insights on LinkedIn!
This article was developed with the support of AI tools and reviewed and edited by the Celeris team.
