Developing fintech software in Switzerland and the EU comes with challenges that most engineering teams have never had to deal with. Security concepts written before development starts. Infrastructure hosted on Swiss-certified financial cloud. nFADP data protection built in from the foundation.
The challenges are well known. What they look like in practice is not so. But not anymore.
At Modeso, we've been building fintech products since 2013, and we've seen how demanding it is. The five projects below are proof. Each one had to work inside the EU's financial infrastructure, under demanding regulatory constraints, without the option of meeting compliance later.
Look into every story — and our takeaways for each.
By 2020, TWINT was already the app millions of Swiss people used to split a restaurant bill, pay at the supermarket, or send money to friends. The next move was to go further: vouchers, partner deals, all inside the same app. But every new feature would ship to millions of people who trusted it with their money. That's not a comfortable place to experiment. But we were honored to start this project.
Every new feature had to pass a strict security review, stay stable under the kind of traffic that comes with a national campaign, and feel like it belonged in an app people use to handle their money.
Initially, we joined as a tech partner and have been building the marketplace layer ever since. Starting with a Digital Voucher module, we expanded into four more features: Super Deals, Storefinder, the Insurhub insurance integration, and Spin & Win. Each one had to meet Swiss nFADP data protection requirements, pass independent penetration testing, and follow OWASP security principles before anything went into the core app.
We built each marketplace feature as a separate unit with its own security approval, isolated from the core payment system. That way, if something broke, payments kept working. For example: Spin & Win handled 6 million spins, including bursts of thousands of simultaneous plays during campaigns. If something had gone wrong, it couldn't have touched the payment system.
Our partnership has grown from one module to five, and TWINT's overall transaction volume has grown with it: 773 million transactions in 2024, up from 590 million the year before.
Most teams adding features to an existing product connect them directly to the same codebase, via the same release cycle. This means the same things can go wrong together.
If you're building on top of a financial product people already rely on, ask this before you build anything: If this new feature breaks, what else breaks with it? The answer should be nothing.
Würth Financial Services had been selling insurance in Switzerland for 80 years. They knew their products and they knew their customers. Yet, they couldn’t reach the millions of people that open their phones to pay for things every day. TWINT could.
So Würth came to TWINT with an idea: let users browse, compare, and buy insurance policies within the payment app they already used. TWINT liked the idea and recommended Modeso to build it, since we had already worked together.
The challenge was time. TWINT's certification process (security reviews, compliance checks, penetration testing) normally pushes a launch timeline back by months. Würth needed to test whether the concept would actually attract users, which meant getting something live fast. We had three months from the first meeting to launch.
Insurhub — the name of the product — launched with six Allianz insurance products, designed to look and feel like the rest of the TWINT app. A backend connected Würth, TWINT, and the insurers so policies could be issued and tracked directly through the platform.
We'd already spent years building inside TWINT's platform before Insurhub came along. We knew what the security concept needed to contain, how the certification process worked, and where things usually stalled. That meant instead of figuring out the rules while trying to hit a deadline, we could just build.
If you're launching inside a regulated platform like TWINT, the certification process will take as long as it takes. What saves time is working with a team that has already been through it, so the learning curve isn't eating your deadline.
Private and institutional investors across Switzerland trust Albin Kistler to decide where to put their money. Behind its analysis is a legacy proprietary algorithm that pulls together 25 years of financial data.
All would be good, but the software running it was built in Microsoft Access by a small team who had left long since. The remaining team could run the system, but no one could trace how the calculations moved through the database tables.
Albin Kistler decided to replicate, improve, and move the algorithm to a web platform.
The stakes were high enough: the wrong move could break the core of their business.
The algorithm had no proper documentation, so we had to reverse-engineer it: go through the old system step by step and write everything down, until every developer on the project could follow the logic from the raw data inputs to the final output.
That process also changed how we ran the project. Once we understood how the algorithm worked, it was clear we couldn't build it incrementally: users needed to see the whole calculation engine running correctly before they could give any meaningful feedback. So we switched to a waterfall approach for the core algorithm, then moved back to agile once that foundation was solid and we were building the interface and additional features on top of it.
The rebuild also required connecting to three external systems:
None of them were straightforward. SIX apiD alone took significant time to get right. We had to work out exactly which data we were licensed to pull, from which markets, and within which timeframes, before we could build anything on top of it.
The platform went live in November 2023, following a soft launch and data migration in October. Here’s what the rebuild delivered:
The biggest risk in legacy modernization projects is losing track of how the old system actually worked while you're replacing it. We spent weeks reverse-engineering the algorithm before writing new code. Without that, we'd have ended up with a new black box instead of the old one.
If you're modernising a system where the business logic is critical, start by asking: does anyone still fully understand how this works? If the answer is no (or not entirely), that's where the project actually begins. The code comes after.
Michael Schwander had spent years as an auditor watching accountants deal with the same problem: preparing annual financial statements in Excel, manually, with no safety net. Plenty of accounting software existed, but most of it was built for large firms and too complex for smaller practices. Michael decided to build something that filled that gap and came to us with the concept for Aumico.
The first version was deliberately simple. Accountants could import data from an Excel file and turn it into a PDF report. The layout had issues, some features didn't work perfectly, but that was the point. We needed to get something in front of real users fast to learn what actually mattered before building more.
We gathered feedback, iterated, and kept building. Not every call was right. For example, a cash flow statement feature turned out to be unnecessary for most customers. It’s not a legal requirement for the majority of Swiss accounting firms, so almost nobody used it.
On the other hand, users were far more particular about the final report layout than we expected. Minor alignment issues that we thought they'd overlook were dealbreakers. The finished document had to be flawless, even if the process getting there had rough edges.
Those feedback loops shaped everything: language options, customisation tools, collaboration features for accounting teams, integrations with major accounting systems including Bexio, Abacus, and Xero.
Aumico launched in a market where accountants had been making do with Excel for years. Two years later, it had become the tool they switched to.
We built the cash flow feature. Almost nobody used it. Meanwhile, something we didn't think was essential became a must-have for accountants — collaborative editing. The only way we found that out was by putting something in front of users early enough that we could still change course.
If you're building a product from scratch, launch something imperfect early. The people you're building for will tell you what matters. That's worth more than any amount of upfront planning.
Auditing is legally serious work: if an audit is later found to be incorrect during a regulatory check, the firm bears the responsibility. That means every step of the process needs to be documented, guided, and traceable. Rietmann & Partner, which has been doing audits in Switzerland since 1911, looked at everything available on the market. Nothing came close to handling that properly. Most tools were either too generic, too rigid, or built for entirely different regulatory contexts.
So they came to us to build something from scratch.
To see how auditing actually worked, we ran a series of workshops with Rietmann & Partner's auditors — people who’d use the system every day. We looked into what decisions auditors made at each stage, what rules governed those decisions, and where the current manual process created the most risk. That groundwork shaped everything.
The system we built is rule-based: auditors are guided from uploading balance sheets through to generating the final report. Predefined rules flag issues along the way. Different roles (auditors and lead auditors) see and can edit only what's relevant to them.
The system replaced a process that had been running on spreadsheets and institutional memory for years. Rietmann & Partner's auditors now move through every stage of an audit using a single guided tool, from the first document upload to the final report. New auditors can follow the same process from day one, without needing someone to walk them through it.
And because the architecture is multi-tenant with rules configured per client, the same system works across Swiss, German, and international auditing standards.
Every professional process has logic that's invisible until you sit with the people doing it. Rietmann & Partner's auditors knew where things fell through the cracks in the old process. We just had to ask before we started building.
If you're digitising a process that carries regulatory weight, start with the people doing the work, not the requirements document.
If you're somewhere in the middle of a similar project — or trying to figure out whether it's even the right move — these cases are the closest thing we have as an answer to what it takes to build EU-compliant software.
With 90+ projects under our belt, we know what it's like to deal with strict regulations in fintech. We also work as full-cycle partners, which means we take full responsibility for the solution from strategy to delivery.
If it would help to talk through your specific situation, that's something we're happy to do.
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
