MoSCoW Prioritization in Swiss Banking: Uniting Compliance and Efficiency

Every Swiss SME knows the pressure: Time is tight, budgets are limited, and expectations are high. In the regulated banking environment, there's an additional layer – seamless compliance with regulations. Many managing directors face the challenge of managing dozens of project requirements without losing sight of the big picture or jeopardising compliance.

The sheer volume of tasks and requests alone can paralyse projects before they even properly begin. A look at the numbers highlights the relevance: 99.7% of all Swiss companies are SMEs, and they account for two-thirds of jobs. This underscores the need for efficient methods that also work in complex, regulated environments like Swiss banking.

As a practitioner with an IPSO certification in AI Business, I've personally experienced how quickly projects can fail if priorities aren't clear from the outset. Especially in banking, where FINMA requirements and the new Data Protection Act (nDSG) set firm boundaries, precise requirements analysis isn't a luxury but a necessity. The MoSCoW method offers a clear, pragmatic way to separate the essential from the desirable and focus on what truly matters.

How can I prioritise my project requirements in a regulated environment using the MoSCoW method?

Through clear categorisation into essential, important, desirable, and excluded requirements. The MoSCoW method is an effective tool for evaluating and prioritising requirements. It was specifically developed to maintain focus in projects with limited resources and fixed deadlines. In the Swiss banking environment, where regulatory requirements such as those from FINMA and the new Data Protection Act (nDSG) are non-negotiable, this level of clarity is invaluable.

We fundamentally classify requirements into three levels to create a solid foundation for professional requirements management. First, there are the Business Requirements, which answer the "why?" – the bank's business objectives. These include concrete goals such as reducing the Average Handling Time (AHT) by 15% or cutting search time from 2–5 minutes to under 30 seconds. These objectives are the driving force behind any project.

Next are the Stakeholder Requirements. These describe what individual stakeholders need to fulfil the business requirements. They are often more specific and reflect the needs of departments, employees, or customers. Finally, there are the System Requirements, which detail what the system must do to meet the business and stakeholder level requirements. This can range from technical specifications to functional requirements.

Let's assume we've identified 24 such requirements. Developing all 24 requirements simultaneously is usually impossible in reality – time, budget, and resources are limited. This is where MoSCoW comes into play. The method divides requirements into four categories:

• Must Have: The project cannot go live without these, or it won't be compliant. These are the absolute core functionalities and all regulatory requirements. In banking, this includes, for example, full compliance with the nDSG, FINMA guidelines, and fundamental security standards. The business Must-Haves mentioned above, such as the 15% reduction in AHT and the 50% reduction in search time, also fall into this category. For a Swiss banking institution, this could be 17 out of the 24 identified requirements.
• Should Have: Important requirements that deliver high value but are not strictly necessary for the first release. The absence of these functions would require a workaround, but the system would still be usable. They should ideally be implemented if resources allow.
• Could Have: Nice-to-have features that enhance the product but have a lesser impact on overall success. They are only implemented if all Must-Haves and Should-Haves are completed and there is still capacity.
• Won't Have: Requirements that will explicitly not be implemented in this project or phase. This clear demarcation helps maintain focus and manage expectations. Examples could include fully automated AI-based credit decisions, a voice interface, or an external chatbot, which might be desirable but are not part of the initial MVP.

This strict separation is particularly essential in banking. FINMA sets clear rules, and the nDSG requires careful handling of personal data. A "Must Have" here means that without this requirement, operations are not legal or secure. This creates an unambiguous priority list that is understandable to all stakeholders and forms the basis for successful project progress.

What compliance requirements are indispensable (Must-Haves) for Swiss SMEs in banking?

All regulatory requirements from FINMA and the nDSG are mandatory Must-Haves, as are core functions for business operations. In the Swiss financial sector, regulatory requirements are comprehensive and non-negotiable. For an SME in banking, this means that all aspects prescribed by the Swiss Financial Market Supervisory Authority (FINMA) and the new Swiss Data Protection Act (nDSG) must be classified as "Must Have" without any ifs or buts.

FINMA requirements cover a broad spectrum, from Anti-Money Laundering (AML) and adherence to risk management guidelines to IT security and outsourcing of services. An AI project in banking, for example, must ensure that all data processing complies with FINMA circulars on Operational Risks (OpRisk) or Corporate Governance. This means data provenance must be traceable, models must be transparent and explainable, and potential bias risks must be minimised. The responsibility for complying with these requirements clearly lies with the institution.

In parallel, the nDSG came into effect on 1 September 2023, significantly tightening requirements for the protection of personal data. For banks, this means, among other things:

• Data Protection by Design and by Default: Systems must be designed to ensure data protection from the ground up.
• Data Security: Appropriate technical and organisational measures to protect data are mandatory.
• Transparency and Information Obligation: Customers must be clearly and understandably informed about how their data is processed.
• Right to Access and Right to Erasure: These rights must be technically implementable.
• Notification Obligation in Case of Data Breaches: In the event of a data security breach, the Federal Data Protection and Information Commissioner (FDPIC) must be notified.

Each of these nDSG requirements is a "Must Have". An AI system, for instance, that analyses customer data for personalised offers must ensure that data can be anonymised or pseudonymised, that customer consent is obtained, and that they can exercise their rights at any time. Anyone compromising here risks not only hefty fines but also a massive loss of reputation.

In addition to regulatory requirements, functions that are absolutely indispensable for the core operations of banking business also count as "Must Haves". These include, for example, the stability of core banking systems, accurate transaction processing, and ensuring liquidity. If an AI project aims to optimise internal processes, then the objectives that directly contribute to operational efficiency and secure customer satisfaction should also be considered Must-Haves. The 15% reduction in Average Handling Time (AHT) and the 50% reduction in search time are prime examples from our practice, as they directly impact service quality and cost structure.

Why is the separation of mandatory (Must-Haves) and optional (Should/Could-Haves) crucial for the success of AI projects?

It ensures regulatory compliance, prevents resource waste, and enables a rapid market launch of a functional product. The clear distinction between what is absolutely necessary and what would be desirable is the linchpin for the success of any project, but especially for complex AI initiatives in regulated industries. Without this separation, teams get bogged down, budgets explode, and market launch is indefinitely delayed.

At its core, it's about defining a Minimum Viable Product (MVP) that delivers core functionality and, above all, meets compliance requirements. This is the first step in our release strategy. If a Swiss banking institution has 24 requirements for a new AI project in customer advisory, it's simply impossible to implement them all at once. In our practical example, the MoSCoW method allowed us to clearly divide the requirements: 17 Must-Haves, 6 Should-Haves, and 1 Could-Have. This focus enabled realistic planning.

Imagine trying to build everything at once. The team becomes overwhelmed, quality control suffers, and complexity increases exponentially. Every additional feature that isn't a "Must Have" ties up development time, testing capacity, and budget. If these resources are then missing to implement a critical nDSG requirement, the entire project is at risk. A Story Map, divided into themes, epics, and user stories, utilising the INVEST criteria, helps us to map these priorities in a structured way and maintain an overview.

Consistent prioritisation using MoSCoW forces all stakeholders to concentrate on the essentials. It creates transparency about which functions are absolutely necessary for go-live and which can be added later. This minimises the risk of developing an over-engineered product that is expensive, delayed, and perhaps not even compliant in the end. The early delivery of a functional and compliant MVP also builds trust with management and stakeholders, allowing for early feedback and iterative product development.

Furthermore, the MoSCoW method helps to explicitly name the "Won't Have" requirements. This may seem trivial but is crucial for avoiding misunderstandings and clearly defining scope. For example, if it's decided that an automated AI credit decision or an external chatbot interface will not be part of the initial project, then everyone knows that these resources are available for other, more important tasks. This saves not only development costs but also the time spent on discussions and redesigns.

The MoSCoW method is more than just a prioritisation tool; it's a mindset that embeds efficiency, compliance, and strategic focus in projects. Especially in Switzerland, where SMEs form the backbone of the economy and are simultaneously subject to strict regulations, this method is indispensable.

I, Lukas Huber, have repeatedly observed in my career: those who don't know their priorities will end up doing everything, but nothing properly. Especially in banking, where mistakes are costly and customer trust is paramount, you cannot afford to compromise on the "Must Haves".

Use the MoSCoW method to lay a solid foundation for your projects, optimise resource allocation, and ensure you deliver a product that is not only innovative but also meets all regulatory requirements. The success of your AI project largely depends on your readiness to clearly define and consistently pursue the essential.

✅ Focus on the Essentials: The MoSCoW method ensures you concentrate on the most critical requirements that are indispensable for project success and compliance.

✅ Risk Minimisation: By prioritising compliance requirements as "Must Haves", you significantly minimise legal and regulatory risks.

✅ Efficient Resource Utilisation: You avoid wasting resources on less important functions and optimally deploy your budget, time, and team.

Would you like to learn more about how to successfully prioritise your AI projects in a regulated environment? Talk to us.