Regulatory Change Never Waits
How junior business analysts can stay ahead of regulatory change without creating more chaos
In the last article, we looked at a simple six step framework for handling regulatory requirements without drowning in paperwork. The big idea was straightforward: good analysis in a regulated environment is not about writing more documents. It is about making change clearer, safer, and easier to deliver.
Now it is time for the next part of the story.
Because even the best framework has one awkward little problem.
It works beautifully once you know which regulation or obligation you are dealing with. But in real life, that is rarely the hard part. The hard part is spotting what is coming early enough to do something sensible about it.
A lot of junior business analysts imagine regulation like a train timetable. One rule arrives, the team deals with it, everyone takes a breath, and then the next one shows up politely a few months later.
Real life is less polite.
Regulatory change behaves more like a crowded airport conveyor belt. One suitcase arrives, then three more, then one odd shaped bag no one recognizes, and then suddenly someone says, “By the way, that first suitcase also belongs to two other teams.”
That is why business analysts in banking and insurance need more than requirement writing skills. They also need a simple way to watch the regulatory pipeline, understand what matters, and prepare the team before the pressure starts.
In this article, we will look at what the never ending regulatory pipeline means for your work, how to track change without reading everything ever published, what new regulation means for requirements, and the four mistakes that create the most avoidable rework.
The Regulatory Pipeline Is Never Empty
The six step framework from the previous article assumes that you already know which obligations apply. In practice, that is rarely the case for long.
The regulatory landscape is never still. New rules arrive in waves. Existing rules get updated. Guidance appears later and changes how the original text should be understood. One new obligation can also create a ripple effect across systems, controls, and requirements that the team thought were already settled.
For a BA in banking or insurance, part of the job is knowing what is coming before it lands in the middle of your project plan.
Right now in the European Union, two big changes are especially important.
One is DORA, the Digital Operational Resilience Act. It has been in force since January 2025 and is changing how institutions deal with ICT risk, third party providers, vendor contracts, and incident reporting. If your project touches a cloud provider, an external platform, or any important third party system, DORA is probably already part of the picture.
The second is PSD3 together with the Payment Services Regulation, often called PSR. Political agreement was reached in November 2025, with formal publication expected in mid 2026 and a transposition period of around 18 to 24 months after that. For any BA working in payments, this is not distant future material. It is already something to watch closely. Fraud liability, open banking interfaces, and strong customer authentication are all areas where requirements will likely need to be updated before the deadline arrives.
The impact is practical, not theoretical.
A transaction threshold that looked fine under PSD2 may need to be reviewed under PSR.
A vendor contract that looked acceptable last year may need new clauses because of DORA.
The earlier a BA sees that coming, the easier and cheaper the change is to manage.
How to track the regulatory pipeline without reading everything
The good news is that you do not need to read every regulation from page one to page three hundred and fifty seven.
You just need a simple monitoring habit and a clear idea of where the early signals appear.
For EU wide regulation, the main sources are usually the European Banking Authority, EIOPA for insurance, and ESMA for financial markets. These organizations often publish consultation papers, draft standards, and supporting materials long before the final compliance deadline arrives.
That matters because reading a consultation paper is not legal work. It is early requirement discovery.
It gives you a first look at what may change, which parts of the business might be affected, and where future delivery work is likely to appear.
For national implementation, the key source is your local regulator or supervisor. That might be the FCA in the UK, BaFin in Germany, or the CNB in the Czech Republic. National authorities often add practical guidance that sits on top of the EU text. And very often, that is where the operational detail becomes much clearer.
Assign one person to do a monthly regulatory scan for the three or four regulators most relevant to your domain.
The output does not need to be a giant report. A one page summary is enough.
That summary should answer three things:
What is coming
When it is likely to matter
Which systems, controls, or requirements it could affect
That summary can then go into the backlog as a flagged item. Not an active delivery item yet, but something visible and tracked until the regulation is final enough to act on properly.
This is one of those habits that looks small and saves a huge amount of confusion later.
What a regulatory change means for your requirements
When a new regulation appears, your first job is not to design the solution.
Your first job is to understand the impact.
Which rules in your rule catalogue are affected
Which requirements refer to those rules
Which systems implement them
Which controls, reports, or manual activities also depend on them
This is exactly why traceability matters so much.
In the previous article, Step 5 focused on connecting obligations, rules, requirements, tests, and evidence. That may feel like extra work when everything is calm. But the moment a new regulation appears, it starts paying for itself.
If your requirements are connected to rules, and those rules are connected to regulatory obligations, you can work out the impact of change in hours instead of weeks.
That is a big difference.
Take DORA as an example.
DORA requires financial entities to maintain a register of contractual arrangements with ICT third party providers.
For a BA, that is not just a legal sentence to admire from a distance.
It becomes a practical requirement question.
Which system or process will capture vendor data
Who keeps that data current
What fields are mandatory
How do you prove the data is complete
How quickly can it be produced if a regulator asks for it
That is the real job of analysis in a regulated environment. You take an obligation and turn it into something testable, buildable, and operationally useful before the deadline arrives.
The Four Mistakes That Cause Most Avoidable Rework
After working across regulated delivery programs, the same failure patterns show up again and again. They are not usually dramatic at the start. In fact, they often look like small shortcuts. But later, they create expensive rework.
1. Treating compliance as a final gate instead of a design partner
One of the most common mistakes is bringing compliance in too late.
If compliance reviews the requirements for the first time when the release is almost ready, they can still find problems, but by then the team has very little room left to fix them properly.
That is not a review. That is a rescue mission.
Bring compliance in from the start, ideally when the objective and obligations are first being discussed. Early input is almost always cheaper and more useful than late correction.
2. Writing requirements without capturing control intent
A requirement that says, “the system shall process the transaction,” sounds complete until somebody asks, “And what control is supposed to happen around that?”
That is where weak requirements start to show.
A more useful requirement explains not only the action, but also the control behaviour that matters.
For example, a transaction might need an audit event when an amount crosses a threshold. Or it might require manual review when screening is incomplete. Without that control intent, the requirement may describe activity, but not the risk handling behind it.
And in regulated work, that missing piece matters a lot.
3. Shipping changes without evidence mapping
Teams often know what changed. That part is usually visible.
What is less visible is whether the team knows what was tested, what evidence was produced, and where that evidence lives.
That gap becomes painful very quickly during audits, reviews, or post incident investigations.
It is not enough to say the control was tested. You need to know how, where, and with what result.
Evidence mapping may sound dull, but it is one of the quiet things that makes regulated delivery much more manageable.
4. Updating the implementation but not the requirement version
This one causes more trouble than many teams expect.
A developer fixes behaviour during the sprint. The code is updated. The team is happy. Everyone moves on.
But the requirement never gets updated.
Now the implementation says one thing and the requirement says another. The traceability chain breaks, and from that point on, confusion spreads very easily.
Auditors do not follow the code first. They follow the chain of requirement, decision, approval, test, and evidence.
If one link is out of date, confidence drops fast.
The Small Template That Prevents Big Problems, Impact Assessment Template
For every medium or high impact change, capture the essentials before sign off.
Keep it compact. Keep it useful.
Your impact assessment should include:
Change ID, owner, and target release
Impact class such as regulatory, customer, or operational
Affected rules, controls, requirements, and systems
Compliance decision owner and sign off requirement
Linked tests and evidence location
Go or no go decision with rollback trigger
This does not need to become a massive template, it just needs to give the team enough structure to make good decisions and keep the audit trail intact.
AI Can Support the Decision. It Should Not Own It
AI tools are becoming more common in regulated delivery teams. They can help with drafting, analysis, summarising, and decision support. That makes them useful, but it also means they need to be treated carefully.
A simple principle helps here.
If AI output can influence a customer outcome, treat it like any other controlled requirement.
That means asking practical questions.
What part of the output must be explainable to compliance or audit
What data is allowed to be used
What data is stored and for how long
When is human review mandatory
How are model changes versioned, approved, and rolled back
A good example is a claims fraud model.
If the model returns a score of 0.85 or above, it may be sensible to route the case to manual review.
What it should not do is automatically reject a customer claim with no human involvement.
The model can inform the decision.
A person should still make the decision.
That is a useful rule of thumb for junior BAs. Whenever AI enters a regulated process, ask where human judgment must remain in the loop and how that control will be expressed in requirements.
Final thoughts
The regulatory pipeline is never empty. That is not a temporary problem. It is simply part of the environment.
For a business analyst, that means the job is not only about understanding today’s obligations. It is also about spotting tomorrow’s changes early enough to prepare the team properly.
You do not need to become a lawyer.
You do not need to read every document ever published.
But you do need a habit for monitoring what is coming, a simple way to assess impact, and enough structure to connect obligations to requirements before the pressure arrives.
That is where the real value sits.