Surviving the Regulatory Tsunami

Disclaimer: The views and opinions expressed in this article are those of the author and may not reflect the perspectives of IIBA.

Highlights

Compliance decisions are rarely perfect — they are usually compromises between cost, risk, and convenience.
A strong BA does not interpret the law, but helps translate legal uncertainty into practical solution options.
Regulatory change is where Business Analysts move beyond requirements writing and become decision enablers.

Nowadays, when cashless transactions are the lifeblood of the economy, banking systems are expected to be absolutely reliable and available 24/7. In banking, production errors mean not only cutting customers off from their funds and a drastic loss of trust, but above all, the risk of administrative penalties imposed by the regulator.

Legislators regularly step into this heavily loaded and sensitive environment. Regulatory implementations leave little room for half-measures and usually require a very disciplined approach. When legal language is unclear and time is running out, rigorous analysis based on BABOK® standards becomes crucial. It is the Business Analyst's craft that allows us to control chaos and protect the organization from legal risks.

Cost, Security, Convenience: Pick Your Criteria

In a legal environment, requirements elicitation is tedious work with both the requirements and the actual text of the law. The analyst’s role is not to interpret the law or give legal opinions - that is the role of lawyers. However, our task is to deeply understand these regulations to provide decision-makers with the information needed to choose the right solution. Lawyers do not know how the bank's systems work and are not familiar with the edge cases that bank employees encounter. This is where the analyst adds value - by connecting the legal perspective, practical business scenarios, and possible implementation options.

Working on changes in a highly regulated context, it is worth establishing key criteria by which we will analyze or evaluate proposed solutions. Good criteria should be:

Important in the context of the change being introduced.
Important in the context of the ecosystem we work in.
Something the target solution will actually affect.

Human creativity has no limits, so it is worth limiting ourselves to a few criteria that will actually matter to us. Too many criteria can only make working with requirements more difficult. On the other hand, skipping a criterion can lead to the loss of a valuable perspective. For me, fewer criteria, but with a broader meaning, work better.

Personally, I most often work with three criteria that create a kind of "Compliance Constraint Triangle", consisting of three vertices:

Cost (Effort): Real money spent on development, but also the increased load on infrastructure or additional man-hours for back-office employees.
Security (Legal Compliance): Although the solution must be 100% legal, the law is often not clearly defined. We have to balance the risk. Example: when multiple bailiff seizures overlap, we must block the appropriate amount, but at the same time absolutely make the statutory tax-free amount available to the client. In such a case, it is sometimes necessary to decide whether to risk accidentally blocking funds due to the client for edge cases, or rather the risk of overpaying funds that should go to the bailiff.
User Convenience: Usually means the level of automation that allows for immediate processing of instructions without manual intervention and forcing the client to visit a branch. This convenience will apply to both the bank's clients and its employees.

From Theory to Practice: Shaping the Solution

Personally, I treat this triangle as my internal analytical tool. I use it to organize my own thoughts and ideas. Moreover, it allows me to formulate accurate questions for stakeholders. It is a tool that I do not present directly at meetings or workshops. Probably if this were presented before formulating a proposed solution, the direction would always be the same:

Cost: Minimizing the effort related to introducing a new solution.
Legal Compliance: Introducing changes sufficient to be compliant with regulations.
User Convenience: Maximizing convenience for employees and clients.

Based on these criteria, requirements can be gathered, and based on the requirements, solution proposals can be prepared. Only at the stage of analyzing possible solutions do these criteria make more sense. Then you can see that it is difficult to find an ideal solution, and usually, some compromise must be made.

Theory in Action: A Case Study

Let's look at a problem from Polish law that concerns handling consumer bankruptcy. In the case of consumer bankruptcy, supervision over the bank client's funds is exercised by a trustee. Their role is to pay off the debt, but at the same time, they must leave the client with some funds to live on.

In the event of bankruptcy, the amount of funds available to the client is directly indicated by law. Such funds include child benefits and an appropriate percentage of a salary (50%) or a pension (75%).

As analysts, we should ask about the legal and public-image consequences of extreme decisions:

What is the risk of making excessive funds available to the client?
What is the risk of failing to identify exempt income (making funds available only based on a letter from the trustee or court)?
Can the bank be held liable for failing to fulfill its legal obligations?

Although banks do not have an obligation to automatically identify funds excluded from the bankruptcy estate, the Office of Consumer Protection may push for a bankrupt client to have equally convenient access to their due funds as other consumers.

How is the system supposed to automatically recognize which transfer is protected? Let's look at the options:

Option A: A cheap and convenient, but risky solution (Verification by title).
The simplest idea is to use an algorithm checking the transfer title (e.g., looking for the word "salary", "remuneration"). This option is inexpensive to implement and requires no action from the client. Unfortunately, the law is extremely flawed – it allows for easy abuse, because any debtor can type the word "salary" in the title of a standard transfer from a friend, tricking the system. I realize that banks use similar verifications for marketing promotions (e.g., "transfer your salary and get 200 PLN"). The difference is that losses from bypassing promotion rules are negligible, while errors in handling consumer bankruptcy mean breaking the law.
Option B: A safe and convenient, but terribly expensive solution (Changing the national infrastructure).
The ideal concept would be to expand the nationwide interbank operations interface (e.g., in the Elixir/STIR system) with a new marker for "salary" transactions. This solution removes the risk of error from the bank but would require significant changes to the payment infrastructure of the entire country.
Option C: A safe and cheap, but inconvenient solution (Shifting the handling to the trustee).
We can implement a mechanism where the bank blocks absolutely everything, and the burden of verifying and manually releasing protected funds falls on the trustee. The bank is legally safe, IT implementation costs are relatively low, but the client suffers from a longer process of accessing their own money.

While reading this article, you've likely already thought of other, alternative solutions to this problem. However, my goal here is not to present all possible technical options, but to show a wide range of scenarios that can be mapped on our conceptual grid.

When talking to the business side, I really like presenting such extreme variants. They evoke emotions, stimulate imagination, and force stakeholders to answer a difficult question honestly: What compromise are we ready for? The role of a BA is to put hard data about costs and risks for each of these scenarios on the table.

Between Influence and Responsibility: Where Does the Analyst's Role End?

When performing analysis for legal changes, a Business Analyst must constantly remind themselves what their role is. In such high-stakes projects, it is easy to fall into the trap of taking on a burden that does not belong to us. It must be said directly: the role of a BA is neither to give the final opinion on the law nor to make the final decisions on the shape of the adopted strategy. That is what business experts, legal counsel, and the Compliance department are for.

The analyst's task, however, is to provide reliable data that will allow others to make these decisions.

The Decision-Making Paradox: Frustration vs. Freedom

Such a structure of the BA role creates a specific paradox. On one hand, it can be frustrating – as the people closest to the system and process, we naturally want to have a real impact on the shape of the organization and the direction of changes. The feeling that we are "only preparing the ground" can cause resistance among ambitious specialists.

On the other hand, this approach is extremely liberating. Regulatory analyses are a high-risk domain and often become an arena of internal politics and clashing interests of different departments. Knowing that the ultimate responsibility for choosing a specific path (and the potential consequences of misinterpreting the law) rests on the shoulders of business decision-makers allows the analyst to "sleep peacefully".

However, being exempt from making decisions does not mean being exempt from taking care of the process. On the contrary – a BA's professionalism is shown in how wide a spectrum of the problem they can present. Our responsibility is to make sure that the decision-maker cannot say: "I didn't know it costs so much" or "Nobody mentioned this risk".

Summary

Legislative implementations are one of the most difficult tests a modern financial organization faces. In a world where cashless operations cannot stop, and a mistake means not only user frustration but also real legal sanctions, the role of the Business Analyst is evolving. We are no longer just “requirements writers”. We are becoming compliance architects.

Effectively navigating a legislative tsunami requires more from us than just knowing the systems. It requires reliable, almost detective-like analysis of the current state (AS-IS), courage in modeling extreme scenarios, and a clear understanding of our own role as a provider of readable data.

Although the final course is set by business decision-makers and lawyers, it is the analyst who draws the map that allows the organization to avoid the shallows and safely guide the system to its destination. By acting this way, we protect not only data and accounting processes but, above all, the operational stability and reputation of the organization, which is the highest value in the world of finance.

About the Author

Damian Cebulak is a seasoned System Analyst and team leader with extensive practice in delivering IT projects in the banking sector. At IIBA Poland Chapter, Damian serves as Head of Marketing and plays a key role in marketing management and project operational activities, helping us work efficiently and achieve our goals.

Damian is also passionate about continuous learning, history and photography. While walking through Warsaw, you might spot him exploring the city with a camera in hand.