Most banking apps are static.

Ours adapts to you in real time — and it just won an international hackathon.

The epic moment : We won the callenge.

What happens when you stop designing one interface for everyone, and let AI design the right one for each person?

This project won the first edition of the Sofinco France Hackathon 2026 🏆 — here’s everything we built, why we built it, and what we learned.

Every banking app looks the same. You open it, you see a dashboard. Maybe a balance, some recent transactions, a navigation bar at the bottom. Whether you’re 24 or 74, whether you can see perfectly or not at all, whether you’re a credit expert or someone who just needs to check if they have enough for groceries, the app doesn’t care. It shows you the same thing.

That’s the problem we decided to solve.

The architecture: a Context Engine.

The initial insight was that : banking apps have enormous amounts of data about their users and do almost nothing with it at the interface level. Recommendations exist, sure,but they live in push notifications nobody really reads. The interface itself? Static. Identical for all. I thought that was a design failure worth solving.

At the core of the system is what we call the Context Engine — a cloud-based AI module that continuously reads contextual signals (time, location, ambient light, user behaviour, voice input) and translates them into an interface configuration decision. It then selects the appropriate modules from a pre-built Feature Bank ; a catalogue of “54 validated banking components” (a projected initial amount of componenets necessary) — and assembles them into the right interface for that user, in that moment.

The key design principle: the AI never generates interface elements. It selects from a pre-approved catalogue. That’s what makes this viable in a regulated banking context — predictable, auditable, compliant.

We agreed as a team to frame the project around Sofinco —the Hackathon organiser and a French consumer credit specialist with a strong mobile product. That was a perfect canvas. We adopted a Design Thinking methodology together, and we aligned on three target user profiles: a young digital native, an elderly user, and a visually impaired user. Once the direction was set, the decentralised the work and I took ownership of the technical and design architecture.

The interface is no longer designed once for all. It evolves IN REAL TIME with the user.

To document the system rigorously, I adopted UML 2.5 as my formal modelling language and produced three complementary diagram types, each capturing a distinct dimension of the architecture. The Sequence Diagram was my primary tool for communicating dynamic behaviour — it traces the exact message exchange between actors (User, Mobile App, Voice Interface, AI Engine, Bank Backend, and Database) across time, making it possible to see precisely how a voice credit request travels through the system, step by step, from the user’s utterance to the adaptive interface response. This diagram was essential for validating the logic of the Context Engine’s decision loop and identifying where latency could accumulate.

The Sequence Diagram for communicating dynamic behaviour

The Deployment Diagram served a different purpose: it grounded the architecture in infrastructure reality. I mapped each component — the mobile app on the user’s smartphone, the API Gateway, AI Engine, and Voice Processing Service in the cloud layer, and the Core Banking System and transaction database on the bank’s own servers — onto their physical and logical nodes, with communication protocols documented between them. This diagram was critical for communicating to the jury that the system was not just a design concept but an architecturally sound solution deployable on real infrastructure.

The Deployment Diagram grounding the architecture in infrastructure reality

Finally, the Activity Diagram — functioning as the system’s master workflow which captured the full adaptive decision process from application launch through AI analysis, accessibility detection, interface generation, and user interaction. Unlike the Sequence Diagram, which focuses on who talks to whom, the Activity Diagram focuses on what the system decides and when, making the branching logic of the Context Engine explicit: the exact point where the system determines whether to activate Standard, Elderly, or Voice-First mode, and how each branch propagates through to the rendered interface.

Together, they formed a coherent technical narrative: the Deployment Diagram shows where things live, the Sequence Diagram shows how they communicate, and the Activity Diagram shows how the AI decides.

What it actually “sounds” like.

Let me walk you through three concrete scenarios that we demonstrated at the hackathon.

Scenario 1 — Voice command : A user says: “I need to finance a project.” The NLP engine detects a credit intent. The dashboard instantly reconfigures: the Credit Simulator, Personalised Offers, and Instalment Payment modules rise to the top. The user never had to navigate anywhere.

Scenario 2 — Elderly user : The system detects from the user profile and navigation behaviour that this is an elderly user. Without any settings change by the user, the interface switches: font size increases to 18pt+, contrast ratio hits 7:1, the 14-widget dashboard reduces to 3 large buttons — Balance, Credit, Pay. No friction. No opt-in required.

Scenario 3 — Visually impaired user : The app detects VoiceOver/TalkBack is active. The interface shifts to Voice-First mode: a large “tap to speak” area, a waveform animation during listening, a spoken response read aloud. Full banking by voice. No visual dependency.

1. Context Sensing : Collects device signals — time, location, ambient light, motion, voice input.
2. Context Modelling : Builds a dynamic User Context Model — user type, financial state, intent, accessibility flags.
3. Adaptation Decision : Hybrid rule-based + ML model selects which Feature Bank modules to surface and how to rank them.
4. Interface Generation : Renders the personalised interface from the configuration spec, with smooth adaptive transitions.

The responsible AI question !

We thought hard about this. Every AI recommendation in the system comes with an explanation: “Based on your recent activity.” Users can override any adaptation. All data process requires explicit GDPR consent. The recommendation models are designed to avoid bias by excluding protected demographic characteristics from credit-related decisions.

Transparency and user control aren’t afterthoughts here. They’re structural properties of the system.

What this taught me ?

The biggest insight isn’t technical. It’s philosophical. We’ve been designing apps as fixed objects for decades; you design one thing, you ship it to everyone. This project showed that the app can be a system that generates the right experience for each person. That’s a different design problem entirely, and a more interesting one.

Building this alone from the initial concept through to the architecture, the prototype, the UML models, and the pitch taught me that the hardest part of designing an intelligent system isn’t the intelligence. It’s the constraints. Banking is regulated. Users are diverse. Data is sensitive. The Feature Bank idea came directly from asking myself: how do I make this adaptive without making it unpredictable? That tension shaped every decision I made.

We won the hackathon because the jury saw something they hadn’t seen before: not a prettier banking app, but a smarter one. An interface that treats each user as an individual. I built that. And I’m proud of it.

We’re just at the beginning of what adaptive interfaces can do. But winning the Sofinco Hackathon 2026 confirmed one thing clearly: the industry is ready for this shift. If you’re working on adaptive interfaces, personalisation in regulated industries, or accessible AI systems — I’d love to connect.

Groupe picture during the presentation infront of the jury and investors. (I’m holding the teams destiny in my hand lol)